SSTP nejprve ověřuje server a teprve potom uživatele

Klient SSTP může dokončit TLS a přesto uživatele o sekundu později odmítnout. Tato posloupnost není chyba, je to protokolový stack: nejprve zabezpečení přenosu, potom autentizace uživatele. Protože obě fáze selhávají s různými zprávami, potřebují i různé opravy. Přečtení toho, která fáze chybu způsobila, je většinou diagnostiky.

Důvěryhodný certifikát prokazuje koncový bod; o účtu neříká nic.

Co TLS handshake zajišťuje

Klient ověřuje serverem předložený certifikát proti svému úložišti důvěry, požadovanému názvu hostitele, oknu platnosti a jakékoli další politice, kterou platforma uplatňuje. Tím chrání spojení s zamýšleným koncovým bodem. Neprokazuje však, že konkrétní účet je povolený, nevypršelý nebo má oprávnění pro vzdálený přístup. To jsou samostatné otázky, které později klade jiná komponenta.

Právě proto je odstranění kontrol certifikátu, abyste se dostali k přihlašovací výzvě, špatná oprava. Získáte přihlašovací výzvu na spojení, které nemůžete ověřit. Chyba certifikátu patří k názvu hostitele, hodinám, řetězu nebo konfiguraci důvěry.

Co SSTP a PPP přidávají navrch

SSTP běží přes HTTPS a nese v sobě PPP, s vlastní řídicí výměnou kolem spojení. PPP pak provádí své fáze spojení a autentizace a metoda autentizace závisí na politice serveru a možnostech klienta. PAP, CHAP, MS-CHAPv2 a EAP jsou všechny možnosti autentizace PPP s velmi odlišnými vlastnostmi. Uživatelská kontrola VPN je právě tato fáze PPP, nikoli vrstva TLS pod ní.

Odmítnutí uživatele tedy může znamenat přihlašovací údaje, omezení účtu nebo neshodu metody.

Důvod na straně serveru je mnohem užitečnější než resetování každého tajemství v profilu. Událost vypnutí účtu a selhání vyjednání metody vypadají u klienta podobně a na serveru nemají nic společného.

Přiřaďte chybu k fázi

Zkontrolujte, zda se spojení dostane k TLS, potom k výměně SSTP přes HTTP a potom k fázi PPP. Udržujte časová razítka v protokolech zarovnaná mezi pokusy, aby se dřívější selhání nepletlo s pozdějším úspěchem. Klient, který v jednom okně zaznamená dva pokusy, bude jinak vypadat, jako by selhal v poslední fázi, které dosáhl. Čtěte první relevantní chybu, ne poslední řádek.

Stejné zarovnání je důležité na straně serveru, kde jsou záznam o autentizaci a transportní protokol často oddělené soubory s oddělenými hodinami. Dvě minuty rozchodu stačí k tomu, aby zjevná příčina vypadala nemožně.

Po přihlášení je autorizace stále oddělená

Úspěšné přihlášení neuděluje přístup ke každému soukromému zdroji. Trasy určují, co je dosažitelné, DNS určuje, co se překládá, a každá služba stále uplatňuje vlastní oprávnění. Relace zobrazená jako připojená je tvrzení o tunelu, ne o sdílení souborů. Když se uživatel může připojit a nemůže dosáhnout jednoho hostitele, fáze tunelu už skončila.

Je to stejné vrstvení, které ukázal handshake, o úroveň výš.

Nechte obnovu účtu na procesu podporovaném operátorem, místo abyste měnili nastavení přenosu v reakci na výslovné odmítnutí uživatele. Změna přenosu, aby se opravil vypnutý účet, je druh opravy, která vypadá, že funguje, když je účet znovu povolen z nesouvisejícího důvodu.