Prečo BGP cez VPN neriadi cestu podkladovej vrstvy

Dve lokality prepájajú BGP cez tunel IPsec, učia sa navzájom svoje prefixy a diagram sa premenuje na riadenie cesty. Práve tento štítok je začiatkom zmätku. Relácia si skutočne vymieňa dosiahnuteľnosť a skutočne uplatňuje politiku, ale nemá čo povedať k tomu, ktorý poskytovateľ, kábel alebo smerovač prenáša šifrované pakety. Videl som tím prestavovať funkčný tunel, pretože očakával, že zmena trasy BGP presunie prevádzku na inú optickú cestu, na ktorú relácia nikdy nemohla mať vplyv.

Čo si ľudia myslia, že relácia kupuje

Väčšina očakávania vychádza z toho, ako vyzerá zmena trasy v laboratóriu. Ohlásite prefix cez tunel, vzdialená strana ho nainštaluje a prevádzka sa pohne. Ten istý sled sa deje na smerovači, ktorý naozaj má ovládače inžinierstva prevádzky, preto sa obe zamieňajú. V laboratóriu obe lokality zvyčajne zdieľajú jedno prístupové spojenie, a práve preto sa rozdiel tam nikdy neprejaví.

BGP je protokol dosiahnuteľnosti. Hovorí partnerovi, že dokážete doručiť pakety pre prefix, a umožňuje každej strane zoradiť ponuky, ktoré dostane. Cez tunel je to naozaj užitočné: prefixy sa objavujú a miznú, ako lokality prichádzajú a odchádzajú, a môžete odmietnuť rozsah bez zapisovania statickej trasy na každom okrajovom zariadení. Čo nerobí, je to, že by dostal smerovače poskytovateľa pod vašu kontrolu.

Podkladová vrstva nesie vonkajšiu hlavičku. Váš koncový bod tunela posiela šifrované pakety na adresu partnera a sieť medzi týmito dvoma adresami ich preposiela trasami, ktoré nainštalovali jej operátori. Nič v relácii BGP toto rozhodnutie nemení, iba ak ten istý poskytovateľ ponúka podporovanú službu, ktorá to robí.

Čo relácia skutočne nesie

Hovorca BGP otvára TCP spojenie na port 179 svojho partnera, pričom používa formáty správ a atribúty cesty definované v RFC 4271. Keď adresa partnera leží vnútri tunela, tunel musí byť hore a adresa dosiahnuteľná skôr, než relácia vôbec začne. Dokončená výmena IKE nie je sused BGP. Implementácie IPsec založené na trasách prepúšťajú prevádzku len vtedy, keď existuje zodpovedajúca trasa tunela, a tá založená na politike potrebuje adresu partnera vnútri chráneného selektora. Obrátenie tohto vytvára klasický stav, keď je tunel zelený a relácia stojí nečinne.

Keď je relácia hore, politika rozhoduje, čo ju prechádza. Zoznamy prefixov, filtre AS-path, strop maximálneho počtu prefixov a výslovné rozhodnutie o predvolených trasách sú minimum a platia v oboch smeroch. Partner, ktorý prijíma všetko, čo dostane, vám môže dať predvolenú trasu, ktorá potichu nahrádza lokálny prístup na internet. Oba smery potrebujú samostatné zoznamy, pretože to, čo prijímate od partnera, a to, čo mu ohlasujete, sú dve rôzne rozhodnutia.

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

Potom hrýzne MTU. Zapuzdrenie zmenšuje užitočný obsah, takže veľká aktualizácia môže zastaviť reláciu, ktorá vyzerá dokonale ustálená: partner zostáva hore, prefixy nikdy neprídu a nič zjavné nespadne do záznamu. Obmedzte TCP MSS na rozhraní tunela alebo nastavte MTU tunela s miestom na réžiu, skôr než obviníte filtre.

Kam vonkajšie pakety stále idú

Šifrované pakety z jednej lokality do druhej vychádzajú tým, čo lokálny smerovač vyberie pre verejnú adresu partnera. Ak obe lokality kupujú tranzit od toho istého poskytovateľa, prechádzajú tou istou metropolitnou budovou alebo jedna strana sedí za NAT na úrovni operátora, tunel prežije výpadok poskytovateľa iba náhodou. Počítanie ikon tunelov v monitorovacom nástroji vám o tom nič nepovie.

Výber trasy a inštalácia preposielania sú tiež samostatné udalosti. Prefix môže sedieť v tabuľke BGP ako najlepší a napriek tomu chýbať v tabuľke preposielania, pretože ďalší skok sa nedá vyriešiť alebo vyhrá konkrétnejšia trasa. Keď niekto hlási, že BGP sa prefix naučil, ale prevádzka netečie, užitočná otázka je, či je nainštalovaný a na ktorý ďalší skok ukazuje.

