SSTP denbora-muga edo ziurtagiri-errorea: nola bereizi

SSTP konexioak huts egiten du erabiltzailearen aulkitik berdinak diruditen bi modutan, eta bakoitzaren konponketa geruza desberdinean dago. Denbora-mugak esan nahi du beharrezko trukea ez zela inoiz amaitu; ziurtagiri-erroreak esan nahi du nortasun-materiala heldu eta baztertu egin zela. Bigarrena lehenengotzat hartzen baduzu, inoiz arazoa izan ez diren suebaki eta pasahitzetara bidaltzen zaitugu. Bereizteko froga bezeroaren beraren erregistroan dago, ezer aldatu aurretik irakurtzen baduzu.

Bi hutsegite, bi truke desberdin

SSTPk tunel bat darama HTTPS itxurako saio baten barruan, horregatik bizirik irauten du 443 besterik onartzen ez duten sareetan. Bezeroak TLS esku-ematea osatzen du, protokoloaren berariazko metodoarekin HTTP eskaera bat bidaltzen du, eta gero tunela korronte horren barruan ibiltzen da. Urrats horietako edozeinetan huts egiteak konexioa gelditzen du, eta geroagokoek bakarrik dute zerikusia kredentzialekin.

Ordena hori da diagnostikoa. TLS esku-ematea inoiz osatzen ez bada, ez da kredentzialik bidali, beraz pasahitza berrezartzeak ezin du lagundu. Esku-ematea osatu eta gero trabatzen bada, nortasuna onartu da eta eskaeraren bidean zerbait-ek baztertu du. Esku-emateak egiaztapen-mezu batekin huts egiten badu, zerbitzariak erantzun du eta bezeroari ez zaio gustatu entzun duena. Hiru emaitza, hiru geruza.

Erregistro-lerroak normalean esaten du hiruretako zeinetan zauden, horregatik merezi du lehen aldaketaren aurretik jasotzea.

Denbora-muga batek esan nahi du etapa bat ez zela inoiz amaitu

Hasi izen-ebazpenarekin eta TCP irisgarritasunarekin, hango denbora-muga geroagoko denbora-mugaren berdin-berdina dirudielako. 443 irekita dagoela jakinarazten duen portu-egiaztatzaileak entzule batek konexio bat onartu zuela frogatzen du, eta ez besterik.

Hurrengo susmagarria bidea da, ez ostalaria. Proxy-ek eta aplikazioak ezagutzen dituzten suebakiek batzuetan SSTPk erabiltzen duen eskaera-metodoa baztertzen dute, edo orduetan irekita geratzen den korronte bat botatzen dute, eta bi jokabideek denbora-muga ematen dute bezeroaren aldean. Ostalari berak zerbitzatutako HTTPS orri arruntak primeran kargatzen du tunel-metodoa baztertuta dagoen bitartean, horregatik amaierako puntura nabigatzeak hain gutxi frogatzen du. Probatu proxya ez duen sare batetik bi kasu horiek bereizteko.

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

Parearen edozein erantzunen aurretiko denbora-mugak ez du ezer esaten kontuari buruz, eta une horretan pasahitza aldatzeak aldagai bat besterik ez du gehitzen.

Ziurtagiri-erroreak esan nahi du nortasuna baztertu zela

Hemen zerbitzariak bai erantzun zuen, beraz sareak funtzionatzen du eta galdera nortasunera mugitzen da. Konparatu bezeroak markatzen duen izena ziurtagiriak benetan baieztatzen dituen izenekin, eta gero egiaztatu baliozkotasun-datak eta igorpen-katea.

Bezeroak konfiantza ez duen CA pribatu batek iraungitako ziurtagiriak adinako errore-klasea sortzen du, eta ordu batzuetan oker dabilen erloju batek ere bai. Helbide gordina markatzeak desadostasun berria sortzen du, ziurtagiriak izenak baieztatzen baititu, ez helbideak. Kudeatutako inplementazio batean, lortu asmo den konfiantza-konfigurazioa bere administratzailearengandik, errore-orri batek eskaintzen duen ordezko sustraia onartu beharrean. Egiaztapena piztuta jarraitzen du arrazoia konpontzen duzun bitartean.

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

Mantendu TLS etapa arrakastatsua ukitu gabe behin gaindituta, geroago desegiteak tunela zer aldaketak konpondu zuen ezkutatzen baitu.

Non nahasten diren biak

Bi hutsegiteak altxatzen ez den konexio gisa agertzen dira, eta biak erabiltzaileak zerikusi ez duen zerbait aldatu ondoren iristen dira. Bat-etortze horrek egiten du konponketa okerra denbora batez sinesgarri.

Bi ohiturak bereizten dituzte. Hartu bezeroaren erregistroa konfigurazioa ukitu aurretik, lehen egoera gordetzeko. Aldatu geruza bat saiakera bakoitzeko, hurrengo emaitza aldagai ezagun batena izan dadin. Portu-egiaztatzailea eta nabigatzailea behaketa partzialak dira, ez segida osoa, eta inork ez du ordezkatzen bezeroaren beraren txostena. Ohitura bakoitzak ez du ezer kostatzen, eta biek ikerketa laburtzen dute.

Ziurtagiriaren galdera eta irisgarritasunaren galdera bereiz dokumentatuta daude arrazoi batengatik.

Proba ezazu berriro benetako bezeroarekin, eta gero joan barrurantz

Konponketa zehatza tokian dagoenean, saiatu berriro egiazko SSTP bezeroarekin eta benetako profilekin, ez nabigatzaileko fitxa batekin.

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

Saioa konektatzen bada eta baliabideek huts egiten badute, tunela ez da susmagarria jada: joan bideratzearen, DNSaren eta zerbitzu-sarbidearen aldera. Hori beste ikerketa bat da, beste froga batzuekin. Funtzionatzen duten TLS eta autentifikazio etapak mantentzeak lehenaren errepikapen bihurtzea eragozten du. Idatzi huts egin zuen etapa tiketetan, bestela hurrengo pertsona berriro hasiko da goitik.