Jak ověřit, zda VPN klient skutečně podporuje SSTP

Nazvat produkt VPN klientem nic neříká o tom, zda mluví SSTP, a port 443 v adrese dokazuje ještě méně. SSTP běží přes TLS nad TCP 443, pak následuje řídicí výměna SSTP, poté PPP pro samotné spojení, a navrch validace certifikátu a metoda autentizace PPP. Klient protokol podporuje jen tehdy, když uvedená implementace v nainstalované verzi zvládne každou z těchto vrstev podle požadavků vašeho serveru. Provedlte níže uvedené kontroly popořadě a zastavte se u první, která selže, protože právě tu má smysl řešit.

Slaďte implementaci, verzi a platformu

Začněte platformou, aplikací a nainstalovaným buildem, protože jedno jméno výrobce může označovat dvě zcela odlišné implementace. Vestavěné typy VPN a klienti třetích stran nejsou totéž a plugin může ukazovat název adaptéru, který popisovaný protokol neodpovídá. Dokumentace k aktuálnímu vydání nepopisuje build, který běží na stroji před vámi. Přečtěte si stránku pro konkrétní verzi a porovnejte ji s tím, co o sobě klient uvádí.

Ve Windows přichází typ tunelu z platformy, nikoli z GUI, takže se ptejte platformy. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress vypíše Sstp, když se nativní klient pokusí protokol použít, a přehled typů připojení jej uvádí mezi vestavěnými typy tunelu. V Linuxu nativní klient SSTP vůbec není, takže otázka zní, zda je nainstalovaná a aktuální samostatná implementace, například sstpc z balíčku sstp-client.

Nejprve formát profilu, potom označení

Profily nejsou zaměnitelné a soubor, který jste dostali, obvykle otázku vyřeší rychleji než jakýkoli seznam funkcí. Direktivy OpenVPN, klíče WireGuard a nastavení připojení SSTP popisují tři nesouvisející protokoly a žádný dialog importu jeden v druhý nepřevádí. Sdílený port TCP 443 nic nepřekládá, protože SSTP, OpenVPN přes TLS i běžná služba HTTPS mohou obsadit stejný port a nemají nad ním nic společného.

Pokud je soubor .ovpn nebo konfigurace WireGuard, odpověď je jasná: tento klient nemá mluvit SSTP. Import do klienta, který umí jen SSTP, selže už ve fázi profilu, dlouho před jakýmkoli vyjednáváním protokolu.

Co TLS o nasazení nedokazuje

Dokončený TLS handshake dokazuje, že server má certifikát, a nic nedokazuje o tom, zda váš klient důvěřuje vydavatelskému řetězu nebo zda odpovídá jméno v něm. Validace musí uspět vůči zamýšlenému serveru, včetně jakékoli soukromé CA, kterou organizace provozuje, a klient, který nabízí přeskakování chyb certifikátu, kontrolu odstranil, místo aby získal podporu protokolu. Validace řetězu a shoda jména jsou dva oddělené testy a stack, který projde jedním, může selhat na druhém. Obojí patří do akceptačních kritérií, ne do dodatku o řešení potíží.

Poté potvrďte metodu autentizace PPP, protože nasazení s EAP-TLS potřebuje klienta, který umí v PPP předložit certifikát, zatímco metoda založená na hesle potřebuje podporu této výměny. Adresa serveru a heslo nepopisují skutečný požadavek organizace, zejména když před ním stojí druhý faktor nebo kontrola zařízení. Zeptejte se, kterou metodu server vyžaduje, než budete předpokládat, že ji klient splní.

Sledujte relaci ve čtyřech fázích

Sledujte, jak spojení prochází čtyřmi hranicemi: TCP a TLS k serveru, řídicí výměna SSTP, vyjednávání PPP a nakonec zdroj, který skutečně potřebujete. Log, který se zastaví po TLS, popisuje jinou závadu než ten, který se zastaví uvnitř PPP, a oba vedou k jinému vlastníkovi. Načtení webové stránky hostitele v prohlížeči dokazuje jen to, že na 443 něco odpovědělo, což je v této oblasti nejčastější falešný pozitiv. Pokud se stránka načte a klient přesto selhává, problém je nad TLS a webový server není podezřelý.

Skončete skutečným privátním zdrojem a vyhledáním jména, protože relace, která se naváže a nic nepřenáší, vypadá ve většině stavových oken stejně jako funkční. Jeden úspěšný požadavek na potřebný zdroj vyřeší otázku, kterou ikona vyřešit nemůže.

Když podpora chybí, změňte plán

Pokud klient neumí SSTP, pořiďte schválenou alternativu nebo požádejte vlastníka serveru o protokol, který podporují obě strany. Mazání nerozpoznaných voleb, dokud import neprojde, vytvoří profil, který se nikam nepřipojí, což je pomalejší cesta ke stejnému slepému konci. Instalátor z neznámého zdroje, který inzeruje univerzální kompatibilitu, přidá do stroje neschválenou cestu důvěry a často nahradí klientskou platformu něčím, co organizace neumí aktualizovat. Ani jeden z těchto kroků není oprava a oba se vrací obtížněji než původní problém.

Otázku kompatibility řešte odděleně od výkonu a volby koncového bodu, protože blízký server je k ničemu, když klient neumí mluvit jeho protokolem. Ladění latence neopraví fázi, která nikdy neskončí.