Wbudowany VPN w Windows nie dociera do bramy SSL dostawcy: dlaczego

Windows ma cztery typy tuneli, a brama SSL dostawcy nie jest żadnym z nich. Skieruj mimo to wbudowany profil na taką bramę, a połączenie zawiedzie przed pytaniem o dane logowania, zwykle z komunikatem, że połączenie zostało zakończone przez system lokalny. Ten tekst jest sygnałem niezgodności, a nie diagnozą. Typ profilu i klient, który posiada protokół, muszą się zgadzać, a jednego z nich brakuje.

Cztery typy i jedno okno

Każdy zapisany profil ma typ tunelu. Wbudowany klient akceptuje PPTP, L2TP, IKEv2 i SSTP, a także tryb automatyczny, który próbuje ich po kolei. Nie ma ogólnego wpisu SSL VPN i nie da się go dodać przez okno dialogowe. Brama dostawcy mówi własnym protokołem aplikacyjnym po TLS, który implementuje tylko klient tego dostawcy.

Lista jest o jedno polecenie stąd i warto ją uruchomić przed każdym innym rozwiązywaniem problemów, bo zajmuje sekundę i usuwa całą klasę błędnych założeń:

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

Jeśli profil mówi SSTP, a brama nie jest serwerem RRAS, niezgodność jest już ustalona. Żadna praca z certyfikatami ani zaporą tego nie zmieni.

SSTP i TLS dostawcy wyglądają tak samo na porcie 443

SSTP opakowuje sesję PPP w TLS i jedzie po TCP 443. W stosie Microsoftu kończy ją RRAS, który przedstawia certyfikat serwera weryfikowany przez klienta. Urządzenie Fortinet, Citrix lub Pulse także kończy TLS na 443, a jego portal otwiera się w każdej przeglądarce bez skarg.

Ten test w przeglądarce dowodzi osiągalności, nie zgodności. Protokół sesji za portalem należy do dostawcy, a wbudowany klient nie ma jego implementacji. To, czy dostawca dostarcza własnego klienta, mówi, z którą połową niezgodności masz do czynienia.

Zdarza się też odwrotna pomyłka. Profil skonfigurowany jako SSTP wobec prawdziwego serwera RRAS może zawieść na walidacji certyfikatu, gdy portal działa, i jest to problem certyfikatu, a nie protokołu.

Błędy, które pojawiają się, zanim powstanie tunel

Kody z serii 800 są zgłaszane przed ustanowieniem jakiegokolwiek tunelu, dlatego reguły zapory rzadko je zmieniają. Błąd 812 to zasada po stronie serwera, która odrzuca metodę uwierzytelniania zaproponowaną przez klienta. Pozostałe z tego zakresu pochodzą od lokalnego menedżera połączeń, a nie z sieci.

Włącz śledzenie, zanim cokolwiek przebudujesz. Śledzenie nazywa etap, który zawodzi, a nazwa etapu jest warta więcej niż tekst w oknie dialogowym:

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

Ślady trafiają do katalogu śledzenia i zostają tam, aż je wyczyścisz, więc potem wyłącz śledzenie, zamiast zostawiać je włączone na tygodnie.

Podłączony profil i tak może zepsuć wszystko

Profil, który się łączy, a potem psuje przeglądanie, udział lokalny lub silnik kontenerów, ma problem z routowaniem, a nie z tunelem. Brama domyślna przeniosła się do tunelu, więc każdy cel przechodzi teraz przez peera, który może go nie routować.

Decydują o tym dwa ustawienia. Jedno to właściwość split tunneling w profilu. Drugie to opcja dla każdego adaptera, by używać bramy domyślnej w sieci zdalnej, która jest w zaawansowanych ustawieniach IPv4.

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

Włączenie split tunneling bez dodania tras daje tunel, który się łączy i nic nie osiąga. Wyłączenie go bez sprawdzenia DNS daje nazwy wewnętrzne rozwiązywane na publiczne odpowiedzi, bo sufiks i serwery adaptera nie są używane.

Sprawdź instalację, potem typ

Pracuj w tej kolejności i zatrzymaj się, gdy krok zawiedzie, zamiast dostrajać wszystko naraz:

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

Pierwsze polecenie oddziela osiągalność od protokołu. Drugie potwierdza, czym profil twierdzi, że jest. Tabela tras pokazuje, czy tunel przejął trasę domyślną. Polecenie połączenia zgłasza własny błąd menedżera połączeń, który często jest jaśniejszy niż okno dialogowe.

Zapisz w zgłoszeniu typ tunelu, produkt bramy i dokładny błąd. Następna osoba wie wtedy w minutę, czy to niezgodność protokołu, awaria certyfikatu czy decyzja routingu, zamiast zaczynać od „VPN nie działa”.