¿El adaptador OpenVPN parpadea en Windows? Compruebe si hay una IP duplicada

En Windows, un adaptador OpenVPN que toma una dirección, la suelta y lo repite cada pocos segundos normalmente no es un fallo de DHCP. Se le indica al adaptador que use una dirección que ya responde otra cosa, así que Windows la marca como no utilizable y el cliente empieza de nuevo. El registro del cliente permanece silencioso porque el conflicto se resuelve por debajo, dentro de la propia pila de red del sistema operativo.

Esa distinción importa, porque cada paso de diagnóstico dirigido a la configuración del túnel pasará por alto una dirección duplicada en el lado del servidor.

Empiece por el registro de eventos de Windows, no por el registro del cliente

Windows registra los conflictos de direcciones en el registro del sistema, con los identificadores de evento 4198 y 4199. El primero informa de un conflicto detectado para una dirección, el segundo informa de que una interfaz no pudo usar la dirección con la que estaba configurada. Ninguno menciona OpenVPN, y por eso mismo es fácil pasarlos por alto.

Extraiga los eventos recientes y compare sus marcas de tiempo con el ciclo de renovación del adaptador: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflicto cada quince segundos encaja con un cliente que reintenta la misma dirección contra un propietario que sigue respondiendo por ella. Un solo conflicto en el momento de la conexión apunta más bien a una colisión puntual. En cualquier caso, la siguiente pregunta es quién más tiene la dirección.

Tres disposiciones ponen dos hosts en una dirección

Pregunte al servidor quién cree que tiene la dirección y luego pregunte a la red quién responde por ella. grep -H ifconfig-push /etc/openvpn/ccd/* enumera cada dirección de túnel fijada y el certificado al que pertenece. ip -4 neigh show dev tap0 muestra lo que el puente ha aprendido en la segunda capa. Comparar esas dos listas encuentra la mayoría de los duplicados en menos de un minuto.

Tres disposiciones explican casi todos: una entrada de client-config-dir fija una dirección para dos certificados, un segmento tap puenteado da a una máquina una dirección que otro host ya tiene de forma estática, o un archivo de concesión obsoleto devuelve una dirección que un cliente aún conectado cree poseer. El tercer caso es el más traicionero, porque ifconfig-pool-persist reutiliza deliberadamente direcciones para clientes conocidos.

Haga la dirección única en lugar de competir por ella

El orden de arranque solo decide quién gana hoy, así que trate como temporal cualquier corrección basada en la secuencia de reinicio. Dé a cada cliente su propia línea ifconfig-push o asigne direcciones estáticas de un rango que no toque ninguna interfaz de puente ni de servidor. Revise también la lista de clientes en busca de nombres comunes duplicados, porque duplicate-cn permite que dos sesiones compartan una identidad y, por tanto, una dirección fijada. Si un dispositivo puenteado necesita de verdad una dirección fija, muévalo a su propia subred o resérvela del conjunto en un lugar que el servidor registre.

Borre el archivo persist solo después de saber qué concesiones contiene, o la próxima reconexión repartirá las mismas direcciones otra vez.

Reinicie en el orden correcto y confirme un solo propietario por dirección

Aplique el cambio primero en el servidor y luego reconecte los clientes, para que cada participante se registre contra el conjunto corregido. Reiniciar primero los clientes los deja con direcciones que el servidor aún cree ocupadas. Tras el reinicio, lea el archivo de estado y confirme que cada nombre común aparece una vez con una dirección. Dos entradas para un nombre significan que una sesión antigua nunca se cerró, no que el conjunto esté roto.

Si un cliente sigue sin poder conservar su dirección, compruebe si la lleva una interfaz de puente en el mismo host. Un puente que heredó una dirección de un dispositivo de proveedor responderá ARP por ella incluso cuando el servidor VPN ya haya entregado esa dirección a un cliente.

Observe un ciclo de renovación completo antes de cerrar el ticket

Una lectura limpia no demuestra nada. Observe el adaptador al menos diez minutos y fuerce una reconexión a mitad: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. La dirección debería sobrevivir a la reconexión y permanecer en un estado preferido.

Luego vuelva a ejecutar la consulta de eventos del primer paso y confirme que no devuelve nada nuevo. Un registro silencioso durante una reconexión es la prueba de que el conflicto desapareció, mientras que un registro silencioso tras una sola conexión solo significa que la carrera aún no ha ocurrido. Por último, pruebe el recurso para el que existe el túnel, porque un puente que perdió su dirección puede romper una ruta del proveedor mientras la propia VPN parece sana.

Anote el rango del conjunto, cada dirección fijada y el host que la posee en las notas del servidor. Así la próxima colisión se detecta en minutos en lugar de necesitar toda una tarde para redescubrirla.