WireGuard พีร์ออกผ่าน WAN ผิดฝั่ง: ห้าขั้นตอนตรวจตามลำดับ

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

ไล่ตรวจตามรายการด้านล่างตามลำดับ แต่ละข้อมีเงื่อนไขหยุด และการข้ามไปข้างหน้ามักให้คำตอบที่ผิดอย่างมั่นใจ

แยกแฮนด์เชกออกจากโฟลว์ที่ส่งต่อ

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

หยุดทันทีที่จับได้ว่าตัวเองกำลังให้เหตุผลจากแฮนด์เชก มันเป็นหลักฐานเกี่ยวกับเส้นทางไปยังปลายทางเท่านั้น

อ่านกฎนโยบาย ไม่ใช่ตารางเริ่มต้น

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

ตรวจเครื่องหมายและการแปลงไปพร้อมกัน

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

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

สังเกตว่าอินเทอร์เฟซใดรับคำตอบ

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

หากคำตอบมาทางอัปลิงก์ผิด ปัญหาได้ย้ายจาก WireGuard ไปสู่การติดตามการเชื่อมต่อหรือการแปลงแล้ว การเปลี่ยนการตั้งค่าพีร์จะไม่ช่วยแก้

เปลี่ยนเพียงหนึ่งอย่างโดยมีทางกลับ

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

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