Cloud-VPN heeft BGP nodig: waarom andere routingprotocollen falen

De IPsec-beveiligingsassociatie staat, de tunneltellers lopen, en verkeer naar het cloudprefix verdwijnt. De operator probeert dan OSPF in te schakelen op de klantrouter, in de verwachting dat de buur zich vormt, en er gebeurt niets. De tunnel was nooit het ontbrekende stuk: een beheerde cloud-VPN biedt een gedefinieerd routingcontract, en op de grote platforms is dat contract BGP. Totdat er een sessie bestaat en een prefix wordt geaccepteerd, is de tunnel slechts een versleuteld pad zonder bestemmingen erachter.

De tunnel staat en de route ontbreekt

Dat fase 1 en fase 2 worden voltooid, bewijst dat de peers het over de bescherming eens zijn, niet dat een van beide weet waar het verkeer heen moet. Het zijn afzonderlijke toestandsmachines met afzonderlijke faalmodi.

Stel drie vragen in volgorde: is het prefix aangekondigd, is het door de peer geaccepteerd, en is het voor doorsturen geïnstalleerd? Een prefix dat is aangekondigd en gefilterd, is een beleidsprobleem. Een prefix dat nooit is aangekondigd, is een sessie- of configuratieprobleem. Een prefix dat is geaccepteerd maar niet geïnstalleerd, is een routekeuzeprobleem, en elk antwoord wijst naar een ander deel van de configuratie.

Wat de provider u werkelijk geeft

Een beheerde VPN-gateway is geen onbeperkte router. De provider geeft u een gateway met ondersteunde peeradressen, een instelling voor autonoom systeem, prefixlimieten en een gedefinieerd faalgedrag. Dat oppervlak is het product.

Google Cloud documenteert dynamische BGP-routing voor HA VPN, waarbij Cloud Router peer-routes leert en geschikte aangepaste dynamische routes aan de VPC levert. AWS Site-to-Site VPN documenteert een keuze tussen statische en dynamische routing, en beschrijft BGP-livenesscontroles als nuttig voor tunnel-failover, terwijl het ook healthchecks ondersteunt voor apparaten zonder BGP. Het gedrag van het ene platform mag niet uit de productnaam van het andere worden afgeleid.

De praktische consequentie is dat u eerst de beheerde modus kiest en daarna de ondersteunde parameters leest. Een ontwerp dat een adjacencytype veronderstelt dat de dienst niet biedt, is geen configuratieprobleem dat op de klantrouter moet worden opgelost.

Tunnelbescherming en bereikbaarheid zijn aparte taken

IPsec beschermt het verkeer dat voor de tunnel is geselecteerd. BGP levert de bereikbaarheidsinformatie die een prefix geschikt maakt. Een werkende tunnel bewijst niet dat het verwachte prefix is aangekondigd, geaccepteerd of geïnstalleerd.

Stelt u zich een filiaal voor dat 10.42.0.0/16 via twee geschikte tunnelpaden aankondigt. Verwijder één bruikbaar pad en de routekeuze kan veranderen zonder dat iemand de route van elke workload aanpast. Detectie, routekeuze en toepassingsherstel zijn niet onmiddellijk en niet identiek tussen uitrolingen, dus de failovertest moet de hele reeks observeren en niet het eerste pakket dat erdoor komt.

Wanneer een cloudprefix onbereikbaar is, controleer dan de sessiestatus en de geleerde routes voordat u de cryptografie aanraakt. Een SA die staat zonder route erachter is de meest voorkomende vorm van dit symptoom.

Waar OSPF-aannames breken

OSPF, IS-IS of een ander protocol binnen een IPsec-tunnel is heel goed mogelijk op een zelfbeheerd apparaat, waar u beide uiteinden en het doorstuurontwerp bezit. Dat feit zegt niets over een beheerde dienst die alleen BGP als dynamische routingmodus biedt.

Als een voorgesteld ontwerp een adjacency nodig heeft die de dienst niet ondersteunt, wijzig de architectuur dan bewust. Opties zijn een zelfbeheerd apparaat in de VPC, statische routing waar de dienst dat ondersteunt, of een ander connectivityproduct. Alleen op de klantrouter het protocol configureren kan geen peer aan de cloudkant toevoegen die niet bestaat, en het zal het prefix niet laten verschijnen.

Draag het antwoord van de ene leverancier niet over naar de gateway van een andere. Dezelfde woorden, zoals dynamische routing of tunnel-failover, kunnen verschillende mechanismen en verschillende limieten beschrijven.

Lees de dienstvereiste en ontwerp daarna

Schrijf vóór de eerste configuratieregel de buuradressen, de nummers van de autonome systemen, de prefixes die u zult aankondigen en accepteren, de routelimieten en het verwachte gedrag wanneer een tunnel uitvalt op. Die vijf punten zijn het contract waartegen u ontwerpt.

Controleer daarna in dezelfde volgorde: sessie tot stand gebracht, prefix ontvangen, route aanwezig in de routetabel van de VPC en een echte stroom naar een dienstadres. Herhaal na een geforceerde failover, omdat een sessie die opnieuw tot stand komt met een andere routeset kan terugkomen. Als het ontwerp afhangt van convergentie onder één seconde, meet die dan in plaats van haar aan te nemen.

Bewaar het dienstcontract bij de wijzigingsregistratie. Wanneer iemand later vraagt waarom de tunnel geen OSPF kan draaien, is het antwoord een productgrens, geen protocolbeperking, en de registratie zou dat moeten vermelden.