Kvifor BGP over ein VPN ikkje styrer underlagsbana di

To nettstader peerar BGP over ein IPsec-tunnel, lærer kvarandre sine prefiks, og diagrammet vert omdøypt til banekontroll. Det er den merkelappen som startar forvirringa. Sesjonen byter nåbarheit og brukar politikk, men han har ingenting han skulle ha sagt om kva leverandør, kabel eller ruter som fraktar dei krypterte pakkane. Eg har sett eit team byggje om ein fungerande tunnel fordi dei venta at ei BGP-ruteendring skulle flytte trafikken til ei anna fiberbane som sesjonen aldri kunne påverke.

Kva folk trur ein sesjon kjøper

Det meste av forventninga kjem frå korleis ei ruteendring ser ut i eit laboratorium. Du annonserer eit prefiks over tunnelen, den fjerne sida installerer det, og trafikken flyttar seg. Den same sekvensen skjer på ein ruter som faktisk har knottar for trafikktekniske grep, så dei to vert blanda saman. I laboratoriet deler begge nettstadene vanlegvis éi aksesslinje, og det er nettopp derfor skilnaden aldri viser seg der.

BGP er ein nåbarheitsprotokoll. Han fortel ein peer at du kan levere pakkar for eit prefiks, og lèt kvar side rangere tilboda ho får. Det er verkeleg nyttig over ein tunnel: prefiks dukkar opp og forsvinn etter kvart som nettstadene kjem og går, og du kan avvise eit område utan å skrive ei statisk rute på kvar kant-eining. Det han ikkje gjer, er å setje rutarane til ein leverandør under din kontroll.

Underlaget ber den ytre overskrifta. Tunnelsluttpunktet ditt sender krypterte pakkar til ein peer-adresse, og nettet mellom dei to adressene videresender dei med rutene operatørane deira har installert. Ingenting i BGP-sesjonen endrar den avgjerda, med mindre den same leverandøren tilbyr ei støtta teneste som gjer det.

Kva sesjonen faktisk ber

BGP-høgtalaren opnar ei TCP-tilkopling til port 179 hos peeren sin og brukar meldingsformata og stiattributta som er definerte i RFC 4271. Når peer-adressa ligg inne i tunnelen, må tunnelen vere oppe og adressa nåbar før sesjonen i det heile kan starte. Ei fullført IKE-utveksling er ikkje ein BGP-nabo. Rutebaserte IPsec-implementasjonar slepp trafikk gjennom først når ei samsvarande tunnelrute finst, og den policybaserte treng peer-adressa inne i den verna veljaren. Snu dette på hovudet og du får den klassiske tilstanden der tunnelen er grøn og sesjonen sit ledig.

Når sesjonen er oppe, avgjer politikken kva som kryssar han. Prefikslister, AS-path-filter, eit tak på maksimalt tal prefiks og ei uttrykkeleg avgjerd om standardruter er minimumet, og dei gjeld i begge retningar. Ein peer som godtek alt han mottek, kan gje deg ei standardrute som stille erstattar lokal internettilgang. Dei to retningane treng separate lister, fordi det du godtek frå ein peer, og det du annonserer til han, er to ulike avgjerder.

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 bit MTU. Innpakkinga krympar den brukbare nyttelasta, så ein stor oppdatering kan stoppe ein sesjon som ser fullstendig etablert ut: peeren blir ståande oppe, prefiksa kjem aldri, og ingenting openbert hamnar i loggen. Avgrens TCP MSS på tunnelgrensesnittet, eller set ein tunnel-MTU med plass til overhead, før du gjev filtera skulda.

Kvar dei ytre pakkane framleis går

Krypterte pakkar frå ein nettstad til den andre går ut gjennom det den lokale ruteren vel for den offentlege adressa til peeren. Viss begge nettstadene kjøper transit frå same leverandør, kryssar same metrofasilitet, eller den eine sida sit bak carrier-grade NAT, overlever tunnelen ein leverandørfeil berre ved eit tilfelle. Å telje tunnelikon i eit overvakingsverktøy fortel deg ingenting om dette.

Ruteval og installasjon av videresending er også separate hendingar. Eit prefiks kan sitje i BGP-tabellen som det beste og likevel mangle i videresendingstabellen, fordi neste hopp ikkje kan løysast opp eller ei meir spesifikk rute vinn. Når nokon rapporterer at BGP har lært prefikset, men at trafikken ikkje flyt, er det nyttige spørsmålet om det er installert og kva neste hopp det peikar på.

