VPN do Windows: o perfil guardado face ao estado da interface ativa

Uma VPN do Windows aparece em dois locais que respondem a perguntas diferentes, e confundi-los produz um diagnóstico confiante mas errado. O perfil guardado diz o que alguém configurou; a interface ativa diz o que a pilha acabou de aplicar. Quando uma ligação se estabelece e o tráfego continua a seguir o caminho errado, ambas as vistas têm de ser lidas, nessa ordem. Nenhuma delas sozinha lhe diz se o pacote da aplicação saiu pelo túnel.

Duas vistas do mesmo túnel

A vista do perfil é configuração: endereço do servidor, tipo de túnel, método de autenticação, definições de túnel dividido. Pode estar correta enquanto a ligação a ignora, e pode estar desatualizada enquanto a ligação funciona perfeitamente, porque um cliente que volta a ligar-se pode não reler o que editou. A vista da interface é estado aplicado: que adaptadores existem, que famílias de endereços transportam, as suas métricas e o seu estado de ligação. Muda à medida que os túneis aparecem e desaparecem, o que a torna o local certo para uma pergunta de encaminhamento em direto e o local errado para uma pergunta de configuração.

Lê-las em conjunto é o método completo, e ler qualquer uma delas sozinha é como as pessoas acabam a eliminar um adaptador saudável. Os comandos abaixo produzem ambas as vistas sem alterar nada.

Leia ambas as vistas sem alterar nada

Comece pelos perfis guardados, porque é o facto mais barato de confirmar. Repare no tipo de túnel e no valor de túnel dividido, uma vez que ambos decidem que destinos devem entrar no túnel. Se o perfil estiver errado, corrija-o através da sua superfície de configuração suportada, porque nada na lista de interfaces repara um perfil que aponta para um gateway errado.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

A vista da interface tem uma forma diferente: um túnel pode ocupar duas linhas quando transporta ambas as famílias de endereços. Leia o índice como a identidade e o alias como uma etiqueta que alguém escolheu, e espere que o alias mude entre versões do cliente.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

A presença não é prova de uso, porque uma interface pode existir, estar ligada e ainda assim não ser a que a rota para o seu destino escolhe. Tenha isso em conta antes de tratar um adaptador desconhecido como a culpa. Estas duas falhas parecem idênticas de fora: um perfil correto com uma rota que nunca o usa, e um perfil errado com uma rota que o usa. Têm correções completamente diferentes, e é por isso que existe a secção seguinte.

Siga a rota até ao destino

Pergunte à pilha que caminho seguiria para o endereço que a aplicação contacta realmente. É a pergunta a que a lista de interfaces não consegue responder sozinha.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

O primeiro comando relata dois campos que vale a pena ler: o alias de interface da origem escolhida e o salto seguinte para esse destino. O índice 37 no segundo comando é o que a primeira saída imprimiu, não uma constante a copiar, e o endereço 10.60.20.10 é ilustrativo. Se a origem escolhida pertencer ao adaptador físico enquanto o destino deveria estar dentro do túnel, encontrou o problema de seleção, porque a interface VPN pode estar perfeitamente saudável e simplesmente não ser preferida. A métrica é apenas parte dessa decisão, uma vez que a especificidade da rota, a política e o estado da interface participam todas.

Compare três estados nas mesmas condições

Registe a lista de interfaces e a rota escolhida antes de ligar, enquanto está ligado e depois de desligar, com o mesmo destino e os mesmos comandos em cada vez. Essa comparação separa uma interface de túnel atual de um adaptador antigo e oculto deixado por uma desinstalação, e de um segundo cliente que também está a correr. Também lhe diz se a interface do túnel desaparece de forma limpa, porque um adaptador que persiste após desligar é um problema diferente de um que nunca apareceu. Sem as três instantâneas, qualquer alias desconhecido parece o culpado.

Guarde as três saídas com o ticket, porque duas saídas de comandos valem mais do que um parágrafo de descrição. Um colega pode compará-las sem repetir a sua sessão.

Não elimine o que não identificou

Os adaptadores desconhecidos pertencem geralmente a algo: um cliente gerido, um comutador virtual, uma rede de contentores ou um agente de segurança. Eliminar um pode remover um componente que funciona e deixar o sintoma original exatamente onde estava. Se a rota estiver obsoleta, encontre o proprietário da rota e corrija-a aí; se o perfil estiver errado, edite o perfil. A documentação do Get-NetIPInterface lista os campos usados acima, incluindo as colunas de métrica e estado que tornam a comparação significativa.

Nomeie o objeto, encontre o seu proprietário, e depois atue sobre esse proprietário. Qualquer outra coisa é renomear o problema em vez de o ler.