SSTP aŭtentigas unue la servilon kaj poste la uzanton
SSTP validigas unue la servilan atestilon kaj aŭtentigas la uzanton poste, per PPP. Adaptu la eraron al la koncerna etapo anstataŭ tuŝi ambaŭ samtempe.
SSTP kliento povas fini TLS kaj tamen rifuzi la uzanton unu sekundon poste. Tiu sinsekvo ne estas cimo, ĝi estas la protokola stako: unue transporta sekureco, poste uzanta aŭtentigo. Ĉar la du etapoj malsukcesas per malsamaj mesaĝoj, ili ankaŭ bezonas malsamajn riparojn. Legi, kiu etapo produktis la eraron, estas la plej granda parto de la diagnozo.
Fidinda atestilo pruvas la finpunkton; pri la konto ĝi diras nenion.
Kion la TLS-manpremo establas
La kliento validigas la atestilon prezentitan de la servilo kontraŭ sia fida konservejo, la petita gastiga nomo, la valideca fenestro kaj ajna plia politiko, kiun la platformo aplikas. Tio protektas la konekton al la celita finpunkto. Ĝi ne pruvas, ke aparta konto estas ebligita, neekspirinta aŭ permesita uzi malproksiman aliron. Tiuj estas apartaj demandoj, kiujn poste starigas alia komponanto.
Tial forigi atestilajn kontrolojn por atingi la ensalutan inviton estas la malĝusta riparo. Vi ricevas ensalutan inviton sur konekto, kiun vi ne povas kontroli. Atestila eraro apartenas al la gastiga nomo, la horloĝo, la ĉeno aŭ la fida agordo.
Kion SSTP kaj PPP aldonas supre
SSTP funkcias super HTTPS kaj portas PPP interne, kun propra kontrola interŝanĝo ĉirkaŭ la konekto. PPP tiam plenumas siajn ligajn kaj aŭtentigajn fazojn, kaj la aŭtentiga metodo dependas de la servila politiko kaj la klientaj kapabloj. PAP, CHAP, MS-CHAPv2 kaj EAP ĉiuj estas PPP-aŭtentigaj ebloj kun tre malsamaj ecoj. La uzanta kontrolo de la VPN estas tiu PPP-fazo, ne la TLS-tavolo sub ĝi.
Uzanta rifuzo do povas signifi akreditaĵojn, kontan limigon aŭ metodan malkongruon.
La kialo ĉe la servila flanko estas multe pli utila ol restarigi ĉiun sekreton en la profilo. Okazaĵo de malŝaltita konto kaj malsukceso de metoda intertraktado aspektas simile ĉe la kliento kaj havas nenion komunan ĉe la servilo.
Adaptu la eraron al la etapo
Kontrolu, ĉu la konekto atingas TLS, poste la SSTP HTTP-interŝanĝon, poste la PPP-fazon. Tenu la protokolajn tempomarkojn vicigitaj inter provoj, por ke pli frua malsukceso ne konfuziĝu kun pli posta sukceso. Kliento, kiu registras du provojn en unu fenestro, alie aspektos kvazaŭ ĝi malsukcesis ĉe la lasta atingo. Legu la unuan gravan eraron, ne la lastan linion.
La sama vicigo gravas ĉe la servila flanko, kie la aŭtentiga rikordo kaj la transporta protokolo ofte estas apartaj dosieroj kun apartaj horloĝoj. Du minutoj da dekliniĝo sufiĉas por igi evidentan kaŭzon aspekti neebla.
Post ensaluto, rajtigo restas aparta
Sukcesa ensaluto ne donas ĉiun privatan rimedon. Itineroj determinas kio estas atingebla, DNS determinas kio solviĝas, kaj ĉiu servo ankoraŭ aplikas siajn proprajn permesojn. Seanco montranta konektitan estas aserto pri la tunelo, ne pri la dosiera kunhavigo. Kiam uzanto povas konektiĝi kaj ne povas atingi unu gastiganton, la tunela fazo jam finiĝis.
Tio estas la sama tavoligo, kiun montris la manpremo, unu nivelon pli alte.
Tenu kontan reakiron ene de la subtenata procedo de la operatoro anstataŭ ŝanĝi transportajn agordojn kiel respondon al eksplicita uzanta rifuzo. Ŝanĝi la transporton por ripari malŝaltitan konton estas la speco de riparo, kiu ŝajnas funkcii kiam la konto estas reebligita pro senrilata kialo.