ย้ายผู้ให้บริการ VPN: วางแผนชื่อโฮสต์ ไม่ใช่แค่ IP
ระเบียน DNS ใหม่ไม่ได้ย้ายเซสชันที่มีอยู่ วางแผนว่าใครควบคุมชื่อ แต่ละไคลเอนต์แก้ไขชื่อเมื่อใด และคุณจะปลดระวางปลายทางเก่าอย่างไร
ระเบียน DNS ของคุณถูกต้อง ตัวแทนทำงานปกติ แต่ไคลเอนต์บางตัวยังใช้เวลาหลายชั่วโมงหมุนหมายเลขที่อยู่เก่า บางตัวล้มเหลวทันทีกับชื่อที่แก้ไขได้แต่ไม่เคยตอบกลับ ผลลัพธ์ทั้งสองมาจากช่องว่างเดียว: ชื่อโฮสต์เปลี่ยนสิ่งที่ไคลเอนต์ค้นหา ไม่ใช่เวลาที่ค้นหา และไม่ใช่สิ่งที่เชื่อถือเมื่อคำตอบมาถึง
อาการ: ระเบียนถูกต้อง อุโมงค์เก่า
โปรไฟล์ที่เก็บชื่อไว้ไม่ใช่ไคลเอนต์ที่แก้ไขชื่อนั้นตลอดเวลา ส่วนใหญ่แก้ไขเพียงครั้งเดียวตอนใช้การกำหนดค่าหรือตอนที่อุโมงค์ขึ้น แล้วนำที่อยู่นั้นกลับมาใช้จนจบเซสชัน TTL ที่ยาวซ้อนอยู่ด้านบนคือเหตุผลที่ต้องวางแผนการเปลี่ยนผ่านรอบการเชื่อมต่อใหม่ ไม่ใช่รอบการแก้ไข DNS
ไม่มีพฤติกรรมใดเป็นการบกพร่อง และนั่นคือสิ่งที่ทำให้อาการสับสน ไคลเอนต์ทำงานจากคำตอบที่ได้มาก่อนหน้า และไม่มีสิ่งใดฝั่งเซิร์ฟเวอร์แสดงว่าคำตอบนั้นคืออะไร วางแผนการเชื่อมต่อใหม่ในหน้าต่างบำรุงรักษาและบอกผู้ใช้ว่าจะเห็นอะไร หรือใช้หน้าต่างนั้นตอบตั๋ว ปกติผลลัพธ์คือคิวของรายงานที่เหมือนกัน
ใครควบคุมชื่อ และไคลเอนต์ตรวจสอบอะไร
การควบคุมโซนเป็นตัวกำหนดว่าการย้ายจะเร็วแค่ไหน เก็บระเบียนไว้ที่ผู้ลงทะเบียนที่คุณเข้าสู่ระบบได้ และจดไว้ว่าใครอีกที่เปลี่ยนได้
ความเชื่อใจไม่ได้ตามชื่อไป ไคลเอนต์ที่ใช้ TLS อาจตรวจสอบตัวตนของใบรับรองหรือชื่อที่ปักหมุดไว้ ขณะที่ WireGuard ตรวจสอบคีย์สาธารณะของคู่ตรงข้ามและเพิกเฉยต่อชื่อโฮสต์ทั้งหมด ความแตกต่างนั้นเป็นตัวตัดสินว่าการแก้ไข DNS เพียงพอหรือทุกโปรไฟล์ต้องใช้ลายนิ้วมือใหม่ การเปลี่ยนระเบียนไม่ควรให้สิทธิ์ปลายทางที่ไม่มีใครอนุมัติ
เก็บการเข้าถึงเพื่อการดูแลและการกู้คืนให้ห่างจากชื่อไคลเอนต์สาธารณะ การสูญเสียบัญชีโฮสติ้งไม่ควรทำให้สูญเสียระเบียนที่เปลี่ยนเส้นทางไคลเอนต์ด้วย เก็บเส้นทางการกู้คืนไว้ที่ที่ไม่ขึ้นกับผู้ให้บริการที่คุณจากไป
เมื่อใดที่ไคลเอนต์แต่ละตัวอ่านชื่อใหม่
เวลาการแก้ไขชื่อเป็นคุณสมบัติของไคลเอนต์แต่ละตัว ดังนั้นตรวจสอบการใช้งานที่คุณส่งมอบจริงก่อนสัญญาหน้าต่างการเปลี่ยนผ่าน wg-quick แก้ไขปลายทางเมื่ออินเทอร์เฟซขึ้นและเก็บที่อยู่นั้นไว้จนกว่าอุโมงค์จะรีสตาร์ท ไคลเอนต์ OpenVPN ค้นหาชื่อเมื่อเชื่อมต่อ และจะดูอีกครั้งเมื่อเชื่อมต่อใหม่หรือไม่ขึ้นอยู่กับตัวเลือกของมัน
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
ไคลเอนต์มือถือคือความประหลาดใจปกติ เพราะอาจเก็บที่อยู่ที่แก้ไขแล้วข้ามการหลับหรือการเปลี่ยนเครือข่าย เผยแพร่ระเบียน A และ AAAA เฉพาะเมื่อตัวแทนตอบได้ทั้งสองตระกูล ที่อยู่ที่ตอบในตระกูลหนึ่งไม่ได้พิสูจน์อะไรเกี่ยวกับอีกตระกูล และระเบียน AAAA ที่ตายแล้วเพิ่มเวลาหมดอายุให้ทุกความพยายาม จัดทำเอกสารพฤติกรรมการแก้ไขชื่อสำหรับไคลเอนต์ทุกตัวที่คุณรองรับ แล้วทดสอบบนอุปกรณ์ที่ผู้คนใช้จริง
การเชื่อมต่อใหม่เป็นการกระทำของผู้ใช้ในไคลเอนต์ส่วนใหญ่ และเซิร์ฟเวอร์บังคับไม่ได้ ใส่ขั้นตอนนั้นไว้ในบันทึกการบำรุงรักษา พร้อมบรรทัดว่าผู้ใช้จะเห็นอะไรเมื่อเกิดขึ้น
เปลี่ยนผ่านด้วยหลักฐาน แล้วปลดระวางปลายทางเก่า
ก่อนสลับ พิสูจน์ทุกชั้นที่ตัวแทน: ตัวรับฟังตอบกลับ ไฟร์วอลล์เปิดพอร์ต เส้นทางกลับมาถูกต้อง ชื่อแก้ไขไปยังที่อยู่ใหม่ และตัวตนที่รู้จักได้รับการยอมรับ ตัวรับฟังที่รับการเชื่อมต่อไม่เหมือนกับตัวที่ทำแฮนด์เชคเสร็จ ดังนั้นทดสอบแฮนด์เชคไม่ใช่พอร์ต เก็บรายการเพิกถอนปัจจุบันไว้ข้างการกำหนดค่า เพราะข้อมูลสำรองที่กู้คืนจะสร้างรายการคู่ตรงข้ามใหม่ตามเดิมและจะเปิดการเข้าถึงที่คุณปิดไปแล้วอีกครั้ง บันทึกว่าคุณทดสอบด้วยตัวตนใด เพราะ «มันทำงานได้» ไม่ใช่หลักฐานที่ใครจะทำซ้ำได้
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesระหว่างการเปลี่ยนผ่าน เฝ้าดูความพยายามเชื่อมต่อที่ปลายทางทั้งสองสำหรับตัวตนเดียวกัน ไคลเอนต์ที่ยังตรวจสอบตัวตนกับที่อยู่เก่าคือโปรไฟล์หรือคำตอบที่แคชไว้ซึ่งไม่เคยย้าย การปลดระวางปลายทางเก่าตามแผนที่มีวันที่ เพราะสองบริการที่ยอมรับตัวตนเดียวทิ้งประตูสองบานไว้เปิด
การทดสอบการเปลี่ยนผ่านคือเซสชันแอปพลิเคชันผ่านปลายทางใหม่ ไม่ใช่ ping เมื่อเซสชันนั้นทำงานและปลายทางเก่าไม่บันทึกความพยายามที่ได้รับอนุญาตตลอดรอบการเชื่อมต่อใหม่เต็มรอบ การย้ายก็เสร็จสิ้น