SSTP er PPP yfir HTTPS, ekki vefsíða á porti 443

SSTP flytur PPP inni í HTTPS-tengingu, þess vegna lítur það út eins og vefumferð fyrir hvað sem er í miðjunni. TLS og HTTP reisa ytri rásina, síðan undirbúa SSTP-stýriskilaboð göngin og PPP veitir hegðun lotunnar. Vafri sem hleður síðu á sama vistfangi hefur aðeins lokið hluta fyrsta þrepsins. Að líta á það sem VPN-próf er leiðin sem vinnandi milliþjónn fær sökina fyrir frávik í samskiptareglum.

Farðu í gegnum þrepin fjögur í röð, og bilunin sem þú sérð lendir í einu þeirra.

Þrep 1: TCP og TLS

Biðlarinn opnar TCP-tengingu á port 443 og gerir TLS-handaband. Skírteinakeðjan verður að passa við hýsilnafnið sem biðlarinn var stilltur með. Nafnafrávik hér veldur bilun áður en nokkur SSTP-skilaboð eru skipt, og SSTP-forskriftin gerir ráð fyrir að þessi ytri HTTPS-rás sé þegar til. Ekkert í síðari þrepum getur bætt upp traustabilun hér.

Venjulegur vefþjónn getur klárað þetta þrep fullkomlega og samt mistekist í því næsta. Árangur TLS er sönnun um skírteinið, ekki um samskiptareglurnar á bak við það.

Þrep 2: HTTPS-beiðnin

SSTP sendir beiðni sína með sérstakri aðferð, SSTP_DUPLEX_POST, og heldur skiptunum opnum í stað þess að skila skjali. Þjónn eða milliþjónn sem er stilltur fyrir venjulegar síðubeiðnir getur samþykkt tenginguna og síðan hafnað aðferðinni. Sú höfnun er samhæfnisvandamálið sem fólk lýsir venjulega sem lokuðu porti 443.

Lestu svarálagið og aðferðina í annál þjónsins. Höfnun í þessu þrepi er annað vandamál en TCP-tímanönn, og bæði leiða til mismunandi lagfæringa.

Þrep 3: stýriskilaboð

Þegar beiðnin hefur verið samþykkt skiptir SSTP stýriskilaboðum sem semja og undirbúa göngin. Þetta eru samskiptaregluskilaboð inni í HTTPS-meginmálinu, ekki HTTP-beiðnir, svo milliþjónn sem skoðar og endurskrifar meginmál getur brotið þau á meðan síðubeiðnir haldast ósnortnar.

Hér ávinnur milliþjónn fyrir djúpskoðun sér orðstír. Ef síður hlaðast en VPN mistekst, athugaðu hvort meginmálinu sé breytt frekar en hvort portið sé opið.

Þrep 4: PPP tekur við

Þá veitir PPP hegðun lotunnar: tenglasamninga, auðkenningu og stillingu netlagsins sem fylgir. PPP-auðkenning er aðskilin frá TLS-prófinu sem biðlarinn hefur þegar staðist. Þjónskírteini sem biðlarinn samþykkir segir ekkert um hvort skilríki notandans séu gild eða hvort reikningurinn sé heimilaður.

Samþykkt skírteini og höfnuð innskráning stangast ekki á. Þetta eru samfelld þrep með óháðum niðurstöðum.

Auðkenning hefur nokkrum hlutverkum að gegna

Biðlarinn staðfestir auðkenni TLS-þjónsins gagnvart traustageymslu sinni og stillta nafninu. Síðan auðkennir PPP notandann eða vélina, eftir uppsetningu. Þjónninn getur bætt við eigin stefnu um hver má tengjast og hvað hann má ná. Haltu hýsilnafninu í samræmi við auðkenni skírteinisins, því að skipta því út fyrir hrátt vistfang gerir vinnandi uppsetningu að nafnaprófunarbilun.

Skrifaðu niður hvaða þrep tilkynnti bilunina. Skírteini, aðferð, stýriskilaboð, PPP-auðkenning, síðan leiðir: fimm staðir, fimm lagfæringar.

Hvað vafrapróf getur og getur ekki sýnt

Að hlaða síðu á vistfanginu sannar DNS-upplausn, TCP-aðgengi og að eitthvað hlustar sem talar HTTP. Það sannar ekki að aðferðin sé samþykkt, að stýriskiptin lifi af eða að PPP-auðkenning sé stillt. Notaðu biðlara sem útfærir SSTP í stað þess að breyta annarri stillingu með því að skipta um port.

Þegar lotan er komin upp ráða leiðir, DNS og framsending á þjónshlið enn hvað notandinn nær. Göngin eru leið, ekki heimild.