Kiểm tra kết nối cổng UDP


37

Tôi đang cố kiểm tra xem tôi có thể truy cập vào một cổng cụ thể trên máy chủ từ xa không (cả hai đều có quyền truy cập) thông qua UDP.

Cả hai máy chủ đều phải đối mặt với internet. Tôi đang sử dụng netcat để có một cổng nghe nhất định.

Sau đó tôi sử dụng nmap để kiểm tra cổng đó để xem nó có mở không, nhưng nó không xuất hiện.

Iptables bị tắt.

Bất kỳ đề xuất tại sao điều này có thể được? Cuối cùng tôi sẽ thiết lập một đường hầm VPN, nhưng vì tôi rất mới với các đường hầm, tôi muốn đảm bảo rằng tôi có kết nối trên cổng UDP 1194 trước khi tiến lên.


Tôi đã trả lời câu hỏi "Kiểm tra kết nối cổng UDP". Nhưng tôi khuyên bạn nên tập trung vào phần "đảm bảo OpenVPN cụ thể hơn nhận được các gói UDP của tôi" - có thể dễ dàng đạt được bằng cách xem nhật ký OpenVPN.
Luke404

Câu trả lời:


46

Không có thứ gọi là cổng UDP "mở", ít nhất là không phải theo nghĩa mà hầu hết mọi người thường nghĩ (đó là trả lời một cái gì đó như "OK, tôi đã chấp nhận kết nối của bạn"). UDP không có phiên, vì vậy "một cổng" (đọc: giao thức UDP trong ngăn xếp IP của hệ điều hành) sẽ không bao giờ tự đáp ứng "thành công".

Cổng UDP chỉ có hai trạng thái: nghe hay không. Điều đó thường có nghĩa là "có một ổ cắm mở trên nó theo một quy trình" hoặc "không có bất kỳ ổ cắm nào mở". Trường hợp sau phải dễ dàng phát hiện do hệ thống sẽ phản hồi với gói Không thể truy cập đích của ICMP với mã = ​​3 (Cổng không thể truy cập được). Thật không may, nhiều tường lửa có thể làm rơi các gói đó, vì vậy nếu bạn không nhận lại được bất cứ điều gì, bạn không biết chắc là cổng có ở trạng thái này hay không. Và đừng quên rằng ICMP cũng không có phiên và không thực hiện truyền lại: gói Không thể truy cập cổng rất có thể bị mất ở đâu đó trên mạng.

Một cổng UDP ở trạng thái "nghe" hoàn toàn không thể phản hồi (quá trình nghe trên nó chỉ nhận được gói và không truyền bất cứ thứ gì) hoặc nó có thể gửi lại một cái gì đó (nếu quá trình này hoạt động khi nhận nếu nó hoạt động phản hồi qua UDP cho IP người gửi ban đầu: cổng). Vì vậy, một lần nữa, bạn không bao giờ biết chắc trạng thái là gì nếu bạn không nhận lại được gì.

Bạn nói rằng bạn có thể kiểm soát máy chủ nhận: điều đó giúp bạn có thể xây dựng giao thức của riêng mình để kiểm tra khả năng tiếp cận cổng UDP: chỉ cần đặt một quy trình trên máy chủ nhận sẽ lắng nghe trên cổng UDP đã cho trả lời lại (hoặc gửi cho bạn một email, hoặc chỉ là quái đản và unlink()mọi thứ trên hệ thống tệp máy chủ ... bất cứ điều gì sẽ kích hoạt sự chú ý của bạn sẽ làm).


Hãy nghĩ rằng tôi đang hiểu nó bây giờ. Vì vậy, một netstat trên máy chủ có cổng udp nghe sẽ không bao giờ hiển thị máy chủ từ xa ... Chỉ một tcpdump mới hiển thị các yêu cầu từ xa?
Khóa

Cả netstat và tcpdump đều có khả năng kết xuất dữ liệu về bạn, sau này ở dạng dễ đọc hơn. Kiểm tra trang người đàn ông của họ để biết chi tiết.
Luke404

56

Để kiểm tra xem cổng udp có phản hồi không, hãy sử dụng netcat.

Một ví dụ từ trang man :

