SSTP autentiserer først serveren og deretter brukeren

En SSTP-klient kan fullføre TLS og likevel avvise brukeren et sekund senere. Den rekkefølgen er ikke en feil, det er protokollstakken: transportsikkerhet først, brukerautentisering etterpå. Fordi de to trinnene feiler med forskjellige meldinger, trenger de også forskjellige rettelser. Å lese hvilket trinn som produserte feilen er det meste av diagnosen.

Et klarert sertifikat beviser endepunktet; det sier ingenting om kontoen.

Hva TLS-håndtrykket fastslår

Klienten validerer sertifikatet serveren legger fram mot sitt tillitslager, det forespurte vertsnavnet, gyldighetsvinduet og enhver tilleggspolicy plattformen anvender. Det beskytter forbindelsen til det tiltenkte endepunktet. Det beviser ikke at en bestemt konto er aktivert, ikke utløpt eller tillatt for fjernakses. Det er separate spørsmål som stilles senere av en annen komponent.

Derfor er det feil reparasjon å fjerne sertifikatkontroller for å nå påloggingsforespørselen. Du får en påloggingsforespørsel på en forbindelse du ikke kan verifisere. En sertifikatfeil hører til vertsnavnet, klokken, kjeden eller tillitskonfigurasjonen.

Hva SSTP og PPP legger til på toppen

SSTP kjører over HTTPS og bærer PPP inni seg, med sin egen kontrollutveksling rundt forbindelsen. PPP kjører deretter sine lenke- og autentiseringsfaser, og autentiseringsmetoden avhenger av serverpolicy og klientens evne. PAP, CHAP, MS-CHAPv2 og EAP er alle PPP-autentiseringsalternativer med svært forskjellige egenskaper. VPN-ens brukerkontroll er den PPP-fasen, ikke TLS-laget under den.

En brukeravvisning kan derfor bety legitimasjon, en kontobegrensning eller en metodeavvik.

Årsaken på serversiden er langt mer nyttig enn å tilbakestille hver hemmelighet i profilen. En hendelse med deaktivert konto og en mislykket metodeforhandling ser like ut på klienten og har ingenting til felles på serveren.

Knytt feilen til trinnet

Sjekk om forbindelsen når TLS, deretter SSTP HTTP-utvekslingen, deretter PPP-fasen. Hold loggtidsstempler justert på tvers av forsøk slik at en tidligere feil ikke forveksles med en senere suksess. En klient som logger to forsøk i ett vindu vil ellers se ut som om den feilet på det siste trinnet den nådde. Les den første relevante feilen, ikke den siste linjen.

Den samme justeringen er viktig på serversiden, der autentiseringsposten og transportloggen ofte er separate filer med separate klokker. To minutters skjevhet er nok til å få en åpenbar årsak til å se umulig ut.

Etter pålogging er autorisasjon fortsatt separat

En vellykket pålogging gir ikke tilgang til alle private ressurser. Ruter bestemmer hva som er tilgjengelig, DNS bestemmer hva som løses opp, og hver tjeneste anvender fortsatt sine egne tillatelser. En økt som vises som tilkoblet er en uttalelse om tunnelen, ikke om fildelingen. Når en bruker kan koble til og ikke når én vert, er tunnefasen allerede ferdig.

Det er den samme lagdelingen som håndtrykket viste, ett nivå høyere.

Hold kontogjenoppretting innenfor operatørens støttede prosess i stedet for å endre transportinnstillinger som svar på en eksplisitt brukeravvisning. Å endre transporten for å reparere en deaktivert konto er den typen reparasjon som ser ut til å virke når kontoen aktiveres på nytt av en urelatert grunn.