Uma redefinição de rede do Windows apaga mais do que a falha da VPN

O conselho chega dez minutos depois de cada queixa de VPN no Windows: execute a redefinição de rede, resolve tudo. Não resolve, e não é estreita. Esse botão limpa adaptadores, volta a ligar protocolos, remove endereços estáticos e rotas predefinidas, descarta entradas de firewall e filtros e, ainda por cima, esquece perfis de Wi-Fi. Numa máquina com um túnel a funcionar mas mal configurado, transforma uma falha diagnosticável numa reconstrução não documentada. Guarde cinco coisas primeiro e mantém a opção de desfazer isto.

A redefinição não se limita ao perfil da VPN

Uma ligação VPN é um objeto entre muitos que partilham a pilha de rede. Remover e voltar a adicionar um adaptador altera o índice da interface, e tudo o que fazia referência a esse índice, de uma rota a uma regra de firewall a um controlador de filtro de terceiros, passa a referir algo que já não existe.

A virtualização piora isto. Os comutadores Hyper-V, as pontes VMware, as redes de contentores e os clientes VPN com os seus próprios adaptadores virtuais vivem todos no mesmo espaço. Uma redefinição que reinstala a pilha base pode deixar esses componentes meio presentes, e a máquina resultante reporta hardware a funcionar sem qualquer caminho a funcionar.

Nada disso é um argumento contra redefinir alguma vez. É um argumento contra redefinir primeiro, numa máquina que não documentou, quando a falha real pode ser uma entrada de rota ou um filtro obsoleto. Uma redefinição é uma ferramenta ampla com uma taxa de sucesso estreita, e usá-la como primeiro movimento garante que nunca saberá qual das duas coisas era.

Guarde as provas antes de guardar as definições

A própria falha são dados. Anote o código de erro exato, a hora, que perfil estava selecionado e se a gateway registou alguma tentativa. Um código que diz que o túnel nunca recebeu resposta e um código que diz que a autenticação falhou apontam para reparações completamente diferentes. Depois de uma redefinição pode não conseguir reproduzir nenhum dos dois. Trate o estado avariado como um ativo que está prestes a gastar.

Capture o estado enquanto ainda está avariado, numa pasta fora dos diretórios temporários da máquina:

mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml

O último comando é o que as pessoas omitem, e é frequentemente o que explica a falha. Os filtros sobrantes de um cliente removido sobrevivem como política persistente, e o XML exportado é o único registo local deles. Leia-o antes de uma redefinição apagar o que estava a tentar identificar.

Guarde a configuração que não volta

Algumas definições são recriadas automaticamente. Os endereços estáticos, as rotas personalizadas, os sufixos DNS, as exceções de proxy e as regras de firewall não. Nem os próprios perfis, que vivem num ficheiro de agenda telefónica que a redefinição não lhe restaura.

Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter

A lista de certificados importa mais do que parece. Os certificados de cliente não são destruídos por uma redefinição de rede, mas a lista diz-lhe de quais o perfil dependia e se algum expira em breve. Descobrir um certificado expirado depois de uma reconstrução desperdiça a reconstrução.

Escreva o caminho de recuperação antes de começar

Se a máquina estiver remota e a VPN for a sua única via de entrada, a redefinição pode terminar a sua sessão e pode não haver caminho de volta sem alguém no local. Confirme que existe acesso fora de banda, ou que há uma pessoa disponível, antes de executar qualquer coisa que toque em adaptadores.

Guarde os instaladores e os detalhes de ligação num local a que a máquina ainda consiga chegar depois. Um cliente que tem de ser reinstalado a partir de um portal do fornecedor alcançado pelo túnel é uma dependência circular, e é a forma mais comum de este procedimento se tornar uma paragem do serviço.

Depois registe o que está a fazer e porquê, incluindo os comandos exatos. A pessoa seguinte precisa de saber se a redefinição foi uma experiência ou uma decisão, e “tentámos tudo” não é um registo.

Teste por camadas depois da redefinição

Restaurar demasiado de uma vez torna o resultado ilegível. Trabalhe de baixo para cima: adaptador e endereço, depois resolução de nomes, depois a etapa de identidade do túnel, depois a aplicação. Cada camada tem um comando que responde à sua própria pergunta:

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443

Se a camada do adaptador estiver saudável e a resolução não, pare e corrija a resolução. Reinstalar o cliente VPN nesse ponto acrescenta uma variável e retira uma pista. Restaure apenas as definições que consegue explicar, uma de cada vez, verificando a mesma camada depois de cada uma.

As próprias orientações de resolução de problemas da Microsoft para o erro 720, por exemplo, distinguem problemas de ligação de problemas de atribuição de endereços em vez de receitar uma redefinição geral, o que é o instinto certo para cada código desta família. Leia o que o código afirma antes de pegar na ferramenta mais ampla disponível.