O adaptador OpenVPN parpadea en Windows? Comprobe se hai unha IP duplicada

En Windows, un adaptador OpenVPN que toma un enderezo, sóltase e repíteo cada poucos segundos normalmente non é un fallo de DHCP. Indícalle ao adaptador que use un enderezo ao que xa responde outra cousa, así que Windows márcao como non utilizábel e o cliente comeza de novo. O rexistro do cliente queda silencioso porque o conflito se resolve por debaixo, dentro da propia pila de rede do sistema operativo.

Esa distinción importa, porque cada paso de diagnóstico dirixido á configuración do túnel pasará por alto un enderezo duplicado no lado do servidor.

Comece polo rexistro de eventos de Windows, non polo rexistro do cliente

Windows rexistra os conflitos de enderezos no rexistro do sistema, cos identificadores de evento 4198 e 4199. O primeiro informa dun conflito detectado para un enderezo, o segundo informa de que unha interface non puido usar o enderezo co que estaba configurada. Ningún menciona OpenVPN, e por iso mesmo é doado pasalos por alto.

Extraia os eventos recentes e compare as súas marcas de tempo co ciclo de renovación do adaptador: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflito cada quince segundos encaixa cun cliente que reintenta o mesmo enderezo contra un propietario que segue respondendo por el. Un só conflito no momento da conexión apunta máis ben a unha colisión puntual. En calquera caso, a seguinte pregunta é quen máis ten o enderezo.

Tres disposicións poñen dous servidores nun enderezo

Pregunte ao servidor quen cre que ten o enderezo e logo pregunte á rede quen responde por el. grep -H ifconfig-push /etc/openvpn/ccd/* enumera cada enderezo de túnel fixado e o certificado ao que pertence. ip -4 neigh show dev tap0 mostra o que a ponte aprendeu na segunda capa. Comparar esas dúas listas atopa a maioría dos duplicados en menos dun minuto.

Tres disposicións explican case todos: unha entrada de client-config-dir fixa un enderezo para dous certificados, un segmento tap pontado dá a unha máquina un enderezo que outro servidor xa ten de forma estática, ou un ficheiro de concesión obsoleto devolve un enderezo que un cliente aínda conectado cre posuír. O terceiro caso é o máis traizoeiro, porque ifconfig-pool-persist reutiliza deliberadamente enderezos para clientes coñecidos.

Faga o enderezo único en lugar de competir por el

A orde de arranque só decide quen gaña hoxe, así que trate como temporal calquera corrección baseada na secuencia de reinicio. Dea a cada cliente a súa propia liña ifconfig-push ou asignar enderezos estáticos dun rango que ningunha interface de ponte nin de servidor toque. Revise tamén a lista de clientes por nomes comúns duplicados, porque duplicate-cn permite que dúas sesións compartan unha identidade e, polo tanto, un enderezo fixado. Se un dispositivo pontado necesita de verdade un enderezo fixo, móvao ao seu propio subrede ou resérveo do conxunto nun lugar que o servidor rexistre.

Borrar o ficheiro persist só despois de saber que concesións contén, ou a próxima reconexión repartirá os mesmos enderezos outra vez.

Reinicie na orde correcta e confirme un único propietario por enderezo

Aplique o cambio primeiro no servidor e logo reconecte os clientes, para que cada participante se rexistre contra o conxunto corrixido. Reiniciar primeiro os clientes déixaos con enderezos que o servidor aínda cre ocupados. Tras o reinicio, lea o ficheiro de estado e confirme que cada nome común aparece unha vez cun enderezo. Dúas entradas para un nome significan que unha sesión antiga nunca se pechou, non que o conxunto estea roto.

Se un cliente segue sen poder conservar o seu enderezo, comprobe se o leva unha interface de ponte no mesmo servidor. Unha ponte que herdou un enderezo dun dispositivo de provedor responderá ARP por el mesmo cando o servidor VPN xa entregou ese enderezo a un cliente.

Observe un ciclo de renovación completo antes de pechar o ticket

Unha lectura limpa non demostra nada. Observe o adaptador polo menos dez minutos e force unha reconexión a metade: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. O enderezo debería sobrevivir á reconexión e manterse nun estado preferido.

Logo volva executar a consulta de eventos do primeiro paso e confirme que non devolve nada novo. Un rexistro silencioso durante unha reconexión é a proba de que o conflito desapareceu, mentres que un rexistro silencioso tras unha soa conexión só significa que a carreira aínda non ocorreu. Por último, probe o recurso polo que existe o túnel, porque unha ponte que perdeu o seu enderezo pode romper unha ruta do provedor mentres a propia VPN parece sans.

Anote o rango do conxunto, cada enderezo fixado e o servidor que o posúe nas notas do servidor. Así a próxima colisión detéctase en minutos en lugar de necesitar toda unha tarde para redescubrila.