Túnel dividido no Windows: a caixa da porta de ligação e o prefixo que falta

O túnel diz que está ligado e a wiki ainda carrega. Depois uma transferência encrava e a partilha na prateleira deixa de responder. O túnel fez o seu trabalho, e o perfil reclamava simplesmente todos os destinos.

O Windows trata uma ligação VPN como uma decisão de encaminhamento. Enquanto essa decisão não for restringida, a máquina comporta-se como se tivesse mudado para o escritório.

Porque um túnel a funcionar parece uma falha

Um perfil autorizado a usar a porta de ligação remota instala uma rota predefinida através do túnel. Então cada destino que não está na ligação local sai pela firewall do escritório. As partilhas locais deixam de responder porque o seu tráfego agora viaja para outro continente e volta. Nada no estado do cliente reflete isso.

Os sintomas são confusos de propósito. A resolução de nomes pode continuar a funcionar enquanto a partilha expira, ou o contrário. O utilizador diz que a VPN está avariada, o cliente diz que está bem, e ambas as afirmações são exatas.

A caixa escondida na caixa de diálogo IPv4

A definição está vários diálogos mais fundo. Abra ncpa.cpl, clique com o botão direito na ligação, depois propriedades de IPv4, depois Avançadas, e desmarque a opção que permite à ligação tornar-se a porta de ligação predefinida remota. Essa única caixa decide se o perfil é um túnel completo. Tudo o resto do perfil continua a aplicar-se.

Compare route print -4 antes e depois da reconexão. A entrada 0.0.0.0 que antes apontava para o túnel já deve ter desaparecido, e os prefixos da empresa devem continuar lá.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Alterar a métrica da interface não é um substituto. Uma métrica só decide entre duas rotas predefinidas concorrentes, e um cliente que reinstala a sua própria rota predefinida a cada ligação ganha essa disputa seja qual for o número definido.

O prefixo que ninguém listou

O túnel dividido expõe exatamente os prefixos registados no perfil. Uma sub-rede de escritório acrescentada depois de o perfil ser escrito fica inalcançável enquanto o túnel está perfeitamente saudável. O relatório chega então como um servidor avariado em vez de uma VPN avariada.

Uma rota acrescentada à mão cobre a lacuna até o endereço da porta de ligação mudar. Registar o prefixo na ligação é mais sólido, porque o prefixo passa então a seguir a ligação em vez de um endereço adivinhado.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Leia a lista guardada e a tabela viva em conjunto. Um prefixo guardado pode existir enquanto a tabela nunca o recebe, o que acontece quando um agente de gestão filtra rotas depois de a ligação subir. O contrário também acontece, com uma rota do registo a apontar para um adaptador desligado. Nenhuma das duas vistas sozinha conta a história toda.

Provar o resultado depois de um reinício

Trace nos dois sentidos e resolva por nome. Um traço público deve sair pelo fornecedor, um traço interno deve entrar no túnel, e um anfitrião interno deve responder por nome e não apenas por endereço.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Repita depois de uma desconexão, de uma reconexão e de um reinício. Um prefixo que sobrevive a uma reconexão manual e desaparece depois de um reinício nunca foi guardado no perfil.

Mantenha também a impressora e o NAS no teste, porque um túnel dividido que corta os dispositivos ao lado do portátil resolveu um problema criando outro mais pequeno e mais irritante. A referência da Microsoft para Add-VpnConnectionRoute é o lugar onde verificar a ortografia dos parâmetros face à versão do seu módulo.