SSTP tók port 443: hvers vegna Apache ræsist ekki

Apache hættir að svara á 443 síðdegis þegar einhver virkjar innkomandi VPN-tengingar, og villuskrá þess kennir bind um það í stað áskriftarinnar sem liggur á bak við. Windows Routing and Remote Access kveikir á SSTP á þeirri stundu, og SSTP-hlustarinn gerir tilkall til TCP 443 í gegnum HTTP-stakkinn áður en nokkur biðlari auðkennir sig. Tilkallið stendur jafnvel þótt skírteinið vanti, nafnið sé rangt eða hverri handshake sé hafnað, svo VPN sem enginn kemst inn í heldur portinu samt. Lestu hlustunartöfluna fyrst; PID-ið sem á 443 ræður því hver af leiðréttingunum hér að neðan er jafnvel opin þér.

Áskriftin lifir af brotið skírteini

SSTP umvefur PPP í TLS-lotu, þess vegna þarf það 443 og þess vegna fer það í gegnum milliþjóna sem henda öðrum göngum. Hlustarinn er ekki socket sem VPN-þjónustan opnar fyrir sjálfa sig: SstpSvc skráir hann hjá HTTP-reklinum í kjarnanum, svo portið helst áskilið á meðan þjónustan keyrir. Sú skráning spyr aldrei skírteinisins, sem þýðir að útrunnið nafn, ósamrýmanlegt subject eða ekkert skírteini yfir höfuð skilja 443 eftir upptekið. Bilunin skiptist þá í tvær áttir: höfnuð handshake lenda í System-skrá undir RasSstp, á meðan vefþjónninn getur aðeins tilkynnt að hann hafi ekki getað bundið sig.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

Fyrsta línan skilar PID-inu sem á portið; önnur nefnir þjónustuna á bak við það, og svarið er venjulega HTTP-þjónustan eða RRAS-stakkurinn. Þegar tasklist svarar með sameiginlegu hýsilferli, lestu þjónustudálkinn í stað þess að giska út frá ferlisheitinu.

RasSstp-viðvaranir er aðeins þess virði að lesa eftir það, því þær lýsa handshake sem mistókst og segja ekkert um áskriftina sem olli árekstrinum. VPN-endapunktur sem hafnar hverjum biðlara á portið samt. Meðhöndlaðu skrána sem seinni spurninguna, ekki þá fyrstu.

IIS deilir reklinum, Apache opnar socket

IIS afhendir bindings sín sama kjarnareklinum og SSTP notar, og sá rekull sundurgreinir innkomandi tengingar eftir hýsilsnafni og URL-forskeyti, svo hægt er að biðja báðar þjónusturnar að vilja 443 án þess að önnur þeirra bregðist. Apache og nginx gera hið gagnstæða: þau kalla bind á eigin socket, og stýrikerfið neitar því að heimilisfangið er þegar upptekið. Ekkert í hvorugri uppsetningunni er rangt; munurinn liggur í hvaða API á portið. Þess vegna fellir virkjun VPN einnig eitt vefsvæði á einum hýsil og lætur sams konar vefsvæði á öðrum hýsil ósnortið.

Þessi ósamhverfa ræður lögun viðgerðarinnar. Ef IIS er þegar framdyrnar verður áreksturinn spurning um forskétti, bindings og skírteini. Ef Apache er framdyrnar færist það annaðhvort af 443 eða SSTP-hlustarinn gerir það, og næsti hluti nær yfir báðar hreyfingarnar.

Veldu hvaða þjónusta heldur 443

Port hlustarans býr í einu skráargildi, tugakerfis-DWORD undir Sstpsvc-færibreytulyklinum. Breyttu gildinu, endurræstu Routing and Remote Access og staðfestu út frá hlustunartöflunni að gamla portið sé laust.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

Veldu port sem ekkert annað á hýsilnum vill, og sláðu það inn í tugakerfi: reg add geymir DWORD-ið nákvæmlega eins og það er skrifað, svo gildi sem var hugsað sem sextánundarkerfi lendir sem annað port. Ef fyrirspurnin segir að gildið sé ekki til býr önnur línan það til. Restart-Service RemoteAccess hendir öllum sem eru tengdir, sem er þess virði að skipuleggja. Keyrðu hlustunarprófið aftur eftir það, því úrelt færsla á 443 þýðir að þjónustan hélt gamalli skráningu sinni.

Að færa hlustarann hefur verð sem breytingin á skránni sýnir ekki. Venjulegir SSTP-biðlarar hringja í 443, svo hver biðlarasnið þarf nýja portið, og flæðið hættir að líkjast vefbeiðni fyrir hvað sem er sem skoðar slóðina. Á neti sem þolir aðeins umferð sem lítur út eins og HTTPS fjarlægir það mest af ástæðunni fyrir því að SSTP var valið. Lítill, stýrður biðlarahópur meltrar þetta; opinber eða BYOD-notendahópur ekki.

Hin hreyfingin heldur 443 hjá IIS og meðhöndlar Apache sem bakenda sem milliþjónninn framsendir til. Hún varðveitir sjálfgefið SSTP og skilur eftir einn eiganda portsins, á kostnað framsendra hausa, biðlarafangs sem forritið sér ekki lengur beint og bakenda sem verður að tala það samskiptareglur sem milliþjónninn sendir í raun.

Sannaðu eigandann, skírteinið og handshake í réttri röð

Lokið TCP-tenging sannar að hlustari sé til og ekkert annað, þess vegna getur portskönnun litið heilbrigð út á meðan gangurinn bregst enn. Fjögur stig bregðast á mismunandi vegu, og viðgerð sem beinist að stiginu sem þú braust ekki dýpkar venjulega áreksturinn. Farðu í gegnum þau í röð og stoppaðu þar sem svarið greinist.

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

Fyrsta línan nefnir PID-ið sem heldur 443, og það ætti að vera þjónustan sem þú stilltir rétt í þessu. Önnur listar vélarskírteini með subjectum þeirra, svo nafn sem passar ekki við fangið í biðlarasniðinu stendur strax upp úr. Atburðafyrirspurnin skilar nýlegum SSTP-færslum, og handshake sem nær aldrei PPP-auðkenningu skilur eftir aðra færslu en sú sem auðkennist og er svo hafnað. Síðasta stigið sést aðeins á biðlaranum, þar sem færslan tilkynnir annaðhvort tengt eða nefnir PPP-villuna.

Þegar einn hýsil verður að sinna báðum verkum skaltu velja eiganda 443 viljandi og skrifa valið niður, því annars enduruppgötvar næsta manneskja sem virkjar eiginleika þennan árekstur. Að skipta hlutverkunum er áfram hreinna svar: opinber vefþjónn og endapunktur fyrir fjartengingu bera aðskildar lotur lagfæringa, skírteina og endurræsinga, og þær lotur mætast á eigin tímaáætlun. Hvort sem er, skildu hlustunarprófið, skráarslóðina og valda portið eftir í afhendingarathugasemdinni.