Skadim kohe SSTP apo gabim certifikate: si t’i dallosh

Një lidhje SSTP dështon në dy mënyra që nga karrigia e përdoruesit duken njësoj, dhe rregullimi i secilës qëndron në një shtresë tjetër. Skadimi i kohës do të thotë që një shkëmbim i nevojshëm nuk përfundoi kurrë; gabimi i certifikatës do të thotë që materiali i identitetit mbërriti dhe u refuzua. Trajtimi i të dytit si i të parit të çon te mure zjarri dhe fjalëkalime që nuk ishin kurrë problemi. Prova që i dallon është në regjistrin e vetë klientit, nëse e lexon para se të ndryshosh gjithçka.

Dy dështime, dy shkëmbime të ndryshme

SSTP mbart një tunel brenda një sesioni në formë HTTPS, prandaj i mbijeton rrjeteve që nuk lejojnë asgjë tjetër përveç 443. Klienti përfundon një shtrëngim duarsh TLS, dërgon një kërkesë HTTP me një metodë specifike të protokollit, dhe më pas tuneli ecën brenda atij fluksi. Një dështim në cilindo prej këtyre hapave ndalon lidhjen, dhe vetëm hapat e mëvonshëm përfshijnë kredencialet.

Ky rend është diagnoza. Nëse shtrëngimi i duarve TLS nuk përfundon kurrë, nuk u dërgua asnjë kredencial, prandaj rivendosja e fjalëkalimit nuk mund të ndihmojë. Nëse shtrëngimi përfundon dhe më pas ngec, identiteti u pranua dhe diçka në rrugën e kërkesës e refuzoi. Nëse shtrëngimi dështon me një mesazh validimi, serveri u përgjigj dhe klientit nuk i pëlqeu ajo që dëgjoi. Tre rezultate, tre shtresa.

Rreshti i regjistrit zakonisht thotë në cilën nga të triat je, prandaj ia vlen ta kapësh para ndryshimit të parë.

Skadimi i kohës do të thotë që një fazë nuk përfundoi kurrë

Fillo me zgjidhjen e emrave dhe arritshmërinë TCP, sepse skadimi i kohës atje duket identik me një skadim më vonë. Një kontrollues portash që raporton 443 të hapur provon vetëm se një dëgjues pranoi një lidhje, dhe asgjë më shumë.

I dyshuari tjetër është rruga dhe jo hosti. Proksitë dhe muret e zjarrit që njohin aplikacionet ndonjëherë refuzojnë metodën e kërkesës që përdor SSTP, ose hedhin poshtë një fluks që mbetet i hapur për orë të tëra, dhe të dyja sjelljet duken si skadim kohe nga ana e klientit. Një faqe HTTPS e zakonshme e shërbyer nga i njëjti host ngarkohet në mënyrë të përsosur ndërsa metoda e tunelit refuzohet, prandaj shfletimi te pika fundore provon kaq pak. Provo nga një rrjet pa proksin për t’i ndarë ato dy raste.

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

Një skadim kohe përpara çdo përgjigjeje të palës tjetër nuk thotë asgjë për llogarinë, dhe ndryshimi i fjalëkalimit në atë moment shton vetëm një variabël.

Gabimi i certifikatës do të thotë që identiteti u refuzua

Këtu serveri u përgjigj vërtet, prandaj rrjeti funksionon dhe pyetja kalon te identiteti. Krahaso emrin me të cilin klienti telefonon me emrat që certifikata vërtet pretendon, pastaj kontrollo datat e vlefshmërisë dhe zinxhirin e lëshuesit.

Një CA private që klienti nuk e beson prodhon të njëjtën klasë gabimi si një certifikatë e skaduar, dhe po ashtu një orë që shkon orë të tëra gabim. Telefonimi i adresës së papërpunuar krijon një mospërputhje të re, sepse certifikata pretendon emra dhe jo adresa. Në një vendosje të administruar, merr konfigurimin e synuar të besimit nga administruesi i saj në vend që të pranosh një rrënjë zëvendësuese që ofron një faqe gabimi. Validimi mbetet i ndezur ndërsa rregullon shkakun.

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

Mbaje fazën e suksesshme TLS të paprekur pasi kalon, sepse kthimi i saj më vonë fsheh se cila ndryshim e rregulloi vërtet tunelin.

Ku ngatërrohen të dyja

Të dyja dështimet shfaqen si një lidhje që nuk ngrihet, dhe të dyja vijnë pasi përdoruesi ka ndryshuar diçka të palidhur. Ky rastësi është ajo që e bën rregullimin e gabuar të duket i besueshëm për një kohë.

Dy zakone i mbajnë të ndara. Kap regjistrin e klientit përpara se të prekësh konfigurimin, që gjendja e parë të ruhet. Ndrysho një shtresë për çdo provë, që rezultati tjetër t’i përkasë një variabli të njohur. Një kontrollues portash dhe një shfletues janë vëzhgime të pjesshme dhe jo sekuenca e plotë, dhe asnjëri nuk zëvendëson raportin e vetë klientit. Asnjë zakon nuk kushton gjë, dhe të dyja e shkurtojnë hetimin.

Çështja e certifikatës dhe çështja e arritshmërisë janë dokumentuar veçmas për një arsye.

Provo përsëri me klientin e vërtetë, pastaj shko nga brenda

Pasi korrigjimi konkret të jetë në vend, provo përsëri me klientin aktual SSTP dhe profilin e vërtetë, jo me një skedë shfletuesi.

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

Nëse sesioni lidhet dhe burimet ende dështojnë, tuneli nuk është më i dyshuari: kalo te rrugëzimi, DNS dhe aksesi i shërbimeve. Ai është një hetim tjetër me prova të tjera. Ruajtja e fazave funksionale TLS dhe të vërtetimit parandalon që ai të bëhet një përsëritje e të parit. Shkruaj në tiketë fazën që dështoi, përndryshe personi tjetër do të nisë përsëri nga fillimi.