SSTP mislearret wêr't HTTPS fan de browser slagget: wêrom
SSTP rint binnen TLS op poarte 443, mar it is gjin webfersyk. Test TCP, TLS-identiteit, de SSTP-útwikseling en PPP-autentikaasje as aparte fazen.
De browser iepenet de VPN-hostnamme oer HTTPS sûnder klacht, en de SSTP-klant wegert noch altyd te ferbinen. Der is neat tsjinstridich oan dat pear. SSTP brûkt TLS as bûtenferfier en fiert dêrnei syn eigen fersyk en PPP-lading binnen dy ferbining út, dus in suksesfolle sidebelading bewissiget mar ien ing ding: de host antwurdet in GET op poarte 443. De klant stelt in oare fraach, en de server antwurdet dy miskien min.
De side lade en de tunnel net
Minsken gripe nei de browsertest om't dy fluch is, en behannelje it resultaat dan as bewiis dat de server berikber en konfigurearre is. It is bewiis oer in GET nei it paad dat de adresbalke iepene, net mear. It VPN-petear begjint nei deselde TLS-hânskodding, mar stjoert in metoade en in paad dy't in webside nea brûkt. In 200 foar de browser seit dus neat oer oft it SSTP-einpunt bestiet.
Skied de twa waarnimmingen en de syktocht wurdt koarter. Ferfier en sertifikaatkeatling wurkje, en eat yn 'e protokolútwikseling dêrboppe wurket net. Dat is in oar ûndersyk as in stikene poarte of in ferrûn sertifikaat, en it freget oar bewiis.
Wat de SSTP-klant eins stjoert
De klant stjoert in HTTP-fersyk mei de metoade SSTP_DUPLEX_POST nei it paad /sra_{GUID}/, en hâldt dan it lichem fan 'e ferbining iepen as in twarjochtingstream dy't PPP-ramen draacht. In foldwaande server antwurdet HTTP/1.1 200 en hâldt op him as webserver te hâlden. Eat oars is in sinjier: 405 of 404 betsjut dat it einpunt der net is, 301 of 302 betsjut dat eat it fersyk omleit, en in daliks FIN betsjut dat in proxy of server de stream sletten hat.
Dêrom moat it doel in SSTP-server wêze en net in webserver mei in TLS-sertifikaat deroan skroefd. De metoade, it paad en it langduorjend lichem binne protokolferplichtingen, dus in omkearde proxy kin se net allinnich út konfiguraasje tafoegje. In proxy dy't gewoane HTTPS perfekt trochjout, kin noch altyd in metoade wegerje dy't er net ken.
Wêr't in proxy of webserver de stream brekt
In tuskenpersoan besjocht de HTTP-fersyklade foardat er eat trochjout, en in oanpaste metoade mei in ûngewoan paad kin syn regels net trochkomme. Guon apparaten tsjinje in normale side wylst se de tunnel wegerje of ûnderbrekke, dus de klant meldt in ferbining dy't begjint en dan stjert, ynstee fan in skjinne wegering. Oaren akseptearje it fersyk en passe dan in lichem- of idle-timeout ta dy't de PPP-keepalives net oerlibje. Beide lykje fan 'e klantkant itselde, dêrom is de faze dy't mislearre wichtiger as de flatertekst.
Poarte 443 diele tusken in website en SSTP is in rûtkarringskar, net in belofte dat elke hop beide petearen itselde behannelet. As der in loadbalancer, firewall of TLS-terminator yn it paad sit, foeget dy dan oan 'e fertochte list foardat jo de VPN-konfiguraasje oanreekje.
Test de fazen apart
Fier de kontrôles yn folchoarder út en stop by de earste mislearring, want elke faze slút in oare laach út. De TLS-sonde hjirûnder skiedt sertifikaatidentiteit fan alles wat SSTP docht. Ferfange de hostnamme troch jo einpunt en lês it ûnderwerp en de keatling dy't it printsjet.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comByld dan it oerbliuwende bewiis op 'e fazen ôf ynstee fan te rieden út 'e klantflater. De tabel hjirûnder is de checklist foar it ticket, mei it sinjier dat ien mislearring fan 'e folgjende skiedt.
| 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 |
Notearje de lêste faze dy't slagge is yn it ticket ynstee fan "kin net ferbine" te skriuwen. De MS-SSTP-specifikaasje dokumintearret it fersyk en de PPP-útwikseling dy't nei de TLS-hânskodding komme, en is de referinsje foar wêrom't in browsertest gjin fan beide ferfange kin.
Earst identiteit, dan PPP
TLS-identiteit en PPP-autentikaasje binne efterinoar, net alternatyf, en se trochinoar helje stjoert minsken nei de ferkearde serverynstelling. De klant falidearret earst it serversertifikaat en syn bedoelde doel, dan ûnderhannelt PPP syn eigen steat en autentisearret de brûker mei in útdaging-antwurdmetoade of EAP. In sertifikaatprobleem jout in oare flater as in wegere wachtwurd, en gjin fan beide flaters beskriuwt de faze dy't de oare dekt.
De hostnamme troch in adres ferfange, of foarby de sertifikaatwarskôging klikke, hellet de kontrôle fuort dy't de mislearjende faze identifisearre hawwe soe, ynstee fan it te reparearjen. Hâld de warskôging en lês dy. Reset ek gjin PPP-wachtwurd as de HTTP-útwikseling nea it SSTP-gedrach berikte, want de oanmeldgegevens waarden nea frege.