SSTP ajalõpp või sertifikaadiviga: kuidas neid eristada

SSTP ühendus ebaõnnestub kahel viisil, mis kasutaja toolilt vaadates näevad ühesugused välja, ja kummagi parandus asub erineval kihil. Ajalõpp tähendab, et nõutud vahetus ei lõppenud kunagi; sertifikaadiviga tähendab, et identiteedimaterjal saabus ja lükati tagasi. Kui kohtlete teist nagu esimest, satute tulemüüride ja paroolide juurde, mis kunagi probleemiks ei olnud. Eristav tõend on kliendi enda logis, kui te seda enne millegi muutmise lugeda.

Kaks ebaõnnestumist, kaks erinevat vahetust

SSTP kannab tunnelit HTTPS-kujulise sessiooni sees, seepärast jääb see püsima võrkudes, mis ei luba midagi peale 443. Klient lõpetab TLS-kätluse, saadab HTTP-päringu protokollispetsiifilise meetodiga ja seejärel jookseb tunnel selle voo sees. Ebaõnnestumine mõnes neist sammudest peatab ühenduse ja ainult hilisemad hõlmavad volitusi.

See järjekord ongi diagnoos. Kui TLS-kätlus ei lõpe kunagi, ei saadetud ühtegi volitust, seega parooli lähtestamine ei saa aidata. Kui kätlus lõpeb ja siis takerdub, võeti identiteet vastu ja miski päringu teekonnal lükkas selle tagasi. Kui kätlus ebaõnnestub valideerimisteatega, vastas server ja klient ei pidanud kuuldust lugu. Kolm tulemust, kolm kihti.

Logirida nimetab tavaliselt, millises kolmest te olete, seepärast tasub see enne esimest muudatust talletada.

Ajalõpp tähendab, et etapp ei lõppenud kunagi

Alustage nimelahendusest ja TCP kättesaadavusest, sest ajalõpp seal näeb välja täpselt nagu hilisem ajalõpp. Pordikontroll, mis teatab, et 443 on avatud, tõestab ainult seda, et kuulaja võttis ühenduse vastu, ja ei midagi enamat.

Järgmine kahtlusalune on tee, mitte host. Puhverserverid ja rakendustest teadlikud tulemüürid keelduvad mõnikord päringumeetodist, mida SSTP kasutab, või viskavad kõrvale voo, mis jääb tundideks avatuks, ja mõlemad käitumised näevad kliendi poolelt välja nagu ajalõpp. Sama hosti serveeritav tavaline HTTPS-leht laaditakse laitmatult, samal ajal kui tunneli meetod keelatakse, seepärast tõestab lõpp-punkti sirvimine nii vähe. Katsetage võrgust ilma puhverserverita, et neid kahte juhtu eraldada.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Ajalõpp enne partneri mis tahes vastust ei ütle konto kohta midagi ja parooli muutmine sel hetkel lisab ainult ühe muutuja.

Sertifikaadiviga tähendab, et identiteet lükati tagasi

Siin server tõepoolest vastas, seega võrk töötab ja küsimus liigub identiteedi juurde. Võrrelge nime, millega klient helistab, nimedega, mida sertifikaat tegelikult väidab, ja kontrollige seejärel kehtivuskuupäevi ja väljaandmisahelat.

Privaatne CA, mida klient ei usalda, tekitab sama klassi vea nagu aegunud sertifikaat, ja sama teeb kell, mis on tunde vale. Toorele aadressile helistamine loob uue mittevastavuse, sest sertifikaat väidab nimesid, mitte aadresse. Hallatud juurutuses hankige kavandatud usaldusseade selle administraatorilt, selle asemel et võtta vastu vealehel pakutavat asendusjuurt. Valideerimine jääb sisse, kuni te põhjust parandate.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Hoidke õnnestunud TLS-etapp puutumatuna, kui see on läbitud, sest selle hilisem tagasivõtmine varjab, milline muudatus tunneli tegelikult korda tegi.

Kus need kaks segunevad

Mõlemad tõrked ilmnevad ühendusena, mis ei tõuse, ja mõlemad saabuvad pärast seda, kui kasutaja on muutnud midagi kõrvalist. Just see kokkusattumus teeb vale paranduse mõneks ajaks usutavaks.

Kaks harjumust hoiavad neid lahus. Talletage kliendi logi enne seadistuse puutumist, et esimene olek säiliks. Muutke katse kohta ühte kihti, et järgmine tulemus kuuluks teadaoleva muutuja alla. Pordikontroll ja brauser on osalised vaatlused, mitte kogu jada, ja kumbki ei asenda kliendi enda aruannet. Kumbki harjumus ei maksa midagi ja mõlemad lühendavad uurimist.

Sertifikaadiküsimus ja kättesaadavusküsimus on dokumenteeritud eraldi põhjusega.

Testige uuesti päris kliendiga, seejärel liikuge sissepoole

Kui konkreetne parandus on paigas, proovige uuesti tegeliku SSTP kliendi ja õige profiiliga, mitte brauseri vahekaardiga.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Kui sessioon ühendub ja ressursid ikka ei tööta, ei ole tunnel enam kahtlusalune: liikuge marsruutimise, DNS-i ja teenuse juurdepääsu juurde. See on teine uurimine teiste tõenditega. Töötavate TLS-i ja autentimise etappide hoidmine takistab selle kordumist esimesest. Kirjutage piletisse etapp, mis ebaõnnestus, muidu alustab järgmine inimene jälle ülevalt.