A VPN integrada de Windows non chega a unha pasarela SSL de provedor: por que

Windows inclúe catro tipos de túnel, e unha pasarela SSL de provedor non é ningún deles. Apunta un perfil integrado a unha delas e a conexión falla antes da petición de credenciais, normalmente cunha mensaxe que di que o sistema local rematou a conexión. Ese texto é un sinal de desaxuste, non un diagnóstico. O tipo de perfil e o cliente que posúe o protocolo teñen que coincidir, e falta un dos dous.

Catro tipos e un diálogo

Cada perfil gardado leva un tipo de túnel. O cliente integrado acepta PPTP, L2TP, IKEv2 e SSTP, ademais dun modo automático que os proba en orde. Non hai ningunha entrada xenérica de SSL VPN, e non hai forma de engadir unha desde o diálogo. Unha pasarela de provedor fala o seu propio protocolo de aplicación sobre TLS, que só implementa o cliente dese provedor.

A lista está a unha orde de distancia, e paga a pena executala antes de calquera outro diagnóstico porque tarda un segundo e elimina toda unha clase de suposicións erróneas:

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

Se o perfil di SSTP e a pasarela non é un servidor RRAS, o desaxuste xa está establecido. Ningún traballo de certificados ou devasa o cambia.

SSTP e o TLS de provedor parécense no porto 443

SSTP envolve unha sesión PPP dentro de TLS e viaxa por TCP 443. Na pila de Microsoft termínaa RRAS, que presenta un certificado de servidor que o cliente valida. Un aparello Fortinet, Citrix ou Pulse tamén termina TLS no 443, e o seu portal ábrese en calquera navegador sen queixa.

Esa proba de navegador demostra accesibilidade, non compatibilidade. O protocolo de sesión detrás do portal pertence ao provedor, e o cliente integrado non ten ningunha implementación del. Se o provedor distribúe un cliente propio diche con que metade do desaxuste tratas.

A confusión inversa tamén ocorre. Un perfil configurado como SSTP contra un servidor RRAS auténtico pode fallar na validación do certificado mentres o portal está ben, e iso é un problema de certificado e non de protocolo.

Erros que aparecen antes de que exista un túnel

Os códigos da serie 800 notifícanse antes de que se estableza ningún túnel, por iso as regras de devasa raramente os moven. O erro 812 é unha política do servidor que rexeita o método de autenticación que ofreceu o cliente. Os demais do rango veñen do xestor de conexións local e non da rede.

Activa o seguimento antes de reconstruír nada. O seguimento nomea a etapa que falla, e un nome de etapa vale máis que o texto do diálogo:

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

Os seguimentos acaban no directorio de seguimento e quedan alí ata que os borres, así que desactiva o seguimento despois en lugar de deixalo funcionando durante semanas.

Un perfil conectado aínda pode romper todo

Un perfil que se conecta e despois rompe a navegación, un recurso compartido local ou un motor de contedores ten un problema de encamiñamento, non de túnel. A pasarela predeterminada trasladouse ao túnel, así que cada destino pasa agora por un par que quizais non o encamiñe.

Dous controis deciden isto. Un é a propiedade de split tunneling do perfil. O outro é a opción por adaptador de usar a pasarela predeterminada na rede remota, que está na configuración avanzada de IPv4.

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

Activar o split tunneling sen engadir rutas produce un túnel que se conecta e non chega a nada. Desactivalo sen comprobar o DNS produce nomes internos que se resolven en respostas públicas, porque non se usan o sufixo nin os servidores propios do adaptador.

Verifica a instalación, despois o tipo

Traballa nesta orde, e detente cando falle un paso en lugar de axustalo todo á vez:

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

A primeira orde separa a accesibilidade do protocolo. A segunda confirma que di ser o perfil. A táboa de rutas mostra se o túnel capturou a ruta predeterminada. A orde de marcado informa o erro propio do xestor de conexións, que adoita ser máis claro que o diálogo.

Anota o tipo de túnel, o produto da pasarela e o erro exacto no tícket. A persoa seguinte sabe entón nun minuto se é un desaxuste de protocolo, un fallo de certificado ou unha decisión de encamiñamento, en lugar de comezar por “a VPN non funciona”.