IP สาธารณะเปลี่ยนแล้ว VPN หยุดส่งผ่านทราฟฟิก

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

ทำการตรวจทั้งสี่ตามลำดับและหยุดที่ข้อแรกที่ล้มเหลว

ที่อยู่ใดเปลี่ยนไปจริง

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

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

ให้โปรโตคอลจัดการการย้ายที่

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

ล้างการผูกภายนอกที่ค้างอยู่

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

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

ทดสอบซ้ำด้วยคำขอใหม่

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

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

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