nc -v -u -z -w 3 example.host 20-30
    Send UDP packets to ports 20-30 of example.host, and report which ones
    did not respond with an ICMP packet after three seconds.

Tất nhiên, nếu tường lửa đang hoạt DROPđộng, thường là trường hợp khi xử lý các cổng truy cập internet, bạn sẽ không nhận được phản hồi ICMP.


1
Câu trả lời này mang lại cho tôi một kết quả dương tính giả, trong đó, ngược lại, câu trả lời của Sasha thể hiện những gì tôi mong đợi.
texas-bronius

@ texas-bronius Nếu bạn có quyền truy cập vào máy chủ khác, có thể tốt hơn để thực hiện theo cách của Sasha
motobói

27
  1. cả hai trên máy khách ans máy chủ cài đặt nc: yum install nc(cho centos)
  2. trên máy chủ nghe cổng UDP: nc -ul 6111
  3. trên khách hàng nc -u <server> 6111
  4. nhập bất cứ thứ gì trên máy khách và nhấn enter - bạn sẽ thấy văn bản này trên máy chủ

Lưu ý: Khi bạn chạy nc -ullệnh trên máy chủ, nó sẽ chỉ kết nối cho kết nối đầu tiên đến với nó. Như tôi đã tìm ra, bạn không thể chuyển đổi giữa các máy chủ ping mà không dừng lại và khởi động lại nc -ul. Trong thực tế, nếu bạn ^ C dừng máy khách ( nc -u ...), bạn cũng không thể khởi động lại máy khách mà không khởi động lại trình nghe máy chủ.


1
Tôi thích câu trả lời thông minh này, bởi vì nó cung cấp những hiểu biết của riêng tôi (và những hiểu lầm!) Về cách UDP "gửi và quên" và tất cả xác nhận chỉ có thể được lấy từ cấu hình phù hợp. Quá nhiều yếu tố. Phản hồi này cung cấp một cuộc gọi và phản hồi thực sự đơn giản, dứt khoát, hoạt động hoặc không hoạt động, thay đổi cấu hình, rửa và lặp lại.
texas-bronius

10

Việc kiểm tra các cổng UDP mở bằng nmap có nhiều nguy hiểm - không có bắt tay ba bước để chỉ ra độ mở. Trừ khi quá trình nghe phản hồi với bất kỳ nmap nào gửi, không có cách nào để nmap phân biệt giữa một cổng mở không phản hồi và một cổng được lọc.

Dễ dàng hơn nhiều chỉ là nghe ở một đầu với netcat và sử dụng netcat ở đầu kia để gửi các gói, và xem chúng đến đầu kia. Làm cả hai cách chỉ cần chắc chắn. Bạn cũng có thể tcpdumpthấy các gói đến nơi cần đến.


Tôi hiểu rồi .. Vậy làm thế nào để nmap biết một cổng mở chính xác? Nó có gửi dữ liệu tới cổng đó không và nếu nhận được phản hồi, nó có được coi là mở không? Tôi sẽ sử dụng kết hợp tcpdump và netcat. Cảm ơn bạn đã giải thích tốt câu trả lời của bạn.
Khóa


2

Bạn có thể quét các cổng udp bằng cách sử dụng lệnh sau

nmap -sU -v <hostname or ip>

1

Bạn có thể làm điều này với netcat(nc) hoặc iperfgiả sử bạn có một máy khác để kiểm tra bên ngoài mạng. Lựa chọn của tôi sẽ là nmapquét UDP từ một hệ thống bên ngoài môi trường của bạn. Dòng lệnh nmap của bạn là gì? Có bất kỳ tường lửa phần cứng hoặc các thiết bị khác trong hỗn hợp?


1

Tôi có một cách tiếp cận đơn giản. Nếu máy chủ UDP không trả về dữ liệu dự kiến, tôi chỉ dừng thu thập các chương trình, giả sử nó đã bị hỏng:

LINE: while(1)
{
    my $line;
    my $flags;

    local $SIG{ALRM} = sub {die "exceeded timeout for recv"};
    alarm 5;
    eval {
        $socket->recv($line,2024,$flags);
    };

    unless($line =~ /\{.*\}/){
        if($verbose){
            print STDERR "Invalid or empty dgram:\n",'"', $line, '"',"\n";
        }

        last LINE;
    }
}
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.