Escoller unha fonte de rexistro estable para os membros de GET VPN

Alguén apunta o rexistro do membro do grupo a un enderezo loopback e declara resolvida a inestabilidade de GET VPN. Ás veces é certo. A miúdo o loopback só é alcanzable desde a propia táboa de rutas do membro e desde ningún outro sitio, así que o rexistro volve fallar a próxima vez que o uplink que o levaba flutúe. O enderezo de rexistro é unha identidade do plano de control, e só axuda cando existe unha ruta real en ambos os sentidos. Escollelo a propósito paga a pena, e é un cambio máis pequeno do que suxire a crenza popular.

Que identifica o enderezo de rexistro

Nunha implantación GDOI o membro do grupo rexístrase co servidor de claves e recibe del a política de grupo. O enderezo que o servidor de claves anota é a identidade do membro para esa conversa.

Esa identidade cobre a conversa de control: rexistro, rexeneración de claves e descarga da política. Non se converte na orixe do tráfico dos clientes, e non cambia que interfaces protexen que fluxos.

Manter as dúas cousas separadas é o primeiro paso, porque a maior parte da confusión sobre este axuste vén de esperar que un cambio no plano de control arranxe un síntoma do plano de datos.

Un loopback vale tanto como a súa ruta

Un loopback dá ao membro un enderezo lóxico que non desaparece cando falla un uplink físico. É unha vantaxe real nun encamiñador con varios camiños ata o servidor de claves.

Pero tamén é só un enderezo. Se o servidor de claves non ten ruta de volta cara a el, o rexistro falla exactamente como antes. Se a táboa de rutas do membro chega ao servidor de claves só a través dun uplink, o loopback é estable e o camiño non.

Comproba a alcanzabilidade en ambos os sentidos a través de cada uplink que queiras que sobreviva. Un loopback que se mantén administrativamente activo non demostra nada sobre o reenvío, e o fallo aparece como un servidor de claves inalcanzable máis que como un problema de interface. Escribe a comprobación como un comando por uplink, non como unha suposición. Así a seguinte xanela de cambio parte de probas e non dun diagrama.

Mantén o control e o tráfico protexido separados

A guía de omisión de GDOI de Cisco documenta a interface de rexistro e a relación entre o rexistro e o tratamento da omisión. Le o comportamento da versión que realmente executas en lugar de tratar unha frase como un comando universal.

Revisa o filtrado e a tradución na ruta de control, e confirma que o tráfico de xestión de claves non se arrastra por accidente cara a unha política de protección que depende xustamente da política de grupo que intenta obter. Esa dependencia circular é unha forma clásica de facer que unha implantación funcional falle tras un cambio de política.

A política do plano de datos é un deseño aparte. Cambiar de onde vén o rexistro deixa os fluxos protexidos, os selectores e as regras de omisión exactamente onde estaban.

Comproba a identidade durante a transición

Antes do cambio, anota o grupo, o enderezo de rexistro escollido, o destino do servidor de claves, o contexto de encamiñamento e a ruta de control permitida. Tras un cambio de uplink aprobado, volve inspeccionar a vista de membros rexistrados do servidor de claves e o estado de control do membro.

O que queres ver é o punto final lóxico previsto aínda alcanzable e aínda representado tal como o deseñaches. O que non queres é un segundo rexistro desde un enderezo que non previches, porque así é como aparecen as entradas duplicadas de membro.

Despois proba o tráfico de aplicacións protexido por separado. Unha transferencia pode ter éxito mentres a seguinte rexeneración de claves non ten onde ir, e un rexistro correcto non di nada sobre se un fluxo concreto está ben seleccionado e encamiñado.

Que non arranxa unha fonte estable

Non elimina as entradas duplicadas de membro creadas por unha configuración incorrecta anterior. Non repara un fallo de rexeneración de claves causado por un desaxuste de políticas entre o membro e o servidor de claves. Non sobrevive a un fallo do camiño físico que eliminou a única ruta ata o servidor de claves.

O que fai é eliminar unha variable: a identidade xa non cambia cando cambia un enderezo de uplink. Paga a pena telo, e é unha liña nun deseño e non todo o deseño.

Orde de traballo: nomear a ruta de control, escoller un enderezo con ruta en ambos os sentidos, confirmar a vista do servidor de claves e despois probar o tráfico protexido por separado. Se o rexistro segue fallando, o loopback nunca foi o problema.