Úprimná odpoveď pre revíziu dizajnu je zoznam zdieľaných závislostí: prístupový okruh, nadradený poskytovateľ, budova a akékoľvek stavové zariadenie na spiatočnej ceste. Relácia cez tunel nemôže odstrániť závislosť, nad ktorou nesedí.

Tri rozhodnutia, ktoré sa oplatí oddeliť

Keď dizajn tieto veci mieša, každý rozhovor o výpadku ide v kruhu. Najprv ich oddeľte na papieri, potom každé priraďte zariadeniu, ktoré ho skutočne presadzuje.

Každý riadok má iného vlastníka. Prvý je rokovanie, druhý je konfigurácia na vašich zariadeniach, tretí je väčšinou sieť niekoho iného. Žiadosť o zmenu, ktorá pomenuje riadok, ktorého sa dotýka, je oveľa ľahšie schváliť než tá, ktorá hovorí problém BGP.

Režimy zlyhania, na ktoré sa oplatí pripraviť

Prijatie súhrnnej trasy partnera je najčastejšia samospôsobená rana. Niekto ohlási krátky agregát, aby zjednodušil výmenu, vzdialená strana ho prijme a prevádzka pre rozsahy, ktoré nie sú za tunelom, nasleduje tunel a zomrie. Filtrujte na presne očakávané prefixy alebo použite zoznam prefixov so správnymi hranicami a nikdy neprijímajte holý agregát, pretože robí reláciu upravenou na pohľad.

Čas odstránenia je druhý. Detekcia závisí od časovačov podržania, od BFD, ak ste ho aktivovali, od detekcie mŕtveho partnera tunela a od toho, ako rýchlo vzdialená strana prestane ohlasovať. Existujúce relácie sú samostatný problém: nová trasa môže obnoviť nové spojenia, zatiaľ čo ustálené relácie TCP ďalej používajú zastarané adresy a stavové firewally alebo NAT na ceste môžu držať záznamy, ktoré už nezodpovedajú. Dajte obnovu aplikácie do akceptačných kritérií namiesto predpokladu, že zmena trasy vyrieši všetko.

Tretia je asymetria spiatočnej cesty. Prevádzka môže prichádzať cez tunel a vracať sa spojením poskytovateľa, ktoré nikdy nebolo určené na jej prenos, čo sa prejavuje ako jednosmerný zvuk, neúspešné podanie ruky alebo firewall, ktorý zahadzuje odpovede. Skontrolujte oba smery samostatne.

Čo napísať do zmluvy a ako to overiť

Požiadajte o povolené prefixy písomne: kto je oprávnený vytvárať každý rozsah, či je povolená predvolená trasa a ktoré rodiny adries tunelová služba podporuje. RFC 8212 urobila výslovnú politiku importu a exportu očakávaním pre eBGP v implementáciách, ktoré ju dodržiavajú, preto si partner, ktorý sa stále spolieha na implicitné prijímanie všetkého, zaslúži otázku.

Potom overujte zo zariadenia a nie z diagramu. Užitočné príkazy na smerovačoch v štýle 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

Pridajte dve pozorovania, ktoré vám tabuľka trás nemôže dať. Zachyťte na vonkajšom rozhraní, aby ste potvrdili, na ktorú adresu zapuzdrené pakety skutočne mieria, napríklad tcpdump -ni eth0 udp port 51820 pre tunel WireGuard alebo filter ESP pre IPsec. Potom trasujte smerom k verejnej adrese partnera a porovnajte skoky so stopou vnútri tunela; ak obe sledujú ten istý reťazec poskytovateľa, vaša redundancia žije v politike trás a nie v sieti.

Na záver zámerne otestujte odstránenie. Zložte tunel v servisnom okne, poznamenajte, ako dlho prefix zostáva nainštalovaný, čo sa stane s existujúcimi reláciami a či sa vzdialená strana vráti na trasu, ktorú by ste naozaj prijali. To cvičenie povie o dizajne viac než akýkoľvek diagram.

Trasa nie je povolenie. Prefixy, na ktorých výmene sa dohodnete, nehovoria nič o tom, ktorí používatelia sa môžu dostať ku ktorej službe za tunelom, preto nechajte autentifikáciu, povolené služby a firewally hostiteľov presne tam, kde boli. Dosiahnuteľný partner tiež nie je povolenie na neobmedzený tranzit ani na vytváranie ľubovoľných adries a takáto právomoc patrí do zmluvy ako obchodná otázka, nie do riadku politiky BGP.

• Pomenujte prefixy, ktoré môže každá strana vytvárať, a tie, ktoré nikdy nesmie prijať.
• Obmedzte MSS na tuneli a potvrďte, že veľké aktualizácie naozaj prichádzajú.
• Vymenujte zdieľané závislosti podkladovej vrstvy, nie počet tunelov.
• Zmerajte skutočné odstránenie a poznamenajte, čo robí aplikácia.