Kinuha ng SSTP ang port 443: bakit hindi nagsisimula ang Apache

Humihinto ang Apache sa pagsagot sa 443 sa hapong iyon na may nagpapagana ng mga papasok na koneksyon sa VPN, at ang log ng mga error nito ay sinisisi ang bind sa halip na ang reserbasyon sa likod nito. Binubuksan ng Windows Routing and Remote Access ang SSTP sa sandaling iyon, at inaangkin ng listener ng SSTP ang TCP 443 sa pamamagitan ng HTTP stack bago pa ma-authenticate ang sinumang kliyente. Nananatili ang pag-angkin kahit na wala ang sertipiko, mali ang pangalan, o tinatanggihan ang bawat handshake, kaya ang VPN na walang makapasok ay okupado pa rin ang port. Basahin muna ang talahanayan ng pakikinig; ang PID na may-ari ng 443 ang magpapasya kung alin sa mga pag-aayos sa ibaba ang bukas sa iyo.

Nakaligtas ang reserbasyon sa sirang sertipiko

Binabalot ng SSTP ang PPP sa isang sesyon ng TLS, kaya kailangan nito ang 443 at kaya dumadaan ito sa mga proxy na nagtatapon ng ibang tunnel. Ang listener ay hindi socket na binubuksan ng serbisyo ng VPN para sa sarili nito: inirerehistro ito ng SstpSvc sa HTTP driver ng kernel, kaya nananatiling nakareserba ang port hangga’t tumatakbo ang serbisyo. Hindi kailanman tinatanong ng rehistrong iyon ang sertipiko, na nangangahulugang ang nag-expire na pangalan, hindi tugmang subject, o walang sertipiko ay nag-iiwan ng 443 na okupado. Pagkatapos ay nahahati ang mga pagkabigo sa dalawang direksyon: ang mga tinanggihang handshake ay napupunta sa log ng System sa ilalim ng RasSstp, habang ang web server ay makapag-uulat lamang na hindi ito nakapag-bind.

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

Ibinabalik ng unang linya ang PID na may-ari; pinangalanan ng ikalawa ang serbisyo sa likod nito, at ang sagot ay karaniwang serbisyo ng HTTP o ang stack ng RRAS. Kapag tasklist ay sumagot gamit ang shared host process, basahin ang kolum ng serbisyo sa halip na manghula mula sa pangalan ng proseso.

Ang mga babala ng RasSstp ay sulit basahin pagkatapos lamang niyon, dahil inilalarawan nila ang isang handshake na nabigo at wala silang sinasabi tungkol sa reserbasyon na nagdulot ng banggaan. Ang endpoint ng VPN na tumatanggi sa bawat kliyente ay may-ari pa rin ng port. Tratuhin ang log bilang ikalawang tanong, hindi ang una.

Ibinabahagi ng IIS ang driver, nagbubukas ng socket ang Apache

Ipinapasa ng IIS ang mga bindings nito sa parehong kernel driver na ginagamit ng SSTP, at hinihiwalay ng driver na iyon ang mga papasok na koneksyon ayon sa pangalan ng host at prefix ng URL, kaya maaaring hilingin sa dalawang serbisyo na gustuhin ang 443 nang walang nabibigong isa. Kabaligtaran ang ginagawa ng Apache at nginx: tumatawag sila ng bind sa sarili nilang socket, at tumatanggi ang operating system dahil okupado na ang address. Wala namang mali sa alinman sa mga configuration; ang pagkakaiba ay nasa kung aling API ang may-ari ng port. Kaya nga ang pagpapagana ng VPN ay nagpapatumba ng isang site sa isang host at iniiwan ang magkaparehong site sa ibang host na hindi ginalaw.

Ang kawalan ng simetrya na ito ang nagtatakda ng hugis ng pag-aayos. Kung ang IIS ang pintuan sa harap, ang banggaan ay nagiging usapin ng mga prefix, bindings, at sertipiko. Kung ang Apache ang pintuan sa harap, maaaring ito ang lumipat palayo sa 443 o ang listener ng SSTP, at saklaw ng susunod na seksyon ang dalawang galaw.