Det ærlege svaret for ein designgjennomgang er ei liste over delte avhengnader: aksesskrins, oppstraumsleverandør, fasilitet og eining kvar tilstandsbehaldande eining på returvegen. Ein sesjon over tunnelen kan ikkje fjerne ei avhengnad han ikkje sit over.

Tre avgjerder det er verdt å skilje

Når eit design blandar desse, går kvar driftsforstyrringsdiskusjon i sirkel. Skil dei først på papiret, og knyt deretter kvar einskild til eininga som faktisk handhevar han.

Kvar rad har ein annan eigar. Den første er ein forhandling, den andre er konfigurasjon på einingane dine, den tredje er stort sett nokon andre sitt nett. Ein endringsførespurnad som nemner rada han rører, er langt lettare å godkjenne enn ein som seier BGP-problem.

Feilmodusar det er verdt å planleggje for

Å godta samandragsruta til ein peer er den vanlegaste sjølvpåførte skaden. Nokon annonserer eit kort aggregat for å forenkle utvekslinga, den fjerne sida godtek det, og trafikk for område som ikkje ligg bak tunnelen følgjer tunnelen og døyr. Filtrer på dei nøyaktig forventa prefiksa, eller bruk ei prefiksliste med riktige grenser, og godta aldri eit bart aggregat fordi det får sesjonen til å sjå ryddig ut.

Tidspunktet for tilbaketrekking er det andre. Deteksjon er avhengig av halde-timar, av BFD viss du aktiverte det, av død-peer-deteksjon på tunnelen og av kor raskt den fjerne sida sluttar å annonsere. Eksisterande sesjonar er eit eige problem: ei ny rute kan gjenopprette nye tilkoplingar medan etablerte TCP-sesjonar held fram med å bruke utdaterte adresser, og tilstandsbehaldande brannmurar eller NAT på vegen kan halde oppføringar som ikkje lenger passar. Set applikasjonsgjenoppretting i akseptkriteria i staden for å anta at ei ruteendring ordnar alt.

Den tredje er asymmetri i returvegen. Trafikk kan kome over tunnelen og kome tilbake over ei leverandørlenkje som aldri var meint å bere han, noko som viser seg som einvegs lyd, mislukka handtrykk eller ein brannmur som slepp svara. Sjekk begge retningar kvar for seg.

Kva som skal skrivast i kontrakten, og korleis det vert stadfesta

Be om dei tillatne prefiksa skriftleg: kven som har rett til å opprette kvart område, om ei standardrute er tillaten, og kva adressefamiliar tunneltenesta støttar. RFC 8212 gjorde uttrykkeleg import- og eksportpolitikk til forventninga for eBGP i implementasjonar som følgjer han, så ein peer som framleis lener seg på implisitt godta-alt-åtferd, er verdt å stille spørsmål ved.

Stadfest deretter frå eininga i staden for frå diagrammet. Nyttige kommandoar på FRR-liknande rutarar:

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 observasjonar som rutetabellen ikkje kan gje deg. Ta opp på det ytre grensesnittet for å stadfeste kva adresse dei innpakka pakkane faktisk rettar seg mot, til dømes tcpdump -ni eth0 udp port 51820 for ein WireGuard-tunnel, eller eit ESP-filter for IPsec. Spor deretter mot den offentlege adressa til peeren og samanlikn hoppa med eit spor inne i tunnelen; viss begge følgjer same leverandørkjeda, bur redundansen din i rutepolitikken og ikkje i nettet.

Til slutt, test ein tilbaketrekking med vilje. Ta tunnelen ned i eit vedlikehaldsvindauge, noter kor lenge prefikset blir installert, kva som skjer med eksisterande sesjonar, og om den fjerne sida fell tilbake til ei rute du faktisk ville godta. Den øvinga seier meir om designet enn noko diagram.

Ei rute er ikkje ein autorisasjon. Prefiksa du blir samde om å bytte, seier ingenting om kva brukarar som kan nå kva teneste bak tunnelen, så hald autentisering, tillatne tenester og vertsbrannmurar nøyaktig der dei var. Ein nåbar peer er heller ikkje løyve til ubegrensa transit eller til å opprette vilkårlege adresser, og den slags myndigheit høyrer heime i kontrakten som eit kommersielt spørsmål, ikkje i ei BGP-politikklinje.

• Nemn prefiksa kvar side kan opprette, og dei ho aldri må godta.
• Avgrens MSS på tunnelen og stadfest at store oppdateringar faktisk kjem fram.
• List dei delte underlagsavhengnadene, ikkje talet på tunnelar.
• Ta tid på ein reell tilbaketrekking og noter kva applikasjonen gjer.