SSTP neizdodas tur, kur pārlūka HTTPS izdodas: kāpēc
SSTP darbojas TLS iekšienē 443. portā, bet tā nav tīmekļa pieprasījums. Pārbaudiet TCP, TLS identitāti, SSTP apmaiņu un PPP autentifikāciju kā atsevišķus posmus.
Pārlūks atver VPN resursdatora nosaukumu pa HTTPS bez iebildumiem, un SSTP klients joprojām atsakās savienoties. Šajā pārī nav nekā pretrunīga. SSTP izmanto TLS kā ārēju transportu un pēc tam tajā pašā savienojumā izpilda savu pieprasījumu un PPP kravu, tāpēc veiksmīga lapas ielāde pierāda tikai vienu šauru lietu: resursdators atbild uz GET portā ar numuru 443. Klients uzdod citu jautājumu, un serveris var atbildēt uz to slikti.
Lapa ielādējas, bet tunelis ne
Cilvēki ķeras pie pārlūka testa, jo tas ir ātrs, un pēc tam rezultātu uztver kā pierādījumu, ka serveris ir sasniedzams un konfigurēts. Tas ir pierādījums par GET uz ceļu, ko atvēra adreses josla, ne vairāk. VPN saruna sākas pēc tā paša TLS rokasspiediena, bet sūta metodi un ceļu, ko tīmekļa lapa nekad neizmanto. Tāpēc atbilde 200 pārlūkam neko nepasaka par to, vai SSTP galapunkts pastāv.
Atdaliet divus novērojumus, un meklēšana kļūst īsāka. Transports un sertifikātu ķēde darbojas, un kaut kas protokola apmaiņā virs tām nedarbojas. Tā ir cita izmeklēšana nekā salauzts ports vai beidzies sertifikāts, un tai vajadzīgi citi pierādījumi.
Ko SSTP klients faktiski sūta
Klients sūta HTTP pieprasījumu ar metodi SSTP_DUPLEX_POST uz ceļu /sra_{GUID}/, pēc tam tur savienojuma pamattekstu atvērtu kā divvirzienu plūsmu, kas pārvadā PPP kadrus. Atbilstošs serveris atbild HTTP/1.1 200 un pārstāj uzvesties kā tīmekļa serveris. Viss cits ir paraksts: 405 vai 404 nozīmē, ka galapunkta nav, 301 vai 302 nozīmē, ka kaut kas pieprasījumu pārvirza, un tūlītējs FIN nozīmē, ka starpniekserveris vai serveris aizvēra plūsmu.
Tāpēc mērķim jābūt SSTP serverim, nevis tīmekļa serverim ar pieskrūvētu TLS sertifikātu. Metode, ceļš un ilglaicīgais pamatteksts ir protokola prasības, tāpēc apgrieztais starpniekserveris nevar tās pievienot tikai ar konfigurāciju. Starpniekserveris, kas lieliski pārsūta parasto HTTPS, tomēr var noraidīt metodi, kuru nepazīst.
Kur starpniekserveris vai tīmekļa serveris pārtrauc plūsmu
Starpposms pārbauda HTTP pieprasījuma rindu pirms kaut ko pārsūtīt, un pielāgota metode ar neparastu ceļu var neizturēt tā noteikumus. Dažas ierīces apkalpo parastu lapu, vienlaikus noraidot vai pārtraucot tuneli, tāpēc klients ziņo par savienojumu, kas sākas un pēc tam mirst, nevis par tīru noraidījumu. Citas pieņem pieprasījumu un pēc tam piemēro pamatteksta vai dīkstāves taimautu, ko PPP keepalive signāli neiztur. Abi no klienta puses izskatās vienādi, tāpēc neizdevušais posms ir svarīgāks par kļūdas tekstu.
Porta ar numuru 443 koplietošana starp vietni un SSTP ir maršrutēšanas izvēle, nevis solījums, ka katrs lēciens abas sarunas apstrādās vienādi. Ja ceļā ir slodzes balansētājs, ugunsmūris vai TLS terminators, pievienojiet to aizdomās turamo sarakstam pirms VPN konfigurācijas aizskaršanas.
Pārbaudiet posmus atsevišķi
Izpildiet pārbaudes secīgi un apstājieties pie pirmās kļūdas, jo katrs posms izslēdz citu slāni. Zemāk esošā TLS zonde atdala sertifikāta identitāti no visa, ko dara SSTP. Aizstājiet resursdatora nosaukumu ar savu galapunktu un izlasiet subject un ķēdi, ko tā izdrukā.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPēc tam kartējiet atlikušos pierādījumus uz posmiem, nevis miniet no klienta kļūdas. Zemāk esošā tabula ir kontrolsaraksts citēšanai biļetenā, ar parakstu, kas atdala vienu neveiksmi no nākamās.
| 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 |
Biļetenā ierakstiet pēdējo veiksmīgo posmu, nevis rakstiet "nevar savienoties". MS-SSTP specifikācija dokumentē pieprasījumu un PPP apmaiņu, kas seko TLS rokasspiedienam, un ir atsauce uz to, kāpēc pārlūka tests nevar aizstāt nevienu no tiem.
Vispirms identitāte, pēc tam PPP
TLS identitāte un PPP autentifikācija ir secīgas, nevis alternatīvas, un to sajaukšana aizved cilvēkus pie nepareiza servera iestatījuma. Klients vispirms validē servera sertifikātu un tā paredzēto mērķi, pēc tam PPP apspriež savu stāvokli un autentificē lietotāju ar izaicinājuma-atbildes metodi vai EAP. Sertifikāta problēma dod citu kļūdu nekā noraidīta parole, un neviena kļūda neapraksta posmu, ko aptver otra.
Resursdatora nosaukuma aizstāšana ar adresi vai sertifikāta brīdinājuma izlaišana noņem pārbaudi, kas būtu identificējusi neizdevušos posmu, nevis to izlabo. Saglabājiet brīdinājumu un izlasiet to. Neatiestatiet arī PPP paroli, ja HTTP apmaiņa nekad nesasniedza SSTP uzvedību, jo akreditācijas dati netika pieprasīti.