SSTP verifieer eers die bediener en daarna die gebruiker

’n SSTP-kliënt kan TLS voltooi en die gebruiker ’n sekonde later steeds verwerp. Daardie volgorde is nie ’n fout nie, dit is die protokolstapel: eers vervoersekuriteit, daarna gebruikerverifikasie. Omdat die twee fases met verskillende boodskappe misluk, het hulle ook verskillende regstellings nodig. Om te lees watter fase die fout veroorsaak het, is die grootste deel van die diagnose.

’n Vertroude sertifikaat bewys die eindpunt; dit sê niks oor die rekening nie.

Wat die TLS-handshake vasstel

Die kliënt valideer die sertifikaat wat die bediener voorhou teen sy vertroude sertifikaatbewaarplek, die versoekte gasheernaam, die geldigheidsvenster en watter bykomende beleid die platform ook al toepas. Dit beskerm die verbinding na die beoogde eindpunt. Dit bewys nie dat ’n bepaalde rekening geaktiveer, onvervalle of gemagtig is om afstandtoegang te gebruik nie. Daardie vrae word later deur ’n ander komponent gevra.

Daarom is dit die verkeerde herstel om sertifikaatkontroles te verwyder om by die aanmeldprompt uit te kom. Jy kry ’n aanmeldprompt op ’n verbinding wat jy nie kan verifieer nie. ’n Sertifikaatfout hoort by die gasheernaam, die klok, die ketting of die vertrouenskonfigurasie.

Wat SSTP en PPP daarbo byvoeg

SSTP loop oor HTTPS en dra PPP binne-in hom, met sy eie beheerde uitruiling rondom die verbinding. PPP voer dan sy skakel- en verifikasiefases uit, en die verifikasiemetode hang af van die bediener se beleid en die kliënt se vermoë. PAP, CHAP, MS-CHAPv2 en EAP is almal PPP-verifikasie-opsies met baie verskillende eienskappe. Die VPN se gebruikerstoets is daardie PPP-fase, nie die TLS-laag daaronder nie.

’n Gebruikerverwerping kan dus geloofsbriewe, ’n rekeningbeperking of ’n metodewanpassing beteken.

Die rede aan die bedienerkant is baie nuttiger as om elke geheim in die profiel te herstel. ’n Gebeurtenis van gedeaktiveerde rekening en ’n mislukte metode-onderhandeling lyk aan die kliëntkant soortgelyk en het niks aan die bedienerkant gemeen nie.

Pas die fout by die fase

Kontroleer of die verbinding TLS bereik, dan die SSTP HTTP-uitruiling, dan die PPP-fase. Hou logtydstempels oor herprobeersels heen in lyn sodat ’n vroeëre mislukking nie met ’n latere sukses verwar word nie. ’n Kliënt wat twee pogings in een venster log, sal anders lyk of dit by die laaste fase wat dit bereik het, misluk het. Lees die eerste relevante fout, nie die laaste reël nie.

Dieselfde inlynstelling maak saak aan die bedienerkant, waar die verifikasierekord en die vervoerlog dikwels aparte lêers met aparte klokke is. Twee minute se skewing is genoeg om ’n ooglopende oorsaak onmoontlik te laat lyk.

Ná aanmelding is magtiging steeds apart

’n Suksesvolle aanmelding verleen nie elke private hulpbron nie. Roetes bepaal wat bereikbaar is, DNS bepaal wat oplos, en elke diens pas steeds sy eie regte toe. ’n Sessie wat as gekoppel wys, is ’n stelling oor die tonnel, nie oor die lêerdeling nie. Wanneer ’n gebruiker kan koppel en nie een gasheer kan bereik nie, is die tonnelfase reeds voltooi.

Dit is dieselfde gelaagdheid wat die handshake gewys het, een vlak hoër.

Hou rekeningherstel by die operateur se ondersteunde proses eerder as om vervoerinstellings te verander in reaksie op ’n eksplisiete gebruikerweiering. Om die vervoer te verander om ’n gedeaktiveerde rekening reg te maak, is die soort herstel wat blyk te werk wanneer die rekening om ’n onverwante rede heractiveer word.