Moln-VPN kräver BGP: varför andra routingprotokoll misslyckas

IPsec-säkerhetsassociationen är uppe, tunnelmätarna rör sig och trafiken till molnprefixet försvinner. Operatören försöker då aktivera OSPF på kundens router, förväntar sig att grannen bildas, och ingenting händer. Tunneln var aldrig den saknade biten: ett hanterat moln-VPN exponerar ett definierat routingkontrakt, och på de stora plattformarna är det kontraktet BGP. Tills det finns en session och ett prefix accepteras är tunneln bara en krypterad väg utan destinationer bakom sig.

Tunneln är uppe och rutten saknas

Att fas 1 och fas 2 slutförs bevisar att parterna är överens om skyddet, inte att någon sida vet vart trafiken ska skickas. Det är separata tillståndsmaskiner med separata felmoder.

Ställ tre frågor i ordning: annonserades prefixet, accepterades det av grannen och installerades det för vidarebefordran? Ett prefix som annonserades och filtrerades är ett policyproblem. Ett prefix som aldrig annonserades är ett sessions- eller konfigurationsproblem. Ett prefix som accepterades men inte installerades är ett vägvalsproblem, och varje svar pekar på en annan del av konfigurationen.

Vad leverantören faktiskt ger dig

En hanterad VPN-gateway är inte en obegränsad router. Leverantören ger dig en gateway med stödda grannadresser, en inställning för autonoma system, prefixgränser och ett definierat felbeteende. Den ytan är produkten.

Google Cloud dokumenterar dynamisk BGP-routing för HA VPN, där Cloud Router lär sig grannrutter och levererar lämpliga anpassade dynamiska rutter till VPC:n. AWS Site-to-Site VPN dokumenterar ett val mellan statisk och dynamisk routing, och beskriver BGP-livskontroller som användbara för tunnel-failover samtidigt som det också stöder hälsokontroller för enheter utan BGP. Ingen av plattformarnas beteende bör härledas från den andras produktnamn.

Den praktiska konsekvensen är att du först väljer det hanterade läget och sedan läser de stödda parametrarna. En design som förutsätter en grannskapstyp som tjänsten inte erbjuder är inte ett konfigurationsproblem att lösa på kundens router.

Tunnelskydd och nåbarhet är separata uppgifter

IPsec skyddar trafiken som valts för tunneln. BGP levererar nåbarhetsinformationen som gör ett prefix lämpligt. En fungerande tunnel bevisar inte att det förväntade prefixet annonserades, accepterades eller installerades.

Föreställ dig en filial som annonserar 10.42.0.0/16 via två lämpliga tunnelvägar. Ta bort en användbar väg och vägvalet kan ändras utan att någon redigerar varje arbetsbelastnings rutt. Identifiering, vägval och applikationsåterställning är inte omedelbara och inte identiska mellan utrullningar, så failover-testet måste observera hela sekvensen och inte det första paketet som passerar.

När ett molnprefix inte är nåbart, kontrollera sessionsstatusen och de inlärda rutterna innan du rör kryptografin. En SA som är uppe utan rutt bakom sig är den vanligaste formen av detta symptom.

Där OSPF-antaganden bryter samman

OSPF, IS-IS eller ett annat protokoll inne i en IPsec-tunnel är fullt möjligt på en självhanterad apparat, där du äger båda ändarna och vidarebefordringsdesignen. Det faktumet säger ingenting om en hanterad tjänst som bara erbjuder BGP som dynamiskt routingläge.

Om en föreslagen design behöver en grannskap som tjänsten inte stöder, ändra arkitekturen medvetet. Alternativen inkluderar en självhanterad apparat i VPC:n, statisk routing där tjänsten stöder det, eller en annan anslutningsprodukt. Att konfigurera protokollet bara på kundens router kan inte lägga till en granne på molnsidan som inte finns, och det får inte prefixet att dyka upp.

Flytta inte en leverantörs svar till en annan leverantörs gateway. Samma ord, som dynamisk routing eller tunnel-failover, kan beskriva olika mekanismer och olika gränser.

Läs tjänstekravet och designa sedan

Skriv ner grannadresserna, numren för de autonoma systemen, prefixen du kommer att annonsera och acceptera, ruttgränserna och det förväntade beteendet när en tunnel fallerar, innan den första konfigurationsraden. De fem punkterna är kontraktet du designar mot.

Verifiera sedan i samma ordning: session etablerad, prefix mottaget, rutt finns i VPC:ns routingtabell och ett verkligt flöde till en tjänsteadress. Upprepa efter en påtvingad failover, eftersom en session som återupprättas kan komma tillbaka med en annan ruttuppsättning. Om designen beror på konvergens under en sekund, mät den i stället för att anta den.

Behåll tjänstekontraktet tillsammans med ändringsloggen. När någon senare frågar varför tunneln inte kan köra OSPF är svaret en produktgräns, inte en protokollbegränsning, och loggen bör säga det.