ทำไม BGP บน VPN จึงไม่ควบคุมเส้นทางเลเยอร์ล่างของคุณ
BGP บน VPN แลกเปลี่ยนการเข้าถึงได้และใช้นโยบายเส้นทาง แต่เลเยอร์ล่างยังคงเลือกเส้นทางภายนอก สิ่งที่เซสชันควบคุมจริง
สองไซต์เพียร์ BGP ผ่านอุโมงค์ IPsec เรียนรู้คำนำหน้าของกันและกัน และไดอะแกรมถูกเปลี่ยนชื่อเป็นการควบคุมเส้นทาง ป้ายกำกับนั่นเองคือจุดเริ่มต้นของความสับสน เซสชันแลกเปลี่ยนการเข้าถึงได้และใช้นโยบายจริง แต่ไม่มีสิทธิ์พูดว่าผู้ให้บริการ สาย หรือเราเตอร์ใดขนส่งแพ็กเก็ตที่เข้ารหัส ฉันเคยเห็นทีมสร้างอุโมงค์ที่ทำงานอยู่ใหม่เพราะคาดว่าการเปลี่ยนเส้นทาง BGP จะย้ายทราฟฟิกไปยังเส้นทางไฟเบอร์อีกเส้นที่เซสชันไม่มีทางมีอิทธิพลได้
สิ่งที่ผู้คนคิดว่าเซสชันซื้อ
ความคาดหวังส่วนใหญ่มาจากรูปร่างของการเปลี่ยนเส้นทางในห้องแล็บ คุณประกาศคำนำหน้าผ่านอุโมงค์ ฝั่งไกลติดตั้งมัน และทราฟฟิกเคลื่อนที่ ลำดับเดียวกันนี้เกิดขึ้นบนเราเตอร์ที่มีปุ่มควบคุมวิศวกรรมทราฟฟิกจริง ดังนั้นทั้งสองจึงถูกสับสน ในห้องแล็บทั้งสองไซต์มักใช้ลิงก์เชื่อมต่อเดียวร่วมกัน และนั่นคือเหตุผลว่าทำไมความแตกต่างจึงไม่เคยปรากฏที่นั่น
BGP เป็นโปรโตคอลการเข้าถึงได้ มันบอกเพียร์ว่าคุณส่งแพ็กเก็ตสำหรับคำนำหน้าได้ และให้แต่ละฝั่งจัดลำดับข้อเสนอที่ได้รับ มันมีประโยชน์จริงผ่านอุโมงค์ คำนำหน้าปรากฏและหายไปเมื่อไซต์มาและไป และคุณสามารถปฏิเสธช่วงได้โดยไม่ต้องเขียนเส้นทางสแตติกบนอุปกรณ์ขอบทุกตัว สิ่งที่มันไม่ทำคือนำเราเตอร์ของผู้ให้บริการมาอยู่ใต้การควบคุมของคุณ
เลเยอร์ล่างขนส่งส่วนหัวภายนอก ปลายอุโมงค์ของคุณส่งแพ็กเก็ตที่เข้ารหัสไปยังที่อยู่เพียร์ และเครือข่ายระหว่างสองที่อยู่นั้นส่งต่อด้วยเส้นทางที่ผู้ดำเนินการติดตั้งไว้ ไม่มีสิ่งใดในเซสชัน BGP เปลี่ยนการตัดสินใจนั้น เว้นแต่ผู้ให้บริการรายเดียวกันเสนอบริการที่รองรับซึ่งทำเช่นนั้น
สิ่งที่เซสชันขนส่งจริง
สปีกเกอร์ BGP เปิดการเชื่อมต่อ TCP ไปยังพอร์ต 179 ของเพียร์ โดยใช้รูปแบบข้อความและแอตทริบิวต์เส้นทางที่กำหนดใน RFC 4271 เมื่อที่อยู่เพียร์อยู่ภายในอุโมงค์ อุโมงค์ต้องขึ้นและที่อยู่ต้องเข้าถึงได้ก่อนที่เซสชันจะเริ่มได้ การแลกเปลี่ยน IKE ที่เสร็จสิ้นไม่ใช่เพื่อนบ้าน BGP การใช้งาน IPsec แบบอิงเส้นทางปล่อยทราฟฟิกผ่านเมื่อมีเส้นทางอุโมงค์ที่ตรงกันเท่านั้น และแบบอิงนโยบายต้องมีที่อยู่เพียร์ภายในตัวเลือกที่ได้รับการป้องกัน การกลับด้านสิ่งนี้ทำให้เกิดสภาวะคลาสสิกที่อุโมงค์เป็นสีเขียวแต่เซสชันนั่งว่าง
เมื่อเซสชันขึ้นแล้ว นโยบายตัดสินว่าอะไรข้ามมัน รายการคำนำหน้า ตัวกรอง AS-path เพดานจำนวนคำนำหน้าสูงสุด และการตัดสินใจชัดเจนเกี่ยวกับเส้นทางเริ่มต้นคือขั้นต่ำ และใช้ทั้งสองทิศทาง เพียร์ที่ยอมรับทุกอย่างที่ได้รับอาจให้เส้นทางเริ่มต้นที่แทนที่การเข้าถึงอินเทอร์เน็ตภายในอย่างเงียบ ๆ ทั้งสองทิศทางต้องมีรายการแยกกัน เพราะสิ่งที่คุณยอมรับจากเพียร์กับสิ่งที่คุณประกาศให้มันเป็นสองการตัดสินใจที่ต่างกัน
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
จากนั้น MTU ก็กัด การห่อหุ้มลดเพย์โหลดที่ใช้ได้ ดังนั้นการอัปเดตขนาดใหญ่อาจหยุดเซสชันที่ดูเหมือนตั้งขึ้นอย่างสมบูรณ์ เพียร์ยังขึ้นอยู่ คำนำหน้าไม่เคยมาถึง และไม่มีอะไรชัดเจนในบันทึก จำกัด TCP MSS บนอินเทอร์เฟซอุโมงค์ หรือตั้งค่า MTU อุโมงค์โดยเผื่อค่าใช้จ่ายเพิ่มเติม ก่อนที่จะโทษตัวกรอง
แพ็กเก็ตภายนอกยังคงไปที่ใด
แพ็กเก็ตที่เข้ารหัสจากไซต์หนึ่งไปยังอีกไซต์ออกผ่านสิ่งที่เราเตอร์ภายในเลือกสำหรับที่อยู่สาธารณะของเพียร์ ถ้าทั้งสองไซต์ซื้อทรานซิตจากผู้ให้บริการรายเดียวกัน ผ่านสถานที่เมโทรเดียวกัน หรือฝั่งหนึ่งอยู่หลัง NAT ระดับผู้ให้บริการ อุโมงค์จะรอดจากความล้มเหลวของผู้ให้บริการเพียงโดยบังเอิญ การนับไอคอนอุโมงค์ในเครื่องมือตรวจสอบไม่ได้บอกอะไรคุณเกี่ยวกับเรื่องนี้
การเลือกเส้นทางและการติดตั้งการส่งต่อก็เป็นเหตุการณ์แยกกัน คำนำหน้าอาจนั่งในตาราง BGP ในฐานะที่ดีที่สุดและยังขาดจากตารางการส่งต่อ เพราะฮอปถัดไปแก้ไม่ได้หรือเส้นทางที่เฉพาะเจาะจงกว่าชนะ เมื่อมีคนรายงานว่า BGP เรียนรู้คำนำหน้าแล้วแต่ทราฟฟิกไม่ไหล คำถามที่มีประโยชน์คือมันถูกติดตั้งหรือไม่และชี้ไปที่ฮอปถัดไปใด
คำตอบที่ซื่อสัตย์สำหรับการทบทวนการออกแบบคือรายการการพึ่งพาร่วม วงจรเชื่อมต่อ ผู้ให้บริการต้นน้ำ สถานที่ และอุปกรณ์ใด ๆ ที่เก็บสถานะบนเส้นทางขากลับ เซสชันผ่านอุโมงค์ไม่สามารถลบการพึ่งพาที่มันไม่ได้นั่งอยู่บนนั้น
สามการตัดสินใจที่ควรแยกจากกัน
เมื่อการออกแบบผสมสิ่งเหล่านี้ ทุกบทสนทนาเกี่ยวกับความล้มเหลวจะวนเป็นวงกลม แยกมันบนกระดาษก่อน แล้วจึงจับคู่แต่ละอย่างกับอุปกรณ์ที่บังคับใช้จริง
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
แต่ละแถวมีเจ้าของต่างกัน แถวแรกคือการเจรจา แถวที่สองคือการกำหนดค่าบนอุปกรณ์ของคุณ แถวที่สามส่วนใหญ่เป็นเครือข่ายของคนอื่น คำขอเปลี่ยนแปลงที่ระบุแถวที่มันแตะนั้นอนุมัติได้ง่ายกว่าคำขอที่บอกว่าปัญหา BGP มาก
โหมดความล้มเหลวที่ควรวางแผน
การยอมรับเส้นทางสรุปของเพียร์เป็นแผลที่ทำร้ายตัวเองที่พบบ่อยที่สุด มีคนประกาศแอกกรีเกตสั้น ๆ เพื่อทำให้การแลกเปลี่ยนง่ายขึ้น ฝั่งไกลยอมรับมัน และทราฟฟิกสำหรับช่วงที่ไม่ได้อยู่หลังอุโมงค์ก็ตามอุโมงค์ไปและตาย กรองตามคำนำหน้าที่คาดหวังอย่างแม่นยำ หรือใช้รายการคำนำหน้าที่มีขอบเขตถูกต้อง และอย่ายอมรับแอกกรีเกตเปล่า ๆ เพราะมันทำให้เซสชันดูเรียบร้อย
จังหวะการถอนเป็นอย่างที่สอง การตรวจจับขึ้นอยู่กับตัวจับเวลาการถือ ถ้าคุณเปิดใช้ BFD การตรวจจับเพียร์ที่ตายของอุโมงค์ และความเร็วที่ฝั่งไกลหยุดประกาศ เซสชันที่มีอยู่เป็นปัญหาอีกเรื่อง เส้นทางใหม่อาจฟื้นการเชื่อมต่อใหม่ในขณะที่เซสชัน TCP ที่ตั้งไว้ยังใช้ที่อยู่เก่า และไฟร์วอลล์ที่เก็บสถานะหรือ NAT บนเส้นทางอาจเก็บรายการที่ไม่ตรงกันอีกต่อไป ใส่การกู้คืนของแอปพลิเคชันในเกณฑ์การยอมรับแทนการถือว่าการเปลี่ยนเส้นทางแก้ทุกอย่าง
อย่างที่สามคือ ความไม่สมมาตรของเส้นทางขากลับ ทราฟฟิกอาจมาถึงผ่านอุโมงค์และกลับผ่านลิงก์ผู้ให้บริการที่ไม่เคยถูกออกแบบมาให้ขนส่งมัน ซึ่งปรากฏเป็นเสียงทางเดียว การจับมือที่ล้มเหลว หรือไฟร์วอลล์ที่ทิ้งคำตอบ ตรวจสอบทั้งสองทิศทางแยกกัน
สิ่งที่จะเขียนในสัญญา และวิธีตรวจสอบ
ขอคำนำหน้าที่อนุญาตเป็นลายลักษณ์อักษร ใครมีสิทธิ์สร้างแต่ละช่วง เส้นทางเริ่มต้นได้รับอนุญาตหรือไม่ และบริการอุโมงค์รองรับตระกูลที่อยู่ใด RFC 8212 ทำให้การนำเข้าและส่งออกนโยบายที่ชัดเจนเป็นความคาดหวังสำหรับ eBGP ในการใช้งานที่ปฏิบัติตาม ดังนั้นเพียร์ที่ยังพึ่งพาพฤติกรรมยอมรับทุกอย่างโดยนัยจึงควรถูกตั้งคำถาม
จากนั้นตรวจสอบจากอุปกรณ์ไม่ใช่จากไดอะแกรม คำสั่งที่มีประโยชน์บนเราเตอร์สไตล์ FRR:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
เพิ่มการสังเกตสองอย่างที่ตารางเส้นทางให้คุณไม่ได้ บันทึกบนอินเทอร์เฟซภายนอกเพื่อยืนยันว่าแพ็กเก็ตที่ห่อหุ้มนั้นเล็งไปที่ที่อยู่ใดจริง ตัวอย่างเช่น tcpdump -ni eth0 udp port 51820 สำหรับอุโมงค์ WireGuard หรือตัวกรอง ESP สำหรับ IPsec จากนั้นติดตามไปยังที่อยู่สาธารณะของเพียร์และ เปรียบเทียบฮอปกับการติดตามภายในอุโมงค์ ถ้าทั้งสองตามห่วงโซ่ผู้ให้บริการเดียวกัน ความซ้ำซ้อนของคุณอยู่ในนโยบายเส้นทางไม่ใช่ในเครือข่าย
สุดท้าย ทดสอบการถอนโดยเจตนา ลดอุโมงค์ลงในช่วงเวลาบำรุงรักษา บันทึกว่าคำนำหน้าถูกติดตั้งไว้นานเท่าใด เกิดอะไรกับเซสชันที่มีอยู่ และฝั่งไกลถอยกลับไปยังเส้นทางที่คุณจะยอมรับจริงหรือไม่ การฝึกนั้นบอกเกี่ยวกับการออกแบบมากกว่าไดอะแกรมใด ๆ
เส้นทางไม่ใช่การอนุญาต คำนำหน้าที่คุณตกลงแลกเปลี่ยนไม่ได้บอกอะไรเกี่ยวกับผู้ใช้ใดเข้าถึงบริการใดหลังอุโมงค์ ดังนั้นเก็บการพิสูจน์ตัวตน บริการที่อนุญาต และไฟร์วอลล์โฮสต์ไว้ในที่เดิม เพียร์ที่เข้าถึงได้ก็ไม่ใช่การอนุญาตให้ทรานซิตไม่จำกัดหรือสร้างที่อยู่ตามอำเภอใจ และอำนาจประเภทนั้นอยู่ในสัญญาในฐานะคำถามเชิงพาณิชย์ ไม่ใช่ในบรรทัดนโยบาย BGP
- ระบุคำนำหน้าที่แต่ละฝั่งสร้างได้ และคำนำหน้าที่ไม่ควรยอมรับเลย
- จำกัด MSS บนอุโมงค์และยืนยันว่าการอัปเดตขนาดใหญ่มากถึงจริง
- ระบุการพึ่งพาร่วมของเลเยอร์ล่าง ไม่ใช่จำนวนอุโมงค์
- วัดการถอนจริงและบันทึกว่าแอปพลิเคชันทำอะไร