VPN บน UDP เงียบเมื่อสแกนพอร์ต? ทำไมจึงเกิดเช่นนี้
WireGuard และ OpenVPN ที่เสริมความแข็งแรงทิ้งดาต้าแกรมที่ผ่านการยืนยันตัวตนไม่สำเร็จโดยไม่ตอบกลับ ความเงียบจากสแกนเนอร์เป็นพฤติกรรมที่คาดไว้ ไม่ใช่พอร์ตที่ปิด
คุณสแกนพอร์ตของ VPN ไม่ได้รับคำตอบ แล้วสรุปว่าบริการล่มหรือไฟร์วอลล์ปิดอยู่ กับ WireGuard และกับช่องควบคุมของ OpenVPN ที่มีการยืนยันตัวตนของตัวเอง ข้อสรุปนั้นใช้ไม่ได้ ดาต้าแกรมที่ไม่มีการยืนยันตัวตนที่ถูกต้องจะถูกทิ้งโดยไม่มีการตอบกลับ ความเงียบจึงเป็นภาพของบริการที่แข็งแรงเมื่อมองจากภายนอก การตรวจนั้นผิดก่อนที่อุโมงค์จะผิด.
ความเงียบคือโปรโตคอล ไม่ใช่ความผิดพลาด
UDP ไม่มีการสร้างการเชื่อมต่อ จึงไม่มี SYN และไม่มีการตอบรับที่จะให้สแกนเนอร์แยกพอร์ตที่เปิดออกจากพอร์ตที่ถูกกรอง การตรวจมาถึงเป็นดาต้าแกรมเดี่ยว และบริการตรวจว่าตรงกับโปรโตคอลที่คาดไว้หรือไม่ เมื่อไม่ตรง แพ็กเก็ตจะถูกทิ้ง และการทิ้งคือพฤติกรรมที่บันทึกไว้ ไม่ใช่ความผิดปกติ
WireGuard ตรวจสอบข้อความแฮนด์เชกของตนด้วยวิธีเข้ารหัส และเพิกเฉยต่อทุกสิ่งที่ไม่ผ่าน OpenVPN ที่ใช้ tls-auth หรือ tls-crypt ก็ทำเช่นเดียวกันกับช่องควบคุมของตน ในทั้งสองกรณีเพย์โหลดใด ๆ ไม่เคยไปถึงขั้นที่หันหน้าสู่ผู้ใช้ จึงไม่มีอะไรให้ตอบกลับและไม่มีข้อผิดพลาดให้ส่งคืน
TCP จะให้การรีเซ็ตจากพอร์ตที่ปิดแก่คุณ UDP กลับทิ้งคุณไว้กับความกำกวม ซึ่งสแกนเนอร์แก้ด้วยการพิมพ์ว่าเปิดหรือถูกกรองแทนการเดา
สแกนเนอร์สรุปอะไรได้และสรุปอะไรไม่ได้
ผลการสแกนให้ข้อมูลได้เท่ากับเพย์โหลดที่ส่งออกไป จัดลำดับสิ่งที่สังเกตได้ตามสิ่งที่แต่ละอย่างสนับสนุนจริง:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
อ่านแถวที่สามเป็นเพียงการทดสอบเชิงบวกเดียวในรายการ ต้องใช้โปรไฟล์จริง กุญแจจริง และปลายทางที่ถูกต้อง ซึ่งเป็นสิ่งที่สแกนเนอร์ทั่วไปไม่มี
ดูทั้งสองปลายของเส้นทาง
สำหรับเซิร์ฟเวอร์ที่คุณดูแล ให้ดักจับที่อินเทอร์เฟซก่อนสรุปสิ่งใด แล้วถามบริการว่าเห็นอะไร ทั้งสองคำสั่งต้องใช้ root บนเกตเวย์:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showหากไม่มีแพ็กเก็ตปรากฏที่อินเทอร์เฟซ แสดงว่าเส้นทางทิ้งมันไปก่อนที่บริการจะเห็นอะไร และจุดต่อไปคือการกำหนดเส้นทางและการกรอง หากแพ็กเก็ตมาถึงแต่ไม่มีแฮนด์เชกใดสำเร็จ บริการเข้าถึงได้ และความไม่ตรงกันอยู่ที่กุญแจ การตั้งค่าปลายทาง หรือเวอร์ชันโปรโตคอล การเปรียบเทียบนั้นตอบคำถามที่สแกนเนอร์ตอบไม่ได้ รันมันขณะไคลเอนต์จริงกำลังพยายามเชื่อมต่อ ไม่ใช่ขณะสแกนเนอร์ทำซ้ำตัวเอง
เปลี่ยนการทดสอบ ไม่ใช่การป้องกัน
ทางลัดที่ชวนให้ทำคือปิดการป้องกันช่องควบคุมเพื่อให้การวินิจฉัยได้รับการตอบกลับ นั่นแลกคุณสมบัติความปลอดภัยจริงกับผลสแกนที่สวยกว่า และเป็นทิศทางที่ผิด ให้ใช้โปรไฟล์ที่ถูกต้องจากเครือข่ายที่ได้รับอนุมัติแทน และบันทึกปลายทางกับเวลาเพื่อให้การเปรียบเทียบทำซ้ำได้
การทดสอบที่มีประโยชน์ที่สุดคือการทดสอบเชิงอนุพันธ์: โปรไฟล์เดียวกันบนเส้นทางที่ทำงานและบนเส้นทางที่ไม่ทำงาน หากเส้นทางที่ทำงานสร้างแฮนด์เชกและเส้นทางที่ล้มเหลวไม่สร้างอะไรที่อินเทอร์เฟซ คุณก็ระบุตำแหน่งจุดขาดได้โดยไม่ทำให้อะไรอ่อนแอลง
ดังนั้นแพ็กเก็ต UDP ที่ไม่ได้รับการตอบกลับจึงไม่ได้พิสูจน์ว่าเซิร์ฟเวอร์ออฟไลน์หรือปลอดภัย มันพิสูจน์เพียงว่าการตรวจนี้ บนเส้นทางนี้ ในขณะนี้ ไม่ได้รับการยอมรับ