Servidor OpenVPN con nopool: declare un rango de pool explícito

Los auxiliares del servidor configuran una subred y luego la llenan con un pool dinámico de su propia elección. Ese valor por defecto resulta cómodo hasta que algunas direcciones deben quedar fuera de la asignación, ya estén reservadas para asignaciones fijas o retenidas para un segmento futuro. Suprimir el pool automático y declarar el rango uno mismo requiere dos líneas y una decisión deliberada sobre qué direcciones no son para asignación. El resto es disciplina operativa: inventario, aplicación, verificación y reversión.

Este es un cambio en un servicio en funcionamiento, así que trátelo como una tarea operativa: primero inventario, aplicación por el ciclo de vida habitual, verificación con un cliente nuevo y una reversión preparada.

Empiece por la subred que ya tiene

Lea la configuración actual del servidor y las direcciones que los clientes tienen realmente. El cambio del pool solo tiene sentido frente a esa línea base, y la línea base no siempre es lo que sugiere el archivo, porque un producto gestionado o un generador de configuración puede ser el propietario del archivo que está leyendo.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confirme la topología vigente. Con la topología de subred cada cliente toma una dirección del pool; los diseños net30 más antiguos asignan un bloque pequeño por cliente y la aritmética es completamente distinta. Si el servidor sigue en net30, esta página es la guía de migración equivocada y los números del pool no significarán lo que espera. Compruebe esa línea antes de copiar aritmética de direcciones de cualquier otro sitio.

Anote la dirección del propio servidor, cada asignación fija del directorio de configuración de clientes y cualquier dirección de la que dependa una ruta o una regla de acceso. Esas son las direcciones que deben quedar fuera del rango dinámico. Anotarlas primero es lo que convierte el rango en una decisión y no en una conjetura. También da a la reversión algo concreto que restaurar.

Añada nopool y declare el rango

La palabra clave auxiliar acepta nopool, que conserva la configuración de la subred y suprime el pool dinámico automático, como describe el manual de OpenVPN 2.6. La línea explícita ifconfig-pool aporta después el rango inclusivo que pretende, y su máscara de red coincide con la subred. Ambas líneas pertenecen al mismo bloque de servidor, porque un pool sin su subred no tiene sentido. El orden entre ellas solo importa para la legibilidad, ya que el auxiliar expande el par cuando arranca el servicio.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Ambos límites son inclusivos, así que el ejemplo ofrece setenta y una direcciones. Mantenga la dirección del servidor y cada asignación fija fuera de ese intervalo; una asignación fija que caiga dentro del rango dinámico produce una colisión que depende del orden de conexión, que es el peor tipo de depurar. Deje un margen entre el conjunto reservado y el rango si es probable que las asignaciones fijas crezcan.

El tamaño del rango y la concurrencia son límites separados. Cien direcciones no significan cien clientes simultáneos si max-clients dice lo contrario, y un pool mayor que el límite de concurrencia es normal en lugar de derrochador. Lo importante es que los dos límites se elijan deliberadamente en lugar de heredarse de un valor por defecto.

Mantenga las asignaciones fijas fuera del rango dinámico

Un ifconfig-push específico de un cliente es un mecanismo distinto de la asignación del pool y debe usar parámetros adecuados a la topología activa. En modo de subred es una sola dirección y máscara de red; arrastrar un par net30 porque apareció en un ejemplo antiguo es un error frecuente.

El historial de asignaciones es una pista, no una autoridad. Un archivo persist recuerda qué cliente tenía qué dirección, de modo que los clientes que se reconectan tienden a recibir la misma, y no reserva direcciones, no las libera ni sustituye una asignación fija. Si un dispositivo concreto debe tener siempre una dirección concreta, use una asignación fija en lugar de confiar en el archivo persist.

Después revise las rutas que dependen de las direcciones. Una ruta empujada a los clientes, una regla de cortafuegos que admite una subred o una comprobación de monitorización que espera un host concreto pueden presuponer el rango antiguo. Cambiar el pool sin leerlas traslada el fallo a un lugar que parece no relacionado.

Aplique por el ciclo de vida y luego verifique

Aplique el cambio tal como el servicio recibe normalmente la configuración, ya sea un archivo directo más un reinicio o una capa de gestión que regenera el archivo. Una edición manual en un archivo generado sobrevive hasta la siguiente generación y no más. Anote qué mecanismo es el propietario del archivo, porque el siguiente operador necesitará saber dónde hacer el mismo cambio. Después reinicie una vez y lea el registro antes de invitar a un cliente.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Conecte un cliente que no se había conectado antes y confirme que la dirección cae dentro del rango declarado y fuera del conjunto reservado. Después confirme el camino de vuelta: el cliente debe alcanzar lo que la política permite y nada más. Una dirección que encaja con el plan pero no tiene ruta funcional no es un cambio exitoso.

Vuelva a conectar un cliente que tenía una dirección del rango antiguo. Debería recibir una dirección del rango nuevo, y cualquier estado a nivel de sesión ligado a la dirección antigua debería haber desaparecido. Si conserva la dirección antigua, algo más la está asignando y el pool no es el propietario que usted cree.

Revertir un cambio de rango

Guarde las tres líneas anteriores en su registro de cambios, no solo el archivo anterior. Restaurarlas y reiniciar devuelve la asignación al comportamiento antiguo, y los clientes que se reconecten después recibirán direcciones de él.

Dos advertencias pertenecen al registro. Los clientes ya conectados cuando revierte conservan sus direcciones actuales hasta que se reconectan, así que una reversión no es instantánea en toda la flota. Y si el rango antiguo se solapaba con una asignación fija, restaurarlo restaura también la colisión; ese solapamiento es la razón del cambio y necesita una solución distinta de una reversión.

Un cambio de pool está terminado cuando un cliente nuevo recibe una dirección dentro del rango, una dirección reservada nunca se entrega y las rutas y reglas que consumen esas direcciones siguen comportándose como se pretende. Cualquier cosa menos deja a la siguiente persona descubrir cuál de las tres no es cierta.