Sky-VPN trenger BGP: hvorfor andre rutingprotokoller mislykkes

IPsec-sikkerhetsassosiasjonen er oppe, tunnel-tellerne beveger seg, og trafikken til sky-prefikset forsvinner. Operatøren prøver så å aktivere OSPF på kundens ruter, forventer at naboen dannes, og ingenting skjer. Tunnelen var aldri den manglende brikken: en administrert sky-VPN eksponerer en definert rutingkontrakt, og på de store plattformene er den kontrakten BGP. Inntil det finnes en sesjon og et prefiks godtas, er tunnelen bare en kryptert vei uten destinasjoner bak seg.

Tunnelen er oppe, og ruten mangler

At fase 1 og fase 2 fullføres beviser at partene er enige om beskyttelsen, ikke at noen av sidene vet hvor trafikken skal sendes. Det er separate tilstandsmaskiner med separate feilmoduser.

Still tre spørsmål i rekkefølge: ble prefikset annonsert, ble det godtatt av naboen, og ble det installert for videresending? Et prefiks som ble annonsert og filtrert, er et politikkproblem. Et prefiks som aldri ble annonsert, er et sesjons- eller konfigurasjonsproblem. Et prefiks som ble godtatt men ikke installert, er et ruteproblem, og hvert svar peker på en annen del av konfigurasjonen.

Hva leverandøren faktisk gir deg

En administrert VPN-gateway er ikke en ubegrenset ruter. Leverandøren gir deg en gateway med støttede nabo-adresser, en innstilling for autonomt system, prefiksgrenser og en definert feilatferd. Den flaten er produktet.

Google Cloud dokumenterer dynamisk BGP-ruting for HA VPN, der Cloud Router lærer naboruter og leverer egnede egendefinerte dynamiske ruter til VPC-en. AWS Site-to-Site VPN dokumenterer et valg mellom statisk og dynamisk ruting, og beskriver BGP-livssjekker som nyttige for tunnel-failover, samtidig som det støtter helsesjekker for enheter uten BGP. Ingen av plattformenes atferd bør utledes fra den andres produktnavn.

Den praktiske konsekvensen er at du først velger den administrerte modusen og deretter leser de støttede parameterne. Et design som forutsetter en nabo-type tjenesten ikke tilbyr, er ikke et konfigurasjonsproblem som skal løses på kundens ruter.

Tunnelbeskyttelse og nåbarhet er separate oppgaver

IPsec beskytter trafikken som er valgt for tunnelen. BGP leverer nåbarhetsinformasjonen som gjør et prefiks egnet. En fungerende tunnel beviser ikke at det forventede prefikset ble annonsert, godtatt eller installert.

Se for deg en filial som annonserer 10.42.0.0/16 gjennom to egnede tunnelbaner. Fjern én brukbar bane, og rutervalget kan endre seg uten at noen redigerer ruten for hver arbeidsbelastning. Registrering, rutervalg og applikasjonsgjenoppretting er ikke umiddelbare og ikke identiske mellom utrullinger, så failover-testen må observere hele sekvensen og ikke den første pakken som slipper gjennom.

Når et sky-prefiks ikke er nåbart, sjekk sesjonstilstanden og de lærte rutene før du rører kryptografien. En SA som er oppe uten en rute bak seg, er den vanligste formen for dette symptomet.

Hvor OSPF-antakelser bryter sammen

OSPF, IS-IS eller en annen protokoll inne i en IPsec-tunnel er fullt mulig på et selvadministrert apparat, der du eier begge endene og videresendingsdesignet. Det faktumet sier ingenting om en administrert tjeneste som bare tilbyr BGP som dynamisk rutingmodus.

Hvis et foreslått design trenger en nabo-tilknytning tjenesten ikke støtter, endre arkitekturen bevisst. Alternativene inkluderer et selvadministrert apparat i VPC-en, statisk ruting der tjenesten støtter det, eller et annet tilkoblingsprodukt. Å konfigurere protokollen bare på kundens ruter kan ikke legge til en nabo på skysiden som ikke finnes, og det vil ikke få prefikset til å dukke opp.

Ikke flytt én leverandørs svar over på en annen leverandørs gateway. De samme ordene, som dynamisk ruting eller tunnel-failover, kan beskrive ulike mekanismer og ulike grenser.

Les tjenestekravet, og design deretter

Før den første konfigurasjonslinjen, skriv ned nabo-adressene, numrene til de autonome systemene, prefiksene du vil annonsere og godta, rutegrensene og forventet atferd når en tunnel feiler. De fem punktene er kontrakten du designer mot.

Bekreft deretter i samme rekkefølge: sesjon etablert, prefiks mottatt, rute til stede i VPC-ens rutetabell og en reell flyt til en tjenesteadresse. Gjenta etter en tvungen failover, fordi en sesjon som gjenopprettes kan komme tilbake med et annet rutesett. Hvis designet avhenger av konvergens under ett sekund, mål det i stedet for å anta det.

Oppbevar tjenestekontrakten sammen med endringsloggen. Når noen senere spør hvorfor tunnelen ikke kan kjøre OSPF, er svaret en produktgrense, ikke en protokollbegrensning, og loggen bør si det.