ทำไมเซิร์ฟเวอร์ VPN ที่อยู่หลัง CGNAT จึงไม่รับการเชื่อมต่อเลย

เราเตอร์รายงานที่อยู่ WAN ที่ขึ้นต้นด้วย 100.72 ชื่อ DNS แบบไดนามิกแก้ไขไปยังที่อยู่สาธารณะอื่น และเซิร์ฟเวอร์ VPN บนเราเตอร์นั้นไม่เคยจับมือจากภายนอกได้สำเร็จ การส่งต่อพอร์ตกำหนดค่าไว้แล้ว บริการทำงานอยู่ และการทดสอบจาก LAN ยังใช้ได้ ไม่มีสิ่งใดในบันทึกของเราเตอร์ที่ดูเหมือนข้อผิดพลาด การรวมกันนี้คือ NAT ระดับผู้ให้บริการ และไม่มีกฎไฟร์วอลล์ใดเปิดพอร์ตบนที่อยู่ที่ ISP ถืออยู่ได้

การยืนยันที่อยู่ที่แชร์กันใช้เวลาสองนาทีและป้องกันการเปลี่ยนแปลงการกำหนดค่าหนึ่งสัปดาห์

สัญญาณที่บ่งชี้ถึง NAT ของผู้ให้บริการ

เปรียบเทียบที่อยู่ WAN ในหน้าสถานะของเราเตอร์กับที่อยู่ที่การค้นหาภายนอกรายงาน ที่อยู่ WAN ภายใน 100.64.0.0/10 เป็นสัญญาณปกติ และช่วงส่วนตัว 10/8, 172.16/12 และ 192.168/16 ก็หมายถึงสิ่งเดียวกัน หาก traceroute แสดงฮอปสาธารณะเดิมซ้ำ หรือฮอปช่วงต้นตอบด้วยที่อยู่ส่วนตัว แสดงว่ามีตัวแปลงอีกตัวอยู่ระหว่างเราเตอร์กับอินเทอร์เน็ต ISP บางรายแสดงที่อยู่ที่จัดสรรไว้เฉพาะในพอร์ทัลลูกค้า จึงส่งออกค่านั้นพร้อมกับ traceroute

การเปลี่ยนโปรโตคอลหรือพอร์ตไม่ช่วย เพราะปัญหาคือการเข้าถึงขาเข้า ไม่ใช่พอร์ตที่ปิด

ทำไมการส่งต่อและ DNS แบบไดนามิกจึงแก้ไขไม่ได้

กฎการส่งต่อพอร์ตแมปพอร์ตบนอินเทอร์เฟซ WAN ของเราเตอร์ แต่ทราฟฟิกขาเข้าไม่เคยไปถึงอินเทอร์เฟซนั้น: ISP แปลงก่อนแล้วส่งต่อเฉพาะสิ่งที่ตารางของตนเองอนุญาต การเผยแพร่ที่อยู่ที่แชร์กันใน DNS แบบไดนามิกจะชี้ไคลเอนต์ไปยังเกตเวย์ของ ISP ที่ผู้ใช้จำนวนมากใช้อยู่ จึงแก้ไขชื่อได้แต่การจับมือยังล้มเหลว การทดสอบ hairpin สำเร็จเพราะเราเตอร์ตอบกฎของตนเองจากภายใน และ UPnP ก็มีจุดบอดเดียวกันทุกประการ

การกำหนดค่าไคลเอนต์ใหม่ก็ไม่ช่วย เพราะความล้มเหลวเกิดขึ้นก่อนที่จะอ่านการตั้งค่าไคลเอนต์ใด ๆ

ส่งต่อผ่าน VPS พร้อมเส้นทางที่ชัดเจน

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

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

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

บรรทัด iroute บอก OpenVPN ว่าไคลเอนต์ใดได้รับทราฟฟิกสำหรับซับเน็ตบ้าน ส่วนบรรทัด route ใส่ซับเน็ตนั้นลงในตารางเคอร์เนลของ VPS เพื่อให้แพ็กเก็ตเข้าสู่อุโมงค์จริง สำหรับบริการที่เผยแพร่ ให้เพิ่มกฎ NAT ปลายทางที่ส่งต่อพอร์ตสาธารณะไปยัง 10.8.0.10 และเปิดใช้งาน net.ipv4.ip_forward

ทดสอบเส้นทางจากภายนอก

ตรวจสอบทุกฮอปทางฝั่งสาธารณะ เพราะอุโมงค์ที่สำเร็จไม่ได้พิสูจน์ว่าบริการเข้าถึงได้ สถานะการฟังและแคปเจอร์แพ็กเก็ตบน VPS แยก 'ไม่มีอะไรมา' ออกจาก 'มาแล้วถูกทิ้ง'

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

ทางเลือกที่ควรประเมินราคาก่อน

ที่อยู่ IPv4 เฉพาะจาก ISP เป็นวิธีที่สั้นที่สุดและมักเป็นค่าบริการรายเดือนเล็กน้อย IPv6 แบบเนทีฟขจัดการแปลที่ทั้งสองด้านเมื่อ VPN เครือข่ายไคลเอนต์และระเบียน DNS รองรับทั้งหมด เครือข่ายทับซ้อนแบบ mesh ที่มีเราเตอร์ซับเน็ตภายในเครือข่ายบ้านให้การส่งต่อแบบเดียวกันโดยไม่ต้องมี VPS แต่แลกกับการพึ่งพาบริการประสานงาน

เลือกการส่งต่อเมื่อข้อกำหนดคือการเข้าถึงขาเข้าที่เสถียรและทุกกฎต้องอยู่ภายใต้การควบคุมของคุณ เลือกที่อยู่ ISP เมื่องบประมาณเอื้ออำนวยและเป้าหมายคือเพียงเลิกคิดถึงเรื่องนี้