Las direcciones estables de OpenVPN deben seguir la identidad, no la IP de origen

Los planes de direcciones que dicen «este portátil recibe 10.90.0.10» son en realidad afirmaciones sobre la identidad: qué dispositivo autenticado puede tener esa dirección. La IP pública actual de ese dispositivo casi no tiene que ver, porque NAT e itinerancia la cambian sin cambiar quién es el usuario. Construir el plan sobre la dirección de origen produce reglas que se rompen en la primera red de hotel. Construirlo sobre la identidad autenticada produce un plan que sobrevive a los viajes.

Empieza por lo que el servidor puede verificar y luego decide para qué sirve la dirección.

Elige la clave de identidad antes que la dirección

Un certificado de cliente separado por dispositivo da al servidor una clave estable y verificable para cada miembro, que es la base más limpia para una asignación estática. Un despliegue con autenticación por usuario puede basarse en el nombre de usuario, siempre que la selección de configuración siga el mismo campo. Mezclar los dos modelos produce asignaciones que coinciden con un certificado para un cliente y con un nombre de usuario para otro, y nadie puede predecir cuál ganará. Decide qué clave usa el plan antes de escribir una sola reserva.

Con duplicate-cn, varias sesiones simultáneas pueden presentar el mismo nombre común, así que una dirección fijada no puede identificarlas individualmente. Eso es una propiedad del modelo de identidad, no algo que un mejor plan de direcciones pueda arreglar.

Reserva direcciones fuera del rango dinámico

En una red con topología de subred como 10.90.0.0/24, reserva las direcciones bajas para los miembros con nombre y pon el pool dinámico en un rango disjunto. Una asignación para un miembro fijado tiene este aspecto ifconfig-push 10.90.0.10 255.255.255.0 en el archivo que el servidor selecciona para esa identidad. El segundo argumento significa algo distinto con net30, así que el ejemplo no es neutral respecto a la topología. Lee la topología antes de copiarlo.

La persistencia del pool registra los arrendamientos recientes y tiende a devolver la misma dirección, lo que es una comodidad y no una reserva. No dejes que el archivo de persistencia se convierta en el registro de propiedad, porque cambia con el historial de conexiones y no con la política.

La precedencia de la asignación decide quién gana

El manual documenta un orden: una asignación explícita generada durante client-connect puede surtir efecto antes que una entrada de client-config-dir, que a su vez precede a la asignación ordinaria del pool. Ese orden explica la mayoría de los informes «la dirección fijada no se aplicó». También significa que un asignador dinámico que escribe configuración por sesión puede sobrescribir en silencio un archivo estático que creías autoritativo.

Elige una capa que posea las asignaciones y haz que las demás sean de solo lectura. Dos capas que ambas afirman decidir producen asignaciones que dependen del momento.

Un asignador dinámico necesita el mismo modelo

Una integración de client-connect que reparte direcciones por sesión es un asignador pequeño con los problemas habituales de los asignadores. Tiene que validar la identidad solicitante, reservar una dirección de forma atómica, emitir solo la salida por conexión admitida y liberar la reserva al desconectar o fallar. Las solicitudes concurrentes necesitan un bloqueo o una restricción de base de datos, no una secuencia de leer y luego escribir. Sin limpieza, el pool pierde direcciones hasta un reinicio.

Mantén el estado del asignador donde el siguiente operador pueda leerlo y registra la decisión identidad-a-dirección, no solo la dirección.

Decide si la dirección es política o comodidad

Si una regla de cortafuegos o una ruta permite tráfico desde una dirección de túnel, entonces la dirección participa en la política de acceso y una reasignación hereda ese permiso. Coordina el ciclo de vida de la identidad, la dirección y el cortafuegos, o liga la regla a algo que no pueda reasignarse. El direccionamiento estable hace legible la configuración; no sustituye a la autenticación.

Escribe el plan como un inventario con un propietario por entrada y revísalo cuando se retire un dispositivo. La reserva no utilizada es la que se reutiliza por accidente.