De ce BGP peste un VPN nu controlează calea stratului inferior

Două locații fac peering BGP printr-un tunel IPsec, învață prefixele celeilalte și diagrama este redenumită ca control al căii. Această etichetă este începutul confuziei. Sesiunea schimbă într-adevăr accesibilitate și aplică într-adevăr politică, dar nu are niciun cuvânt de spus despre ce furnizor, cablu sau router transportă pachetele criptate. Am văzut o echipă reconstruind un tunel funcțional pentru că se aștepta ca o schimbare de rută BGP să mute traficul pe o altă cale de fibră pe care sesiunea nu ar fi putut-o influența niciodată.

Ce presupun oamenii că cumpără o sesiune

Cea mai mare parte a așteptării vine din felul în care arată o schimbare de rută într-un laborator. Anunți un prefix prin tunel, partea îndepărtată îl instalează și traficul se mișcă. Aceeași secvență se întâmplă pe un router care chiar are pârghii de inginerie a traficului, așa că cele două se confundă. În laborator ambele locații partajează de obicei o singură legătură de acces, și exact de aceea diferența nu apare niciodată acolo.

BGP este un protocol de accesibilitate. Îi spune unui peer că poți livra pachete pentru un prefix și lasă fiecare parte să ordoneze ofertele pe care le primește. Acest lucru este cu adevărat util prin tunel: prefixele apar și dispar pe măsură ce locațiile vin și pleacă, și poți refuza un interval fără să scrii o rută statică pe fiecare dispozitiv de margine. Ce nu face este să pună routerele unui furnizor sub controlul tău.

Stratul inferior poartă antetul exterior. Punctul final al tunelului tău trimite pachete criptate către o adresă de peer, iar rețeaua dintre aceste două adrese le transmite cu rutele pe care le-au instalat operatorii ei. Nimic din sesiunea BGP nu schimbă această decizie, decât dacă același furnizor expune un serviciu suportat care face asta.

Ce transportă de fapt sesiunea

Vorbitorul BGP deschide o conexiune TCP către portul 179 al peerului său, folosind formatele de mesaj și atributele de cale definite în RFC 4271. Când adresa peerului se află în interiorul tunelului, tunelul trebuie să fie activ și adresa accesibilă înainte ca sesiunea să poată începe. Un schimb IKE finalizat nu este un vecin BGP. Implementările IPsec bazate pe rute lasă traficul să treacă doar când există o rută de tunel potrivită, iar cea bazată pe politică are nevoie de adresa peerului în selectorul protejat. Inversarea acestui lucru produce starea clasică în care tunelul este verde, iar sesiunea stă inactivă.

Odată ce sesiunea este activă, politica decide ce o traversează. Listele de prefixe, filtrele AS-path, un plafon de prefixe maxime și o decizie explicită despre rutele implicite sunt minimul, și se aplică în ambele direcții. Un peer care acceptă tot ce primește poate să-ți dea o rută implicită care înlocuiește în tăcere accesul local la internet. Cele două direcții au nevoie de liste separate, pentru că ceea ce accepți de la un peer și ceea ce îi anunți sunt două decizii diferite.

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

Apoi mușcă MTU. Encapsularea micșorează încărcătura utilă, așa că o actualizare mare poate bloca o sesiune care pare perfect stabilită: peerul rămâne activ, prefixele nu sosesc niciodată și nimic evident nu ajunge în jurnal. Limitează MSS-ul TCP pe interfața tunelului sau setează un MTU de tunel cu spațiu pentru suprasarcină, înainte de a da vina pe filtre.

Unde merg totuși pachetele exterioare

Pachetele criptate dintr-o locație în cealaltă ies prin ceea ce routerul local selectează pentru adresa publică a peerului. Dacă ambele locații cumpără tranzit de la același furnizor, traversează aceeași facilitate metropolitană sau o parte stă în spatele unui NAT de nivel operator, tunelul supraviețuiește unei defecțiuni a furnizorului doar din întâmplare. Numărarea pictogramelor de tunel într-un instrument de monitorizare nu-ți spune nimic despre asta.

Selectarea rutei și instalarea forwardingului sunt și ele evenimente separate. Un prefix poate sta în tabela BGP ca cel mai bun și totuși lipsi din tabela de forwarding, pentru că următorul salt nu poate fi rezolvat sau o rută mai specifică câștigă. Când cineva raportează că BGP a învățat prefixul dar traficul nu curge, întrebarea utilă este dacă este instalat și către ce următor salt indică.

