SSTP vispirms autentificē serveri un tikai pēc tam lietotāju
SSTP vispirms validē servera sertifikātu un lietotāju autentificē vēlāk, caur PPP. Saskaņojiet kļūdu ar attiecīgo posmu, nevis aiztieciet abus uzreiz.
SSTP klients var pabeigt TLS un tomēr pēc sekundes noraidīt lietotāju. Šī secība nav kļūda, tā ir protokolu steks: vispirms transporta drošība, pēc tam lietotāja autentifikācija. Tā kā abi posmi neizdodas ar atšķirīgiem ziņojumiem, tiem vajadzīgi arī atšķirīgi labojumi. Izlasīt, kurš posms radīja kļūdu, ir lielākā diagnostikas daļa.
Uzticams sertifikāts pierāda galapunktu; par kontu tas neko nepasaka.
Ko nosaka TLS rokasspiediens
Klients validē servera uzrādīto sertifikātu pret savu uzticības krātuvi, pieprasīto resursdatora nosaukumu, derīguma logu un jebkuru papildu politiku, ko piemēro platforma. Tas aizsargā savienojumu ar paredzēto galapunktu. Bet nepierāda, ka konkrēts konts ir iespējots, nav beidzies vai ir atļauts attālinātai piekļuvei. Tie ir atsevišķi jautājumi, ko vēlāk uzdod cita komponente.
Tāpēc sertifikātu pārbaužu noņemšana, lai nonāktu pie pieteikšanās uzvednes, ir nepareizais labojums. Jūs saņemat pieteikšanās uzvedni savienojumā, kuru nevarat pārbaudīt. Sertifikāta kļūda pieder resursdatora nosaukumam, pulkstenim, ķēdei vai uzticības konfigurācijai.
Ko pievieno SSTP un PPP
SSTP darbojas virs HTTPS un iekšienē pārvadā PPP, ar savu vadības apmaiņu ap savienojumu. Pēc tam PPP izpilda savas saites un autentifikācijas fāzes, un autentifikācijas metode ir atkarīga no servera politikas un klienta iespējām. PAP, CHAP, MS-CHAPv2 un EAP visas ir PPP autentifikācijas opcijas ar ļoti atšķirīgām īpašībām. VPN lietotāja pārbaude ir šī PPP fāze, nevis TLS slānis zem tās.
Tāpēc lietotāja noraidījums var nozīmēt akreditācijas datus, konta ierobežojumu vai metodes neatbilstību.
Iemesls servera pusē ir daudz noderīgāks nekā katra profila noslēpuma atiestatīšana. Konta atspējošanas notikums un metodes sarunu neveiksme klientā izskatās līdzīgi, bet serverī tām nav nekā kopīga.
Saskaņojiet kļūdu ar posmu
Pārbaudiet, vai savienojums sasniedz TLS, pēc tam SSTP HTTP apmaiņu, pēc tam PPP posmu. Turiet žurnālu laikspiedolus saskaņotus starp mēģinājumiem, lai agrāka neveiksme netiktu sajaukta ar vēlāku panākumu. Klients, kas vienā logā reģistrē divus mēģinājumus, citādi izskatīsies tā, it kā būtu neizdevies pēdējā sasniegtajā posmā. Lasiet pirmo būtisko kļūdu, nevis pēdējo rindu.
Tāda pati saskaņošana ir svarīga servera pusē, kur autentifikācijas ieraksts un transporta žurnāls bieži ir atsevišķi faili ar atsevišķiem pulksteņiem. Divas minūtes novirzes pietiek, lai acīmredzamu iemeslu padarītu šķietami neiespējamu.
Pēc pieteikšanās autorizācija joprojām ir atsevišķa
Veiksmīga pieteikšanās nepiešķir katru privāto resursu. Maršruti nosaka, kas ir sasniedzams, DNS nosaka, kas tiek atrisināts, un katrs pakalpojums joprojām piemēro savas atļaujas. Sesija, kas parādīta kā savienota, ir apgalvojums par tuneli, nevis par failu koplietošanu. Kad lietotājs var savienoties un nevar sasniegt vienu resursdatoru, tuneļa posms jau ir beidzies.
Tas ir tas pats slāņojums, ko parādīja rokasspiediens, vienu līmeni augstāk.
Turiet konta atjaunošanu operatora atbalstītajā procesā, nevis mainiet transporta iestatījumus reaģējot uz skaidru lietotāja noraidījumu. Transporta maiņa, lai salabotu atspējotu kontu, ir tāda veida labojums, kas šķietami darbojas, kad konts tiek atkal iespējots nesaistīta iemesla dēļ.