เรกคอร์ด DDNS เก่าค้างกับจุดปลายทาง VPN ที่เสีย: แยกได้อย่างไร

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

ความล้มเหลวสองแบบที่ดูเหมือนกัน

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

ลำดับสำคัญที่นี่ การตรวจสอบ DNS ใช้เวลาหนึ่งนาทีและย้อนกลับได้ การสร้าง CA ใหม่ไม่ใช่ทั้งสองอย่าง

เทียบที่อยู่ก่อนสิ่งอื่นใด

ถามเจ้าของเครือข่ายว่าสายมีที่อยู่ใดอยู่ตอนนี้ แล้วถาม DNS ว่ามันเผยแพร่อะไร dig +short vpn.example.com ให้คำตอบที่ไคลเอนต์ของคุณจะได้รับ และ dig @1.1.1.1 vpn.example.com แสดงว่าตัวแปลงอื่นเห็นอะไรที่แตกต่างหรือไม่ ถ้าสองอย่างนี้ไม่ตรงกัน คุณกำลังดูพฤติกรรมแคช ไม่ใช่ตัวอัปเดตที่เสีย

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

ข้อมูลรับรองของตัวอัปเดตคืออะไรกันแน่

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

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

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

สิ่งที่การแก้ DNS ทำไม่ได้

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

ในทางกลับกัน การเปลี่ยนรหัสผ่าน VPN ไม่ใช่การแก้ไขสำหรับ DNS ที่เก่าค้าง มันเพียงเพิ่มความล้มเหลวที่สองให้กับตั๋วใบเดิม

เชื่อมต่อใหม่และพิสูจน์ให้ครบทั้งเส้นทาง

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

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