คุณจำเป็นต้องใช้ DNS แบบไดนามิกสำหรับเซิร์ฟเวอร์ VPN ที่บ้านหรือไม่?

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

เงื่อนไขข้อแรก: ที่อยู่ของคุณย้ายที่จริง

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

วัดแทนการเดา อ่านที่อยู่ WAN บนหน้าสถานะของเราเตอร์ แล้วเทียบกับสิ่งที่โลกภายนอกเห็น รันคำสั่งนี้จากเครื่องใน LAN:

curl -fsS https://api.ipify.org; echo

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

เงื่อนไขข้อสอง: ไคลเอนต์ค้นชื่ออีกครั้ง

TTL สั้นคือส่วนที่คนข้ามไป ตัวแก้แบบเรียกซ้ำเคารพ TTL ของระเบียน แต่สแตกฝั่งไคลเอนต์แคชแยกกัน และอุโมงค์ที่ขึ้นอยู่แล้วก็ไม่แก้ไขอะไรใหม่ ระหว่างดีบักให้ตั้งระเบียนไว้ที่ 60-300 วินาที ซึ่งย่นหน้าต่างที่ให้คำตอบเก่า และไม่ได้ย้ายเซสชันที่เชื่อมต่ออยู่

OpenVPN แก้ไขบรรทัด remote vpn.example.net 1194 ใหม่ทุกครั้งที่เชื่อมต่อใหม่ และ resolv-retry infinite ทำให้มันลองใหม่แทนที่จะจบการทำงานเมื่อค้นหาไม่สำเร็จ บนเซิร์ฟเวอร์ float อนุญาตให้เซสชันที่สร้างแล้วติดตามเพียร์ที่ที่อยู่ต้นทางเปลี่ยนไป WireGuard ตรงกว่า: wg-quick up จะแก้ Endpoint เมื่อใช้การกำหนดค่า และไคลเอนต์จะแก้ใหม่เมื่อสร้างอุโมงค์ใหม่ ดังนั้นแฮนด์เชกที่ยังสำเร็จกับที่อยู่เดิมจะสำเร็จต่อไปจนกว่าจะหยุด

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

เงื่อนไขข้อสาม: เส้นทางขาเข้ายังเปิดอยู่

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

ทดสอบจากภายนอก โทรศัพท์บนข้อมูลมือถือที่ปิด Wi-Fi คือการทดสอบที่ซื่อสัตย์และถูกที่สุด ส่วนแล็ปท็อปใน LAN เดียวกันไม่ใช่ เมื่อชื่อแก้ไปที่ที่อยู่สาธารณะของคุณและเราเตอร์ไม่มี NAT ลูปแบ็ก การทดสอบจากข้างในจะล้มเหลวทั้งที่ระเบียนถูกต้องสมบูรณ์ และนั่นทำให้คนส่วนใหญ่ไปแก้ระเบียนที่ไม่เคยผิด

จะรันอะไรเมื่อทั้งสามข้อเป็นจริง

ddclient เป็นตัวอัปเดตที่สร้างความประหลาดใจน้อยที่สุดสำหรับโฮสต์เล็ก การกำหนดค่าขั้นต่ำเผยแพร่ที่อยู่ที่ผู้ให้บริการเห็น ซึ่งหลีกเลี่ยงความผิดพลาดของ NAT ซ้อน:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

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

ตรวจสอบก่อนผูกมัด

การค้นครั้งเดียวบอกคุณว่าโลกที่เหลือเห็นอะไร และพิมพ์ TTL ที่คุณต้องรอหลังการเปลี่ยนแปลง:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

เมื่อคำตอบคือไม่

หากเงื่อนไขข้อแรกหรือข้อสามล้มเหลว สิ่งที่เปลี่ยนคือการตัดสินใจไม่ใช่การกำหนดค่า เบื้องหลัง NAT ของผู้ให้บริการ ทางเลือกปฏิบัติของคุณคือขอที่อยู่สาธารณะจาก ISP ย้ายจุดเข้าไปยัง VPS เล็ก ๆ ที่มีที่อยู่คงที่ หรือใช้ชั้นซ้อนที่เก็บจุดนัดพบของตัวเอง หากที่อยู่คงที่ ให้ข้ามตัวอัปเดต ระเบียน A หนึ่งระเบียน ระเบียน AAAA หนึ่งระเบียนหากใช้ IPv6 การส่งต่อพอร์ตเดิม

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

ก่อนไปต่อ ให้ยืนยันสี่ข้อตามลำดับ:

• ที่อยู่ที่ตัวอัปเดตเผยแพร่ตรงกับที่อยู่ WAN ของเราเตอร์
• TTL ของระเบียนสั้นพอให้การเปลี่ยนแปลงปรากฏภายในไม่กี่นาที
• การส่งต่อพอร์ตผูกกับอินเทอร์เฟซ ไม่ใช่ที่อยู่คงที่
• ไคลเอนต์จริงหนึ่งตัวเชื่อมต่อใหม่และส่งทราฟฟิกผ่านตั้งแต่การเปลี่ยนแปลงครั้งสุดท้าย

หากทั้งสี่ข้อเป็นจริง ปล่อยการตั้งค่าไว้ตามเดิม ความล้มเหลวครั้งต่อไปของคุณคือกุญแจหรือกฎไฟร์วอลล์ ไม่ใช่ปัญหาการตั้งชื่อ หากข้อใดล้มเหลว ให้แก้บรรทัดนั้นก่อนเพิ่มชิ้นส่วนที่เคลื่อนไหวอีกชิ้น RFC 2136 อธิบายกลไกการอัปเดตเอง หากคุณอยากเห็นว่าดีมอนใส่อะไรลงบนสาย