Proč BGP přes VPN neřídí vaši cestu spodní vrstvy

Dvě lokality navážou BGP přes tunel IPsec, naučí se navzájem své prefixy a diagram se přejmenuje na řízení cesty. Právě tento štítek je začátek zmatku. Relace skutečně vyměňuje dosažitelnost a skutečně uplatňuje politiku, ale nemá slovo v tom, který poskytovatel, kabel nebo router nese šifrované pakety. Viděl jsem tým přestavět funkční tunel, protože očekávali, že změna trasy BGP přesune provoz na jinou optickou cestu, kterou relace nikdy nemohla ovlivnit.

Co si lidé myslí, že relace kupuje

Většina očekávání pochází z toho, jak změna trasy vypadá v laboratoři. Inzerujete prefix přes tunel, vzdálená strana jej nainstaluje a provoz se pohne. Stejný sled se děje na routeru, který skutečně má páky pro inženýrství provozu, takže se obojí zaměňuje. V laboratoři obě lokality obvykle sdílejí jedno přístupové vedení, a právě proto se tam rozdíl nikdy neukáže.

BGP je protokol dosažitelnosti. Říká protějšku, že dokážete doručit pakety pro prefix, a nechává každou stranu seřadit nabídky, které dostane. To je přes tunel skutečně užitečné: prefixy se objevují a mizí, jak lokality přicházejí a odcházejí, a můžete odmítnout rozsah, aniž byste na každém okrajovém zařízení psali statickou trasu. Co nedělá, je to, že by dávalo routery poskytovatele pod vaši kontrolu.

Spodní vrstva nese vnější hlavičku. Váš koncový bod tunelu posílá šifrované pakety na adresu protějšku a síť mezi těmito dvěma adresami je předává podle tras, které nainstalovali její operátoři. Nic v relaci BGP toto rozhodnutí nemění, pokud stejný poskytovatel nenabízí podporovanou službu, která to dělá.

Co relace skutečně nese

BGP speaker otevře TCP spojení na port 179 svého protějšku a použije formáty zpráv a atributy cesty definované v RFC 4271. Když adresa protějšku leží uvnitř tunelu, musí být tunel nahoře a adresa dosažitelná, než relace vůbec může začít. Dokončená výměna IKE není soused BGP. Implementace IPsec založené na trasách propouštějí provoz až tehdy, když existuje odpovídající trasa tunelu, a implementace založená na politice potřebuje adresu protějšku uvnitř chráněného selektoru. Obrácené pořadí dává klasický stav, kdy je tunel zelený a relace nečinně stojí.

Jakmile je relace nahoře, politika rozhoduje, co ji prochází. Seznamy prefixů, filtry AS-path, strop maximálního počtu prefixů a výslovné rozhodnutí o výchozích trasách jsou minimum a platí v obou směrech. Protějšek, který přijme vše, co dostane, vám může předat výchozí trasu, jež tiše nahradí místní přístup k internetu. Oba směry potřebují samostatné seznamy, protože to, co od protějšku přijímáte, a to, co mu inzerujete, jsou různá rozhodnutí.

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

Dál kouše MTU. Zapouzdření zmenšuje použitelný náklad, takže velká aktualizace může zablokovat relaci, která vypadá dokonale navázaná: protějšek zůstává nahoře, prefixy nikdy nedorazí a v logu není nic zjevného. Omezte TCP MSS na rozhraní tunelu nebo nastavte MTU tunelu s rezervou na režii, než obviníte filtry.

Kam vnější pakety stále jdou

Šifrované pakety z jedné lokality do druhé odcházejí tím, co místní router vybere pro veřejnou adresu protějšku. Pokud obě lokality kupují tranzit od stejného poskytovatele, procházejí stejným metropolitním zařízením nebo jedna strana sedí za NAT operátorské úrovně, tunel přežije výpadek poskytovatele jen náhodou. Počítání ikon tunelů v monitorovacím nástroji o tom nic neříká.

Výběr trasy a instalace předávání jsou také oddělené události. Prefix může v tabulce BGP sedět jako nejlepší a přesto chybět v předávací tabulce, protože další skok je neřešitelný nebo vyhrává konkrétnější trasa. Když někdo hlásí, že se BGP prefix naučilo, ale provoz neteče, užitečná otázka je, zda je nainstalovaný a na který další skok ukazuje.

