SoftEther หลัง NAT: ส่งต่อโดยตรงหรือรีเลย์ VPN Azure?

เซิร์ฟเวอร์ SoftEther ของคุณอยู่หลังเราเตอร์ของผู้ให้บริการที่คุณเปลี่ยนไม่ได้ และไคลเอนต์ยังเชื่อมต่อได้ คุณจึงสันนิษฐานว่ารีเลย์แบกทุกอย่างไว้ ข้อเท็จจริงขึ้นอยู่กับว่ากลไกใดทำงาน: ชื่อ DNS เส้นทาง UDP ที่ประสานกัน หรืออุโมงค์ขาออกไปยังรีเลย์ ทั้งสามแบบทำให้ไคลเอนต์เชื่อมต่อได้ และล้มเหลวในเงื่อนไขต่างกัน ตัดสินใจว่าคุณซื้อเส้นทางใดก่อนแตะผู้ใช้หรือฮับ

สามกลไก สามคำมั่นที่ต่างกัน

DNS แบบไดนามิกคือการตั้งชื่อ มันทำให้ชื่อโฮสต์ชี้ไปยังที่อยู่ที่เปลี่ยนได้ เพื่อให้ผู้คนเลิกไล่ตามตัวเลข และไม่ทำอะไรอื่น การข้ามผ่าน NAT แบบดั้งเดิมคือการประสานงาน: จุดปลาย SoftEther สองจุดแลกเปลี่ยนข้อมูลและพยายามเปิดเส้นทาง UDP ที่ใช้งานได้ผ่านอุปกรณ์แปลงที่อยู่ระหว่างกัน VPN Azure คือรีเลย์: เซิร์ฟเวอร์หมุนออกไปยังบริการ และไคลเอนต์มาถึงผ่านชื่อโฮสต์บนโครงสร้างพื้นฐานของรีเลย์

ทั้งสามเสริมกัน ไม่ใช่เวอร์ชันของฟีเจอร์เดียว การติดตั้งอาจใช้การตั้งชื่อ ขณะที่การเชื่อมต่อจริงขึ้นอยู่กับการข้ามผ่านหรือรีเลย์

ตัดสินใจจากไคลเอนต์และเครือข่าย

การเลือกเริ่มจากไคลเอนต์ เพราะการข้ามผ่านมีเฉพาะในกลไกการเชื่อมต่อดั้งเดิมของ SoftEther OpenVPN, L2TP/IPsec และตัวรับฟัง SSTP บนเซิร์ฟเวอร์เดียวกันไม่ได้รับมาด้วย แม้จะใช้โฮสต์ร่วมกัน ดูว่าผู้ใช้จะรันอะไร แล้วดูว่าเครือข่ายอนุญาตอะไร เครือข่ายองค์กรที่อนุญาตเฉพาะ TCP 443 จะผลักคุณไปยังรีเลย์บนพอร์ตนั้น ขณะที่เครือข่ายที่ปล่อยพอร์ต UDP ที่การข้ามผ่านต้องใช้สามารถลองเส้นทางตรงได้ ยืนยันทั้งสองกับนโยบายขาออกจริง

ตัวรับฟังที่เข้าถึงได้ด้วยมือยังเป็นการออกแบบที่ชอบธรรมเมื่อผู้ดูแลสามารถเผยแพร่ได้ แต่เป็นโครงการแยกต่างหากที่มีการกำหนดที่อยู่และงานไฟร์วอลล์ของตัวเอง

ยืนยันว่าเซสชันเลือกการขนส่งใด

สถานะการเชื่อมต่อเป็นแหล่งข้อมูลที่ซื่อสัตย์เพียงแหล่งเดียวของเส้นทางที่ใช้ อ่านบนเซิร์ฟเวอร์ และแปลงชื่อโฮสต์ที่ไคลเอนต์ได้รับ

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList แสดงว่าเซสชันใดเชื่อมต่ออยู่ และ SessionGet บนเซสชันหนึ่งรายงานประเภทการเชื่อมต่อ รวมถึงว่าเซสชันมาถึงผ่านรีเลย์หรือไม่ บันทึกที่แปลงไปยังโครงสร้างพื้นฐานของรีเลย์บอกคุณว่าเซสชันผ่านบุคคลที่สาม ซึ่งยืนยันได้โดยบล็อกเส้นทางนั้นในการทดสอบ ด้วยไคลเอนต์ดั้งเดิม การเร่ง UDP อาจย้ายเส้นทางข้อมูลออกจากเส้นทางควบคุม ดังนั้นการสังเกตครั้งเดียวไม่ได้อธิบายทั้งเซสชัน ชื่อ DNS แบบไดนามิกที่ล้าสมัยหลังการเปลี่ยนที่อยู่ และรีเลย์ที่ตอบกลับขณะที่เส้นทางไปยังแบ็กเอนด์หายไป เป็นโหมดล้มเหลวสองแบบที่ควรทดสอบแยกกัน บันทึกสิ่งที่คุณวัด ไม่ใช่สิ่งที่การออกแบบตั้งใจ

วางแผนว่าเส้นทางที่เลือกขึ้นอยู่กับอะไร

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

จดชื่อโฮสต์ โปรโตคอล การตั้งค่าฟีเจอร์ และการขนส่งที่สังเกตได้ บันทึกสี่ส่วนนั้นคือสิ่งที่ทำให้คนถัดไปสามารถสร้างการเชื่อมต่อที่ใช้งานได้ซ้ำ