หลังการเปลี่ยนแปลง DNS แล้ว WireGuard ยังใช้ปลายทางเดิมอยู่

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

ชื่อถูกแปลงครั้งเดียว ไม่ใช่ต่อเนื่อง

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

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

เปรียบเทียบระเบียนกับที่อยู่ที่ใช้อยู่

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

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

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

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

รีสตาร์ตผ่านตัวจัดการของอินเทอร์เฟซ

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

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

แฮนด์เชกก่อน แล้วจึงเป็นเส้นทางข้อมูล

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

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