Piliin kung aling serbisyo ang mananatili sa 443

Nakatira ang port ng listener sa isang value ng registry, isang decimal na DWORD sa ilalim ng parameter key ng Sstpsvc. Baguhin ang value, i-restart ang Routing and Remote Access, at kumpirmahin mula sa talahanayan ng pakikinig na libre na ang dating port.

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

Pumili ng port na walang ibang gustong gamitin sa host, at i-type ito sa decimal: reg add inilalagay ang DWORD nang eksakto ayon sa pagkakasulat, kaya ang value na inisip na hexadecimal ay napupunta bilang ibang port. Kung sinasabi ng query na wala ang value, nililikha ito ng ikalawang linya. Restart-Service RemoteAccess pinapatalsik ang lahat ng konektado, na sulit iiskedyul. Patakbuhin muli ang pagsusuri ng pakikinig pagkatapos, dahil ang lumang entry sa 443 ay nangangahulugang pinanatili ng serbisyo ang dating rehistro nito.

May presyo ang paglipat ng listener na hindi ipinapakita ng pagbabago sa registry. Ang mga ordinaryong kliyente ng SSTP ay dumidiyal sa 443, kaya kailangan ng bawat profile ng kliyente ang bagong port, at hindi na magmumukhang web request ang daloy para sa anumang sumusuri sa landas. Sa network na tumatanggap lamang ng trapikong mukhang HTTPS, inaalis niyon ang malaking bahagi ng dahilan kung bakit pinili ang SSTP. Kayang lunukin ito ng maliit at pinamamahalaang populasyon ng kliyente; hindi kaya ng pampubliko o BYOD na base ng gumagamit.

Pinananatili ng kabilang galaw ang 443 sa IIS at itinuturing ang Apache na backend na pinapasa ng proxy. Pinapanatili nito ang default ng SSTP at nag-iiwan ng isang may-ari ng port, kapalit ng mga ipinasa na header, address ng kliyente na hindi na direktang nakikita ng aplikasyon, at backend na dapat magsalita ng protokol na talagang ipinapadala ng proxy.

Patunayan ang may-ari, ang sertipiko, at ang handshake sa pagkakasunod-sunod

Ang natapos na koneksyon sa TCP ay nagpapatunay na may listener at wala nang iba, kaya maaaring magmukhang malusog ang port scan habang bumabagsak pa rin ang tunnel. Iba-iba ang pagbagsak ng apat na yugto, at ang pag-aayos na nakatuon sa yugtong hindi mo sinira ay kadalasang nagpapalalim ng banggaan. Isa-isahin ang mga ito sa pagkakasunod-sunod at huminto kung saan naghihiwalay ang sagot.

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

Pinangalanan ng unang linya ang PID na may hawak ng 443, at dapat itong ang serbisyong kababago mong na-configure. Inililista ng ikalawa ang mga sertipiko ng makina kasama ang kanilang subjects, kaya ang pangalang hindi tumutugma sa address sa profile ng kliyente ay agad na namumukod. Ibinabalik ng query ng mga event ang mga sariwang rekord ng SSTP, at ang handshake na hindi umabot sa authentication ng PPP ay nag-iiwan ng ibang rekord kaysa sa na-authenticate at pagkatapos ay tinanggihan. Ang huling yugto ay makikita lamang sa kliyente, kung saan ang entry ay nag-uulat ng konektado o pinangalanan ang error ng PPP.

Kapag kailangang gawin ng isang host ang dalawang trabaho, sadyang piliin ang may-ari ng 443 at isulat ang pinili, dahil kung hindi ay muling matutuklasan ng susunod na taong magpapagana ng anumang feature ang banggaang ito. Ang paghihiwalay ng mga tungkulin ang nananatiling pinakamalinis na sagot: ang pampublikong web server at endpoint ng remote access ay may hiwalay na siklo ng patch, sertipiko, at restart, at nagtatagpo ang mga siklong iyon ayon sa sarili nilang iskedyul. Anuman ang piliin, iwanan ang pagsusuri ng pakikinig, ang landas ng registry, at ang piniling port sa tala ng paghahatid.