SSTP ir PPP virs HTTPS, ne tīmekļa lapa 443. portā

SSTP pārvieto PPP HTTPS savienojuma iekšienē, tāpēc tas izskatās kā tīmekļa datplūsma jebkam pa vidu. TLS un HTTP izveido ārējo kanālu, pēc tam SSTP vadības ziņojumi sagatavo tuneli, un PPP nodrošina sesijas uzvedību. Pārlūks, kas ielādē lapu tajā pašā adresē ir pabeidzis tikai daļu pirmā posma. Uzskatīt to par VPN testu ir veids, kā strādājošs starpniekservers tiek vainots protokola neatbilstībā.

Izejiet cauri četriem posmiem pēc kārtas, un jūsu redzamā kļūda nonāks vienā no tiem.

1. posms: TCP un TLS

Klients atver TCP savienojumu uz 443. portu un veic TLS rokasspiedienu. Sertifikātu ķēdei jāatbilst resursdatora nosaukumam, ar kuru klients tika konfigurēts. Nosaukuma neatbilstība šeit rada kļūdu pirms jebkura SSTP ziņojuma apmaiņas, un SSTP specifikācija pieņem, ka šis ārējais HTTPS kanāls jau pastāv. Nekas vēlākajos posmos nevar kompensēt uzticēšanās kļūdu šeit.

Parasts tīmekļa serveris var lieliski pabeigt šo posmu un tomēr neizdoties nākamajā. TLS panākums ir pierādījums par sertifikātu, nevis par protokolu aiz tā.

2. posms: HTTPS pieprasījums

SSTP veic savu pieprasījumu ar īpašu metodi SSTP_DUPLEX_POST un tur apmaiņu atvērtu, nevis atgriež dokumentu. Serveris vai starpniekservers, kas konfigurēts parastiem lapu pieprasījumiem, var pieņemt savienojumu un pēc tam noraidīt metodi. Šis noraidījums ir saderības problēma, ko cilvēki parasti apraksta kā bloķētu 443. portu.

Izlasiet atbildes kodu un metodi servera žurnālā. Noraidījums šajā posmā ir cita problēma nekā TCP taimauts, un abas ved pie atšķirīgiem labojumiem.

3. posms: vadības ziņojumi

Kad pieprasījums ir pieņemts, SSTP apmaina vadības ziņojumus, kas vienojas un sagatavo tuneli. Tie ir protokola ziņojumi HTTPS pamattekstā, nevis HTTP pieprasījumi, tāpēc starpniekservers, kas pārbauda un pārraksta pamattekstus, var tos salauzt, kamēr lapu pieprasījumi paliek neskarti.

Šeit dziļās pārbaudes starpierīce nopelna savu reputāciju. Ja lapas ielādējas un VPN neizdodas, pārbaudiet, vai pamatteksts tiek mainīts, nevis vai ports ir atvērts.

4. posms: PPP pārņem

Pēc tam PPP nodrošina sesijas uzvedību: saites pārrunas, autentifikāciju un sekojošo tīkla slāņa konfigurāciju. PPP autentifikācija ir atsevišķa no TLS pārbaudes, ko klients jau ir izturējis. Servera sertifikāts, ko klients pieņem, neko nepasaka par to, vai lietotāja akreditācijas dati ir derīgi vai konts ir autorizēts.

Pieņemts sertifikāts un noraidīta pieteikšanās nav pretrunā. Tie ir secīgi posmi ar neatkarīgiem rezultātiem.

Autentifikācijai ir vairākas lomas

Klients validē TLS servera identitāti pret savu uzticības krātuvi un konfigurēto nosaukumu. Pēc tam PPP autentificē lietotāju vai mašīnu atkarībā no izvietojuma. Serveris var pievienot savu politiku par to, kurš drīkst pievienoties un ko drīkst sasniegt. Saglabājiet resursdatora nosaukumu saskaņā ar sertifikāta identitāti, jo neapstrādātas adreses ievietošana pārvērš strādājošu iestatījumu nosaukuma pārbaudes kļūdā.

Pierakstiet, kurš posms ziņoja par kļūdu. Sertifikāts, metode, vadības ziņojums, PPP autentifikācija, pēc tam maršruti: piecas vietas, pieci labojumi.

Ko pārlūka tests var un ko nevar parādīt

Lapas ielāde adresē pierāda DNS atrisināšanu, TCP sasniedzamību un to, ka kaut kas klausās un runā HTTP. Tas nepierāda, ka metode tiek pieņemta, vadības apmaiņa izdzīvo vai PPP autentifikācija ir konfigurēta. Izmantojiet klientu, kas ievieš SSTP, nevis pārveidojiet citu profilu, mainot portu.

Kad sesija ir uzcelta, maršruti, DNS un pāradresācija servera pusē joprojām nosaka, ko lietotājs var sasniegt. Tunelis ir ceļš, nevis atļauja.