Vælg en stabil registreringskilde til GET VPN-medlemmer

Nogen peger gruppemedlemmets registrering mod en loopback-adresse og erklærer ustabiliteten i GET VPN for løst. Nogle gange er det rigtigt. Ofte kan loopbacken kun nås fra medlemmets egen routingtabel og ingen andre steder, så registreringen bryder stadig sammen næste gang den uplink, der bar den, flapper. Registreringsadressen er en identitet i kontrolplanet, og den hjælper kun, når der findes en reel vej i begge retninger. At vælge den bevidst er værd at gøre, og det er en mindre ændring, end folketroen antyder.

Hvad registreringsadressen identificerer

I en GDOI-udrulning registrerer gruppemedlemmet sig hos nøgleserveren og modtager gruppepolitik fra den. Den adresse, nøgleserveren registrerer, er medlemmets identitet for den samtale.

Den identitet dækker kontrolsamtalen: registrering, nøglefornyelse og download af politikken. Den bliver ikke kilden til kundetrafik, og den ændrer ikke, hvilke grænseflader der beskytter hvilke strømme.

At holde de to ting adskilt er det første skridt, fordi det meste af forvirringen omkring denne indstilling kommer af at forvente, at en ændring i kontrolplanet reparerer et symptom i dataplanet.

En loopback er kun så god som sin rute

En loopback giver medlemmet en logisk adresse, der ikke forsvinder, når en fysisk uplink fejler. Det er en reel fordel på en router med flere veje til nøgleserveren.

Men det er også bare en adresse. Hvis nøgleserveren ikke har en rute tilbage til den, fejler registreringen præcis som før. Hvis medlemmets routingtabel kun når nøgleserveren gennem én uplink, er loopbacken stabil, og vejen er det ikke.

Kontrollér nåbarhed i begge retninger gennem hver uplink, du vil have skal overleve. En loopback, der bliver administrativt oppe, beviser intet om videresendelse, og fejlen viser sig som en unåelig nøgleserver snarere end som et grænsefladeproblem. Skriv kontrollen som en kommando pr. uplink, ikke som en antagelse. Så begynder det næste ændringsvindue med beviser i stedet for med et diagram.

Hold kontrol og beskyttet trafik adskilt

Ciscos GDOI-bypass-vejledning dokumenterer registreringsgrænsefladen og forholdet mellem registrering og håndtering af bypass. Læs adfærden for den version, du faktisk kører, i stedet for at behandle en enkelt sætning som en universel kommando.

Gennemgå filtrering og oversættelse på kontrolstien, og bekræft at nøglestyringstrafik ikke ved et uheld bliver fejet ind i en beskyttelsespolitik, der afhænger af netop den gruppepolitik, den forsøger at hente. Den cirkulære afhængighed er en klassisk måde at få en fungerende udrulning til at fejle efter en politikændring.

Politik for dataplanet er et separat design. At ændre, hvor registreringen kommer fra, efterlader de beskyttede strømme, selektorerne og bypass-reglerne præcis, hvor de var.

Kontrollér identiteten gennem overgangen

Før ændringen skal du notere gruppen, den valgte registreringsadresse, nøgleserverens destination, routingkonteksten og den tilladte kontrolsti. Efter en godkendt uplink-ændring skal du igen inspicere nøgleserverens visning af registrerede medlemmer og medlemmets kontroltilstand.

Det, du gerne vil se, er, at det tilsigtede logiske endepunkt stadig er nåeligt og stadig repræsenteret, som du designede det. Det, du ikke vil se, er en anden registrering fra en adresse, du ikke havde tilsigtet, for det er netop, hvordan dobbelte medlemsposter opstår.

Test derefter beskyttet applikationstrafik for sig. En overførsel kan lykkes, mens den næste nøglefornyelse ikke har nogen steder at gå hen, og en vellykket registrering siger intet om, hvorvidt en bestemt strøm er valgt og rutet korrekt.

Hvad en stabil kilde ikke retter

Den fjerner ikke dobbelte medlemsposter skabt af en tidligere fejlkonfiguration. Den reparerer ikke en fejl i nøglefornyelsen forårsaget af politisk uoverensstemmelse mellem medlem og nøgleserver. Den overlever ikke en fysisk vejfejl, der fjernede den eneste rute til nøgleserveren.

Det, den gør, er at fjerne én variabel: identiteten ændrer sig ikke længere, når en uplink-adresse ændres. Det er værd at have, og det er én linje i et design og ikke hele designet.

Arbejdsrækkefølge: navngiv kontrolstien, vælg en adresse med en rute i begge retninger, bekræft nøgleserverens visning, og test derefter beskyttet trafik separat. Hvis registreringen stadig fejler, var loopbacken aldrig problemet.