Hvorfor BGP over en VPN ikke styrer underlagsbanen din

To nettsteder peerer BGP over en IPsec-tunnel, lærer hverandres prefikser, og diagrammet blir omdøpt til banekontroll. Det er den merkelappen som starter forvirringen. Sesjonen utveksler nåbarhet og anvender politikk, men den har ingenting den skulle ha sagt om hvilken leverandør, kabel eller ruter som frakter de krypterte pakkene. Jeg har sett et team bygge om en fungerende tunnel fordi de forventet at en BGP-ruteendring skulle flytte trafikken til en annen fiberbane som sesjonen aldri kunne påvirke.

Hva folk tror en sesjon kjøper

Det meste av forventningen kommer fra hvordan en ruteendring ser ut i et laboratorium. Du annonserer et prefiks over tunnelen, den fjerne siden installerer det, og trafikken flytter seg. Den samme sekvensen skjer på en ruter som faktisk har knotter for trafikktekniske grep, så de to blir blandet sammen. I laboratoriet deler begge nettstedene vanligvis én aksesslinje, og det er nettopp derfor forskjellen aldri vises der.

BGP er en nåbarhetsprotokoll. Den forteller en peer at du kan levere pakker for et prefiks, og lar hver side rangere tilbudene den mottar. Det er virkelig nyttig over en tunnel: prefikser dukker opp og forsvinner etter hvert som nettsteder kommer og går, og du kan avvise et område uten å skrive en statisk rute på hver kant-enhet. Det den ikke gjør, er å sette en leverandørs rutere under din kontroll.

Underlaget bærer den ytre overskriften. Tunnelsluttpunktet ditt sender krypterte pakker til en peer-adresse, og nettet mellom de to adressene videresender dem med rutene operatørene deres har installert. Ingenting i BGP-sesjonen endrer den beslutningen, med mindre den samme leverandøren tilbyr en støttet tjeneste som gjør det.

Hva sesjonen faktisk bærer

BGP-høyttaleren åpner en TCP-forbindelse til port 179 hos peeren sin og bruker meldingsformatene og stiattributtene som er definert i RFC 4271. Når peer-adressen ligger inne i tunnelen, må tunnelen være oppe og adressen nåbar før sesjonen i det hele tatt kan starte. En fullført IKE-utveksling er ikke en BGP-nabo. Rutebaserte IPsec-implementasjoner slipper trafikk gjennom først når en samsvarende tunnelrute finnes, og den policybaserte trenger peer-adressen inne i den beskyttede velgeren. Snu dette på hodet og du får den klassiske tilstanden der tunnelen er grønn og sesjonen sitter ledig.

Når sesjonen er oppe, bestemmer politikken hva som krysser den. Prefikslister, AS-path-filtre, et tak på maksimalt antall prefikser og en uttrykkelig beslutning om standardruter er minimumet, og de gjelder i begge retninger. En peer som godtar alt den mottar, kan gi deg en standardrute som stille erstatter lokal internettilgang. De to retningene trenger separate lister, fordi det du godtar fra en peer, og det du annonserer til den, er to forskjellige 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

Deretter biter MTU. Innkapslingen krymper den brukbare nyttelasten, så en stor oppdatering kan stoppe en sesjon som ser fullstendig etablert ut: peeren blir stående oppe, prefiksene kommer aldri, og ingenting åpenbart havner i loggen. Begrens TCP MSS på tunnelgrensesnittet, eller sett en tunnel-MTU med plass til overhead, før du gir filtrene skylden.

Hvor de ytre pakkene fortsatt går

Krypterte pakker fra ett nettsted til det andre går ut gjennom det den lokale ruteren velger for peerens offentlige adresse. Hvis begge nettstedene kjøper transit fra samme leverandør, krysser samme metrofasilitet, eller den ene siden sitter bak carrier-grade NAT, overlever tunnelen en leverandørfeil bare ved et tilfelle. Å telle tunnelikoner i et overvåkingsverktøy forteller deg ingenting om dette.

Rutevalg og installasjon av videresending er også separate hendelser. Et prefiks kan sitte i BGP-tabellen som det beste og likevel mangle i videresendingstabellen, fordi neste hopp ikke kan løses opp eller en mer spesifikk rute vinner. Når noen rapporterer at BGP har lært prefikset, men at trafikken ikke flyter, er det nyttige spørsmålet om det er installert og hvilket neste hopp det peker på.

