Kies een stabiele registratiebron voor GET VPN-leden

Iemand richt de registratie van het groeplid op een loopback-adres en verklaart de instabiliteit van GET VPN opgelost. Soms is dat zo. Vaak is de loopback alleen bereikbaar vanuit de eigen routetabel van het lid en nergens anders vandaan, waardoor de registratie opnieuw breekt de volgende keer dat de uplink die hem droeg flappert. Het registratieadres is een identiteit in het controlevlak, en het helpt alleen als er in beide richtingen een echt pad bestaat. Het bewust kiezen is de moeite waard, en het is een kleinere wijziging dan het volksverhaal suggereert.

Wat het registratieadres identificeert

In een GDOI-implementatie registreert het groeplid zich bij de sleutelserver en ontvangt daarvan het groepsbeleid. Het adres dat de sleutelserver vastlegt, is de identiteit van het lid voor dat gesprek.

Die identiteit omvat het controleesprek: registratie, sleutelvernieuwing en het downloaden van het beleid. Het wordt niet de bron van klantverkeer, en het verandert niet welke interfaces welke stromen beschermen.

De twee gescheiden houden is de eerste stap, omdat de meeste verwarring rond deze instelling voortkomt uit de verwachting dat een wijziging in het controlevlak een symptoom in het datavlak oplost.

Een loopback is maar zo goed als zijn route

Een loopback geeft het lid een logisch adres dat niet verdwijnt wanneer één fysieke uplink uitvalt. Dat is een echt voordeel op een router met meerdere paden naar de sleutelserver.

Maar het is ook maar een adres. Als de sleutelserver geen route terug heeft, mislukt de registratie precies zoals voorheen. Als de routetabel van het lid de sleutelserver alleen via één uplink bereikt, is de loopback stabiel en het pad niet.

Controleer bereikbaarheid in beide richtingen via elke uplink die je wilt laten overleven. Een loopback die administratief omhoog blijft, bewijst niets over doorsturen, en de storing verschijnt als een onbereikbare sleutelserver in plaats van als een interfaceprobleem. Schrijf de controle als een commando per uplink, niet als een aanname. Dan begint het volgende wijzigingsvenster met bewijs in plaats van met een diagram.

Houd controle en beschermd verkeer gescheiden

Cisco's GDOI-bypass-handleiding documenteert de registratie-interface en de relatie tussen registratie en de afhandeling van bypass. Lees het gedrag voor de release die je daadwerkelijk draait in plaats van één zin als een universeel commando te behandelen.

Beoordeel filtering en vertaling op het controlepad, en bevestig dat sleutelbeheerverkeer niet per ongeluk in een beveiligingsbeleid terechtkomt dat afhankelijk is van precies het groepsbeleid dat het probeert op te halen. Die circulaire afhankelijkheid is een klassieke manier om een werkende implementatie na een beleidswijziging te laten falen.

Het beleid voor het datavlak is een apart ontwerp. Wijzigen waar de registratie vandaan komt, laat de beschermde stromen, de selectors en de bypass-regels precies waar ze waren.

Controleer de identiteit tijdens de overgang

Noteer vóór de wijziging de groep, het gekozen registratieadres, de bestemming van de sleutelserver, de routeringscontext en het toegestane controlepad. Na een goedgekeurde uplink-wijziging inspecteer je opnieuw de weergave van geregistreerde leden op de sleutelserver en de controlestatus van het lid.

Wat je wilt zien, is dat het beoogde logische eindpunt nog steeds bereikbaar is en nog steeds wordt weergegeven zoals je het hebt ontworpen. Wat je niet wilt, is een tweede registratie vanaf een adres dat je niet bedoelde, want zo ontstaan dubbele ledenvermeldingen.

Test daarna beschermd applicatieverkeer apart. Een overdracht kan slagen terwijl de volgende sleutelvernieuwing nergens heen kan, en een geslaagde registratie zegt niets over de vraag of een bepaalde stroom correct wordt geselecteerd en gerouteerd.

Wat een stabiele bron niet oplost

Het verwijdert geen dubbele ledenvermeldingen die een eerdere verkeerde configuratie heeft gemaakt. Het repareert geen fout in sleutelvernieuwing die door een beleidsverschil tussen lid en sleutelserver ontstaat. Het overleeft geen uitval van een fysiek pad dat de enige route naar de sleutelserver heeft weggenomen.

Wat het wel doet, is één variabele wegnemen: de identiteit verandert niet meer wanneer een uplink-adres verandert. Dat is de moeite waard, en het is één regel in een ontwerp en niet het hele ontwerp.

Werkvolgorde: benoem het controlepad, kies een adres met een route in beide richtingen, bevestig de weergave van de sleutelserver en test daarna beschermd verkeer apart. Als de registratie nog steeds mislukt, was de loopback nooit het probleem.