IP estática de OpenVPN por cliente: ifconfig-push, no ipp.txt

Editar una línea en ipp.txt parece reservar una dirección, y no lo es. Ese archivo, nombrado por ifconfig-pool-persist, registra qué dirección tenía un nombre común la última vez para que el grupo pueda devolver la misma cuando convenga. Nada en él vincula la siguiente conexión a ese número.

Ejecute las comprobaciones siguientes en orden. Cada una confirma el mecanismo o le indica que se detenga y repare una entrada.

Para qué sirve el archivo de persistencia

El archivo existe para mantener las direcciones estables entre reinicios, lo que hace las reconexiones más amables y los registros más fáciles de leer. Se lee como historial y se escribe como historial, y la ruta de asignación queda libre para elegir otra dirección cuando la pista no encaja: otro grupo, una asignación en conflicto o un cliente que llegó después de que el grupo se llenara. Por eso una edición manual puede verse perfecta en el archivo y no cambiar nada en la conexión. Trátelo como una caché de decisiones pasadas y no como una fuente de políticas.

Si necesita una dirección concreta para un cliente concreto, el mecanismo documentado es ifconfig-push, y pertenece a la configuración que posee ese cliente.

Compruebe que se selecciona el cliente correcto

La asignación explícita se busca por el nombre común del cliente, así que un archivo nombrado para la identidad equivocada simplemente nunca se lee. Confirme qué considera el servidor que es el nombre de ese cliente, sobre todo donde username-as-common-name lo cambia tras la autenticación. Luego confirme que el nombre del archivo coincide exactamente con ese valor, incluidas las mayúsculas y minúsculas.

Piense en la concurrencia mientras está aquí. Si se permite duplicate-cn, varios dispositivos pueden presentar la misma identidad, y una dirección fija no puede ser única para todos ellos. Decida si la dirección fija merece rechazar sesiones concurrentes para esa identidad, porque esos dos requisitos no pueden satisfacerse a la vez.

Compruebe que los números coinciden con la topología

El significado de los argumentos depende de la topología del túnel, y aquí es donde un ejemplo copiado hace más daño. En la disposición net30 más antigua cada cliente ocupa un bloque de cuatro direcciones, así que el push suministra un par de direcciones. En la topología de subred el cliente recibe una dirección más la máscara del grupo, y la forma de par es incorrecta. Lea la topología de la configuración en ejecución antes de escribir la línea.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Compruebe la dirección contra todo lo demás que podría poseerla: otra asignación explícita, el rango del grupo dinámico y cualquier ruta estática que presuponga un host fijo. Una dirección que se solape con el grupo funcionará hasta que el grupo se la dé a otro, y ese fallo parecerá aleatorio.

Compruebe el resultado en una conexión nueva

Una sesión existente conserva la dirección que se le dio, así que la única prueba significativa es una conexión nueva. Desconecte el cliente, vuelva a conectarlo y lea la dirección que realmente recibió junto con las rutas que llegaron con ella. Si la dirección sigue siendo dinámica, la asignación no se aplicó, y el siguiente paso es la consulta de la configuración y no otra edición del archivo de historial.

Mantenga las pruebas juntas: el nombre del cliente, el archivo que coincidió, la dirección asignada y el grupo del que salió.

Por último, una dirección de túnel fija no es una credencial del dispositivo. Identifica un lugar en el plan de direcciones, mientras que la autenticación sigue descansando en el certificado y la cuenta. Confundir ambas convierte un conflicto de direcciones en una suposición de seguridad que nadie escribió.