Det ærlige svaret for en designgjennomgang er en liste over delte avhengigheter: aksesskrets, oppstrømsleverandør, fasilitet og enhver tilstandsbeholdende enhet på returveien. En sesjon over tunnelen kan ikke fjerne en avhengighet den ikke sitter over.

Tre beslutninger det er verdt å skille

Når et design blander disse, går hver driftsforstyrrelsesdiskusjon i sirkel. Skill dem først på papiret, og knytt deretter hver enkelt til enheten som faktisk håndhever den.

Hver rad har en annen eier. Den første er en forhandling, den andre er konfigurasjon på dine enheter, den tredje er stort sett noen andres nett. En endringsforespørsel som navngir raden den berører, er langt lettere å godkjenne enn en som sier BGP-problem.

Feilmoduser det er verdt å planlegge for

Å godta en peers sammendragsrute er den vanligste selvpåførte skaden. Noen annonserer et kort aggregat for å forenkle utvekslingen, den fjerne siden godtar det, og trafikk for områder som ikke ligger bak tunnelen følger tunnelen og dør. Filtrer på de nøyaktig forventede prefiksene, eller bruk en prefiksliste med riktige grenser, og godta aldri et bart aggregat fordi det får sesjonen til å se ryddig ut.

Tidspunktet for tilbaketrekking er det andre. Deteksjon avhenger av holde-timere, BFD hvis du aktiverte det, død-peer-deteksjon på tunnelen og hvor raskt den fjerne siden slutter å annonsere. Eksisterende sesjoner er et eget problem: en ny rute kan gjenopprette nye forbindelser mens etablerte TCP-sesjoner fortsetter å bruke utdaterte adresser, og tilstandsbeholdende brannmurer eller NAT på veien kan holde oppføringer som ikke lenger passer. Sett applikasjonsgjenoppretting i akseptkriteriene i stedet for å anta at en ruteendring ordner alt.

Den tredje er asymmetri i returveien. Trafikk kan ankomme over tunnelen og komme tilbake over en leverandørlenke som aldri var ment å bære den, noe som viser seg som enveis lyd, mislykkede håndtrykk eller en brannmur som slipper svarene. Sjekk begge retninger hver for seg.

Hva som skal skrives i kontrakten, og hvordan det verifiseres

Be om de tillatte prefiksene skriftlig: hvem som har rett til å opprette hvert område, om en standardrute er tillatt, og hvilke adressefamilier tunneltjenesten støtter. RFC 8212 gjorde uttrykkelig import- og eksportpolitikk til forventningen for eBGP i implementasjoner som følger den, så en peer som fortsatt lener seg på implisitt godta-alt-atferd, er verdt å stille spørsmål ved.

Verifiser deretter fra enheten i stedet for fra diagrammet. Nyttige kommandoer på FRR-lignende rutere:

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

Legg til to observasjoner som rutetabellen ikke kan gi deg. Ta opp på det ytre grensesnittet for å bekrefte hvilken adresse de innkapslede pakkene faktisk retter seg mot, for eksempel tcpdump -ni eth0 udp port 51820 for en WireGuard-tunnel, eller et ESP-filter for IPsec. Spor deretter mot peerens offentlige adresse og sammenlign hoppene med et spor inne i tunnelen; hvis begge følger samme leverandørkjede, bor redundansen din i rutepolitikken og ikke i nettet.

Til slutt, test en tilbaketrekking med vilje. Ta tunnelen ned i et vedlikeholdsvindu, noter hvor lenge prefikset blir installert, hva som skjer med eksisterende sesjoner, og om den fjerne siden faller tilbake til en rute du faktisk ville godta. Den øvelsen sier mer om designet enn noe diagram.

En rute er ikke en autorisasjon. Prefiksene du blir enige om å utveksle, sier ingenting om hvilke brukere som kan nå hvilken tjeneste bak tunnelen, så hold autentisering, tillatte tjenester og vertsbrannmurer nøyaktig der de var. En nåbar peer er heller ikke tillatelse til ubegrenset transit eller til å opprette vilkårlige adresser, og den slags myndighet hører hjemme i kontrakten som et kommersielt spørsmål, ikke i en BGP-politikklinje.

• Navngi prefiksene hver side kan opprette, og de den aldri må godta.
• Begrens MSS på tunnelen og bekreft at store oppdateringer faktisk ankommer.
• List de delte underlagsavhengighetene, ikke antall tunneler.
• Ta tid på en reell tilbaketrekking og noter hva applikasjonen gjør.