IP ของ WAN เปลี่ยนและอุโมงค์หลุด: การตรวจตามลำดับ

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

ตั้งชื่อเหตุการณ์ก่อนอ่านบันทึก

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

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

การโรมมิ่งและการเชื่อมต่อใหม่เป็นโปรโตคอลที่ต่างกัน

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

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

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

สถานะที่อุโมงค์ไม่ได้เป็นเจ้าของ

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

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

เรียงลำดับการตรวจจากภายนอกเข้าภายใน

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

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

ตัดสินใจพฤติกรรมที่คาดหวังและเขียนไว้

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

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