SSTP ne uspijeva tamo gdje HTTPS u pregledniku uspijeva: zašto
SSTP radi unutar TLS-a na portu 443, ali to nije web zahtjev. Testirajte TCP, TLS identitet, SSTP razmjenu i PPP autentifikaciju kao odvojene faze.
Preglednik otvara VPN ime hosta preko HTTPS-a bez prigovora, a SSTP klijent ipak odbija da se poveže. Ništa u tom paru nije proturječno. SSTP koristi TLS kao vanjski transport, a zatim pokreće vlastiti zahtjev i PPP korisni teret unutar te veze, pa uspješ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čitava, a tunel ne
Ljudi posežu za testom u pregledniku 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 nakon istog TLS rukovanja, ali šalje metodu i putanju koju web stranica nikada ne koristi. Zato odgovor 200 za preglednik ne govori ništa o tome postoji li SSTP krajnja točka.
Odvojite dva zapažanja i potraga postaje kraća. Transport i lanac certifikata rade, a nešto u razmjeni protokola iznad njih ne radi. To je druga istraga od pokvarenog porta ili isteklog certifikata i traži drugačije dokaze.
Šta SSTP klijent zapravo šalje
Klijent šalje HTTP zahtjev metodom SSTP_DUPLEX_POST na putanju /sra_{GUID}/, a zatim drži tijelo veze otvorenim kao dvosmjerni tok koji nosi PPP okvire. Ispravan server odgovara HTTP/1.1 200 i prestaje da se ponaša kao web server. Bilo šta drugo je potpis: 405 ili 404 znači da krajnje točke nema, 301 ili 302 znači da nešto preusmjerava zahtjev, a trenutni FIN znači da je proxy ili server zatvorio tok.
Zato meta mora biti SSTP server, a ne web server s prikačenim TLS certifikatom. Metoda, putanja i dugotrajno tijelo su zahtjevi protokola, pa obrnuti proxy ne može dodati ih samo konfiguracijom. Proxy koji savršeno prosljeđuje običan HTTPS ipak može odbiti metodu koju ne prepoznaje.
Gdje proxy ili web server prekida tok
Posrednik pregleda red HTTP zahtjeva prije nego bilo šta proslijedi, a prilagođena metoda s neobičnom putanjom može pasti njegova pravila. Neki uređaji poslužuju normalnu stranicu dok odbijaju ili prekidaju tunel, pa klijent prijavljuje vezu koja počne i zatim umre umjesto čistog odbijanja. Drugi prihvate zahtjev, pa primijene tajmaut za tijelo ili mirovanje koji PPP keepalive-i ne mogu preživjeti. Oboje izgleda isto s klijentove strane, zato je faza koja je pala važnija od teksta greške.
Dijeljenje porta 443 između web stranice i SSTP-a je odluka o rutiranju, a ne obećanje da svaki hop obrađuje oba razgovora na isti način. Ako je na putu balanser opterećenja, firewall ili TLS terminator, dodajte ga na listu sumnjivaca prije nego dirnete VPN konfiguraciju.
Testirajte faze odvojeno
Izvršite provjere po redu i zaustavite se na prvom neuspjehu, jer svaka faza isključuje drugi sloj. TLS sonda ispod odvaja identitet certifikata od svega što SSTP radi. Zamijenite ime hosta svojom krajnjom toč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 umjesto da pogađate iz greške klijenta. Tabela ispod je kontrolna lista za tiket, s potpisom koji odvaja jedan neuspjeh od sljedeć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 posljednju fazu koja je uspjela umjesto da pišete "nema veze". MS-SSTP specifikacija dokumentuje zahtjev i PPP razmjenu koji slijede nakon TLS rukovanja i referenca je za to zašto test u pregledniku ne može zamijeniti nijedno od toga.
Prvo identitet, zatim PPP
TLS identitet i PPP autentifikacija su uzastopni, ne alternativni, i njihovo miješanje vodi ljude na pogrešnu postavku servera. Klijent prvo provjeri certifikat servera i njegovu namjenu, zatim PPP pregovara vlastito stanje i autentificira korisnika metodom izazov-odgovor ili EAP. Problem s certifikatom daje drugačiju grešku od odbijene lozinke i nijedna greška ne opisuje fazu koju pokriva ona druga.
Zamjena imena hosta adresom ili preskakanje upozorenja o certifikatu uklanja provjeru koja bi identificirala neuspjelu fazu umjesto da je popravi. Zadržite upozorenje i pročitajte ga. Ne resetirajte PPP lozinku kad HTTP razmjena nikada nije stigla do SSTP ponašanja, jer podaci za prijavu nikada nisu traženi.