SSTP autentiserar först servern och sedan användaren

En SSTP-klient kan slutföra TLS och ändå avvisa användaren en sekund senare. Den ordningen är inte en bugg, det är protokollstacken: transportsäkerhet först, användarautentisering efteråt. Eftersom de två stegen misslyckas med olika meddelanden behöver de också olika åtgärder. Att läsa vilket steg som producerade felet är det mesta av diagnosen.

Ett betrott certifikat bevisar slutpunkten; det säger ingenting om kontot.

Vad TLS-handskakningen fastställer

Klienten validerar certifikatet som servern presenterar mot sitt betroddhetslager, det begärda värdnamnet, giltighetsfönstret och eventuell ytterligare policy som plattformen tillämpar. Det skyddar anslutningen till den avsedda slutpunkten. Det bevisar inte att ett visst konto är aktiverat, inte har gått ut eller är tillåtet för fjärråtkomst. Det är separata frågor som ställs senare av en annan komponent.

Därför är det fel åtgärd att ta bort certifikatkontroller för att nå inloggningsprompten. Du får en inloggningsprompt på en anslutning du inte kan verifiera. Ett certifikatfel hör till värdnamnet, klockan, kedjan eller förtroendekonfigurationen.

Vad SSTP och PPP lägger till ovanpå

SSTP körs över HTTPS och bär PPP inuti, med sitt eget kontrollutbyte runt anslutningen. PPP kör sedan sina länk- och autentiseringsfaser, och autentiseringsmetoden beror på serverns policy och klientens förmåga. PAP, CHAP, MS-CHAPv2 och EAP är alla PPP-autentiseringsalternativ med mycket olika egenskaper. VPN:ets användarkontroll är den PPP-fasen, inte TLS-lagret under den.

Ett användaravslag kan därför betyda autentiseringsuppgifter, en kontobegränsning eller en metodmissmatchning.

Orsaken på serversidan är mycket mer användbar än att återställa varje hemlighet i profilen. En händelse med inaktiverat konto och ett misslyckat metodförhandlande ser likadana ut på klienten och har ingenting gemensamt på servern.

Koppla felet till steget

Kontrollera om anslutningen når TLS, sedan SSTP HTTP-utbytet, sedan PPP-fasen. Håll loggtidsstämplar justerade mellan försök så att ett tidigare fel inte förväxlas med en senare framgång. En klient som loggar två försök i ett fönster kommer annars att se ut som att den misslyckades i det sista steget den nådde. Läs det första relevanta felet, inte den sista raden.

Samma justering är viktig på serversidan, där autentiseringsposten och transportloggen ofta är separata filer med separata klockor. Två minuters snedvridning räcker för att få en uppenbar orsak att verka omöjlig.

Efter inloggning är auktoriseringen fortfarande separat

En lyckad inloggning ger inte varje privat resurs. Rutter avgör vad som är nåbart, DNS avgör vad som löses upp, och varje tjänst tillämpar fortfarande sina egna behörigheter. En session som visas som ansluten är ett påstående om tunneln, inte om fildelningen. När en användare kan ansluta och inte når en värd är tunnefasen redan avslutad.

Det är samma skiktning som handskakningen visade, en nivå högre.

Håll kontåterställning inom operatörens stödda process i stället för att ändra transportinställningar som svar på en uttrycklig användaravvisning. Att ändra transporten för att reparera ett inaktiverat konto är den typ av reparation som verkar fungera när kontot återaktiveras av en orelaterad anledning.