Windows’ innebygde VPN når ikke en leverandørs SSL-gateway: hvorfor

Windows leveres med fire tunneltyper, og en leverandørgateway er ikke en av dem. Retter du likevel en innebygd profil mot en, feiler tilkoblingen før påloggingsforespørselen, vanligvis med en melding om at tilkoblingen ble avsluttet av det lokale systemet. Den teksten er et signal om manglende samsvar, ikke en diagnose. Profiltypen og klienten som eier protokollen må stemme overens, og én av dem mangler.

Fire typer og én dialog

Hver lagrede profil har en tunneltype. Den innebygde klienten godtar PPTP, L2TP, IKEv2 og SSTP, i tillegg til en automatisk modus som prøver dem i rekkefølge. Det finnes ingen generell SSL VPN-oppføring, og det er ingen måte å legge til én via dialogen. En leverandørgateway snakker sin egen applikasjonsprotokoll over TLS, som bare klienten til den leverandøren implementerer.

Listen er én kommando unna, og den er verdt å kjøre før annen feilsøking fordi den tar et sekund og fjerner en hel klasse av feil antakelser:

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

Hvis profilen sier SSTP og gatewayen ikke er en RRAS-server, er manglende samsvar allerede fastslått. Ingen sertifikat- eller brannmurjobb endrer det.

SSTP og leverandør-TLS ser like ut på port 443

SSTP pakker en PPP-økt inn i TLS og går på TCP 443. I Microsoft-stakken avsluttes den av RRAS, som viser frem et serversertifikat som klienten validerer. En Fortinet-, Citrix- eller Pulse-enhet avslutter også TLS på 443, og portalen åpnes i enhver nettleser uten klager.

Den nettlesertesten beviser nåbarhet, ikke kompatibilitet. Sesjonsprotokollen bak portalen tilhører leverandøren, og den innebygde klienten har ingen implementasjon av den. Om leverandøren leverer sin egen klient forteller deg hvilken halvdel av manglende samsvar du har med å gjøre.

Den omvendte forvekslingen skjer også. En profil konfigurert som SSTP mot en ekte RRAS-server kan feile på sertifikatvalidering mens portalen er i orden, og det er et sertifikatproblem og ikke et protokollproblem.

Feil som vises før en tunnel finnes

Kodene i 800-serien rapporteres før noen tunnel er etablert, derfor flytter brannmurregler dem sjelden. Feil 812 er en serverpolitikk som avviser autentiseringsmetoden klienten tilbød. Andre i området kommer fra den lokale tilkoblingsbehandleren og ikke fra nettverket.

Slå på sporing før du bygger opp noe på nytt. Sporingen navngir trinnet som feiler, og et trinnnavn er mer verdt enn dialogteksten:

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

Sporinger havner under sporingsmappen og blir der til du rydder dem, så slå sporingen av etterpå i stedet for å la den gå i ukevis.

En tilkoblet profil kan fortsatt ødelegge alt

En profil som kobler til og deretter ødelegger nettsurfing, en lokal deling eller en containermotor har et ruteproblem, ikke et tunnelproblem. Standardgatewayen flyttet til tunnelen, så hver destinasjon går nå gjennom en motpart som kanskje ikke ruter den.

To kontroller avgjør dette. Den ene er split-tunneling-egenskapen på profilen. Den andre er alternativet per adapter for å bruke standardgatewayen på fjernnettverket, som ligger under de avanserte IPv4-innstillingene.

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

Å slå på split tunneling uten å legge til ruter gir en tunnel som kobler til og ikke når noe. Å slå det av uten å sjekke DNS gir interne navn som løses til offentlige svar, fordi adapterens eget suffiks og servere ikke brukes.

Kontroller rørleggerarbeidet, deretter typen

Arbeid i denne rekkefølgen, og stopp når et trinn feiler i stedet for å justere alt på en gang:

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

Den første kommandoen skiller nåbarhet fra protokoll. Den andre bekrefter hva profilen påstår å være. Rutetabellen viser om tunnelen fanget standardruten. Ringekommandoen rapporterer tilkoblingsbehandlerens egen feil, som ofte er klarere enn dialogen.

Noter tunneltypen, gatewayproduktet og den nøyaktige feilen i saken. Neste person vet da innen et minutt om det er manglende protokollsamsvar, en sertifikatfeil eller en rutebeslutning, i stedet for å begynne med «VPN-en virker ikke».