Ako overiť, či VPN klient naozaj podporuje SSTP

Nazvať produkt VPN klientom nič nehovorí o tom, či rozpráva SSTP, a port 443 v adrese dokazuje ešte menej. SSTP spúšťa TLS cez TCP 443, potom riadiacu výmenu SSTP, potom PPP pre samotné spojenie, a navrchu validáciu certifikátu a metódu autentizácie PPP. Klient podporuje protokol len vtedy, keď uvedená implementácia v nainštalovanej verzii dokončí každú z týchto vrstiev podľa požiadaviek vášho servera. Vykonajte nižšie uvedené kontroly poporiadku a zastavte sa pri prvej, ktorá zlyhá, pretože práve tú má zmysel riešiť.

Zlaďte implementáciu, verziu a platformu

Začnite platformou, aplikáciou a nainštalovaným buildom, pretože jedno meno výrobcu môže stáť nad dvoma úplne odlišnými implementáciami. Vstavané typy VPN a klienti tretích strán nie sú to isté a doplnok môže zobrazovať názov adaptéra, ktorý neopisuje protokol pod ním. Dokumentácia k aktuálnemu vydaniu neopisuje build, ktorý beží na počítači pred vami. Prečítajte si stránku pre konkrétnu verziu a porovnajte ju s tým, čo o sebe klient uvádza.

Vo Windows typ tunela pochádza z platformy, nie z grafického rozhrania, preto sa pýtajte platformy. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress vypíše Sstp, keď sa natívny klient pokúsi o protokol, a prehľad typov pripojenia ho uvádza medzi vstavanými typmi tunela. V Linuxe natívny klient SSTP vôbec nie je, takže otázka znie, či je nainštalovaná a aktuálna samostatná implementácia, napríklad sstpc z balíka sstp-client.

Najprv formát profilu, potom označenie

Profily nie sú zameniteľné a súbor, ktorý ste dostali, otázku zvyčajne vyrieši rýchlejšie než akýkoľvek zoznam funkcií. Direktívy OpenVPN, kľúče WireGuard a nastavenia pripojenia SSTP opisujú tri nesúvisiace protokoly a žiadny dialóg importu jeden nepremení na druhý. Zdieľaný port TCP 443 nič neprekladá, pretože SSTP, OpenVPN cez TLS aj bežná služba HTTPS môžu obsadiť rovnaký port a nemajú nad ním nič spoločné.

Ak je súbor .ovpn alebo konfigurácia WireGuard, odpoveď je už jasná: od tohto klienta sa nežiada, aby rozprával SSTP. Import do klienta, ktorý vie len SSTP, zlyhá už vo fáze profilu, dávno pred začiatkom akéhokoľvek vyjednávania protokolu.

Čo TLS o nasadení nedokazuje

Dokončený TLS handshake dokazuje, že server má certifikát, a nič nedokazuje o tom, či váš klient dôveruje vydavateľskému reťazcu alebo či v ňom sedí meno. Validácia musí uspieť voči zamýšľanému serveru, vrátane akejkoľvek súkromnej CA, ktorú organizácia prevádzkuje, a klient, ktorý ponúka preskakovanie chýb certifikátu, kontrolu odstránil, namiesto toho aby získal podporu protokolu. Validácia reťazca a zhoda mena sú dva oddelené testy a stack, ktorý prejde jedným, môže zlyhať na druhom. Obe patria do akceptačných kritérií, nie do dodatku o riešení problémov.

Potom potvrďte metódu autentizácie PPP, pretože nasadenie s EAP-TLS potrebuje klienta, ktorý vie v PPP predložiť certifikát, kým metóda založená na hesle potrebuje podporu tejto výmeny. Adresa servera a heslo neopisujú skutočnú požiadavku organizácie, najmä keď pred nimi stojí druhý faktor alebo kontrola zariadenia. Pýtajte sa, ktorú metódu server vyžaduje, skôr než budete predpokladať, že ju klient splní.

Sledujte reláciu v štyroch fázach

Sledujte, ako spojenie prechádza štyrmi hranicami: TCP a TLS k serveru, riadiaca výmena SSTP, vyjednávanie PPP a potom zdroj, ktorý naozaj potrebujete. Log, ktorý sa zastaví po TLS, opisuje inú poruchu než ten, ktorý sa zastaví vnútri PPP, a oba vedú k iným zodpovedným. Načítanie webovej stránky hostiteľa v prehliadači dokazuje len to, že na 443 niečo odpovedalo, čo je najčastejší falošný pozitív v tejto oblasti. Ak sa tá stránka načíta a klient napriek tomu zlyháva, problém je nad TLS a webový server nie je podozrivý.

Skončite skutočným privátnym zdrojom a vyhľadaním mena, pretože relácia, ktorá sa nadviaže a nič neprenáša, vyzerá vo väčšine stavových okien rovnako ako funkčná. Jedna úspešná požiadavka na potrebný zdroj vyrieši otázku, ktorú ikona nedokáže.

Keď podpora chýba, zmeňte plán

Ak klient nevie rozprávať SSTP, zaobstarajte schválenú alternatívu alebo požiadajte vlastníka servera o protokol, ktorý podporujú obe strany. Mazanie nerozpoznaných možností, kým import neprejde, vytvorí profil, ktorý sa nikam nepripojí, čo je pomalšia cesta k tej istej slepej uličke. Inštalátor z neznámeho zdroja, ktorý inzeruje univerzálnu kompatibilitu, pridá do počítača neschválenú cestu dôvery a často nahradí klientsku platformu niečím, čo organizácia nevie aktualizovať. Ani jeden z týchto krokov nie je oprava a oba sa vracajú ťažšie než pôvodný problém.

Otázku kompatibility riešte oddelene od výkonu a voľby koncového bodu, pretože blízky server je nanič, keď klient nevie rozprávať jeho protokol. Ladenie latencie neopraví fázu, ktorá sa nikdy nedokončí.