Windows’ indbyggede VPN kan ikke nå en leverandørs SSL-gateway: hvorfor

Windows leveres med fire tunneltyper, og en leverandørgateway er ikke en af dem. Retter du alligevel en indbygget profil mod en, fejler forbindelsen før loginprompten, som regel med en meddelelse om, at forbindelsen blev afsluttet af det lokale system. Den tekst er et mismatchsignal, ikke en diagnose. Profiltypen og den klient, der ejer protokollen, skal passe sammen, og en af dem mangler.

Fire typer og én dialog

Hver gemt profil bærer en tunneltype. Den indbyggede klient accepterer PPTP, L2TP, IKEv2 og SSTP, plus en automatisk tilstand, der prøver dem i rækkefølge. Der findes ingen generisk SSL VPN-post, og der er ingen måde at tilføje en via dialogen. En leverandørgateway taler sin egen applikationsprotokol over TLS, som kun den leverandørs klient implementerer.

Listen er én kommando væk, og den er værd at køre før anden fejlfinding, fordi den tager et sekund og fjerner en hel klasse af forkerte antagelser:

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

Hvis profilen siger SSTP, og gatewayen ikke er en RRAS-server, er mismatchet allerede fastslået. Intet certifikat- eller firewallarbejde ændrer det.

SSTP og leverandør-TLS ligner hinanden på port 443

SSTP pakker en PPP-session ind i TLS og kører på TCP 443. I Microsoft-stakken afsluttes den af RRAS, som fremviser et servercertifikat, klienten validerer. Et Fortinet-, Citrix- eller Pulse-apparat afslutter også TLS på 443, og dets portal åbner i enhver browser uden klager.

Den browsertest beviser nåbarhed, ikke kompatibilitet. Sessionsprotokollen bag portalen tilhører leverandøren, og den indbyggede klient har ingen implementering af den. Hvorvidt leverandøren leverer sin egen klient, fortæller dig, hvilken halvdel af mismatchet du har med at gøre.

Den omvendte forveksling sker også. En profil konfigureret som SSTP mod en ægte RRAS-server kan fejle på certifikatvalidering, mens portalen er fin, og det er et certifikatproblem og ikke et protokolproblem.

Fejl der vises, før en tunnel findes

800-seriekoderne rapporteres, før nogen tunnel er etableret, og derfor flytter firewallregler dem sjældent. Fejl 812 er en serverpolitik, der afviser den godkendelsesmetode, klienten tilbød. Andre i området kommer fra den lokale forbindelsesmanager og ikke fra netværket.

Slå sporing til, før du genopbygger noget. Sporingen navngiver det fejlende trin, og et trinnavn er mere værd end dialogteksten:

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

Sporinger lander under sporingsmappen og bliver der, til du rydder dem, så slå sporing fra bagefter i stedet for at lade den køre i ugevis.

En tilsluttet profil kan stadig ødelægge alt

En profil, der forbinder og derefter ødelægger browsing, en lokal deling eller en containermotor, har et ruteproblem, ikke et tunnelproblem. Standardgatewayen flyttede til tunnelen, så hver destination går nu gennem en peer, der måske ikke router den.

To kontroller afgør dette. Den ene er split-tunneling-egenskaben på profilen. Den anden er indstillingen for hver adapter til at bruge standardgatewayen på fjernnetværket, som ligger under de avancerede IPv4-indstillinger.

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

At slå split tunneling til uden at tilføje ruter giver en tunnel, der forbinder og intet når. At slå det fra uden at tjekke DNS giver interne navne, der opløses til offentlige svar, fordi adapterens eget suffiks og servere ikke bruges.

Kontroller rørføringen, derefter typen

Arbejd i denne rækkefølge, og stop, når et trin fejler, i stedet for at justere alt på én 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 kommando adskiller nåbarhed fra protokol. Den anden bekræfter, hvad profilen påstår at være. Rutetabellen viser, om tunnelen har fanget standardruten. Opkaldskommandoen rapporterer forbindelsesmanagerens egen fejl, som ofte er klarere end dialogen.

Notér tunneltypen, gatewayproduktet og den præcise fejl i sagen. Den næste person ved så inden for et minut, om det er et protokolmismatch, en certifikatfejl eller en rutebeslutning, i stedet for at begynde med “VPN virker ikke”.