¿Qué dirección entregará el grupo en la próxima reconexión?
Las direcciones del grupo siguen un orden que no es aleatorio: primero la recordada, luego la libre usada menos recientemente. Léelo antes de fijar una regla.
Una regla que ayer coincidía deja de coincidir hoy porque el cliente volvió con otra dirección de túnel. El asignador no es aleatorio, sin embargo, y conocer su orden convierte esa sorpresa en un evento predecible. Prefiere la dirección que el mismo cliente tenía antes, recurre a la libre usada menos recientemente y lo olvida todo si no le das dónde recordar. Las reglas que suponen una concesión siguen coincidiendo hasta el día en que en silencio dejan de hacerlo.
El orden que sigue el asignador
Con una sesión por common name, el asignador busca primero una dirección que el mismo cliente usó antes y que ahora está libre. Si esa dirección ya no está, toma la dirección libre que lleva más tiempo inactiva. Con sesiones simultáneas activadas para el mismo nombre, la preferencia por la dirección anterior no se aplica y en su lugar se usa la primera dirección libre, porque las sesiones se tratan como pares separados.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
De ahí se siguen dos consecuencias de inmediato. Un cliente que se reconecta rápido suele conservar su dirección, y por eso nadie nota el mecanismo hasta que cambia. Y otro dispositivo que se conecta durante esa pequeña ventana puede tomar la dirección mientras está brevemente libre, tras lo cual el primer cliente recibe otra cosa y toda regla basada en el número antiguo es errónea. Ninguno de los dos eventos produce una línea de registro que parezca una falla.
Por qué una concesión parece estable y luego se mueve
La estabilidad aquí es una propiedad emergente de las reconexiones que llegan antes de que nadie más reclame la dirección. No es una promesa, y no se aplica mientras el cliente está desconectado. Prevé que la dirección cambie en lugar de sorprenderte cuando lo haga. Un grupo apenas mayor que la cantidad de dispositivos hace rutinarias las colisiones, porque el respaldo de la dirección usada menos recientemente casi no tiene entre qué elegir.
La concurrencia máxima es la cifra con la que hay que dimensionar, no la cantidad de usuarios. Alguien que prueba desde dos dispositivos a la vez, o un cliente que se reconecta antes de que expire la sesión anterior, ocupa dos concesiones durante un rato. Un grupo dimensionado solo para el número de personas producirá exactamente la rotación que la gente culpa al servidor.
El archivo de persistencia recuerda, no reserva
Una dirección que sobrevive a un reinicio del servicio necesita un archivo de persistencia. Guarda el nombre del cliente y la dirección al apagar y los vuelve a leer al iniciar el servicio, y por eso un reinicio planificado ya no reorganiza todas las reglas que escribiste.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Lo que no hace es retener la dirección mientras el cliente está ausente. En ese hueco el asignador es libre de dar el número a otra persona, y el archivo registra entonces una preferencia obsoleta que la siguiente conexión no puede cumplir. Trátalo como una pista que mejora el comportamiento en reinicios, no como direccionamiento estático.
Comprueba el grupo contra cada subred enrutada mientras estás en el archivo. Un rango superpuesto entrega direcciones a las que el servidor no puede enrutar, y el síntoma es un cliente que se conecta, recibe una dirección y no alcanza nada.
Fijar una dirección correctamente
Cuando una regla de cortafuegos o un registro DNS realmente necesita una dirección fija, asígnala en lugar de esperarla. Una entrada de configuración por cliente puede empujar una dirección y una máscara directamente, y esa entrada se indexa por el nombre efectivo del cliente.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Mantén las direcciones fijas fuera del grupo dinámico para que el asignador nunca entregue el mismo número a otra sesión. Luego revisa la topología del túnel, porque cambia cuántas direcciones del grupo consume cada cliente: la antigua disposición punto a punto consume un bloque pequeño por cliente, mientras que una disposición de subred usa una dirección cada uno. Un grupo que parece generoso con una topología puede agotarse con la otra.
Confirma el resultado en el cliente en lugar de confiar en la contabilidad del servidor. Cuando la sesión vuelva, mira la dirección de la interfaz y la ruta empujada, porque un registro en el servidor puede informar la dirección solicitada mientras la interfaz sostiene otra.
La dirección remota es una cuestión aparte
La dirección de la línea remota del cliente debe ser alcanzable antes de que exista ningún túnel. Poner ahí una dirección del grupo, como el propio punto final del túnel del servidor, hace que el cliente intente alcanzar el punto final a través de un túnel que aún no ha construido, y el resultado es un bucle o un tiempo de espera silencioso en lugar de un atajo.
Usa el punto final público que proporcionó el operador y reserva el grupo para aquello para lo que fue diseñado: direcciones dentro del túnel. Anotar el rango del grupo, las asignaciones fijas y la ruta de persistencia en un solo lugar ahorra a la siguiente persona tratar cada concesión como arbitraria.