ifconfig-push: dirección de par en net30 o máscara de subred en subnet?

Los clientes dinámicos se conectan y el enrutamiento funciona bien, pero el único cliente con una dirección fija no llega al servidor en absoluto. Nada en el cortafuegos ha cambiado, y la línea CCD parece verosímil. La causa habitual es un segundo argumento escrito para una topología TUN distinta de la que ejecuta el servidor. El fallo es silencioso: el cliente sube con una dirección y el servidor acepta la conexión, pero no cruza ningún tráfico.

En net30 ese campo es una dirección de par; en subnet es una máscara de subred. Las dos formas son alternativas, nunca una secuencia.

Las dos formas, lado a lado

En un despliegue net30 tradicional cada cliente posee un bloque /30: una dirección de red, dos direcciones utilizables y una dirección de difusión. ifconfig-push toma la dirección del cliente y la dirección de par, y el par es la otra dirección utilizable del mismo bloque, usada por el lado servidor del enlace punto a punto.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Bajo topology subnet el cliente comparte una subred con el servidor, y la misma directiva toma una dirección y una máscara de subred. La dirección propia del servidor procede de la directiva server, no del segundo campo. Mezclar las formas produce un cliente que cree estar en un enlace punto a punto mientras el servidor lo encamina como host de subred, o lo contrario. Por eso una máscara de subred nunca debe emparejarse con net30.

Ambas líneas del bloque son líneas individuales para un archivo CCD. Cada cliente recibe exactamente una de ellas.

Lea la topología que el servidor ejecuta realmente

Lea la configuración en ejecución en lugar de un valor predeterminado del paquete, porque la topología puede haberse fijado hace años y copiado hacia delante. Busque topology subnet o su ausencia, y luego compruebe cómo la línea server asigna direcciones. Una configuración que nunca menciona la topología no es lo mismo que una que fija subnet.

Luego lea los ajustes que ha recibido el cliente. La dirección, la máscara y el par que informa le dicen qué interpretación aplicó el servidor.

Mantenga la dirección fija fuera del grupo dinámico

Una dirección fija debe quedar fuera del grupo dinámico, o dos clientes pueden recibir la misma dirección. Con topología subnet, nopool en la línea server suprime el grupo automático, y un rango ifconfig-pool explícito define qué reciben los clientes dinámicos.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

El servidor toma 10.99.0.1 para sí mismo, y la dirección fija del cliente queda fuera del rango del grupo. El archivo CCD se nombra por la identidad efectiva del cliente, no por el nombre del archivo de perfil, y no lleva ninguna extensión adicional. Si username-as-common-name está activo, el nombre de usuario autenticado es la identidad que hay que emparejar. Dos dispositivos que comparten una identidad también compartirán la dirección fija, lo que es un problema de política y no de enrutamiento.

Verifique la asignación que el cliente recibió realmente

Reconecte el cliente previsto y confirme qué archivo CCD se seleccionó antes de comprobar cualquier otra cosa. Después verifique la dirección, la máscara o el par, y la ruta de vuelta al servidor. Un cliente que muestra una dirección de par en un despliegue subnet sigue usando la forma equivocada.

Cambiar la topología afecta a cada cliente y a cada sustitución, así que trátelo como una migración y no como una reparación de un solo cliente. Corregir la línea estática para que coincida con la topología ya en uso suele ser el cambio menor. referencia de server-options documenta el ayudante y las sustituciones específicas del cliente.