Direcciones de cliente OpenVPN estáticas detrás de OPNsense

Los nombres necesitan direcciones que no se muevan, y el archivo de grupo de OpenVPN solo hace que una dirección sea pegajosa. Pierda ese archivo, o reemita un certificado con un nombre común distinto, y el cliente que vuelve aterriza en otro lugar del grupo mientras su registro DNS sigue apuntando a la dirección antigua. La respuesta duradera es una anulación específica del cliente que fija la dirección, más una red de túnel más amplia para que las direcciones fijadas queden fuera del rango dinámico. La aritmética que hay detrás de esa ampliación es donde vive la mayor parte de la confusión.

OPNsense guarda esas anulaciones en la configuración específica del cliente del servidor, indexadas por el nombre común del certificado, lo que hace que el nombre común forme parte del plan de direcciones.

Un arrendamiento pegajoso no es una dirección estática

El archivo de grupo escribe asignaciones de dirección a cliente y las devuelve cuando un cliente conocido se reconecta. Eso es comodidad, no un contrato: el archivo se puede regenerar, la asignación desaparece cuando cambia la identidad del cliente, y dos servidores que comparten un grupo no se pondrán de acuerdo al respecto. Una anulación específica del cliente funciona de otra manera, porque la dirección viene de la configuración y no del historial. También sobrevive a un reinicio y a una reinstalación del dispositivo, siempre que la anulación se respalde junto con el resto de la configuración.

La alternativa dinámica, conectar la VPN al DNS con un script de conexión de cliente y actualizaciones dinámicas, funciona y requiere un resolutor que acepte actualizaciones más un script en cada conexión. En un dispositivo estás limitado a los paquetes que distribuye el fabricante, y normalmente es ahí donde ese plan se detiene.

La aritmética /30 que nadie disfruta

Con la topología net30 predeterminada, cada cliente recibe su propio /30: la primera dirección utilizable va al lado del servidor y la segunda al cliente. Por lo tanto, las anulaciones deben quedar fuera de la red de túnel dinámica del servidor, lo que significa ampliar primero esa red. Un servidor en 10.8.0.0/24 puede pasar a 10.8.0.0/23, dejando la mitad del rango antiguo para clientes dinámicos y la otra mitad para anulaciones. Añada el /24 original como red local IPv4 adicional para que el tráfico hacia ambas mitades entre en el túnel.

Cada dirección de anulación debe caer en un límite /30, así que el último octeto es múltiplo de cuatro. Un /30 en 10.8.1.0 da al cliente 10.8.1.2, y esa es la dirección que lleva el registro DNS. Elegir 10.8.1.3 en su lugar produce un cliente que se conecta y no puede pasar tráfico, porque la dirección pertenece a una subred que la topología nunca le asignó.

El plan es más fácil de mantener si las anulaciones se asignan desde arriba del rango ampliado hacia abajo, de modo que el grupo dinámico se expanda hacia el espacio libre en lugar de alrededor de islas fijas.

Redes locales y la zona que consultan los clientes

El tráfico de cliente a cliente necesita su propio permiso. La lista de redes locales IPv4 del servidor debe incluir ambas mitades del rango, dinámica y estática; sin ella, el servidor acepta un paquete de un cliente y no tiene ninguna política que lo deje pasar a otro. El síntoma se lee como un fallo de DNS, porque el nombre se resuelve y la conexión sigue fallando. Compruebe al mismo tiempo el ajuste de cliente a cliente, ya que una entrada de red local por sí sola no habilita el reenvío entre pares.

Publique los registros en la zona que los clientes remotos consultan realmente. Un registro en una zona servida solo por el resolutor de la LAN es invisible para un cliente cuyo resolutor empujado apunta a otro sitio, y añadir más registros a la zona equivocada nunca lo repara. Confirme la opción DNS empujada y el dominio de búsqueda antes de añadir nada.

Qué comprobar en una conexión nueva

Reconecte el cliente y confirme que la dirección asignada coincide con su anulación antes de probar cualquier otra cosa. Luego resuelva el nombre desde un segundo cliente y conéctese al servicio por nombre, lo que ejercita el registro DNS, la ruta y el cortafuegos a la vez. Confirme la ruta de respuesta en el lado del servidor, ya que un nombre que se resuelve mientras el servicio sigue inaccesible es un problema de enrutamiento o de política, no de nombres. Mantenga la tabla de anulaciones junto a la lista de certificados para que ambas se revisen juntas.

Un certificado reemitido con un nombre común distinto deja de coincidir con su anulación y devuelve al cliente al grupo dinámico. Espere eso después de cualquier cambio de identidad.