O adaptador OpenVPN pisca no Windows? Verifique se há um IP duplicado

No Windows, um adaptador OpenVPN que toma um endereço, abandona-o e repete isso a cada poucos segundos normalmente não é um erro de DHCP. Diz-se ao adaptador para usar um endereço ao qual outra coisa já responde, então o Windows marca-o como inutilizável e o cliente recomeça. O log do cliente permanece silencioso porque o conflito é resolvido por baixo, dentro da própria pilha de rede do sistema operativo.

Essa distinção importa, porque cada passo de diagnóstico dirigido à configuração do túnel vai deixar passar um endereço duplicado do lado do servidor.

Comece pelo registo de eventos do Windows, não pelo log do cliente

O Windows registra os conflitos de endereços no registo do sistema, com os IDs de evento 4198 e 4199. O primeiro relata um conflito detetado para um endereço, o segundo relata que uma interface não conseguiu usar o endereço com que estava configurada. Nenhum deles menciona o OpenVPN, e é exatamente por isso que passam facilmente despercebidos.

Extraia os eventos recentes e compare as respetivas marcas temporais com o ciclo de renovação do adaptador: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Um conflito a cada quinze segundos corresponde a um cliente que tenta de novo o mesmo endereço contra um proprietário que continua a responder por ele. Um único conflito no momento da ligação aponta antes para uma colisão pontual. Em qualquer caso, a pergunta seguinte é quem mais detém o endereço.

Três disposições colocam dois anfitriões num único endereço

Pergunte ao servidor quem, na sua opinião, detém o endereço, e depois pergunte à rede quem responde por ele. grep -H ifconfig-push /etc/openvpn/ccd/* lista cada endereço de túnel fixado e o certificado a que pertence. ip -4 neigh show dev tap0 mostra o que a ponte aprendeu na segunda camada. Comparar essas duas listas encontra a maioria dos duplicados em menos de um minuto.

Três disposições explicam quase todos: uma entrada de client-config-dir fixa um endereço para dois certificados, um segmento tap ligado em ponte dá a uma máquina um endereço que outro anfitrião já tem estaticamente, ou um ficheiro de concessão obsoleto devolve um endereço que um cliente ainda ligado pensa possuir. O terceiro caso é o mais traiçoeiro, porque ifconfig-pool-persist reutiliza deliberadamente endereços para clientes conhecidos.

Torne o endereço exclusivo em vez de competir por ele

A ordem de arranque só decide quem ganha hoje, por isso trate como temporária qualquer correção baseada na sequência de reinício. Dê a cada cliente a sua própria linha ifconfig-push, ou atribua endereços estáticos de um intervalo que nenhuma interface de ponte ou de servidor toque. Reveja também a lista de clientes quanto a nomes comuns duplicados, porque duplicate-cn permite que duas sessões partilhem uma identidade e, portanto, um endereço fixado. Se um dispositivo ligado em ponte precisar mesmo de um endereço fixo, mova-o para a sua própria sub-rede ou reserve-o do conjunto num local que o servidor registe.

Apague o ficheiro persist só depois de saber que concessões contém, ou a próxima reconexão voltará a distribuir os mesmos endereços.

Reinicie pela ordem certa e confirme um único proprietário por endereço

Aplique a alteração primeiro no servidor e só depois reconecte os clientes, para que cada participante se registe contra o conjunto corrigido. Reiniciar primeiro os clientes deixa-os com endereços que o servidor ainda considera ocupados. Após o reinício, leia o ficheiro de estado e confirme que cada nome comum aparece uma vez com um endereço. Duas entradas para um nome significam que uma sessão antiga nunca foi fechada, não que o conjunto esteja avariado.

Se um cliente continuar a não conseguir manter o seu endereço, verifique se uma interface de ponte no mesmo anfitrião o transporta. Uma ponte que herdou um endereço de um dispositivo do fornecedor responderá a ARP por ele mesmo quando o servidor VPN já entregou esse endereço a um cliente.

Observe ao longo de um ciclo completo de renovação antes de fechar o ticket

Uma leitura limpa não prova nada. Observe o adaptador pelo menos dez minutos e force uma reconexão a meio: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. O endereço deverá sobreviver à reconexão e permanecer num estado preferido.

Depois, execute novamente a consulta de eventos do primeiro passo e confirme que não devolve nada novo. Um registo silencioso ao longo de uma reconexão é a prova de que o conflito desapareceu, enquanto um registo silencioso após uma única ligação significa apenas que a corrida ainda não aconteceu. Por fim, teste o recurso para o qual o túnel existe, porque uma ponte que perdeu o seu endereço pode quebrar um caminho do fornecedor enquanto a própria VPN parece saudável.

Registe o intervalo do conjunto, cada endereço fixado e o anfitrião que o detém nas notas do servidor. A próxima colisão passa então a ser detetada em minutos em vez de exigir uma tarde inteira para ser redescoberta.