ชื่อปลายทาง VPN กับชื่อบริการส่วนตัว: เจ้าของสองคน

สองชื่อสามารถอธิบายสาขาเดียวกันและตอบคำถามที่ต่างกันโดยสิ้นเชิงได้ vpn.branch.example บอกเพื่อนระยะไกลว่าปลายทาง VPN อยู่ที่ไหน และต้องถูกแปลงชื่อก่อนที่อุโมงค์ใดจะเกิดขึ้น inventory.branch.example บอกผู้ใช้ที่ได้รับอนุญาตว่าแอปพลิเคชันส่วนตัวอยู่ที่ใด และสำคัญเฉพาะเมื่ออุโมงค์เชื่อมต่อแล้ว การดูแลชื่อหนึ่งไม่ส่งผลใด ๆ ต่ออีกชื่อหนึ่ง

ตั้งชื่อระเบียนทั้งสองก่อนแก้ไขปัญหาใด ๆ

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

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

เมื่อมีการเสนอการเปลี่ยนแปลง ให้ถามว่าเกี่ยวข้องกับระเบียนใดในสองระเบียน ถ้าไม่มีใครตอบได้ การเปลี่ยนแปลงนั้นยังไม่พร้อมจะกำหนดเวลา

ปลายทางต้องถูกแปลงชื่อก่อนที่อุโมงค์ใดจะเกิดขึ้น

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

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

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

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

ชื่อบริการอธิบายว่าแอปพลิเคชันอยู่ที่ใด

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

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

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

ทดสอบทั้งสองเส้นทางแยกกัน

ตรวจสอบปลายทางจากนอกอุโมงค์และบริการจากภายใน และเก็บผลลัพธ์เป็นข้อเท็จจริงสองข้อที่เป็นอิสระต่อกัน:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

เรียกใช้คู่นี้หลังทุกการเปลี่ยนที่อยู่ และบันทึกว่าระเบียนใดเคลื่อนที่ การส่งมอบที่บอกเพียง «อัปเดต DNS แล้ว» ทำให้วิศวกรคนต่อไปต้องเดาว่าวงจรชีวิตใดในสองวงจรที่ทำงานจริง