ddclient ประกาศทางออกของ VPN: แก้ไขแหล่งที่มาของการค้นหา

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

ยืนยันว่าชื่อควรเข้าถึงอะไร

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

ชื่อส่วนตัวสำหรับที่อยู่ tunnel ของไคลเอนต์ VPN เป็นปัญหาอีกแบบที่มีคำตอบอีกแบบ คือมันอยู่ใน DNS ส่วนตัว และไม่ต้องการบริการค้นหาสาธารณะเลย การผสมข้อกำหนดทั้งสองเข้าด้วยกันคือวิธีที่การกำหนดค่าที่ใช้งานได้เริ่มประกาศที่อยู่ที่ไม่มีใครขอ

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

ทำซ้ำค่าก่อนเปลี่ยนสิ่งใด

สังเกตเส้นทางทั้งสองแยกกัน เมื่ออุโมงค์ทำงาน โพรบรายงานทางออก เมื่ออุโมงค์ปิด หรือเมื่อผูกโพรบกับอินเทอร์เฟซทางกายภาพ มันจะรายงานที่อยู่ที่บ้าน: curl --interface eth0 https://ifconfig.me. หากคำตอบทั้งสองต่างกัน คุณได้ทำซ้ำข้อบกพร่องโดยไม่แตะตัวอัปเดต

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

ชี้การค้นหาไปยังเส้นทางที่เลือก

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

สำหรับเส้นทางสถานะเราเตอร์ ddclient รุ่นใหม่ใช้กลุ่มตัวเลือก usev4 และ fwv4 พร้อมรูปแบบข้ามสำหรับข้อความรอบหน้าเว็บ ตรวจสอบ README สำหรับเวอร์ชันที่ติดตั้ง เพราะรุ่นเก่าเขียนแนวคิดเดียวกันด้วย use และ fw และชื่อตัวเลือกที่คัดลอกจากรุ่นผิดจะล้มเหลวตอนเริ่มทำงาน

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

เก็บความลับและเวอร์ชันให้เป็นระเบียบ

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

ddclient README อธิบายแนวทางการค้นหาและชื่อตัวเลือกของมัน อย่าผสมผลลัพธ์ IPv4 และ IPv6 ในบันทึกเดียว และอย่าสมมติว่าตัวเลือกที่มีในรุ่นหนึ่งจะมีในอีกรุ่น

ตรวจสอบค่า แล้วจึงตรวจสอบการเข้าถึง

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

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