SSTP het poort 443 ingeneem: waarom Apache nie wil begin nie

Apache hou op om op 443 te antwoord die middag wanneer iemand inkomende VPN-verbindings aktiveer, en sy foutlog blameer die bind eerder as die reservering daaronder. Windows Routing and Remote Access skakel SSTP op daardie oomblik aan, en die SSTP-luisteraar eis TCP 443 deur die HTTP-stapel voordat enige kliënt geverifieer word. Die eis staan selfs wanneer die sertifikaat ontbreek, die naam verkeerd is of elke handdruk verwerp word, so 'n VPN waarby niemand kan aanmeld nie, bly steeds op die poort. Lees eers die luistertabel; die PID wat 443 besit, bepaal watter van die regstellings hieronder selfs vir jou oop is.

Die reservering oorleef 'n gebreekte sertifikaat

SSTP verpak PPP in 'n TLS-sessie, daarom het dit 443 nodig en daarom reis dit deur proxies wat ander tonnels verwerp. Die luisteraar is nie 'n sokkel wat die VPN-diens self oopmaak nie: SstpSvc registreer dit by die kernel HTTP-drywer, so die poort bly gereserveer solank die diens loop. Daardie registrasie raadpleeg nooit die sertifikaat nie, wat beteken 'n vervalde naam, 'n verkeerde onderwerp of glad geen sertifikaat laat 443 beset. Foute verdeel dan in twee rigtings: verwerpte handdrukke beland in die System-log onder RasSstp, terwyl die webbediener net kan rapporteer dat dit nie kon bind nie.

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

Die eerste reël gee die besittende PID; die tweede noem die diens daaronder, en die antwoord is gewoonlik die HTTP-diens of die RRAS-stapel. Wanneer tasklist met 'n gedeelde gasheerproses antwoord, lees die dienskolom eerder as om uit die prosesnaam te raai.

RasSstp-waarskuwings is eers daarna werd om te lees, want hulle beskryf 'n handdruk wat misluk het en sê niks oor die reservering wat die botsing veroorsaak het nie. 'n VPN-eindpunt wat elke kliënt verwerp, besit steeds die poort. Behandel die log as die tweede vraag, nie die eerste nie.

IIS deel die drywer, Apache maak 'n sokkel oop

IIS gee sy bindings aan dieselfde kernel-drywer wat SSTP gebruik, en daardie drywer demultiplekseer inkomende verbindings volgens gasheernaam en URL-voorvoegsel, so albei dienste kan gevra word om 443 te wil hê sonder dat enige van hulle misluk. Apache en nginx doen die teenoorgestelde: hulle roep bind op hul eie sokkel, en die bedryfstelsel weier omdat die adres reeds beset is. Niks in enige van die twee konfigurasies is verkeerd nie; die verskil lê in watter API die poort besit. Dit is ook waarom die aktivering van die VPN een werf op een gasheer platlê en 'n identiese werf op 'n ander gasheer onaangeraak laat.

Hierdie asimmetrie bepaal die vorm van die herstel. As IIS reeds die voordeur is, word die botsing 'n vraag oor voorvoegsels, bindings en sertifikate. As Apache die voordeur is, skuif óf dit van 443 af óf die SSTP-luisteraar, en die volgende afdeling dek albei skuiwe.

Kies watter diens 443 hou

Die luisterpoort woon in 'n enkele registerwaarde, 'n desimale DWORD onder die Sstpsvc-parametersleutel. Verander die waarde, herbegin Routing and Remote Access, en bevestig uit die luistertabel dat die ou poort vry 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 'n poort wat niks anders op die gasheer wil hê nie, en tik dit in desimaal: reg add stoor die DWORD presies soos geskryf, so 'n waarde wat as heksadesimaal bedoel is, beland as 'n ander poort. As die navraag sê die waarde bestaan nie, skep die tweede reël dit. Restart-Service RemoteAccess laat almal wat gekoppel is, val, wat die moeite werd is om te beplan. Voer daarna die luisterkontrole weer uit, want 'n verouderde inskrywing op 443 beteken die diens het sy ou registrasie behou.

Om die luisteraar te skuif, het 'n prys wat die registerwysiging nie wys nie. Gewone SSTP-kliënte skakel 443, so elke kliëntprofiel het die nuwe poort nodig, en die vloei hou op om soos 'n webversoek te lyk vir enigiets wat die pad ondersoek. Op 'n netwerk wat net verkeer duld wat soos HTTPS lyk, verwyder dit die meeste van die rede waarom SSTP gekies is. 'n Klein, bestuurde kliëntepopulasie absorbeer dit; 'n openbare of BYOD-gebruikersbasis nie.

Die ander skuif hou 443 by IIS en behandel Apache as 'n backend waarna die proxy aanstuur. Dit behou die SSTP-verstek en laat een eienaar vir die poort, teen die koste van oorgedraagde opskrifte, 'n kliëntadres wat die toepassing nie meer direk sien nie, en 'n backend wat die protokol moet praat wat die proxy werklik stuur.

Bewys die eienaar, die sertifikaat en die handdruk in volgorde

'n Voltooide TCP-verbinding bewys dat daar 'n luisteraar is en niks anders nie, daarom kan 'n poortskandering gesond lyk terwyl die tonnel steeds misluk. Die vier fases misluk op verskillende maniere, en 'n herstel wat op die fase gerig is wat jy nie gebreek het nie, verdiep gewoonlik die botsing. Werk hulle in volgorde deur en stop waar die antwoord afwyk.

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

Die eerste reël noem die PID wat 443 hou, en dit behoort die diens te wees wat jy pas opgestel het. Die tweede lys masjien-sertifikate met hul onderwerpe, so 'n naam wat nie by die adres in die kliëntprofiel pas nie, val dadelik op. Die gebeurtenisnavraag gee onlangse SSTP-rekords terug, en 'n handdruk wat nooit PPP-verifikasie bereik nie, laat 'n ander rekord as een wat verifieer en dan geweier word. Die laaste fase is net op die kliënt sigbaar, waar die inskrywing óf verbind rapporteer óf die PPP-fout noem.

Wanneer een gasheer albei take moet doen, kies die eienaar van 443 doelbewus en skryf die keuse neer, want die volgende persoon wat 'n funksie aktiveer, sal andersins hierdie botsing weer ontdek. Om die rolle te skei bly die skoner antwoord: 'n openbare webbediener en 'n afstandtoegang-eindpunt het aparte siklusse vir pleisters, sertifikate en herbegin, en daardie siklusse ontmoet op hul eie skedule. Laat in elk geval die luisterkontrole, die registerpad en die gekose poort in die oorhandigingsnota.