SSTP najprv overuje server a až potom používateľa

Klient SSTP môže dokončiť TLS a napriek tomu o sekundu neskôr používateľa odmietnuť. Táto postupnosť nie je chyba, je to protokolový zásobník: najprv bezpečnosť prenosu, potom autentizácia používateľa. Keďže obe fázy zlyhávajú s rôznymi správami, potrebujú aj rôzne opravy. Prečítať, ktorá fáza chybu spôsobila, je väčšina diagnostiky.

Dôveryhodný certifikát dokazuje koncový bod; o účte nehovorí nič.

Čo TLS handshake ustanovuje

Klient overuje certifikát predložený serverom voči svojmu úložisku dôvery, požadovanému názvu hostiteľa, oknu platnosti a akejkoľvek ďalšej politike, ktorú platforma uplatňuje. Tým chráni spojenie s zamýšľaným koncovým bodom. Nepreukazuje však, že konkrétny účet je povolený, nevypršal alebo má oprávnenie na vzdialený prístup. To sú samostatné otázky, ktoré neskôr kladie iná komponenta.

Preto je odstránenie kontrol certifikátu na dosiahnutie prihlasovacej výzvy nesprávna oprava. Získate prihlasovaciu výzvu na spojení, ktoré neviete overiť. Chyba certifikátu patrí k názvu hostiteľa, hodinám, reťazcu alebo konfigurácii dôvery.

Čo SSTP a PPP pridávajú navrch

SSTP beží cez HTTPS a nesie v sebe PPP, s vlastnou riadiacou výmenou okolo spojenia. PPP potom vykonáva svoje fázy spojenia a autentizácie a metóda autentizácie závisí od politiky servera a možností klienta. PAP, CHAP, MS-CHAPv2 a EAP sú všetky možnosti autentizácie PPP s veľmi odlišnými vlastnosťami. Používateľská kontrola VPN je práve táto fáza PPP, nie vrstva TLS pod ňou.

Odmietnutie používateľa teda môže znamenať prihlasovacie údaje, obmedzenie účtu alebo nesúlad metódy.

Dôvod na strane servera je oveľa užitočnejší než resetovanie každého tajomstva v profile. Udalosť vypnutého účtu a zlyhanie vyjednávania metódy vyzerajú na klientovi podobne a na serveri nemajú nič spoločné.

Priraďte chybu k fáze

Skontrolujte, či sa spojenie dostane k TLS, potom k výmene SSTP cez HTTP a potom k fáze PPP. Udržujte časové pečiatky v protokoloch zarovnané medzi pokusmi, aby sa skoršie zlyhanie nezamenilo s neskorším úspechom. Klient, ktorý v jednom okne zaznamená dva pokusy, bude inak vyzerať, akoby zlyhal v poslednej fáze, ktorú dosiahol. Čítajte prvú relevantnú chybu, nie posledný riadok.

Rovnaké zarovnanie je dôležité na strane servera, kde sú záznam o autentizácii a transportný protokol často oddelené súbory s oddelenými hodinami. Dve minúty rozchodu stačia na to, aby zjavná príčina vyzerala nemožne.

Po prihlásení je autorizácia stále oddelená

Úspešné prihlásenie neudeľuje prístup ku každému súkromnému zdroju. Trasy určujú, čo je dosiahnuteľné, DNS určuje, čo sa prekladá, a každá služba stále uplatňuje vlastné oprávnenia. Relácia zobrazená ako pripojená je tvrdenie o tuneli, nie o zdieľaní súborov. Keď sa používateľ môže pripojiť a nemôže dosiahnuť jedného hostiteľa, fáza tunela už skončila.

Je to rovnaké vrstvenie, aké ukázal handshake, o úroveň vyššie.

Nechajte obnovu účtu na procese podporovanom operátorom, namiesto zmeny nastavení prenosu v reakcii na výslovné odmietnutie používateľa. Zmena prenosu na opravu vypnutého účtu je druh opravy, ktorá vyzerá, že funguje, keď je účet znova povolený z nesúvisiaceho dôvodu.