Port w polu adresu VPN systemu Windows działa tylko z SSTP

Serwer VPN odpowiada na porcie TCP 10443, wbudowany klient Windows ma prawidłowe poświadczenia, a połączenie mimo to pada po pauzie, która wygląda jak limit czasu DNS. Przyczyną jest zwykle pole adresu: wpisanie vpn.example.com:10443 w polu Nazwa serwera lub adres powoduje, że Windows czyta cały ciąg jako nazwę hosta, ponieważ to pole nie jest ogólnym wejściem host:port. To, czy port można tam w ogóle wyrazić, zależy od typu tunelu używanego przez profil, i tylko jeden z czterech typów traktuje wartość jako coś, co potrafi przeanalizować.

Dlaczego pole adresu nie jest polem host:port

Właściwością profilu stojącą za tym polem jest ServerAddress, a każdy typ tunelu decyduje, co robi z tym ciągiem. Trzy z nich nie mają parametru portu do wypełnienia, więc dwukropek i liczba są po prostu znakami w nazwie, która nigdy się nie rozwiąże. Czwarty działa przez HTTPS, gdzie port jest częścią adresu URL, więc wartość trzeba zapisać w formie, która zostanie przeanalizowana jako adres URL.

Dlatego awaria wygląda na rozwiązywanie nazw, a nie na odrzucone połączenie. Nie ma złego portu do zgłoszenia, jest tylko nieistniejąca nazwa hosta, a błąd pojawia się po tym, jak resolver się podda. Zanim dotkniesz serwera, sprawdź, jaki typ tunelu deklaruje profil.

Trzy typy ze stałym portem

PPTP łączy się z TCP 1723, a następnie przenosi tunel w GRE, protokole IP 47. L2TP/IPsec używa UDP 1701 dla tunelu oraz UDP 500 i 4500 dla IPsec, przy czym 4500 to port przechodzenia przez NAT. IKEv2 również używa UDP 500 i 4500. Żaden z tych profili nie udostępnia pola portu nigdzie w interfejsie i żaden nie wynegocjuje niestandardowego portu.

Serwer nasłuchujący na niestandardowym porcie jest więc nieosiągalny dla tych profili, niezależnie od tego, jak zapisano adres. Praktyczne odpowiedzi są wąskie: opublikuj standardowy port na serwerze albo przetłumacz standardowy port na niestandardowy na routerze przed nim. Oba rozwiązania pozostawiają profil klienta nietknięty, co wiele znaczy, gdy profil jest wdrażany przez zasady, a nie wpisywany ręcznie.

SSTP wymaga adresu URL, nie nazwy

SSTP jest wyjątkiem, bo działa wewnątrz sesji TLS. Pole musi zostać przeanalizowane jako adres URL: najpierw schemat https://, potem host, potem dwukropek i port. Bez schematu Windows nadal traktuje wartość jak zwykłą nazwę i połączenie nie udaje się przed jakąkolwiek wymianą TLS.

Powód, dla którego to zaskakuje, jest taki, że domyślny port przyjmuje gołą nazwę hosta. Profil, który nigdy nie potrzebował niestandardowego portu, nigdy nie uczy tej reguły, a pierwsza osoba, która go dodaje, odkrywa ją przez porażkę. Po zapisaniu odczytaj zapisaną wartość zamiast ufać oknu dialogowemu:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress pokazuje dokładnie to, co zostało zapisane. Jeśli czyta się jako goła nazwa hosta z dwukropkiem, profil nigdy nie otrzymał adresu URL i żadna liczba ponownych prób tego nie naprawi.

Składnia producenta wklejana w to samo pole

Niektóre bramy dokumentują dodatkowe konwencje dla tego pola, takie jak realm dołączony po porcie albo parametry zapytania zmieniające obsługę certyfikatów. Są one rozumiane przez serwer tego producenta i, w niektórych kompilacjach, przez jego własnego klienta. Nie są częścią formatu profilu Windows, a wklejenie ich do wbudowanego profilu zwykle daje ten sam cichy błąd nazwy.

Parametr wyłączający walidację certyfikatów traktuj jako ostrzeżenie, a nie jako poprawkę. Jeśli profil łączy się tylko z tym parametrem, certyfikat nie pasuje do używanej nazwy, a właściwa naprawa jest po stronie bramy, nie klienta. Realm po porcie ma tę samą właściwość: robi coś tylko wtedy, gdy serwer po drugiej stronie go oczekuje.

Udowodnij port, a potem odczytaj etap, który zawodzi

Zanim obwinisz profil, potwierdź, że coś przyjmuje TCP na tym porcie z sieci klienta:

Test-NetConnection vpn.example.com -Port 10443

Sukces dowodzi nasłuchu, nie SSTP. Serwer WWW, odwrotne proxy lub balanser obciążenia mogą zakończyć uzgadnianie TCP i nadal nie mówić po SSTP, więc zielony test przy czerwonym VPN to realna kombinacja. Porównaj podmiot certyfikatu z nazwą w profilu i sprawdź dziennik RasClient w kompilacjach, które go dostarczają, ponieważ zapisuje on etap, który zawiódł, zamiast ogólnego limitu czasu.

Następnie rozważ opcję, która usuwa problem, zamiast go dokumentować: przekieruj TCP 443 z zewnątrz na 10443 na serwerze VPN. Klient używa wtedy profilu domyślnego bez żadnego portu, co zwykle jest najczystszym rozwiązaniem dla zarządzanej floty i pozostawia niestandardowy port jako szczegół wewnętrzny.