เราท์ติ้งแบบเรียกซ้ำ: เมื่ออุโมงค์ดักจับแพ็กเก็ตของตัวเอง

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

ตรวจสอบเส้นทางภายนอกก่อน

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

ทำไมเซสชันจึงอยู่ได้ชั่วขณะ

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

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

ค้นหาว่าใครเป็นเจ้าของข้อยกเว้นของปลายทาง

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

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

ตรวจสอบอีกครั้งหลังการเปลี่ยนเครือข่าย

เส้นทางโฮสต์ผ่านเกตเวย์ Wi-Fi ถูกต้องจนกว่าเครื่องจะย้ายไปยังเครือข่ายอื่น แล้วอาการเดิมก็กลับมาโดยไม่มีการเปลี่ยนแปลงการตั้งค่าเลย

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

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