Hvorfor BGP over en VPN ikke styrer din underlagsrute

To sites peer BGP over en IPsec-tunnel, lærer hinandens præfikser, og diagrammet bliver omdøbt til rutestyring. Det mærkat er, hvor forvirringen starter. Sessionen udveksler nåbarhed og anvender politik, men den har ingen indflydelse på, hvilken udbyder, kabel eller router der bærer de krypterede pakker. Jeg har set et team genopbygge en fungerende tunnel, fordi de forventede, at en BGP-ruteændring ville flytte trafikken over på en anden fiberrute, som sessionen aldrig kunne påvirke.

Hvad folk tror, en session køber

Det meste af forventningen kommer fra, hvordan en ruteændring ser ud i et laboratorium. Du annoncerer et præfiks over tunnelen, den fjerne side installerer det, og trafikken flytter sig. Den samme sekvens sker på en router, der faktisk har håndtag til trafikengineering, så de to bliver blandet sammen. I laboratoriet deler begge sites normalt ét adgangsforbind, og det er netop derfor, forskellen aldrig viser sig der.

BGP er en nåbarhedsprotokol. Den fortæller en peer, at du kan levere pakker til et præfiks, og lader hver side rangordne de tilbud, den modtager. Det er virkelig nyttigt over en tunnel: præfikser dukker op og forsvinder, efterhånden som sites kommer og går, og du kan afvise et interval uden at skrive en statisk rute på hver kantrouter. Det, den ikke gør, er at sætte en udbyders routere under din kontrol.

Underlaget bærer det ydre headere. Dit tunnelendepunkt sender krypterede pakker til en peer-adresse, og netværket mellem de to adresser videresender dem ved hjælp af de ruter, dets operatører har installeret. Intet i BGP-sessionen ændrer den beslutning, medmindre den samme udbyder stiller en understøttet tjeneste til rådighed, der gør det.

Hvad sessionen faktisk bærer

BGP-speakeren åbner en TCP-forbindelse til port 179 på sin peer og bruger de beskedformater og stiattributter, der er defineret i RFC 4271. Når peer-adressen ligger inde i tunnelen, skal tunnelen være oppe, og adressen skal være nåbar, før sessionen overhovedet kan starte. En gennemført IKE-udveksling er ikke en BGP-nabo. Rutebaserede IPsec-implementeringer lukker først trafik igennem, når der findes en matchende tunnelrute, og en politikbaseret kræver peer-adressen inde i den beskyttede selector. Vendes det om, får man den klassiske tilstand, hvor tunnelen er grøn, og sessionen står ledig.

Når sessionen er oppe, bestemmer politik, hvad der krydser den. Præfikslister, AS-path-filtre, et loft over maksimalt antal præfikser og en udtrykkelig beslutning om default-ruter er minimumet, og de gælder i begge retninger. En peer, der accepterer alt, hvad den modtager, kan give dig en default-rute, der stille erstatter lokal internetadgang. De to retninger kræver separate lister, fordi det, du accepterer fra en peer, og det, du annoncerer til den, er forskellige beslutninger.

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

Dernæst bider MTU. Indkapslingen skrumper den brugbare nyttelast, så en stor opdatering kan standse en session, der ser helt etableret ud: peeren forbliver oppe, præfikser ankommer aldrig, og intet oplagt ender i loggen. Begræns TCP MSS på tunnelinterfacet, eller sæt en tunnel-MTU med plads til overhead, før du giver filtrene skylden.

Hvor de ydre pakker stadig går hen

Krypterede pakker fra et site til det andet forlader via det, den lokale router vælger til peerens offentlige adresse. Hvis begge sites køber transit hos samme udbyder, krydser samme metrofacilitet, eller den ene side sidder bag carrier-grade NAT, overlever tunnelen kun en udbyderfejl ved et tilfælde. At tælle tunnelikoner i et overvågningsværktøj fortæller dig intet om det.

Rutevalg og installation af videresendelse er også separate begivenheder. Et præfiks kan stå i BGP-tabellen som det bedste og stadig mangle i videresendelsestabellen, fordi næste hop ikke kan opløses, eller en mere specifik rute vinder. Når nogen rapporterer, at BGP har lært præfikset, men trafikken ikke flyder, er det nyttige spørgsmål, om det er installeret, og hvilket næste hop det peger på.

