ทดสอบการเชื่อมต่อพอร์ต UDP


37

ฉันพยายามที่จะทดสอบว่าฉันสามารถไปที่พอร์ตเฉพาะบนเซิร์ฟเวอร์ระยะไกล (ทั้งที่ฉันสามารถเข้าถึง) ผ่าน UDP

เซิร์ฟเวอร์ทั้งสองหันเข้าหาอินเทอร์เน็ต ฉันใช้ netcat เพื่อฟังพอร์ตที่แน่นอน

ฉันใช้ nmap เพื่อตรวจสอบพอร์ตนั้นเพื่อดูว่าเปิดอยู่หรือไม่ แต่ดูเหมือนจะไม่เป็นเช่นนั้น

Iptables ถูกปิด

ข้อเสนอแนะใด ๆ ว่าทำไมถึงเป็นเช่นนี้? ในที่สุดฉันจะตั้งค่าอุโมงค์ VPN แต่เนื่องจากฉันใหม่กับอุโมงค์มากฉันต้องการตรวจสอบให้แน่ใจว่าฉันมีการเชื่อมต่อบนพอร์ต UDP 1194 ก่อนที่จะล้ำหน้า


ฉันตอบคำถาม "การทดสอบการเชื่อมต่อพอร์ต UDP" แต่ฉันขอแนะนำให้จดจ่อกับส่วนที่เฉพาะเจาะจงมากขึ้น "ตรวจสอบให้แน่ใจว่า OpenVPN ได้รับชิ้นส่วน UDP ของฉัน" ซึ่งสามารถทำได้อย่างง่ายดายโดยดูจากบันทึกของ OpenVPN
ลุ

คำตอบ:


46

ไม่มีสิ่งเช่นพอร์ต UDP "เปิด" อย่างน้อยก็ไม่ได้อยู่ในความรู้สึกที่คนส่วนใหญ่คุ้นเคยกับการคิด (ซึ่งเป็นการตอบคำถามแบบ "ตกลงฉันยอมรับการเชื่อมต่อของคุณ") UDP ไม่มีเซสชันดังนั้น "พอร์ต" (อ่าน: โปรโตคอล UDP ใน IP สแต็คของระบบปฏิบัติการ) จะไม่ตอบสนอง "ความสำเร็จ" ด้วยตัวเอง

พอร์ต UDP มีสองสถานะเท่านั้น: การฟังหรือไม่ ซึ่งมักแปลว่า "เปิดซ็อกเก็ตโดยใช้กระบวนการ" หรือ "ไม่มีซ็อกเก็ตเปิดอยู่" กรณีหลังควรตรวจจับได้ง่ายเนื่องจากระบบควรตอบกลับด้วยแพ็กเก็ตICMP ปลายทางที่ไม่สามารถเข้าถึงได้ที่มีรหัส = 3 (พอร์ตที่เข้าไม่ถึง) น่าเสียดายที่ไฟร์วอลล์จำนวนมากสามารถดร็อปแพ็กเก็ตเหล่านั้นได้ดังนั้นหากคุณไม่ได้รับสิ่งใดกลับมาคุณไม่ทราบว่าพอร์ตนั้นอยู่ในสถานะนี้หรือไม่ และอย่าลืมว่า ICMP นั้นมีเซสชั่นน้อยลงเช่นกันและไม่ทำการส่งสัญญาณซ้ำ: แพ็คเก็ตพอร์ตที่เข้าถึงไม่ได้อาจหายไปไหนก็ได้บนเน็ต

พอร์ต UDP ในสถานะ "กำลังฟัง" อาจไม่ตอบสนองเลย (กระบวนการรับฟังเพิ่งได้รับแพ็คเก็ตและไม่ส่งข้อมูลใด ๆ ) หรือสามารถส่งบางสิ่งกลับมาได้ (หากกระบวนการทำงานตามการรับและถ้ามันทำโดย ตอบสนองผ่าน UDP ไปยัง IP ผู้ส่งดั้งเดิม: พอร์ต) ดังนั้นอีกครั้งคุณไม่มีทางรู้แน่นอนว่ารัฐคืออะไรถ้าคุณไม่ได้อะไรกลับมา

คุณบอกว่าคุณสามารถควบคุมโฮสต์ที่รับได้: นั่นทำให้คุณสามารถสร้างโปรโตคอลของคุณเองเพื่อตรวจสอบความสามารถในการเข้าถึงพอร์ต UDP: เพียงแค่วางกระบวนการบนโฮสต์ผู้รับที่จะรับฟังพอร์ต UDP ที่กำหนดและตอบกลับ (หรือส่งถึงคุณ อีเมลหรือเพียงแค่คลั่งไคล้และunlink()ทุกอย่างในระบบไฟล์โฮสต์ ... อะไรก็ตามที่ทำให้คุณสนใจ)


คิดว่าฉันเข้าใจแล้ว ดังนั้น netstat บนเซิร์ฟเวอร์ที่มีพอร์ต udp ที่ฟังจะไม่แสดงรีโมตโฮสต์ ... เฉพาะ tcpdump เท่านั้นที่ควรแสดงรีโมตการร้องขอ?
ล็อค

ทั้ง netstat และ tcpdump มีความสามารถในการถ่ายโอนข้อมูลกับคุณซึ่งเป็นรูปแบบที่มนุษย์อ่านได้มากขึ้น ตรวจสอบรายละเอียด man page ของพวกเขา
ลุ

