Triar una font d'enregistrament estable per als membres de GET VPN

Algú apunta l'enregistrament del membre del grup a una adreça loopback i declara resolta la inestabilitat de GET VPN. De vegades ho és. Sovint la loopback només és abastable des de la taula d'encaminament del mateix membre i de cap altre lloc, així que l'enregistrament torna a fallar la propera vegada que l'uplink que el portava fluctua. L'adreça d'enregistrament és una identitat del pla de control, i només ajuda quan hi ha un camí real en tots dos sentits. Triar-la deliberadament val la pena, i és un canvi més petit del que suggereix la creença popular.

Què identifica l'adreça d'enregistrament

En una implantació GDOI el membre del grup s'enregistra al servidor de claus i en rep la política de grup. L'adreça que el servidor de claus desa és la identitat del membre per a aquesta conversa.

Aquesta identitat cobreix la conversa de control: enregistrament, regeneració de claus i descàrrega de la política. No es converteix en l'origen del trànsit dels clients, i no canvia quines interfícies protegeixen quins fluxos.

Mantenir les dues coses separades és el primer pas, perquè la major part de la confusió sobre aquest paràmetre ve d'esperar que un canvi al pla de control arregli un símptoma del pla de dades.

Una loopback val tant com la seva ruta

Una loopback dóna al membre una adreça lògica que no desapareix quan falla un uplink físic. És un avantatge real en un encaminador amb diversos camins fins al servidor de claus.

Però també és només una adreça. Si el servidor de claus no té cap ruta de tornada, l'enregistrament falla exactament com abans. Si la taula d'encaminament del membre arriba al servidor de claus només per un uplink, la loopback és estable i el camí no.

Comproveu l'abastabilitat en tots dos sentits per cada uplink que vulgueu que sobrevisqui. Una loopback que es manté administrativament activa no demostra res sobre el reenviament, i la fallada apareix com un servidor de claus inabastable més que com un problema d'interfície. Escriviu la comprovació com una ordre per uplink, no com una suposició. Així la propera finestra de canvi parteix de proves i no d'un diagrama.

Manteniu el control i el trànsit protegit separats

La guia de bypass GDOI de Cisco documenta la interfície d'enregistrament i la relació entre l'enregistrament i la gestió del bypass. Llegiu el comportament de la versió que realment executeu en lloc de tractar una frase com una ordre universal.

Reviseu el filtratge i la traducció al camí de control, i confirmeu que el trànsit de gestió de claus no s'arrossega per accident cap a una política de protecció que depèn precisament de la política de grup que intenta obtenir. Aquesta dependència circular és una manera clàssica de fer que una implantació funcional falli després d'un canvi de política.

La política del pla de dades és un disseny a part. Canviar d'on ve l'enregistrament deixa els fluxos protegits, els selectors i les regles de bypass exactament on eren.

Comproveu la identitat durant la transició

Abans del canvi, anoteu el grup, l'adreça d'enregistrament triada, la destinació del servidor de claus, el context d'encaminament i el camí de control permès. Després d'un canvi d'uplink aprovat, torneu a inspeccionar la vista de membres registrats del servidor de claus i l'estat de control del membre.

El que voleu veure és el punt final lògic previst encara abastable i encara representat tal com el vau dissenyar. El que no voleu és un segon enregistrament des d'una adreça que no havíeu previst, perquè així és com apareixen els duplicats d'entrades de membre.

Després proveu el trànsit d'aplicacions protegit per separat. Una transferència pot tenir èxit mentre la propera regeneració de claus no té on anar, i un enregistrament correcte no diu res sobre si un flux concret està ben seleccionat i encaminat.

Què no arregla una font estable

No elimina els duplicats d'entrades de membre creats per una configuració incorrecta anterior. No repara una fallada de regeneració de claus causada per un desajust de polítiques entre el membre i el servidor de claus. No sobreviu a una fallada del camí físic que va eliminar l'única ruta fins al servidor de claus.

El que fa és eliminar una variable: la identitat ja no canvia quan canvia una adreça d'uplink. Val la pena tenir-ho, i és una línia en un disseny i no tot el disseny.

Ordre de treball: nomenar el camí de control, triar una adreça amb ruta en tots dos sentits, confirmar la vista del servidor de claus i després provar el trànsit protegit per separat. Si l'enregistrament encara falla, la loopback mai va ser el problema.