A VPN integrada do Windows não alcança um gateway SSL de fornecedor: porquê

O Windows traz quatro tipos de túnel, e um gateway SSL de fornecedor não é nenhum deles. Aponte mesmo assim um perfil integrado para um deles, e a ligação falha antes do pedido de credenciais, normalmente com uma mensagem de que a ligação foi terminada pelo sistema local. Esse texto é um sinal de incompatibilidade, não um diagnóstico. O tipo de perfil e o cliente que possui o protocolo têm de coincidir, e falta um dos dois.

Quatro tipos e uma caixa de diálogo

Cada perfil guardado leva um tipo de túnel. O cliente integrado aceita PPTP, L2TP, IKEv2 e SSTP, além de um modo automático que os tenta por ordem. Não existe nenhuma entrada genérica de SSL VPN, e não há forma de acrescentar uma pela caixa de diálogo. Um gateway de fornecedor fala o seu próprio protocolo de aplicação sobre TLS, que só o cliente desse fornecedor implementa.

A lista está a um comando de distância, e vale a pena executá-la antes de qualquer outra resolução de problemas porque demora um segundo e elimina toda uma classe de pressupostos errados:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Se o perfil diz SSTP e o gateway não é um servidor RRAS, a incompatibilidade já está estabelecida. Nenhum trabalho de certificados ou firewall a altera.

SSTP e o TLS de fornecedor parecem iguais na porta 443

O SSTP envolve uma sessão PPP dentro de TLS e circula em TCP 443. Na pilha da Microsoft é terminado pelo RRAS, que apresenta um certificado de servidor que o cliente valida. Um equipamento Fortinet, Citrix ou Pulse também termina TLS na 443, e o seu portal abre em qualquer navegador sem queixas.

Esse teste no navegador prova a alcançabilidade, não a compatibilidade. O protocolo de sessão por trás do portal pertence ao fornecedor, e o cliente integrado não tem nenhuma implementação dele. Saber se o fornecedor distribui um cliente próprio diz-lhe com que metade da incompatibilidade está a lidar.

A confusão inversa também acontece. Um perfil configurado como SSTP contra um servidor RRAS genuíno pode falhar na validação do certificado enquanto o portal está bem, e isso é um problema de certificado e não de protocolo.

Erros que aparecem antes de existir um túnel

Os códigos da série 800 são reportados antes de qualquer túnel ser estabelecido, e é por isso que as regras de firewall raramente os movem. O erro 812 é uma política do lado do servidor que rejeita o método de autenticação oferecido pelo cliente. Os restantes do intervalo vêm do gestor de ligações local e não da rede.

Ative o rastreio antes de reconstruir seja o que for. O rastreio nomeia a etapa que falha, e um nome de etapa vale mais do que o texto da caixa de diálogo:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Os rastreios ficam no diretório de rastreio e permanecem lá até os limpar, por isso desative o rastreio depois em vez de o deixar a correr durante semanas.

Um perfil ligado ainda pode estragar tudo

Um perfil que se liga e depois estraga a navegação, uma partilha local ou um motor de contentores tem um problema de encaminhamento, não um problema de túnel. O gateway predefinido mudou para o túnel, por isso cada destino passa agora por um par que pode não o encaminhar.

Dois controlos decidem isto. Um é a propriedade de split tunneling do perfil. O outro é a opção por adaptador de usar o gateway predefinido na rede remota, que está nas definições avançadas de IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Ativar o split tunneling sem acrescentar rotas produz um túnel que se liga e não alcança nada. Desativá-lo sem verificar o DNS produz nomes internos que se resolvem em respostas públicas, porque o sufixo e os servidores do próprio adaptador não são usados.

Verifique a instalação, depois o tipo

Trabalhe nesta ordem, e pare quando um passo falhar em vez de ajustar tudo ao mesmo tempo:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

O primeiro comando separa a alcançabilidade do protocolo. O segundo confirma o que o perfil diz ser. A tabela de rotas mostra se o túnel capturou a rota predefinida. O comando de marcação reporta o erro do próprio gestor de ligações, que muitas vezes é mais claro do que a caixa de diálogo.

Registe o tipo de túnel, o produto do gateway e o erro exato no ticket. A pessoa seguinte sabe então num minuto se é uma incompatibilidade de protocolo, uma falha de certificado ou uma decisão de encaminhamento, em vez de começar por “a VPN não funciona”.