Poctivá odpověď pro revizi návrhu je seznam sdílených závislostí: přístupový okruh, nadřazený poskytovatel, zařízení a jakékoli stavové zařízení na zpáteční cestě. Relace přes tunel nemůže odstranit závislost, nad kterou neleží.

Tři rozhodnutí, která stojí za to oddělit

Když návrh tyto věci smíchá, každý rozhovor o výpadku jde v kruzích. Nejdřív je oddělte na papíře, pak každé přiřaďte zařízení, které jej skutečně prosazuje.

Každý řádek má jiného vlastníka. První je vyjednávání, druhý je konfigurace na vašich zařízeních, třetí je většinou cizí síť. Žádost o změnu, která pojmenuje řádek, jehož se týká, se schvaluje mnohem snáze než ta, která říká problém BGP.

Režimy selhání, na které stojí za to se připravit

Přijetí souhrnné trasy protějšku je nejčastější samozpůsobená rána. Někdo inzeruje krátký agregát, aby zjednodušil výměnu, vzdálená strana jej přijme a provoz pro rozsahy, které nejsou za tunelem, následuje tunel a umírá. Filtrujte podle přesně očekávaných prefixů nebo použijte seznam prefixů se správnými mezemi a nikdy nepřijímejte holý agregát, protože dělá relaci úhlednou.

Časování odvolání je druhé. Detekce závisí na hold timerech, BFD, pokud jste jej zapnuli, detekci mrtvého protějšku tunelu a na tom, jak rychle vzdálená strana přestane inzerovat. Existující relace jsou samostatný problém: nová trasa může obnovit nová spojení, zatímco navázané relace TCP dál používají zastaralé adresy a stavové firewally nebo NAT na cestě mohou držet záznamy, které už neodpovídají. Dejte obnovu aplikace do akceptačních kritérií, místo abyste předpokládali, že změna trasy vyřeší vše.

Třetí je asymetrie zpáteční cesty. Provoz může dorazit tunelem a vrátit se poskytovatelským vedením, které nikdy nebylo určeno k jeho přenosu, což se projeví jako jednosměrný zvuk, neúspěšná navázání spojení nebo firewall zahazující odpovědi. Kontrolujte oba směry zvlášť.

Co zapsat do smlouvy a jak to ověřit

Vyžádejte povolené prefixy písemně: kdo je oprávněn vytvářet každý rozsah, zda je povolena výchozí trasa a které rodiny adres služba tunelu podporuje. RFC 8212 udělala z výslovné politiky importu a exportu očekávání pro eBGP v implementacích, které ji dodržují, takže protějšek, který se stále spoléhá na implicitní chování přijmi-vše, stojí za otázku.

Pak ověřujte ze zařízení, ne z diagramu. Užitečné příkazy na routerech typu 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

Přidejte dvě pozorování, která vám směrovací tabulka nedá. Zachyťte na vnějším rozhraní a potvrďte, na kterou adresu zapouzdřené pakety skutečně míří, například tcpdump -ni eth0 udp port 51820 pro tunel WireGuard nebo filtr ESP pro IPsec. Pak traceujte k veřejné adrese protějšku a porovnejte skoky s trace uvnitř tunelu; pokud oba sledují stejný řetězec poskytovatele, vaše redundance žije ve směrovací politice, ne v síti.

Nakonec záměrně otestujte odvolání. Během servisního okna tunel shodte, zaznamenejte, jak dlouho prefix zůstane nainstalovaný, co se stane s existujícími relacemi a zda vzdálená strana spadne na trasu, kterou byste skutečně přijali. To cvičení řekne o návrhu víc než jakýkoli diagram.

Trasa není oprávnění. Prefixy, na kterých se dohodnete, nic neříkají o tom, kteří uživatelé smějí dosáhnout které služby za tunelem, takže autentizaci, povolené služby a firewally hostitelů nechte přesně tam, kde byly. Dosažitelný protějšek také není svolením k neomezenému tranzitu ani k vytváření libovolných adres a tento druh pravomoci patří do smlouvy jako obchodní otázka, ne do řádku politiky BGP.

• Pojmenujte prefixy, které každá strana smí vytvářet, a ty, které nikdy nesmí přijmout.
• Omezte MSS na tunelu a potvrďte, že velké aktualizace skutečně dorazí.
• Vyjmenujte sdílené závislosti spodní vrstvy, ne počet tunelů.
• Změřte skutečné odvolání a poznamenejte, co aplikace dělá.