SSTP dështon aty ku HTTPS i shfletuesit ka sukses: pse
SSTP funksionon brenda TLS në portën 443, por nuk është një kërkesë web. Testoni TCP, identitetin TLS, shkëmbimin SSTP dhe vërtetimin PPP si faza të veçanta.
Shfletuesi hap emrin e hostit të VPN përmes HTTPS pa asnjë ankesë, dhe klienti SSTP vazhdon të refuzojë të lidhet. Nuk ka asgjë kontradiktore në këtë çift. SSTP përdor TLS si transport të jashtëm dhe më pas ekzekuton kërkesën e vet dhe ngarkesën PPP brenda atij lidhjeje, kështu që një ngarkim i suksesshëm i faqes provon vetëm një gjë të ngushtë: hosti përgjigjet ndaj një GET në portën 443. Klienti po bën një pyetje tjetër, dhe serveri mund t'i përgjigjet asaj keq.
Faqja ngarkohet dhe tuneli jo
Njerëzit i drejtohen testit të shfletuesit sepse është i shpejtë, dhe më pas e marrin rezultatin si provë që serveri është i arritshëm dhe i konfiguruar. Është provë për një GET drejt shtegut që hapi shiriti i adresave, asgjë më shumë. Biseda VPN fillon pas të njëjtit handshake TLS, por dërgon një metodë dhe një shteg që një faqe web nuk i përdor kurrë. Prandaj një përgjigje 200 për shfletuesin nuk thotë asgjë nëse pika fundore SSTP ekziston.
Ndani dy vëzhgimet dhe kërkimi shkurtohet. Transporti dhe zinxhiri i certifikatave funksionojnë, dhe diçka në shkëmbimin e protokollit mbi ta nuk funksionon. Ky është një hetim tjetër nga një port i prishur ose një certifikatë e skaduar, dhe kërkon prova të tjera.
Çfarë dërgon në të vërtetë klienti SSTP
Klienti dërgon një kërkesë HTTP me metodën SSTP_DUPLEX_POST në shtegun /sra_{GUID}/, dhe më pas e mban trupin e lidhjes hapur si një rrjedhë dykahëshe që mbart kornizat PPP. Një server në përputhje përgjigjet HTTP/1.1 200 dhe pushon së sjelluri si server web. Çdo gjë tjetër është një nënshkrim: 405 ose 404 do të thotë që pika fundore nuk është aty, 301 ose 302 do të thotë që diçka po e ridrejton kërkesën, dhe një FIN i menjëhershëm do të thotë që një proxy ose server e mbylli rrjedhën.
Prandaj objektivi duhet të jetë një server SSTP dhe jo një server web me një certifikatë TLS të vidhosur sipër. Metoda, shtegu dhe trupi jetëgjatë janë kërkesa të protokollit, kështu që një proxy i kundërt nuk mund t'i shtojë ato vetëm me konfigurim. Një proxy që përcjell në mënyrë të përsosur HTTPS të zakonshëm mund të refuzojë përsëri një metodë që nuk e njeh.
Ku një proxy ose server web e thyen rrjedhën
Një ndërmjetës inspekton rreshtin e kërkesës HTTP përpara se të përcjellë diçka, dhe një metodë e personalizuar me një shteg të pazakontë mund të dështojë në rregullat e tij. Disa pajisje shërbejnë një faqe normale ndërsa refuzojnë ose ndërpresin tunelin, kështu që klienti raporton një lidhje që nis dhe pastaj vdes në vend të një refuzimi të pastër. Të tjerë e pranojnë kërkesën, dhe më pas aplikojnë një afat trupi ose papunësie që keepalive-t PPP nuk e mbijetojnë. Të dyja duken njësoj nga ana e klientit, prandaj faza që dështoi ka më shumë rëndësi sesa teksti i gabimit.
Ndarja e portës 443 midis një faqe web dhe SSTP është një zgjedhje rrugëtimi, jo një premtim që çdo hop i trajton të dyja bisedat njësoj. Nëse në shteg ndodhet një balancues ngarkese, një firewall ose një përfundues TLS, shtojeni në listën e të dyshuarve përpara se të prekni konfigurimin e VPN.
Testoni fazat veçmas
Kryeni kontrollet sipas radhës dhe ndaloni në dështimin e parë, sepse çdo fazë përjashton një shtresë tjetër. Sonda TLS më poshtë e ndan identitetin e certifikatës nga çdo gjë që bën SSTP. Zëvendësoni emrin e hostit me pikën tuaj fundore dhe lexoni subject-in dhe zinxhirin që printon.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPastaj hartëzoni provat e mbetura në faza në vend që të hamendësoni nga gabimi i klientit. Tabela më poshtë është lista e kontrollit për t'u cituar në tiketë, me nënshkrimin që ndan një dështim nga ai pasardhësi.
| 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 |
Regjistroni në tiketë fazën e fundit të suksesshme në vend që të shkruani "nuk mund të lidhet". Specifikimi MS-SSTP dokumenton kërkesën dhe shkëmbimin PPP që pasojnë handshake-un TLS, dhe është referenca për arsyen pse një test në shfletues nuk mund të zëvendësojë asnjërën prej tyre.
Së pari identiteti, pastaj PPP
Identiteti TLS dhe vërtetimi PPP janë vijues, jo alternativë, dhe ngatërrimi i tyre i çon njerëzit te cilësimi i gabuar i serverit. Klienti vërteton fillimisht certifikatën e serverit dhe qëllimin e saj të synuar, pastaj PPP negocion gjendjen e vet dhe vërteton përdoruesin me një metodë sfidë-përgjigje ose EAP. Një problem certifikate prodhon një gabim të ndryshëm nga një fjalëkalim i refuzuar, dhe asnjëri gabim nuk përshkruan fazën që mbulon tjetri.
Zëvendësimi i emrit të hostit me një adresë, ose klikimi përtej paralajmërimit të certifikatës, heq kontrollin që do të kishte identifikuar fazën që dështon në vend që ta rregullojë atë. Mbajeni paralajmërimin dhe lexojeni. Gjithashtu mos e rivendosni fjalëkalimin PPP kur shkëmbimi HTTP nuk arriti kurrë sjelljen SSTP, sepse kredencialet nuk u kërkua kurrë.