วิธีแยกแยะลูปรูตติ้งกับเส้นทางที่กระพริบในไซต์ VPN
ลูปรูตติ้งและเส้นทางที่ไม่เสถียรทำให้เกิดการสูญหายเป็นช่วงๆ แบบเดียวกัน การตรวจสามข้อที่เกตเวย์แยกสองสิ่งนี้ออกก่อนที่คุณจะเปลี่ยนอะไร
สองไซต์ อุโมงค์หนึ่งเส้น และคำนำหน้าปลายทางระยะไกลที่ตอบสนองชั่วขณะแล้วเงียบไป ปฏิกิริยาแรกคือเรียกมันว่าลูปรูตติ้ง และบางครั้งก็เป็นเช่นนั้นจริงๆ แต่ลูปกับเส้นทางที่กระพริบให้ข้อร้องเรียนเดียวกันและต้องการการซ่อมที่ตรงกันข้าม อย่างหนึ่งคือการตัดสินใจส่งต่อที่ไม่สิ้นสุด อีกอย่างคือคำนำหน้าที่ออกจากตารางอยู่ตลอด สามข้อสังเกตแยกสองสิ่งนี้ออก และคุณเก็บทั้งสามได้จากบรรทัดคำสั่งของเกตเวย์ก่อนแตะฟิลเตอร์หรือรีสตาร์ทอุโมงค์
ลูปตัดสินใจทีละฮอป ไซต์ A เลือก B เป็นฮอปถัดไปสำหรับปลายทาง B เลือก A สำหรับปลายทางเดียวกัน และแพ็กเก็ตหมดอายุที่ TTL หลังการเดินทางไปกลับสองรอบ ส่วนการกระพริบนั้นโปรโตคอลรูตติ้งเป็นตัวตัดสิน คำนำหน้าถูกถอนออก ติดตั้งใหม่ หรือแทนที่ด้วยฮอปถัดไปทางเลือก ดังนั้นบางแพ็กเก็ตไม่มีเส้นทางเลย ในขณะที่แพ็กเก็ตอื่นเดินตามเส้นทางที่ดีสมบูรณ์
การตรวจสามข้อที่ชี้ขาดคำถาม
คุณไม่ต้องดักแพ็กเก็ตสำหรับการตัดสินครั้งแรก คุณต้องมีสถานะของคำนำหน้าทั้งสองด้าน ฮอปถัดไปที่แต่ละฝั่งเลือก และจำนวนฮอปที่ซ้ำหรือไม่ซ้ำ หากคำนำหน้ายังติดตั้งอยู่ด้วยฮอปถัดไปเดิมขณะที่ทราฟฟิกล้มเหลว แสดงว่าลูปอยู่ในเส้นทางส่งต่อ หากคำนำหน้าหายไปแล้วกลับมา แสดงว่าข้อบกพร่องอยู่เหนือการส่งต่อ และการซ่อมเป็นของโปรโตคอลรูตติ้ง ไม่ใช่เส้นทางแบบคงที่
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
คำเตือนหนึ่งข้อก่อนเริ่ม หากคุณอ่านสิ่งนี้ผ่านอุโมงค์ที่กำลังลูป เซสชันของคุณจะตายในทันทีที่คุณเปลี่ยนเส้นทาง เปิดคอนโซลหรือเส้นทางบริหารที่ไม่ขึ้นกับคำนำหน้าที่คุณกำลังจะซ่อม
การตรวจข้อแรก คำนำหน้ามั่นคงหรือกำลังเดือด
ถามเคอร์เนลว่าได้ติดตั้งอะไร ไม่ใช่ถามว่าไฟล์กำหนดค่าสัญญาอะไร บนเกตเวย์ลินุกซ์ ip route get 10.20.30.40 ทำงานค้นหาเดียวกับที่เส้นทางส่งต่อทำ รวมถึงตารางนโยบาย ขณะที่ ip route show 10.20.30.0/24 แสดงรายการเอง ip monitor route สตรีมทุกการเปลี่ยนแปลงในขณะที่เกิดขึ้น ซึ่งเป็นวิธีที่เร็วที่สุดในการดูคำนำหน้าเข้ามาและจากไป
บนเราเตอร์ที่รัน FRR หรือ BIRD ตารางส่งต่อไม่ใช่สิ่งที่น่าสนใจ show ip bgp 10.20.30.0/24 คืนเส้นทางที่เลือกและเวลาทำงานของมัน เวลาทำงานที่รีเซ็ตทุกสองสามนาทีคือการกระพริบที่คุณตั้งชื่อได้ ไม่ใช่ลูป show ip bgp summary แสดงสถานะเพื่อนบ้านและจำนวนคำนำหน้า ดังนั้นเพื่อนที่ล้มอยู่ตลอดจึงยกความผิดออกจากเส้นทางส่งต่อ
จดคำตอบไว้ก่อนเปลี่ยนอะไร ความมั่นคงสิบนาทีขณะที่ปิงล้มเหลว และการหายไปสี่ครั้งในสิบนาทีนำไปสู่ขั้นตอนถัดไปที่ต่างกัน กรณีหลังทำให้ทฤษฎีเส้นทางคงที่ทั้งหมดไม่เกี่ยวข้อง
การตรวจข้อสอง ฮอปถัดไปชี้กลับเข้าอุโมงค์ขาเข้าหรือไม่
ลูปต้องให้เกตเวย์สองตัวเห็นตรงกัน บนไซต์ที่รับแพ็กเก็ต ให้ดูเส้นทางที่แพ็กเก็ตจะใช้ออกไป ip route get 10.20.30.40 from 10.10.5.20 พร้อมที่อยู่ต้นทางจริง เพราะกฎนโยบายอาจตอบต่างจากตารางหลัก จากนั้นทำการค้นหาซ้ำบนไซต์ที่ส่งมันมา หากแต่ละฝั่งเลือกอีกฝั่งเป็นฮอปถัดไปสำหรับคำนำหน้าเดียวกัน แสดงว่าลูปได้รับการพิสูจน์ และการดักแพ็กเก็ตใดๆ จะไม่เพิ่มอะไร
สาเหตุเกือบทุกครั้งคือ ประกาศที่ไม่ควรข้ามอุโมงค์ เส้นทางเริ่มต้นที่กระจายซ้ำเข้าไปในอุโมงค์ กลุ่มที่ครอบคลุมซับเน็ตของไซต์ระยะไกลเอง หรือเส้นทางคงที่ที่ชี้ไปยังคู่ค้าเพื่อความปลอดภัย ล้วนสร้างฮอปถัดไปซึ่งกันและกันแบบเดียวกัน อุโมงค์อาจสร้างเสร็จสมบูรณ์และยังพาทราฟฟิกวนเป็นวงกลม บันทึกเรื่องการส่งต่อของ strongSwan อธิบายด้านรูตติ้งของข้อกำหนดนั้น
WireGuard สมควรมีบันทึกของตัวเอง เพราะไม่มีประกาศให้โทษ wg show แสดงรายการ AllowedIPs ของแต่ละคู่ค้า และเคอร์เนลยอมรับปลายทางสำหรับคู่ค้าเฉพาะเมื่อมันอยู่ในช่วงนั้น ลูปตรงนั้นคือช่วง AllowedIPs ที่ทับซ้อนกันหรือเส้นทางคงที่ที่ชี้กลับผ่านอินเทอร์เฟซ ดังนั้นการซ่อมอยู่แค่สองจุดนั้นเท่านั้น
การตรวจข้อสาม อ่านจำนวนฮอป ไม่ใช่ดาว
traceroute -n -I 10.20.30.40 และ mtr -n -r -c 20 10.20.30.40 ต่างแสดงเส้นทาง และโหมด ICMP มักรอดจากการกรองที่กินโพรบ UDP ลูปดูเหมือนลำดับสั้นๆ ที่ซ้ำกันของที่อยู่เกตเวย์สองตัวเดิมโดย TTL เพิ่มขึ้นทุกครั้ง การดรอปดูเหมือนดาวหลังเกตเวย์สุดท้ายที่ตอบ และฮอปเงียบหนึ่งฮอปไม่ใช่หลักฐานของอะไร
เมื่อเส้นทางกำกวม ให้อ่าน TTL บนสาย tcpdump -ni any -vv icmp บนเกตเวย์ทั้งสองแสดง TTL ของแต่ละแพ็กเก็ตและที่อยู่ต้นทางของทุกคำตอบเวลาทำงานเกิน หากแพ็กเก็ตไปถึงไซต์ระยะไกลด้วย TTL ต่ำกว่าจำนวนฮอปที่เส้นทางจะมีได้ แสดงว่ามีบางอย่างเพิ่มฮอปที่ traceroute ไม่ได้แสดงให้คุณเห็น และสิ่งนี้เกิดเมื่อไฟร์วอลล์ของไซต์หนึ่งตอบโพรบแทนอีกไซต์หนึ่ง
ซ่อมเจ้าของคำนำหน้า แล้วตรวจสอบทั้งสองทิศทาง
ตัดสินว่าไซต์ใดสร้างปลายทางและเส้นทางทรานซิตใดได้รับอนุญาต แล้วเปลี่ยนประกาศหรือเส้นทางคงที่ที่เจ้าของนั้น การแก้ไซต์ที่รับเป็นสิ่งล่อใจและมักผิด เพราะมันซ่อนลูปสำหรับคำนำหน้าหนึ่งและทิ้งประกาศที่ไม่ดีไว้ให้คำนำหน้าถัดไป แท็กเส้นทาง รายการกระจาย และกฎ split-horizon มีไว้เพื่อหยุดสิ่งนี้ที่ต้นทาง และถูกกว่าฟิลเตอร์ที่ตรงกับคำนำหน้าเดียว
หลังการเปลี่ยนแปลง ให้ตรวจทิศไปและทิศกลับแยกกัน เพราะลูปอาจถูกแทนที่ด้วยหลุมดำโดยไม่มีอาการดีขึ้นที่มองเห็นได้ รัน ip route get จากทั้งสองด้าน ส่งทราฟฟิกจากโฮสต์ที่ไม่ใช่เกตเวย์ และปล่อยให้ ip monitor route ทำงานอย่างน้อยหนึ่งตัวจับเวลาถือ เพื่อไม่ให้การกระพริบถูกเข้าใจผิดว่าเป็นการซ่อม
ก่อนเปลี่ยนอะไร ให้ยืนยันห้าข้อนี้ คำนำหน้ามั่นคงหรือกำลังเดือด ฮอปถัดไปทั้งสองด้านชี้ไปที่อุโมงค์ จำนวนฮอปซ้ำหรือไม่ ไซต์เดียวเป็นเจ้าของคำนำหน้า และคุณมีเส้นทางบริหารที่อยู่รอดจากการเปลี่ยนแปลง หากข้อใดข้อหนึ่งไม่ทราบ อีกสี่ข้อคือการคาดเดา