Răspunsul onest pentru o revizuire de design este o listă de dependențe partajate: circuitul de acces, furnizorul din amonte, facilitatea și orice dispozitiv cu stare de pe calea de întoarcere. O sesiune prin tunel nu poate elimina o dependență peste care nu stă.

Trei decizii care merită separate

Când un design amestecă aceste lucruri, fiecare conversație despre o defecțiune merge în cerc. Separă-le mai întâi pe hârtie, apoi asociază fiecare cu dispozitivul care o aplică efectiv.

Fiecare rând are alt proprietar. Primul este o negociere, al doilea este configurație pe dispozitivele tale, al treilea este în mare parte rețeaua altcuiva. O cerere de schimbare care numește rândul pe care îl atinge este mult mai ușor de aprobat decât una care spune problemă BGP.

Moduri de eșec pentru care merită să planifici

Acceptarea rutei rezumate a unui peer este cea mai frecventă rană auto-inflijată. Cineva anunță un agregat scurt pentru a simplifica schimbul, partea îndepărtată îl acceptă, iar traficul pentru intervalele care nu sunt în spatele tunelului urmează tunelul și moare. Filtrează pe prefixele exact așteptate sau folosește o listă de prefixe cu limitele corecte și nu accepta niciodată un agregat gol pentru că face sesiunea să pară ordonată.

Momentul retragerii este al doilea. Detectarea depinde de temporizatoarele de menținere, de BFD dacă l-ai activat, de detectarea peerului mort al tunelului și de cât de repede partea îndepărtată încetează să anunțe. Sesiunile existente sunt o problemă separată: o rută nouă poate restabili conexiuni noi în timp ce sesiunile TCP stabilite continuă să folosească adrese învechite, iar firewall-urile cu stare sau NAT de pe cale pot păstra intrări care nu mai corespund. Pune recuperarea aplicației în criteriile de acceptare în loc să presupui că o schimbare de rută rezolvă totul.

A treia este asimetria căii de întoarcere. Traficul poate sosi prin tunel și se poate întoarce printr-o legătură a furnizorului care nu a fost niciodată destinată să o transporte, ceea ce se manifestă ca audio unidirecțional, handshake-uri eșuate sau un firewall care aruncă răspunsurile. Verifică ambele direcții separat.

Ce să scrii în contract și cum să verifici

Cere în scris prefixele permise: cine este autorizat să origineze fiecare interval, dacă o rută implicită este permisă și ce familii de adrese suportă serviciul de tunel. RFC 8212 a făcut din politica explicită de import și export așteptarea pentru eBGP în implementările care o urmează, așa că un peer care încă se bazează pe comportamentul implicit de acceptare a tot merită întrebat.

Apoi verifică de pe dispozitiv, nu din diagramă. Comenzi utile pe routere în stil 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

Adaugă două observații pe care tabela de rute nu ți le poate da. Capturează pe interfața exterioară pentru a confirma către ce adresă vizează de fapt pachetele encapsulate, de exemplu tcpdump -ni eth0 udp port 51820 pentru un tunel WireGuard, sau un filtru ESP pentru IPsec. Apoi trasează către adresa publică a peerului și compară salturile cu o urmărire în interiorul tunelului; dacă ambele urmează același lanț de furnizor, redundanța ta trăiește în politica de rute și nu în rețea.

În final, testează intenționat o retragere. Coboară tunelul într-o fereastră de mentenanță, notează cât timp prefixul rămâne instalat, ce se întâmplă cu sesiunile existente și dacă partea îndepărtată revine la o rută pe care ai accepta-o cu adevărat. Exercițiul acela spune mai mult despre design decât orice diagramă.

O rută nu este o autorizare. Prefixele pe care ești de acord să le schimbi nu spun nimic despre ce utilizatori pot ajunge la ce serviciu din spatele tunelului, așa că păstrează autentificarea, serviciile permise și firewall-urile gazdelor exact acolo unde erau. Un peer accesibil nu este nici permisiune pentru tranzit nelimitat sau pentru a origina adrese arbitrare, iar acest tip de autoritate aparține contractului ca întrebare comercială, nu unei linii de politică BGP.

• Numește prefixele pe care fiecare parte le poate origina și pe cele pe care nu trebuie să le accepte niciodată.
• Limitează MSS-ul pe tunel și confirmă că actualizările mari sosesc într-adevăr.
• Enumeră dependențele partajate ale stratului inferior, nu numărul de tuneluri.
• Cronometrează o retragere reală și notează ce face aplicația.