Elegir una fuente de registro estable para los miembros de GET VPN

Alguien apunta el registro del miembro del grupo a una dirección loopback y declara resuelta la inestabilidad de GET VPN. A veces lo está. A menudo la loopback solo es alcanzable desde la propia tabla de rutas del miembro y desde ningún otro sitio, así que el registro vuelve a romperse la próxima vez que el uplink que lo transportaba fluctúe. La dirección de registro es una identidad del plano de control, y solo ayuda cuando existe una ruta real en ambos sentidos. Elegirla a propósito merece la pena, y es un cambio más pequeño de lo que sugiere la creencia popular.

Qué identifica la dirección de registro

En una implantación GDOI el miembro del grupo se registra con el servidor de claves y recibe de él la política de grupo. La dirección que el servidor de claves anota es la identidad del miembro para esa conversación.

Esa identidad cubre la conversación de control: registro, regeneración de claves y descarga de la política. No se convierte en el origen del tráfico de los clientes, y no cambia qué interfaces protegen qué flujos.

Mantener las dos cosas separadas es el primer paso, porque la mayor parte de la confusión sobre este ajuste viene de esperar que un cambio en el plano de control arregle un síntoma del plano de datos.

Una loopback vale tanto como su ruta

Una loopback da al miembro una dirección lógica que no desaparece cuando falla un uplink físico. Es una ventaja real en un enrutador con varios caminos hasta el servidor de claves.

Pero también es solo una dirección. Si el servidor de claves no tiene ruta de vuelta hacia ella, el registro falla exactamente como antes. Si la tabla de rutas del miembro llega al servidor de claves solo a través de un uplink, la loopback es estable y el camino no.

Comprueba la accesibilidad en ambos sentidos a través de cada uplink que quieras que sobreviva. Una loopback que se mantiene administrativamente activa no demuestra nada sobre el reenvío, y el fallo aparece como un servidor de claves inaccesible más que como un problema de interfaz. Escribe la comprobación como un comando por uplink, no como una suposición. Así la siguiente ventana de cambio parte de pruebas y no de un diagrama.

Mantén el control y el tráfico protegido separados

La guía de omisión de GDOI de Cisco documenta la interfaz de registro y la relación entre el registro y el tratamiento de la omisión. Lee el comportamiento de la versión que realmente ejecutas en lugar de tratar una frase como un comando universal.

Revisa el filtrado y la traducción en la ruta de control, y confirma que el tráfico de gestión de claves no se arrastra por accidente hacia una política de protección que depende justamente de la política de grupo que intenta obtener. Esa dependencia circular es una forma clásica de hacer que una implantación funcional falle tras un cambio de política.

La política del plano de datos es un diseño aparte. Cambiar de dónde viene el registro deja los flujos protegidos, los selectores y las reglas de omisión exactamente donde estaban.

Comprueba la identidad durante la transición

Antes del cambio, anota el grupo, la dirección de registro elegida, el destino del servidor de claves, el contexto de enrutamiento y la ruta de control permitida. Tras un cambio de uplink aprobado, vuelve a inspeccionar la vista de miembros registrados del servidor de claves y el estado de control del miembro.

Lo que quieres ver es el punto final lógico previsto aún accesible y aún representado tal como lo diseñaste. Lo que no quieres es un segundo registro desde una dirección que no previste, porque así es justamente como aparecen las entradas duplicadas de miembro.

Después prueba el tráfico de aplicaciones protegido por separado. Una transferencia puede tener éxito mientras la siguiente regeneración de claves no tiene adónde ir, y un registro correcto no dice nada sobre si un flujo concreto está bien seleccionado y encaminado.

Qué no arregla una fuente estable

No elimina las entradas duplicadas de miembro creadas por una configuración incorrecta anterior. No repara un fallo de regeneración de claves causado por un desajuste de políticas entre el miembro y el servidor de claves. No sobrevive a un fallo del camino físico que eliminó la única ruta hacia el servidor de claves.

Lo que hace es eliminar una variable: la identidad ya no cambia cuando cambia una dirección de uplink. Merece la pena tenerlo, y es una línea en un diseño y no todo el diseño.

Orden de trabajo: nombrar la ruta de control, elegir una dirección con ruta en ambos sentidos, confirmar la vista del servidor de claves y después probar el tráfico protegido por separado. Si el registro sigue fallando, la loopback nunca fue el problema.