Waarom BGP over een VPN je onderlaagpad niet beheert

Twee locaties peeren BGP over een IPsec-tunnel, leren elkaars prefixen, en het diagram wordt omgedoopt tot padbeheersing. Dat label is waar de verwarring begint. De sessie wisselt wel bereikbaarheid uit en past wel beleid toe, maar heeft niets te zeggen over welke provider, kabel of router de versleutelde pakketten vervoert. Ik heb een team een werkende tunnel opnieuw zien bouwen omdat ze verwachtten dat een BGP-routewijziging het verkeer naar een ander glasvezelpad zou verplaatsen dat de sessie nooit kon beïnvloeden.

Wat mensen denken dat een sessie koopt

Het grootste deel van de verwachting komt uit hoe een routewijziging in een lab uitziet. Je adverteert een prefix over de tunnel, de andere kant installeert die, en het verkeer beweegt. Dezelfde volgorde gebeurt op een router die echt knoppen voor traffic engineering heeft, dus de twee worden verward. In het lab delen beide locaties meestal één accesslink, en precies daarom is het verschil daar nooit te zien.

BGP is een bereikbaarheidsprotocol. Het vertelt een peer dat je pakketten voor een prefix kunt afleveren en laat elke kant de ontvangen aanbiedingen rangschikken. Dat is over een tunnel echt nuttig: prefixen verschijnen en verdwijnen terwijl locaties komen en gaan, en je kunt een bereik weigeren zonder op elk edge-apparaat een statische route te schrijven. Wat het niet doet, is de routers van een provider onder jouw controle brengen.

De onderlaag draagt de buitenste kop. Je tunneleindpunt stuurt versleutelde pakketten naar een peer-adres, en het netwerk tussen die twee adressen stuurt ze door met de routes die zijn operators hebben geïnstalleerd. Niets in de BGP-sessie verandert die beslissing, tenzij dezelfde provider een ondersteunde dienst aanbiedt die dat doet.

Wat de sessie echt draagt

De BGP-speaker opent een TCP-verbinding naar poort 179 van zijn peer en gebruikt de berichtformaten en padattributen die in RFC 4271 zijn gedefinieerd. Als het peer-adres in de tunnel ligt, moet de tunnel omhoog zijn en dat adres bereikbaar voordat de sessie überhaupt kan beginnen. Een voltooide IKE-uitwisseling is geen BGP-buur. Op routes gebaseerde IPsec-implementaties laten verkeer pas door als er een bijpassende tunnelroute bestaat, en de op beleid gebaseerde heeft het peer-adres binnen de beschermde selector nodig. Dit omdraaien levert de klassieke toestand op waarin de tunnel groen is en de sessie werkloos staat.

Zodra de sessie omhoog is, bepaalt beleid wat haar kruist. Prefixlijsten, AS-path-filters, een plafond voor maximaal aantal prefixen en een expliciete beslissing over standaardroutes zijn het minimum, en ze gelden in beide richtingen. Een peer die alles accepteert wat hij ontvangt, kan je een standaardroute geven die de lokale internettoegang stil vervangt. De twee richtingen hebben aparte lijsten nodig, want wat je van een peer accepteert en wat je hem adverteert zijn verschillende beslissingen.

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

Daarna bijt de MTU. De inkapseling verkleint de bruikbare payload, dus een grote update kan een sessie blokkeren die perfect gevestigd lijkt: de peer blijft omhoog, prefixen komen nooit aan, en niets duidelijks belandt in het log. Knel de TCP MSS op de tunnelinterface, of stel een tunnel-MTU in met ruimte voor de overhead, voordat je de filters de schuld geeft.

Waar de buitenste pakketten nog steeds heen gaan

Versleutelde pakketten van de ene locatie naar de andere vertrekken via wat de lokale router kiest voor het openbare adres van de peer. Als beide locaties transit bij dezelfde provider kopen, dezelfde metro-faciliteit passeren, of één kant achter carrier-grade NAT zit, overleeft de tunnel een providerstoring alleen per ongeluk. Tunnelpictogrammen tellen in een monitoringstool vertelt je daar niets over.

Routeselectie en het installeren van doorsturing zijn ook aparte gebeurtenissen. Een prefix kan als beste in de BGP-tabel staan en toch in de doorstuurtabel ontbreken, omdat de volgende hop niet oplosbaar is of een specifiekere route wint. Als iemand meldt dat BGP het prefix heeft geleerd maar het verkeer niet stroomt, is de nuttige vraag of het is geïnstalleerd en naar welke volgende hop het wijst.

