Az SSTP előbb a szervert hitelesíti, és csak utána a felhasználót

Egy SSTP kliens befejezheti a TLS-t, és mégis elutasíthatja a felhasználót egy másodperccel később. Ez a sorrend nem hiba, hanem a protokollverem: először az átvitel biztonsága, utána a felhasználó hitelesítése. Mivel a két szakasz különböző üzenetekkel hiúsul meg, különböző javításokat is igényelnek. Annak olvasása, melyik szakasz termelte a hibát, a diagnózis nagy része.

A megbízható tanúsítvány igazolja a végpontot; a fiókról semmit sem mond.

Mit állapít meg a TLS kézfogás

A kliens a szerver által bemutatott tanúsítványt a saját megbízhatósági tárolójához, a kért gazdagépnévhez, az érvényességi ablakhoz és a platform által alkalmazott további szabályzathoz méri. Ez védi a kapcsolatot a szándékolt végponthoz. Nem bizonyítja, hogy egy adott fiók engedélyezett, nem járt le, vagy jogosult a távoli hozzáférésre. Ezek külön kérdések, amelyeket később egy másik összetevő tesz fel.

Ezért a tanúsítvány-ellenőrzések eltávolítása a bejelentkezési kérés eléréséhez a rossz javítás. Olyan kapcsolaton kap bejelentkezési kérést, amelyet nem tud ellenőrizni. Egy tanúsítványhiba a gazdagépnévhez, az órához, a lánchoz vagy a megbízhatósági konfigurációhoz tartozik.

Mit ad hozzá az SSTP és a PPP

Az SSTP HTTPS felett fut, és PPP-t hordoz magában, saját vezérlőcserével a kapcsolat körül. A PPP ezután lefuttatja a kapcsolat- és hitelesítési szakaszait, a hitelesítési módszer pedig a szerver szabályzatától és a kliens képességeitől függ. A PAP, a CHAP, az MS-CHAPv2 és az EAP mind olyan PPP-hitelesítési lehetőségek, amelyek tulajdonságai nagyon eltérőek. A VPN felhasználó-ellenőrzése ez a PPP-szakasz, nem az alatta lévő TLS-réteg.

A felhasználó elutasítása tehát jelenthet hitelesítő adatokat, fiókkorlátozást vagy módszer-eltérést.

A szerveroldali indok sokkal hasznosabb, mint a profil minden titkának visszaállítása. A letiltott fiók eseménye és a módszertárgyalás kudarca a kliensen hasonlónak tűnik, a szerveren pedig semmi közös nincs bennük.

Rendelje a hibát a szakaszhoz

Ellenőrizze, hogy a kapcsolat eléri-e a TLS-t, majd az SSTP HTTP-cserét, majd a PPP-szakaszt. Tartsa a naplók időbélyegeit összehangolva az újrapróbálkozások között, hogy egy korábbi kudarc ne keveredjen egy későbbi sikerrel. Az a kliens, amely egy ablakban két kísérletet naplóz, máskülönben úgy tűnik, mintha az utolsó elért szakaszban hiúsult volna meg. Az első releváns hibát olvassa, ne az utolsó sort.

Ugyanez az összehangolás számít a szerveroldalon, ahol a hitelesítési rekord és az átviteli napló gyakran külön fájlok, külön órákkal. Két perc eltérés elég ahhoz, hogy egy nyilvánvaló ok lehetetlennek tűnjön.

Bejelentkezés után az engedélyezés továbbra is külön

A sikeres bejelentkezés nem ad hozzáférést minden privát erőforráshoz. Az útvonalak határozzák meg, mi érhető el, a DNS határozza meg, mi oldódik fel, és minden szolgáltatás továbbra is a saját engedélyeit alkalmazza. A csatlakozottként megjelenő munkamenet az alagútra vonatkozó állítás, nem a fájlmegosztásra. Amikor egy felhasználó tud csatlakozni, de egy gazdagépet nem ér el, az alagút szakasza már befejeződött.

Ez ugyanaz a rétegzés, amelyet a kézfogás mutatott, egy szinttel feljebb.

Tartsa a fiók-helyreállítást az üzemeltető által támogatott folyamatban, ahelyett hogy az átviteli beállításokat egy kifejezett felhasználói elutasításra válaszul módosítaná. Az átvitel módosítása egy letiltott fiók javítására olyan javítás, amely látszólag működik, amikor a fiókot egy független okból újra engedélyezik.