Det ærlige svar til en designgennemgang er en liste over delte afhængigheder: adgangsforbindelse, upstream-udbyder, facilitet og enhver stateful enhed på returvejen. En session over tunnelen kan ikke fjerne en afhængighed, den ikke ligger oven over.

Tre beslutninger, der er værd at skille ad

Når et design blander dem sammen, går hver nedbrudsdiskussion i ring. Skil dem ad på papiret først, og knyt derefter hver enkelt til den enhed, der faktisk håndhæver den.

Hver række har en anden ejer. Den første er en forhandling, den anden er konfiguration på dine enheder, den tredje er mest en andens netværk. En ændringsanmodning, der navngiver den række, den berører, er langt lettere at godkende end en, der siger BGP-problem.

Fejltilstande, der er værd at planlægge for

At acceptere en peers summary-rute er den mest almindelige selvpåførte skade. Nogen annoncerer et kort aggregat for at forenkle udvekslingen, den fjerne side accepterer det, og trafik for intervaller, der ikke ligger bag tunnelen, følger tunnelen og dør. Filtrer på præcis de forventede præfikser, eller brug en præfiksliste med de rigtige grænser, og accepter aldrig et bart aggregat, fordi det får sessionen til at se pæn ud.

Tidspunktet for tilbagetrækning er det andet. Registrering afhænger af hold-timere, BFD hvis du har aktiveret det, dead-peer-registrering på tunnelen og af, hvor hurtigt den fjerne side stopper med at annoncere. Eksisterende sessioner er et separat problem: en ny rute kan genoprette nye forbindelser, mens etablerede TCP-sessioner fortsætter med at bruge forældede adresser, og stateful firewalls eller NAT på vejen kan holde poster, der ikke længere passer. Sæt applikationsgendannelse i acceptkriterierne i stedet for at antage, at en ruteændring løser alt.

Den tredje er returvejsasymmetri. Trafik kan ankomme over tunnelen og vende tilbage over et udbyderlink, der aldrig var beregnet til at bære det, hvilket viser sig som ensrettet lyd, mislykkede handshakes eller en firewall, der dropper svar. Kontroller begge retninger hver for sig.

Hvad der skal skrives i kontrakten, og hvordan man verificerer det

Bed om de tilladte præfikser skriftligt: hvem der har tilladelse til at udspringe hvert interval, om en default-rute er tilladt, og hvilke adressefamilier tunneltjenesten understøtter. RFC 8212 gjorde eksplicit import- og eksportpolitik til forventningen for eBGP i implementeringer, der følger den, så en peer, der stadig læner sig op ad implicit accepter-alt-adfærd, er værd at stille spørgsmål ved.

Verificer derefter fra enheden i stedet for diagrammet. Nyttige kommandoer på FRR-lignende routere:

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

Tilføj to observationer, som rutetabellen ikke kan give dig. Optag på det ydre interface for at bekræfte, hvilken adresse de indkapslede pakker faktisk retter sig mod, for eksempel tcpdump -ni eth0 udp port 51820 til en WireGuard-tunnel eller et ESP-filter til IPsec. Spor derefter mod peerens offentlige adresse, og sammenlign hoppene med et spor inde i tunnelen; hvis begge følger samme udbyderkæde, bor din redundans i rutepolitikken snarere end i netværket.

Test endelig en tilbagetrækning med vilje. Tag tunnelen ned i et vedligeholdelsesvindue, noter, hvor længe præfikset bliver installeret, hvad der sker med eksisterende sessioner, og om den fjerne side falder tilbage til en rute, du faktisk ville acceptere. Den øvelse siger mere om designet end noget diagram.

En rute er ikke en autorisation. De præfikser, du aftaler at udveksle, siger intet om, hvilke brugere der må nå hvilken tjeneste bag tunnelen, så hold autentificering, tilladte tjenester og host-firewalls præcis, hvor de var. En nåbar peer er heller ikke tilladelse til ubegrænset transit eller til at udspringe vilkårlige adresser, og den slags bemyndigelse hører i kontrakten som et kommercielt spørgsmål, ikke i en BGP-politiklinje.

• Navngiv de præfikser, hver side må udspringe, og dem, den aldrig må acceptere.
• Begræns MSS på tunnelen, og bekræft at store opdateringer faktisk ankommer.
• List de delte underlagsafhængigheder, ikke antallet af tunneler.
• Tag tid på en rigtig tilbagetrækning, og noter, hvad applikationen gør.