Het eerlijke antwoord voor een ontwerpbeoordeling is een lijst gedeelde afhankelijkheden: accesscircuit, upstream-provider, faciliteit en elk stateful apparaat op het retourpad. Een sessie over de tunnel kan geen afhankelijkheid wegnemen waar hij niet boven zit.

Drie beslissingen die het waard zijn te scheiden

Als een ontwerp deze dingen door elkaar haalt, gaat elk storinggesprek in cirkels. Scheid ze eerst op papier en koppel daarna elk aan het apparaat dat het echt afdwingt.

Elke rij heeft een andere eigenaar. De eerste is een onderhandeling, de tweede is configuratie op jouw apparaten, de derde is grotendeels iemand anders zijn netwerk. Een wijzigingsverzoek dat de rij noemt die het raakt, is veel makkelijker goed te keuren dan een dat BGP-probleem zegt.

Storingmodi waar het de moeite waard is op te plannen

De samenvattingsroute van een peer accepteren is de meest voorkomende zelf toegebrachte wond. Iemand adverteert een kort aggregat om de uitwisseling te vereenvoudigen, de andere kant accepteert het, en verkeer voor bereiken die niet achter de tunnel liggen volgt de tunnel en sterft. Filter op de precies verwachte prefixen, of gebruik een prefixlijst met de juiste grenzen, en accepteer nooit een kaal aggregat omdat het de sessie netjes laat lijken.

De timing van intrekking is de tweede. Detectie hangt af van hold-timers, van BFD als je dat hebt ingeschakeld, van dead-peer-detectie van de tunnel en van hoe snel de andere kant stopt met adverteren. Bestaande sessies zijn een apart probleem: een nieuwe route kan nieuwe verbindingen herstellen terwijl gevestigde TCP-sessies verouderde adressen blijven gebruiken, en stateful firewalls of NAT op het pad kunnen vermeldingen houden die niet meer kloppen. Zet applicatieherstel in de acceptatiecriteria in plaats van aan te nemen dat een routewijziging alles oplost.

De derde is asymmetrie van het retourpad. Verkeer kan via de tunnel aankomen en terugkeren over een providerlink die nooit bedoeld was om het te dragen, wat zich uit als eenrichtingsaudio, mislukte handshakes of een firewall die antwoorden laat vallen. Controleer beide richtingen apart.

Wat in het contract te schrijven, en hoe het te verifiëren

Vraag de toegestane prefixen schriftelijk: wie bevoegd is elk bereik te origineren, of een standaardroute is toegestaan, en welke adresfamilies de tunneldienst ondersteunt. RFC 8212 maakte expliciet import- en exportbeleid de verwachting voor eBGP in implementaties die het volgen, dus een peer die nog op impliciet alles-accepteren leunt, is een vraag waard.

Verifieer dan vanaf het apparaat in plaats van het diagram. Nuttige commando’s op FRR-achtige routers:

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

Voeg twee observaties toe die de routetabel je niet kan geven. Leg vast op de buitenste interface om te bevestigen welk adres de ingekapselde pakketten echt richten, bijvoorbeeld tcpdump -ni eth0 udp port 51820 voor een WireGuard-tunnel, of een ESP-filter voor IPsec. Traceer dan richting het openbare adres van de peer en vergelijk de hops met een trace binnen de tunnel; volgen beide dezelfde providerketen, dan leeft je redundantie in het routebeleid en niet in het netwerk.

Test ten slotte met opzet een intrekking. Haal de tunnel naar beneden tijdens een onderhoudsvenster, noteer hoe lang het prefix geïnstalleerd blijft, wat er met bestaande sessies gebeurt en of de andere kant terugvalt op een route die je echt zou accepteren. Die oefening zegt meer over het ontwerp dan welk diagram dan ook.

Een route is geen autorisatie. De prefixen die je afspreekt uit te wisselen zeggen niets over welke gebruikers welke dienst achter de tunnel mogen bereiken, dus houd authenticatie, toegestane diensten en host-firewalls precies waar ze waren. Een bereikbare peer is ook geen toestemming voor onbeperkte transit of voor het origineren van willekeurige adressen, en dat soort bevoegdheid hoort in het contract als commerciële vraag, niet in een BGP-beleidsregel.

• Benoem de prefixen die elke kant mag origineren, en die welke hij nooit mag accepteren.
• Knel de MSS op de tunnel en bevestig dat grote updates echt aankomen.
• Noem de gedeelde onderlaagafhankelijkheden, niet het aantal tunnels.
• Meet een echte intrekking en noteer wat de applicatie doet.