56

เพื่อทดสอบว่าพอร์ต UDP netcatมีการตอบสนองการใช้งาน

ตัวอย่างจากman page :

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.

แน่นอนว่าหากไฟร์วอลล์กำลังดำเนินการDROPซึ่งปกติแล้วเป็นกรณีที่ต้องจัดการกับเกตเวย์ที่ต้องเผชิญกับอินเทอร์เน็ตคุณจะไม่ได้รับการตอบกลับ ICMP


1
คำตอบนี้ให้ฉันเป็นเท็จบวกที่คำตอบของ Sasha แสดงสิ่งที่ฉันคาดหวัง
texas-bronius

@ เท็กซัส bronius ถ้าคุณมีการเข้าถึงเซิร์ฟเวอร์อื่น ๆ ก็อาจจะดีกว่าการทำวิธีของ Sasha
motobói

27
  1. ทั้งบนไคลเอ็นต์และเซิร์ฟเวอร์ติดตั้ง nc: yum install nc(สำหรับ centos)
  2. บนเซิร์ฟเวอร์ฟังพอร์ต UDP: nc -ul 6111
  3. บนลูกค้า nc -u <server> 6111
  4. พิมพ์อะไรก็ได้บนไคลเอนต์และกด Enter - คุณควรเห็นข้อความนี้บนเซิร์ฟเวอร์

หมายเหตุ:เมื่อคุณรันnc -ulคำสั่งบนเซิร์ฟเวอร์คำสั่งนั้นจะเชื่อมต่อเฉพาะการเชื่อมต่อครั้งแรกเท่านั้น nc -ulคุณไม่สามารถที่ผมพบสลับระหว่างเซิร์ฟเวอร์กระตุกได้โดยไม่ต้องหยุดและรีสตาร์ท ในความเป็นจริงถ้าคุณ ^ C หยุดไคลเอ็นต์ ( nc -u ...) คุณจะไม่สามารถรีสตาร์ทไคลเอนต์ได้โดยไม่ต้องเริ่มฟังเซิร์ฟเวอร์ก่อน


1
ฉันชอบคำตอบที่ฉลาดนี้เพราะมันดึงเอาความเข้าใจของฉันเอง (และความเข้าใจผิด!) ว่า UDP นั้นคือ "ส่งและลืม" และการยืนยันทั้งหมดจะได้รับจากการตั้งค่าที่เหมาะสมเท่านั้น ปัจจัยมากเกินไป การตอบกลับนี้ให้การโทรและการตอบรับที่เรียบง่ายและชัดเจนซึ่งไม่สามารถใช้งานได้หรือไม่เปลี่ยนการตั้งค่าล้างและทำซ้ำ
texas-bronius

10

การทดสอบพอร์ต UDP แบบเปิดด้วย nmap นั้นเต็มไปด้วยอันตราย - ไม่มีการจับมือสามทางเพื่อบ่งบอกถึงความเปิดกว้าง ยกเว้นว่ากระบวนการรับฟังตอบสนองสิ่งที่ nmap ส่งไปไม่มีวิธีใดที่ nmap จะแยกความแตกต่างระหว่างพอร์ตเปิดที่ไม่ตอบสนองและพอร์ตกรอง

ง่ายกว่ามากคือการฟังที่ปลายด้านหนึ่งด้วย netcat และใช้ netcat ที่ปลายอีกด้านเพื่อส่งแพ็คเก็ตและดูว่ามันมาถึงปลายอีกด้าน ทำทั้งสองวิธีเพียงแค่ให้แน่ใจว่า คุณสามารถtcpdumpดูแพ็กเก็ตที่ไปถึงที่ที่พวกเขาต้องไป


ฉันเห็น .. ดังนั้น nmap จะรู้ได้อย่างไรว่าเปิดพอร์ตได้อย่างไร มันส่งข้อมูลไปยังพอร์ตนั้นหรือไม่และหากได้รับการตอบกลับจะถือว่าเปิดหรือไม่ ฉันจะใช้การรวมกันของ tcpdump และ netcat ขอบคุณสำหรับคำตอบที่อธิบายได้ดี
ล็อค

9

ฉันพบปัญหาที่คล้ายกันและพบวิธีแก้ปัญหาที่ดีโดยใช้ netcat ที่นี่: http://en.wikipedia.org/wiki/Netcat#Test_if_UDP_port_is_open:_simple_UDP_server_and_client

nc -vzu <host> <port>

ฉันสามารถยืนยันได้ว่าพอร์ต UDP เปิดอยู่และจากนั้นสามารถทำการทดสอบรหัสจริงของฉันได้



1

คุณสามารถทำได้ด้วยnetcat(nc) หรือiperfสมมติว่าคุณมีเครื่องอื่นที่จะทดสอบกับนอกเครือข่าย ตัวเลือกของฉันจะเป็นการnmapสแกน UDP จากระบบนอกสภาพแวดล้อมของคุณ บรรทัดคำสั่ง nmap ของคุณคืออะไร? มีไฟร์วอลล์ฮาร์ดแวร์หรืออุปกรณ์อื่น ๆ ผสมอยู่หรือไม่?


1

ฉันมีวิธีการที่เรียบง่าย หากเซิร์ฟเวอร์ UDP ไม่ส่งคืนข้อมูลที่คาดหวังฉันเพียงหยุดรวบรวม dgrams โดยสมมติว่ามันลงไป:

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;
    }
}
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.