Una única IP de servicio en cada nodo OpenVPN: lo que no hace

Un cliente se conecta a uno de varios servidores OpenVPN y luego necesita un servicio pequeño que se ejecute en ese nodo: una página de estado, un endpoint de métricas, un agente de copias de seguridad. Dar a cada nodo la misma dirección privada de servicio hace que la configuración del cliente sea idéntica con independencia del servidor en el que haya caído. Esa comodidad es real, y también es fácil de sobreinterpretar: la dirección compartida te dice a qué nodo llegaste, no que algo sea redundante.

Por qué la misma dirección en cada nodo funciona

Cada nodo posee la dirección localmente y responde por ella, así que un cliente que la alcanza a través de su túnel actual obtiene el servicio en el extremo opuesto de ese túnel. Nada se coordina entre nodos, y ningún tráfico cruza de un nodo a otro.

La dirección es una etiqueta local, repetida en lugar de replicada. Cada nodo responde solo por sí mismo, y ninguno reenvía tráfico para la dirección en nombre de otro nodo. Eso es lo que mantiene válida una sola configuración de cliente mientras los servidores siguen siendo independientes. Es también la razón por la que el diseño no necesita coordinación entre los nodos.

Por eso la misma configuración funciona en todos los servidores sin un protocolo de enrutamiento entre ellos. Es también por lo que el diseño no dice nada sobre la salud: la dirección existe en un nodo enfermo exactamente igual que en uno sano, porque está ligada al host y no a que el servicio sea útil.

Asígnala al loopback, no al túnel

Poner la dirección en una interfaz de loopback la desacopla de la vida útil de cualquier dispositivo de túnel, de modo que una reconexión o una recarga de configuración no la elimina. La dirección existe mientras exista el host.

Una dirección en lo no es un filtro. El servicio sigue teniendo que escuchar en ella, y el cortafuegos del host sigue evaluando la ruta entrante real, que llega por la interfaz del túnel. Quien supone que loopback significa solo local acaba bloqueando clientes legítimos o exponiendo algo que no pretendía.

Haz persistente la asignación mediante la configuración de red del host en lugar de volver a añadirla desde un hook. Un hook de instalación no se dispara en un nodo donde no subió ningún túnel, y la dirección de servicio no debería depender de la actividad del túnel. Pon la dirección en la configuración de la interfaz que gestiona tu distribución, luego reinicia una vez y compruébala. Un reinicio es la única prueba que sobrevive a un cambio de configuración posterior.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Empuja una ruta y te refieres a un destino

El cliente necesita una ruta de host para la dirección, ofrecida por el servidor al que se conecta. Como todos los servidores ofrecen el mismo destino, el perfil no cambia cuando el cliente se mueve.

Verifica qué instaló el cliente antes de culpar al servicio.

ip route get 10.250.0.1

Para un servicio HTTP, da a la dirección un nombre y un certificado para ese nombre. La IP compartida no es una identidad, y no elimina la verificación TLS, ni justifica copiar una clave privada a cada nodo. Un nombre que resuelve a la dirección compartida mantiene la historia del certificado ordinaria y te permite conservar una identidad por nodo si la necesitas.

Lo que la dirección compartida no puede hacer

No proporciona conmutación por fallo. Si el nodo elegido muere, la dirección muere con él, y el cliente tiene que reconectarse en otro sitio.

No migra una sesión TCP viva, porque una conexión nueva termina en un host distinto que no sabe nada de la anterior.

No elige un nodo sano, ni equilibra carga, ni sincroniza datos entre nodos. Cada una de esas cosas es un mecanismo aparte con sus propios modos de fallo, y fingir que el truco de direccionamiento las cubre es cómo un diseño sencillo adquiere una reputación inmerecida de resiliencia. Si dos túneles están activos a la vez, el significado del destino se vuelve ambiguo, así que mantén explícita la suposición de un solo túnel activo.

Mantén la identidad del servicio junto al nombre

Escribe qué significa la dirección: llega al servicio en el nodo al que el cliente está conectado ahora. Esa sola frase evita la mayor parte del malentendido que atrae este patrón.

Luego documenta las piezas juntas: la dirección, la interfaz en la que vive, la ruta que empuja el servidor, y el nombre y el certificado que presenta el servicio. Cuatro hechos pequeños que un lector futuro puede verificar, en el orden en que los comprobará.

Si el requisito es un destino estable para un servicio local del nodo, el patrón encaja y no cuesta casi nada.

Si el requisito es disponibilidad, sube una capa: un balanceador de carga, un nombre de servicio con comprobaciones de salud, o un sistema de orquestación que ya sabe cómo reemplazar un nodo.

Decidirlo pronto mantiene la dirección compartida en lo que es, una etiqueta cómoda, en lugar de un componente del que en silencio se espera que haga un trabajo para el que nunca se diseñó.