Volba stabilního zdroje registrace pro členy GET VPN

Někdo nasměruje registraci člena skupiny na adresu loopback a prohlásí nestabilitu GET VPN za vyřešenou. Někdy to tak je. Často je ale loopback dostupný jen z vlastní směrovací tabulky člena a odjinud ne, takže registrace se příště znovu rozbije, když uplink, který ji nesl, zakolísá. Registrační adresa je identita v řídicí rovině a pomůže jen tehdy, když existuje skutečná cesta v obou směrech. Vybrat ji vědomě stojí za to a je to menší změna, než naznačuje zažitá představa.

Co registrační adresa určuje

V nasazení GDOI se člen skupiny registruje u serveru klíčů a dostává od něj skupinovou politiku. Adresa, kterou server klíčů zaznamená, je identita člena pro tuto konverzaci.

Tato identita pokrývá řídicí konverzaci: registraci, obnovu klíčů a stažení politiky. Nestává se zdrojem zákaznického provozu, a nemění, která rozhraní chrání které toky.

Držet obojí oddělené je první krok, protože většina zmatení kolem tohoto nastavení pramení z očekávání, že změna v řídicí rovině opraví symptom v rovině datové.

Loopback je jen tak dobrý jako jeho trasa

Loopback dává členovi logickou adresu, která nezmizí, když jeden fyzický uplink selže. To je skutečná výhoda na routeru s několika cestami k serveru klíčů.

Ale je to také jen adresa. Pokud k ní server klíčů nemá zpětnou trasu, registrace selže přesně jako dřív. Pokud se směrovací tabulka člena dostane k serveru klíčů jen přes jeden uplink, loopback je stabilní a cesta ne.

Ověřte dostupnost v obou směrech přes každý uplink, který má přežít. Loopback, který zůstává administrativně aktivní, nedokazuje o předávání nic, a porucha se projeví jako nedostupný server klíčů, ne jako problém rozhraní. Zapište ověření jako příkaz pro každý uplink, ne jako předpoklad. Pak další změnové okno začne od důkazů, ne od schématu.

Držte řízení a chráněný provoz odděleně

Příručka Cisco k obcházení GDOI dokumentuje registrační rozhraní a vztah mezi registrací a zpracováním obcházení. Čtěte chování pro verzi, kterou skutečně provozujete, místo abyste jednu frázi brali jako univerzální příkaz.

Zkontrolujte filtrování a překlad na řídicí cestě a potvrďte, že provoz správy klíčů se omylem nedostal do ochranné politiky, která závisí právě na skupinové politice, kterou se snaží stáhnout. Taková kruhová závislost je klasický způsob, jak zařídit, aby funkční nasazení selhalo po změně politiky.

Politika datové roviny je samostatný návrh. Změna toho, odkud registrace přichází, ponechá chráněné toky, selektory a pravidla obcházení přesně tam, kde byly.

Ověřte identitu během přechodu

Před změnou zaznamenejte skupinu, zvolenou registrační adresu, cíl serveru klíčů, kontext směrování a povolenou řídicí cestu. Po schválené změně uplinku znovu prohlédněte pohled registrovaných členů na serveru klíčů a řídicí stav člena.

Chcete vidět, že zamýšlený logický koncový bod je stále dostupný a stále zastoupený tak, jak jste jej navrhli. Nechcete vidět druhou registraci z adresy, kterou jste nezamýšleli, protože tak duplicitní záznamy členů vznikají.

Potom otestujte chráněný aplikační provoz zvlášť. Přenos může uspět, i když další obnova klíčů nemá kam jít, a úspěšná registrace nic neříká o tom, zda je konkrétní tok správně vybrán a směrován.

Co stabilní zdroj neopraví

Neodstraní duplicitní záznamy členů vytvořené dřívější chybnou konfigurací. Neopraví selhání obnovy klíčů způsobené nesouladem politik mezi členem a serverem klíčů. Nepřežije poruchu fyzické cesty, která odstranila jedinou trasu k serveru klíčů.

Dělá to, že odstraní jednu proměnnou: identita se už nemění, když se změní adresa uplinku. To stojí za to a je to jeden řádek v návrhu, ne celý návrh.

Pořadí práce: pojmenujte řídicí cestu, vyberte adresu s trasou v obou směrech, potvrďte pohled serveru klíčů a potom zvlášť otestujte chráněný provoz. Pokud registrace stále selhává, loopback nikdy nebyl problém.