Por que o Always On VPN deixa de disparar na rede do escritório

O portátil junta-se ao Wi-Fi do escritório, e o perfil Always On que ligava de casa fica em baixo. Nada no registo de eventos lhe chama falha, porque do ponto de vista do cliente a rede é fidedigna e o túnel é desnecessário. A deteção de rede fidedigna é a funcionalidade que toma essa decisão, e compara valores concretos em vez de reconhecer um SSID familiar. Quando a decisão está errada, é preciso ver que comparação passou.

O que o disparador compara realmente

Três coisas têm de coincidir antes de o cliente tratar uma rede como fidedigna. Primeiro, o sufixo DNS específico da ligação que o Windows regista para o adaptador físico tem de aparecer na lista de sufixos do perfil. Segundo, o perfil de ligação que o Windows mantém para essa rede tem de ser o que a política espera, porque a correspondência é feita contra esse perfil e não contra um nome que um utilizador tenha escrito numa caixa de diálogo sem fios. Terceiro, a rede tem de ser classificada como a política exige, o que na prática significa uma rede de domínio ou privada, ou um dispositivo cuja política chegou por gestão. Retire qualquer uma e o disparador ativa-se.

É um teste mais estreito do que comparar o endereço de saída público da VPN, e muito mais estreito do que confiar num SSID. Um ponto de acesso que repita o nome da empresa não satisfaz sozinho as comparações de sufixo e de perfil. Significa também que a funcionalidade nada diz sobre se uma rede é segura; diz se este dispositivo acredita que já está em casa.

Leia o estado atual antes de alterar o perfil

Comece pelo que o Windows acredita agora. O cmdlet de perfil de ligação comunica o nome da rede, a interface e a categoria atribuída pelo Windows, que é a terceira comparação acima. Depois leia o perfil da VPN e procure a lista de sufixos fidedignos, com um despejo completo de propriedades em vez de adivinhar os nomes:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Se esse despejo não expuser o sufixo fidedigno na sua compilação, recorra ao XML do perfil, que é a cópia autoritativa quando a superfície de propriedades difere entre versões. Leia o XML a partir da política de gestão ou do arquivo de perfis de todos os utilizadores, e compare as suas entradas de sufixo com o sufixo do adaptador indicado acima. Registe ambos os valores antes de tocar em qualquer um.

Teste a fronteira nos dois sentidos

Teste na ligação empresarial prevista e numa outra rede aprovada, e registe se o túnel subiu. Depois teste o mesmo dispositivo após sair. Um portátil que dispara em casa e é suprimido no escritório comporta-se como concebido, enquanto um que nunca dispara em lado nenhum tem outra falha. Verifique se os recursos atrás do túnel estão acessíveis quando dispara, porque um túnel iniciado não é prova de um caminho funcional.

Não acrescente um sufixo amplo só para que uma notificação desapareça. Um sufixo que aparece em muitas redes ensina o cliente a suprimir o túnel quase em toda a parte, e a carga de suporte que se segue é pior do que a notificação. Altere os critérios através do proprietário do perfil, que numa frota gerida é o administrador de MDM e não a pessoa ao lado do portátil.

Guarde as duas redes de teste no registo junto do resultado. Uma fronteira que nunca foi testada é apenas uma afirmação.

Separe a supressão do bloqueio

Um túnel que não foi iniciado não é uma ligação bloqueada. A deteção de rede fidedigna controla o disparo automático, enquanto a filtragem de tráfego e o comportamento do kill-switch são definições de política separadas com os seus próprios modos de falha. Um dispositivo numa rede fidedigna pode enviar tráfego fora do túnel de forma legítima, e chamar a isso fuga sem ler a política confunde dois desenhos. Verifique as regras de tráfego do perfil antes de culpar a deteção por uma fuga.

A mesma distinção explica a queixa inversa. Os utilizadores que relatam que a VPN parou ao acaso descrevem geralmente uma mudança de rede que cumpriu os critérios, não uma falha do serviço. O sufixo correspondido e a categoria de rede são as provas a recolher, e ambas aparecem na saída acima.

Recolha essas provas antes de alterar a política. Um interruptor que esconde o sintoma esconde também a causa.

Registe em que se baseou a decisão

Escreva o sufixo correspondido, o nome do perfil de ligação e a categoria de rede nas notas de implementação de cada local. Quando o túnel não sobe, esse registo transforma um mistério numa comparação: ou mudou um dos três valores, ou mudou a política. Também dá ao engenheiro seguinte uma forma de confirmar o desenho em vez de desativar a deteção para fechar o ticket.

Reveja a lista de sufixos quando um local é renomeado ou um domínio é consolidado, porque uma entrada obsoleta continua a suprimir o túnel em silêncio. A referência da Microsoft sobre a deteção de rede fidedigna enumera os elementos do perfil e os pré-requisitos de implementação, e é o documento a citar quando alguém propõe alargar a lista.