Velg en stabil registreringskilde for GET VPN-medlemmer

Noen peker gruppemedlemmets registrering mot en loopback-adresse og erklærer ustabiliteten i GET VPN for løst. Noen ganger er det riktig. Ofte er loopbacken bare tilgjengelig fra medlemmets egen rutetabell og ingen andre steder, så registreringen bryter sammen igjen neste gang uplinken som bar den flapper. Registreringsadressen er en identitet i kontrollplanet, og den hjelper bare når det finnes en reell vei i begge retninger. Å velge den bevisst er verdt det, og det er en mindre endring enn folketroen antyder.

Hva registreringsadressen identifiserer

I en GDOI-utrulling registrerer gruppemedlemmet seg hos nøkkelserveren og mottar gruppepolicy fra den. Adressen nøkkelserveren registrerer, er medlemmets identitet for den samtalen.

Denne identiteten dekker kontrollsamtalen: registrering, nøkkelfornyelse og nedlasting av policyen. Den blir ikke kilden til kundetrafikk, og den endrer ikke hvilke grensesnitt som beskytter hvilke strømmer.

Å holde de to fra hverandre er det første trinnet, fordi det meste av forvirringen rundt denne innstillingen kommer av at man forventer at en endring i kontrollplanet skal reparere et symptom i dataplanet.

En loopback er bare så god som ruten sin

En loopback gir medlemmet en logisk adresse som ikke forsvinner når én fysisk uplink feiler. Det er en reell fordel på en ruter med flere veier til nøkkelserveren.

Men det er også bare en adresse. Hvis nøkkelserveren ikke har rute tilbake til den, feiler registreringen nøyaktig som før. Hvis medlemmets rutetabell bare når nøkkelserveren gjennom én uplink, er loopbacken stabil og veien er det ikke.

Kontroller nåbarhet i begge retninger gjennom hver uplink du vil at skal overleve. En loopback som blir administrativt oppe beviser ingenting om videresending, og feilen viser seg som en utilgjengelig nøkkelserver snarere enn som et grensesnittproblem. Skriv kontrollen som en kommando per uplink, ikke som en antakelse. Da begynner neste endringsvindu med bevis i stedet for med et diagram.

Hold kontroll og beskyttet trafikk fra hverandre

Ciscos GDOI-bypass-veiledning dokumenterer registreringsgrensesnittet og forholdet mellom registrering og håndtering av bypass. Les atferden for versjonen du faktisk kjører, i stedet for å behandle én frase som en universell kommando.

Gå gjennom filtrering og oversettelse på kontrollstien, og bekreft at nøkkeladministrasjonstrafikk ikke ved et uhell blir feid inn i en beskyttelsespolicy som avhenger av nettopp den gruppepolicyen den prøver å hente. Den sirkulære avhengigheten er en klassisk måte å få en fungerende utrulling til å feile etter en policyendring.

Policyen for dataplanet er et eget design. Å endre hvor registreringen kommer fra lar de beskyttede strømmene, selektorene og bypass-reglene ligge nøyaktig der de var.

Kontroller identiteten gjennom overgangen

Før endringen noterer du gruppen, den valgte registreringsadressen, nøkkelserverens destinasjon, rutekonteksten og den tillatte kontrollstien. Etter en godkjent uplink-endring undersøker du nøkkelserverens visning av registrerte medlemmer og medlemmets kontrolltilstand på nytt.

Det du vil se, er at det tiltenkte logiske endepunktet fortsatt er nåbart og fortsatt representert slik du designet det. Det du ikke vil se, er en andre registrering fra en adresse du ikke hadde til hensikt, for det er nettopp slik dupliserte medlemsoppføringer oppstår.

Test deretter beskyttet applikasjonstrafikk for seg. En overføring kan lykkes mens neste nøkkelfornyelse ikke har noe sted å gå, og en vellykket registrering sier ingenting om hvorvidt en bestemt strøm er riktig valgt og rutet.

Hva en stabil kilde ikke retter

Den fjerner ikke dupliserte medlemsoppføringer som en tidligere feilkonfigurasjon har laget. Den reparerer ikke en feil i nøkkelfornyelsen som skyldes policyavvik mellom medlem og nøkkelserver. Den overlever ikke en fysisk veifeil som fjernet den eneste ruten til nøkkelserveren.

Det den gjør, er å fjerne én variabel: identiteten endrer seg ikke lenger når en uplink-adresse endres. Det er verdt å ha, og det er én linje i et design og ikke hele designet.

Rekkefølgen: navngi kontrollstien, velg en adresse med rute i begge retninger, bekreft nøkkelserverens visning, og test deretter beskyttet trafikk separat. Hvis registreringen fortsatt feiler, var loopbacken aldri problemet.