Windows inbyggda VPN når inte en leverantörs SSL-gateway: varför

Windows levereras med fyra tunneltyper, och en leverantörsgateway är inte en av dem. Rikta ändå en inbyggd profil mot en sådan, och anslutningen misslyckas före frågan om inloggningsuppgifter, oftast med ett meddelande om att anslutningen avbröts av det lokala systemet. Den texten är en signal om missmatchning, inte en diagnos. Profiltypen och klienten som äger protokollet måste stämma överens, och en av dem saknas.

Fyra typer och en dialog

Varje sparad profil bär en tunneltyp. Den inbyggda klienten accepterar PPTP, L2TP, IKEv2 och SSTP, plus ett automatiskt läge som prövar dem i tur och ordning. Det finns ingen allmän SSL VPN-post, och det går inte att lägga till en via dialogen. En leverantörsgateway talar sitt eget applikationsprotokoll över TLS, som bara den leverantörens klient implementerar.

Listan är ett kommando bort, och den är värd att köra före all annan felsökning eftersom den tar en sekund och tar bort en hel klass av felaktiga antaganden:

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

Om profilen säger SSTP och gatewayen inte är en RRAS-server är missmatchningen redan fastställd. Inget certifikat- eller brandväggsarbete ändrar det.

SSTP och leverantörs-TLS ser likadana ut på port 443

SSTP packar in en PPP-session i TLS och går över TCP 443. I Microsoft-stacken avslutas den av RRAS, som visar upp ett servercertifikat som klienten validerar. En Fortinet-, Citrix- eller Pulse-enhet avslutar också TLS på 443, och dess portal öppnas i vilken webbläsare som helst utan klagomål.

Det webbläsartestet bevisar nåbarhet, inte kompatibilitet. Sessionsprotokollet bakom portalen tillhör leverantören, och den inbyggda klienten har ingen implementation av det. Om leverantören levererar en egen klient berättar det vilken halva av missmatchningen du har att göra med.

Den omvända förväxlingen förekommer också. En profil konfigurerad som SSTP mot en riktig RRAS-server kan misslyckas i certifikatvalideringen medan portalen är i ordning, och det är ett certifikatproblem och inte ett protokollproblem.

Fel som visas innan en tunnel finns

Koderna i 800-serien rapporteras innan någon tunnel har upprättats, därför flyttar brandväggsregler dem sällan. Fel 812 är en serverpolicy som avvisar den autentiseringsmetod klienten erbjöd. Andra i intervallet kommer från den lokala anslutningshanteraren och inte från nätverket.

Slå på spårning innan du bygger upp något igen. Spårningen namnger steget som misslyckas, och ett stegnamn är värt mer än dialogtexten:

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

Spårningar hamnar under spårningskatalogen och stannar där tills du rensar dem, så stäng av spårningen efteråt i stället för att låta den gå i veckor.

En ansluten profil kan fortfarande förstöra allt

En profil som ansluter och sedan förstör surf, en lokal delning eller en containermotor har ett routingproblem, inte ett tunnelproblem. Standardgatewayen flyttade in i tunneln, så varje destination går nu via en peer som kanske inte routar den.

Två inställningar avgör detta. Den ena är split-tunneling-egenskapen på profilen. Den andra är alternativet per adapter att använda standardgatewayen i fjärrnätverket, som finns under de avancerade IPv4-inställningarna.

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

Att slå på split tunneling utan att lägga till rutter ger en tunnel som ansluter och inte når något. Att slå av det utan att kontrollera DNS ger interna namn som löses till offentliga svar, eftersom adapterns eget suffix och servrar inte används.

Kontrollera rördragningen, sedan typen

Arbeta i den här ordningen, och stanna när ett steg misslyckas i stället för att justera allt på en gång:

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

Det första kommandot skiljer nåbarhet från protokoll. Det andra bekräftar vad profilen påstår sig vara. Routningstabellen visar om tunneln fångade standardrutten. Uppringningskommandot rapporterar anslutningshanterarens eget fel, som ofta är tydligare än dialogen.

Anteckna tunneltypen, gatewayprodukten och det exakta felet i ärendet. Nästa person vet då inom en minut om det är en protokollmissmatchning, ett certifikatfel eller ett routingbeslut, i stället för att börja med ”VPN:et fungerar inte”.