SSTP pada tamo gde HTTPS u pregledaču uspeva: zašto
SSTP radi unutar TLS-a na portu 443, ali to nije veb zahtev. Testirajte TCP, TLS identitet, SSTP razmenu i PPP autentifikaciju kao odvojene faze.
Pregledač otvara VPN ime hosta preko HTTPS-a bez prigovora, a SSTP klijent i dalje odbija da se poveže. Ništa u tom paru nije protivrečno. SSTP koristi TLS kao spoljni transport, a zatim unutar te veze izvodi sopstveni zahtev i PPP teret, pa uspešno učitavanje stranice dokazuje samo jednu usku stvar: host odgovara na GET na portu 443. Klijent postavlja drugo pitanje, a server mu može odgovoriti loše.
Stranica se učita, a tunel ne
Ljudi posežu za testom u pregledaču jer je brz, a zatim rezultat uzimaju kao dokaz da je server dostupan i konfigurisan. To je dokaz o GET-u na putanju koju je otvorila adresna traka, ništa više. VPN razgovor počinje posle istog TLS rukovanja, ali šalje metodu i putanju koju veb stranica nikada ne koristi. Zato odgovor 200 za pregledač ne govori ništa o tome postoji li SSTP krajnja tačka.
Odvojite dva zapažanja i potraga postaje kraća. Transport i lanac sertifikata rade, a nešto u razmeni protokola iznad njih ne radi. To je druga istraga od pokvarenog porta ili isteklog sertifikata i traži drugačije dokaze.
Šta SSTP klijent zapravo šalje
Klijent šalje HTTP zahtev metodom SSTP_DUPLEX_POST na putanju /sra_{GUID}/, a zatim drži telo veze otvorenim kao dvosmerni tok koji nosi PPP okvire. Ispravan server odgovara HTTP/1.1 200 i prestaje da se ponaša kao veb server. Bilo šta drugo je potpis: 405 ili 404 znači da krajnje tačke nema, 301 ili 302 znači da nešto preusmerava zahtev, a trenutni FIN znači da je proxy ili server zatvorio tok.
Zato meta mora biti SSTP server, a ne veb server sa prikačenim TLS sertifikatom. Metoda, putanja i dugotrajno telo su zahtevi protokola, pa obrnuti proxy ne može da ih doda samo konfiguracijom. Proxy koji savršeno prosleđuje običan HTTPS ipak može odbiti metodu koju ne prepoznaje.
Gde proxy ili veb server prekida tok
Posrednik pregleda red HTTP zahteva pre nego što bilo šta prosledi, a prilagođena metoda sa neobičnom putanjom može pasti na njegovim pravilima. Neki uređaji služe normalnu stranicu dok odbijaju ili prekidaju tunel, pa klijent prijavljuje vezu koja počne i zatim umre umesto čistog odbijanja. Drugi prihvate zahtev pa primene vremensko ograničenje tela ili mirovanja koje PPP keepalive poruke ne mogu preživeti. Oboje izgleda isto sa klijentove strane, zato je faza koja je pala važnija od teksta greške.
Deljenje porta 443 između veb stranice i SSTP-a odluka je o rutiranju, a ne obećanje da svaki skok obrađuje oba razgovora na isti način. Ako je na putu balanser opterećenja, firewall ili TLS termininator, dodajte ga na listu sumnjivih pre nego što dirnete VPN konfiguraciju.
Testirajte faze odvojeno
Izvršite provere redom i zaustavite se na prvom neuspehu, jer svaka faza isključuje drugi sloj. TLS sonda ispod odvaja identitet sertifikata od svega što SSTP radi. Zamenite ime hosta svojom krajnjom tačkom i pročitajte subject i lanac koje ispisuje.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comZatim preslikajte preostale dokaze na faze umesto da nagađate iz greške klijenta. Tabela ispod je kontrolna lista za tiket, sa potpisom koji odvaja jedan neuspeh od sledećeg.
| 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 |
U tiket zapišite poslednju fazu koja je uspela umesto da pišete "nema veze". MS-SSTP specifikacija dokumentuje zahtev i PPP razmenu koji slede nakon TLS rukovanja i referenca je za to zašto test u pregledaču ne može zameniti nijedno od toga.
Prvo identitet, zatim PPP
TLS identitet i PPP autentifikacija su uzastopni, ne alternativni, a njihovo mešanje vodi ljude na pogrešnu postavku servera. Klijent prvo proveri sertifikat servera i njegovu namenu, zatim PPP pregovara sopstveno stanje i autentifikuje korisnika metodom izazov-odgovor ili EAP. Problem sa sertifikatom daje drugačiju grešku od odbijene lozinke i nijedna greška ne opisuje fazu koju pokriva ona druga.
Zamena imena hosta adresom ili preskakanje upozorenja o sertifikatu uklanja proveru koja bi identifikovala neuspešnu fazu umesto da je popravi. Zadržite upozorenje i pročitajte ga. Nemojte resetovati PPP lozinku kad HTTP razmena nikada nije stigla do SSTP ponašanja, jer podaci za prijavu nikada nisu zatraženi.