SSTP naam poarte 443: wêrom’t Apache net start

Apache hâldt op mei antwurdzjen op 443 de middei dat immen ynkommende VPN-ferbiningen ynskeakelt, en syn flogboek fan flaters beskuldigt de bind ynstee fan de reservearring derachter. Windows Routing and Remote Access skeakelt SSTP op dat stuit yn, en de SSTP-lústerder easket TCP 443 fia de HTTP-stapel foardat hokker klant dan ek autentisearret. De eask bliuwt jilde sels as it sertifikaat ûntbrekt, de namme ferkeard is of elke handshake wegere wurdt, dat in VPN dêr’t nimmen yn kin, bliuwt dochs op de poarte. Lês earst de lústertabel; de PID dy’t 443 hat, beslút hokker fan ’e oplossingen hjirûnder foar dy iepen is.

De reservearring oerlibbet in brutsen sertifikaat

SSTP pakket PPP yn in TLS-sesje, dêrom hat it 443 nedich en dêrom giet it troch proxies dy’t oare tunnels ferdwine litte. De lústerder is gjin socket dy’t de VPN-tsjinst sels iepenet: SstpSvc registrearret him by de HTTP-stjoerder fan ’e kearn, dat de poarte bliuwt reservearre salang’t de tsjinst rint. Dy registraasje rieplachtet nea it sertifikaat, wat betsjut dat in ferfallen namme, in net kloppend subject of hielendal gjin sertifikaat 443 beset lit. Flaters ferdiele har dan yn twa rjochtingen: wegere handshakes komme yn it System-looch ûnder RasSstp, wylst de webserver allinnich melde kin dat er net bine koe.

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

De earste rigel jout de besittende PID; de twadde neamt de tsjinst dêrefter, en it antwurd is meastentiids de HTTP-tsjinst of de RRAS-stapel. As tasklist antwurdet mei in dielde hostproses, lês dan de tsjinstekolom ynstee fan te rieden út de prosesnamme.

RasSstp-warskôgings binne earst dêrnei it lêzen wurdich, want se beskriuwe in handshake dy’t mislearre en sizze neat oer de reservearring dy’t de botsing feroarsake. In VPN-einpunt dat elke klant wegeret, hat noch altyd de poarte. Behannelje it looch as de twadde fraach, net de earste.

IIS dielt de stjoerder, Apache iepenet in socket

IIS jout syn bindings oan deselde kearnstjoerder dy’t SSTP brûkt, en dy stjoerder skiedt ynkommende ferbiningen op hostnamme en URL-foarheaksel, dat fan beide tsjinsten frege wurde kin om 443 te wollen sûnder dat ien fan beide mist. Apache en nginx dogge it tsjinoerstelde: se roppe bind oan op har eigen socket, en it bestjoeringssysteem wegeret om’t it adres al beset is. Der is neat mis yn ien fan beide konfiguraasjes; it ferskil sit yn hokker API de poarte hat. Dêrom ek makket it ynskeakeljen fan ’e VPN ien side op ien host del en lit in identike side op in oare host ûnoantaast.

Dizze asymmetry beslút de foarm fan ’e reparaasje. As IIS al de foardoar is, wurdt de botsing in fraach oer foarheaksls, bindings en sertifikaten. As Apache de foardoar is, dan ferpleatst it him fan 443 ôf of docht de SSTP-lústerder dat, en de folgjende seksje behannelet beide bewegingen.

Kies hokker tsjinst 443 hâldt

De lústerpoarte wennet yn ien registerwearde, in desimale DWORD ûnder de parameterskaai fan Sstpsvc. Feroarje de wearde, start Routing and Remote Access opnij, en befestigje út ’e lústertabel dat de âlde poarte frij is.

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

Kies in poarte dy’t neat oars op ’e host wol, en typ dy yn desimaal: reg add bewarret de DWORD krekt sa’t er skreaun is, dat in wearde dy’t as heksadesimaal bedoeld is, lânet as in oare poarte. As it fersyk seit dat de wearde net bestiet, makket de twadde rigel dy oan. Restart-Service RemoteAccess smyt elkenien dy’t ferbûn is derút, wat it plansjen wurdich is. Rin dêrnei de lústerkontrôle wer, want in ferâldere ynfier op 443 betsjut dat de tsjinst syn âlde registraasje hâlden hat.

It ferpleatsen fan de lústerder hat in priis dy’t de registerwiziging net sjen lit. Gewoane SSTP-klanten kieze 443, dat elk klantprofyl hat de nije poarte nedich, en de stream hâldt op op in webfersyk te lykjen foar alles wat it paad ûndersiket. Op in netwurk dat allinnich ferkear tolerearret dat op HTTPS liket, nimt dat it measte fan ’e reden wei wêrom’t SSTP keazen waard. In lytse, behearde klantpopulaasje absorbearret dit; in iepenbiere of BYOD-brûkersbasis net.

De oare beweging hâldt 443 by IIS en behannelet Apache as in backend dêr’t de proxy nei trochstjoert. It behâldt de SSTP-standert en lit ien eigner foar de poarte, tsjin de priis fan trochstjoerde kopteksten, in klantadres dat de applikaasje net mear direkt sjocht, en in backend dy’t it protokol prate moat dat de proxy echt stjoert.

Bewiis de eigner, it sertifikaat en de handshake yn oarder

In foltôge TCP-ferbining bewiist dat der in lústerder is en neat oars, dêrom kin in poartescan sûn lykje wylst de tunnel noch mist. De fjouwer fazen mislearje op ferskillende manieren, en in reparaasje rjochte op ’e faze dy’tsto net brutsen hast, ferdjippet meastentiids de botsing. Wurkkje se yn oarder troch en stop dêr’t it antwurd útinoar giet.

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

De earste rigel neamt de PID dy’t 443 hâldt, en dat heart de tsjinst te wêzen dy’tsto krekt konfigurearre hast. De twadde listet masjinesertifikaten mei har subjects op, dat in namme dy’t net by it adres yn it klantprofyl past, falt daliks op. It barrenfersyk jout resinte SSTP-registraasjes werom, en in handshake dy’t nea de PPP-autentikaasje berikt, lit in oare registraasje efter as ien dy’t autentisearret en dan wegere wurdt. De lêste faze is allinnich op ’e klant te sjen, dêr’t de ynfier of ferbûn meldt of de PPP-flater neamt.

As ien host beide taken dwaan moat, kies dan bewust de eigner fan 443 en skriuw de kar op, want oars ûntdekt de folgjende persoan dy’t in funksje ynskeakelt dizze botsing wer. It skieden fan ’e rollen bliuwt it skjinste antwurd: in iepenbiere webserver en in einpunt foar remote tagong drage aparte syklussen foar patches, sertifikaten en opnij starten, en dy syklussen treffe elkoar neffens har eigen skema. Lit yn alle gefallen de lústerkontrôle, it registerpaad en de keazen poarte yn ’e oerdrachtsnotysje.