Cloud-VPN kræver BGP: hvorfor andre routingprotokoller fejler

IPsec-sikkerhedsassociationen er oppe, tunnel-tællerne bevæger sig, og trafikken til cloud-præfikset forsvinder. Operatøren prøver så at aktivere OSPF på kundens router og forventer, at naboen dannes, og der sker intet. Tunnelen var aldrig den manglende brik: en administreret cloud-VPN udstiller en defineret routingkontrakt, og på de store platforme er den kontrakt BGP. Indtil der findes en session, og et præfiks accepteres, er tunnelen bare en krypteret vej uden destinationer bag sig.

Tunnelen er oppe, og ruten mangler

At fase 1 og fase 2 fuldføres beviser, at parterne er enige om beskyttelsen, ikke at nogen af siderne ved, hvor trafikken skal sendes hen. Det er separate tilstandsmaskiner med separate fejltilstande.

Stil tre spørgsmål i rækkefølge: blev præfikset annonceret, blev det accepteret af naboen, og blev det installeret til videresendelse? Et præfiks, der blev annonceret og filtreret, er et politikproblem. Et præfiks, der aldrig blev annonceret, er et session- eller konfigurationsproblem. Et præfiks, der blev accepteret men ikke installeret, er et rutervalgsproblem, og hvert svar peger på en anden del af konfigurationen.

Hvad udbyderen faktisk giver dig

En administreret VPN-gateway er ikke en ubegrænset router. Udbyderen giver dig en gateway med understøttede peer-adresser, en indstilling for autonomt system, præfiksgrænser og en defineret fejlopførsel. Den flade er produktet.

Google Cloud dokumenterer dynamisk BGP-routing til HA VPN, hvor Cloud Router lærer peer-ruter og leverer egnede brugerdefinerede dynamiske ruter til VPC'en. AWS Site-to-Site VPN dokumenterer et valg mellem statisk og dynamisk routing og beskriver BGP-liveness-tjek som nyttige til tunnel-failover, mens den også understøtter sundhedstjek til enheder uden BGP. Ingen af platformenes opførsel bør udledes af den andens produktnavn.

Den praktiske konsekvens er, at du først vælger den administrerede tilstand og derefter læser de understøttede knapper. Et design, der forudsætter en adjacency-type, som tjenesten ikke tilbyder, er ikke et konfigurationsproblem, der skal løses på kundens router.

Tunnelbeskyttelse og nåbarhed er separate opgaver

IPsec beskytter den trafik, der er valgt til tunnelen. BGP leverer den nåbarhedsinformation, der gør et præfiks kvalificeret. En fungerende tunnel beviser ikke, at det forventede præfiks blev annonceret, accepteret eller installeret.

Forestil dig en filial, der annoncerer 10.42.0.0/16 gennem to kvalificerede tunnelstier. Fjern én brugbar sti, og rutervalget kan ændre sig, uden at nogen redigerer hver arbejdsbelastnings rute. Registrering, rutervalg og applikationsgendannelse er ikke øjeblikkelige og ikke identiske på tværs af implementeringer, så failover-testen skal observere hele forløbet og ikke den første pakke, der kommer igennem.

Når et cloud-præfiks er unåeligt, tjek sessionstilstanden og de lærte ruter, før du rører kryptografien. En SA, der er oppe uden en rute bag sig, er den mest almindelige form for dette symptom.

Hvor OSPF-antagelser bryder sammen

OSPF, IS-IS eller en anden protokol inde i en IPsec-tunnel er fuldt mulig på et selvadministreret apparat, hvor du ejer begge ender og videresendelsesdesignet. Den kendsgerning siger intet om en administreret tjeneste, der kun tilbyder BGP som sin dynamiske routingtilstand.

Hvis et foreslået design kræver en adjacency, som tjenesten ikke understøtter, så ændr arkitekturen bevidst. Mulighederne omfatter et selvadministreret apparat i VPC'en, statisk routing hvor tjenesten understøtter det, eller et andet connectivity-produkt. At konfigurere protokollen alene på kundens router kan ikke tilføje en peer på cloud-siden, der ikke findes, og det får ikke præfikset til at dukke op.

Flyt ikke én leverandørs svar over på en anden leverandørs gateway. De samme ord, som dynamisk routing eller tunnel-failover, kan beskrive forskellige mekanismer og forskellige grænser.

Læs servicekravet, og design derefter

Før den første konfigurationslinje skal du skrive nabo-adresserne, numrene på de autonome systemer, de præfikser du vil annoncere og acceptere, rutegrænserne og den forventede opførsel, når en tunnel fejler, ned. De fem punkter er den kontrakt, du designer imod.

Bekræft derefter i samme rækkefølge: session etableret, præfiks modtaget, rute til stede i VPC'ens rutetabel og et reelt flow til en serviceadresse. Gentag efter en tvungen failover, fordi en session, der genetableres, kan komme tilbage med et andet rutesæt. Hvis designet afhænger af sub-sekunds konvergens, så mål den i stedet for at antage den.

Opbevar servicekontrakten sammen med ændringsregistreringen. Når nogen senere spørger, hvorfor tunnelen ikke kan køre OSPF, er svaret en produktgrænse, ikke en protokolbegrænsning, og registreringen bør sige det.