SSTP-k huts egiten du nabigatzailearen HTTPS-ek asmatzen duenean: zergatik
SSTP TLS barruan exekutatzen da 443 portuan, baina ez da web eskaera bat. Probatu TCP, TLS identitatea, SSTP trukea eta PPP autentifikazioa etapa bereizi gisa.
Nabigatzaileak VPN ostalari-izena HTTPS bidez irekitzen du kexarik gabe, eta SSTP bezeroak uko egiten dio konektatzeari. Bikote horretan ez dago ezer kontraesankorrik. SSTP-k TLS kanpoko garraiobide gisa erabiltzen du eta gero bere eskaera eta PPP karga konexio horren barruan exekutatzen ditu, beraz orrialde bat ondo kargatzeak gauza estu bat baino ez du frogatzen: ostalariak GET bati erantzuten dio 443 portuan. Bezeroak beste galdera bat egiten du, eta zerbitzariak gaizki erantzun dezake.
Orrialdea kargatzen da eta tunela ez
Jendeak nabigatzaileko probara jotzen du azkarra delako, eta gero emaitza zerbitzaria irisgarria eta konfiguratuta dagoelako froga gisa hartzen du. Helbide-barrak irekitako biderako GET bati buruzko froga da, besterik ez. VPN elkarrizketa TLS eskuko beraren ondoren hasten da, baina bidaltzen du web orrialde batek inoiz erabiltzen ez duen metodo eta bide bat. Beraz, nabigatzailearentzako 200 erantzunak ez du ezer esaten SSTP amaierako puntua existitzen den ala ez.
Bereizi bi oharrak eta bilaketak laburragoa dirudi. Garraioa eta ziurtagirien katea funtzionatzen dute, eta haien gaineko protokolo trukean zerbait ez. Hau portu hautsi edo ziurtagiri iraungia baino ikerketa desberdina da, eta beste froga batzuk behar ditu.
Zer bidaltzen duen SSTP bezeroak benetan
Bezeroak HTTP eskaera bat bidaltzen du SSTP_DUPLEX_POST metodoarekin /sra_{GUID}/ bidera, eta gero konexioaren gorputza irekita mantentzen du PPP markoak daramatzan noranzko biko fluxu gisa. Zerbitzari egoki batek HTTP/1.1 200 erantzuten du eta web zerbitzari gisa jokatzeari uzten dio. Beste edozein gauza sinadura bat da: 405 edo 404-k amaierako puntua ez dagoela esan nahi du, 301 edo 302-k zerbait eskaera birbideratzen ari dela, eta berehalako FIN batek proxy edo zerbitzari batek fluxua itxi duela.
Horregatik helburuak SSTP zerbitzaria izan behar du, ez TLS ziurtagiria itsatsita duen web zerbitzaria. Metodoa, bidea eta gorputz luzea protokoloaren baldintzak dira, beraz proxy alderantzikatu batek ezin ditu konfigurazio hutsez gehitu. HTTPS arrunta primeran birbidaltzen duen proxy batek hala ere uko egin diezaioke ezagutzen ez duen metodo bati.
Non hausten duen fluxua proxy edo web zerbitzari batek
Bitartekari batek HTTP eskaeraren lerroa aztertzen du ezer birbidali aurretik, eta bide ezohiko metodo pertsonalizatu batek bere arauetan huts egin dezake. Gailu batzuek orrialde normala zerbitzatzen dute tunela baztertu edo eteten duten bitartean, beraz bezeroak hasi eta gero hiltzen den konexio baten berri ematen du, ukapen garbi baten ordez. Beste batzuek eskaera onartzen dute, eta gero gorputz edo inaktibitate denbora-muga bat aplikatzen dute, PPP keepalive-ek gainditu ezin dutena. Biak berdin ikusten dira bezeroaren aldetik, horregatik huts egin duen etapa errorearen testua baino garrantzitsuagoa da.
443 portua webgune baten eta SSTP-ren artean partekatzea bideratze-erabakia da, ez hop bakoitzak bi elkarrizketak modu berean tratatuko dituen promesa. Bidean karga-banatzaile, suebaki edo TLS amaitzaile bat badago, gehitu susmagarrien zerrendara VPN konfigurazioa ukitu aurretik.
Probatu etapak bereizita
Exekutatu egiaztapenak ordenan eta gelditu lehen hutsunean, etapa bakoitzak geruza desberdin bat baztertzen duelako. Beheko TLS zunda ziurtagiriaren identitatea SSTP-k egiten duen guztitik bereizten du. Ordeztu ostalari-izena zure amaierako puntuarekin eta irakurri inprimatzen duen gaia eta katea.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comGero mapatu gainerako frogak etapetara, bezeroaren erroretik asmatu beharrean. Beheko taula txartelean aipatzeko zerrenda da, huts bat hurrengoarengandik bereizten duen sinadurarekin.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Erregistratu txartelean arrakastatsua izan zen azken etapa "ezin da konektatu" idatzi beharrean. MS-SSTP zehaztapena TLS eskukoaren ondoren datozen eskaera eta PPP trukea dokumentatzen ditu, eta nabigatzaileko proba batek bietako bat ordeztu ezin duen arrazoiaren erreferentzia da.
Lehenengo identitatea, gero PPP
TLS identitatea eta PPP autentifikazioa sekuentzialak dira, ez alternatiboak, eta nahasteak jendea zerbitzari-ezarpen oker batera eramaten du. Bezeroak lehenengo zerbitzariaren ziurtagiria eta haren helburuaz balidatzen du, gero PPP-k bere egoera negoziatzen du eta erabiltzailea erronka-erantzun metodo batekin edo EAP-rekin autentifikatzen du. Ziurtagiri arazo batek pasahitz baztertu batek baino errore desberdina sortzen du, eta bi erroreek ez dute besteak estaltzen duen etapa deskribatzen.
Ostalari-izena helbide batekin aldatzeak, edo ziurtagiri abisua saihesteak, huts egiten ari den etapa identifikatuko zuen egiaztapena kentzen du, hura konpondu beharrean. Mantendu abisua eta irakurri. Ez berrezarri PPP pasahitzik HTTP trukea inoiz SSTP portaerara iritsi ez bada, kredentzialak inoiz eskatu ez zirelako.