SSTP is PPP oor HTTPS, nie 'n webblad op poort 443 nie

SSTP dra PPP binne 'n HTTPS-verbinding, en daarom lyk dit vir enigiets in die middel soos webverkeer. TLS en HTTP bou die buitenste kanaal, dan berei SSTP-beheerboodskappe die tonnel voor, en PPP verskaf die sessiegedrag. 'n Blaaier wat 'n bladsy by dieselfde adres laai het net 'n deel van die eerste fase voltooi. Om dit as 'n VPN-toets te beskou, is hoe 'n werkende instaanbediener die skuld kry vir 'n protokolverskil.

Stap die vier fases in volgorde deur, en die fout wat jy sien, val in een van hulle.

Fase 1: TCP en TLS

Die kliënt maak 'n TCP-verbinding na poort 443 oop en voer 'n TLS-handdruk uit. Die sertifikaatketting moet by die gasheernaam pas waarmee die kliënt opgestel is. 'n Naamverskil hier veroorsaak 'n fout voordat enige SSTP-boodskap uitgeruil word, en die SSTP-spesifikasie aanvaar dat hierdie buitenste HTTPS-kanaal reeds bestaan. Niks in die later fases kan 'n vertrouensfout hier vergoed nie.

'n Gewone webbediener kan hierdie fase perfek voltooi en steeds die volgende een faal. TLS-sukses is bewys oor die sertifikaat, nie oor die protokol daaronder nie.

Fase 2: die HTTPS-versoek

SSTP maak sy versoek met 'n spesifieke metode, SSTP_DUPLEX_POST, en hou die uitruiling oop in plaas daarvan om 'n dokument terug te stuur. 'n Bediener of instaanbediener wat vir gewone bladsyversoeke opgestel is, kan die verbinding aanvaar en dan die metode verwerp. Daardie verwerping is die versoenbaarheidsprobleem wat mense gewoonlik beskryf as dat poort 443 geblokkeer is.

Lees die antwoordkode en die metode in die bedienerlog. 'n Verwerping in hierdie fase is 'n ander probleem as 'n TCP-tydsverloop, en die twee lei tot verskillende oplossings.

Fase 3: beheerboodskappe

Sodra die versoek aanvaar is, ruil SSTP beheerboodskappe uit wat die tonnel beding en voorberei. Dit is protokolboodskappe binne die HTTPS-liggaam, nie HTTP-versoeke nie, so 'n instaanbediener wat liggame ondersoek en herskryf, kan hulle breek terwyl bladsyversoeke onaangeraak bly.

Dit is waar 'n diep-inspeksie-middelkas sy reputasie verdien. As bladsye laai en die VPN faal, kyk of die liggaam gewysig word eerder as of die poort oop is.

Fase 4: PPP neem oor

PPP verskaf dan sy sessiegedrag: skakelbedinging, verifikasie en die netwerklaag-opstelling wat volg. PPP-verifikasie is apart van die TLS-kontrole wat die kliënt reeds geslaag het. 'n Bedienersertifikaat wat die kliënt aanvaar, sê niks oor of die gebruiker se geloofsbriewe geldig is of die rekening gemagtig is nie.

'n Aanvaarde sertifikaat en 'n verwerpte aanmelding is nie teenstrydig nie. Dit is opeenvolgende fases met onafhanklike uitkomste.

Verifikasie het verskeie rolle

Die kliënt valideer die TLS-bedieneridentiteit teen sy vertrouensberg en die opgestelde naam. PPP verifieer dan die gebruiker of die masjien, afhangend van die ontplooiing. Die bediener kan sy eie beleid byvoeg oor wie mag koppel en wat hulle mag bereik. Hou die gasheernaam in ooreenstemming met die sertifikaatidentiteit, want om 'n rou adres te gebruik, maak 'n werkende opstelling 'n naamkontrole-fout.

Skryf neer watter fase die fout gerapporteer het. Sertifikaat, metode, beheerboodskap, PPP-verifikasie, dan roetes: vyf plekke, vyf herstellings.

Wat 'n blaaier-toets wel en nie kan wys nie

Om 'n bladsy by die adres te laai, bewys DNS-resolusie, TCP-bereikbaarheid en dat iets luister wat HTTP praat. Dit bewys nie dat die metode aanvaar word, die beheeruitruiling oorleef of PPP-verifikasie opgestel is nie. Gebruik 'n kliënt wat SSTP implementeer eerder as om 'n ander profiel om te skakel deur die poort te verander.

Sodra die sessie op is, besluit roetes, DNS en bedienerkant-deurvoering steeds wat die gebruiker kan bereik. Die tonnel is 'n pad, nie 'n magtiging nie.