SSTP je zasedel vrata 443: zakaj se Apache ne zažene

Apache preneha odgovarjati na 443 tisto popoldne, ko nekdo vklopi dohodne povezave VPN, in njegov dnevnik napak krivi bind namesto rezervacije za njim. Windows Routing and Remote Access takrat vklopi SSTP, poslušalec SSTP pa zahteva TCP 443 prek sklada HTTP, preden se preveri kateri koli odjemalec. Zahteva velja tudi, ko manjka potrdilo, je ime napačno ali je vsak handshake zavrnjen, zato VPN, v katerega nihče ne more vstopiti, še vedno zaseda vrata. Najprej preberite tabelo poslušanja; PID, ki ima 443, odloči, katera od spodnjih popravkov je sploh odprta za vas.

Rezervacija preživi pokvarjeno potrdilo

SSTP ovije PPP v sejo TLS, zato potrebuje 443 in zato gre skozi posrednike, ki zavržejo druge tunele. Poslušalec ni vtičnica, ki bi jo storitev VPN odprla zase: SstpSvc ga registrira pri gonilniku HTTP jedra, zato vrata ostanejo rezervirana, dokler storitev teče. Ta registracija nikoli ne vpraša potrdila, kar pomeni, da poteklo ime, neustrezen subject ali nobeno potrdilo pustijo 443 zasedena. Napake se nato razdelijo v dve smeri: zavrnjeni handshaki pristanejo v dnevniku System pod RasSstp, medtem ko lahko spletni strežnik le sporoči, da se ni mogel vezati.

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

Prva vrstica vrne lastniški PID; druga poimenuje storitev za njim, odgovor pa je običajno storitev HTTP ali sklad RRAS. Ko tasklist odgovori s skupnim gostiteljskim procesom, berite stolpec storitve, namesto da ugibate iz imena procesa.

Opozorila RasSstp so vredna branja šele zatem, ker opisujejo neuspel handshake in ne povedo ničesar o rezervaciji, ki je povzročila trčenje. Končna točka VPN, ki zavrne vsakega odjemalca, še vedno ima vrata. Dnevnik obravnavajte kot drugo vprašanje, ne prvo.

IIS deli gonilnik, Apache odpre vtičnico

IIS preda svoje bindings istemu gonilniku jedra, ki ga uporablja SSTP, in ta gonilnik razdeli dohodne povezave po imenu gostitelja in predponi URL, zato lahko obema storitvama rečemo, naj hočeta 443, ne da bi katera koli odpovedala. Apache in nginx storita nasprotno: kličeta bind na svoji vtičnici in operacijski sistem zavrne, ker je naslov že zaseden. V nobeni od konfiguracij ni nič napačno; razlika je v tem, kateri API ima vrata. Zato vklop VPN podre eno mesto na enem gostitelju in pusti identično mesto na drugem gostitelju nedotaknjeno.

Ta asimetrija odloči obliko popravila. Če je IIS že vhodna vrata, trčenje postane vprašanje predpon, bindings in potrdil. Če so vhodna vrata Apache, se bodisi ta umakne s 443 bodisi poslušalec SSTP, in naslednji razdelek pokriva obe potezi.

Izberite, katera storitev obdrži 443

Vrata poslušalca živijo v eni sami vrednosti registra, decimalnem DWORD pod ključem parametrov Sstpsvc. Spremenite vrednost, znova zaženite Routing and Remote Access in iz tabele poslušanja potrdite, da so stara vrata prosta.

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

Izberite vrata, ki jih nič drugega na gostitelju noče, in jih vnesite decimalno: reg add shrani DWORD natanko tako, kot je zapisan, zato vrednost, mišljena kot šestnajstiška, pristane kot druga vrata. Če poizvedba pravi, da vrednost ne obstaja, jo druga vrstica ustvari. Restart-Service RemoteAccess izvrže vse, ki so povezani, kar je vredno načrtovati. Nato znova zaženite preverjanje poslušanja, ker zastarel vnos na 443 pomeni, da je storitev obdržala staro registracijo.

Premik poslušalca ima ceno, ki je sprememba registra ne pokaže. Običajni odjemalci SSTP kličejo 443, zato vsak profil odjemalca potrebuje nova vrata in tok preneha spominjati na spletno zahtevo za vse, kar pregleduje pot. V omrežju, ki dopušča le promet, ki je videti kot HTTPS, to odstrani večino razloga, zakaj je bil izbran SSTP. Majhna, vodena populacija odjemalcev to absorbira; javna ali BYOD uporabniška baza ne.

Druga poteza obdrži 443 pri IIS in Apache obravnava kot backend, kamor posrednik posreduje. Ohrani privzeto vrednost SSTP in pusti enega lastnika vrat, za ceno posredovanih glav, naslova odjemalca, ki ga aplikacija ne vidi več neposredno, in backenda, ki mora govoriti protokol, ki ga posrednik dejansko pošilja.

Dokažite lastnika, potrdilo in handshake po vrsti

Dokončana povezava TCP dokaže, da poslušalec obstaja, in nič drugega, zato je lahko skeniranje vrat videti zdravo, medtem ko tunel še vedno odpoveduje. Štiri stopnje odpovedo na različne načine, popravilo, usmerjeno v stopnjo, ki je niste pokvarili, pa običajno poglobi trčenje. Predelajte jih po vrsti in ustavite se tam, kjer se odgovor razdeli.

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

Prva vrstica poimenuje PID, ki drži 443, in to bi morala biti storitev, ki ste jo pravkar nastavili. Druga našteje potrdila stroja z njihovimi subject, zato ime, ki se ne ujema z naslovom v profilu odjemalca, takoj pade v oči. Poizvedba dogodkov vrne nedavne zapise SSTP, handshake, ki nikoli ne doseže preverjanja PPP, pa pusti drugačen zapis kot tisti, ki se preveri in nato zavrne. Zadnja stopnja je vidna le pri odjemalcu, kjer vnos poroča povezano ali poimenuje napako PPP.

Ko mora en gostitelj opraviti obe deli, zavestno izberite lastnika 443 in izbiro zapišite, ker bo sicer naslednja oseba, ki vklopi neko funkcijo, to trčenje znova odkrila. Ločevanje vlog ostaja čistejši odgovor: javni spletni strežnik in končna točka oddaljenega dostopa nosita ločene cikle popravkov, potrdil in ponovnih zagonov, ti cikli pa se srečujejo po svojem urniku. V vsakem primeru v predajni zapisek pustite preverjanje poslušanja, pot v registru in izbrana vrata.