SSTP mori portin 443: pse Apache nuk niset
Faqja që dështon nuk është ajo që mban 443. Windows SSTP e rezervon portin përmes stivit HTTP: zhvendosni dëgjuesin, vendosni IIS përpara ose zhvendosni faqen.
Apache ndalon së përgjigjuri në 443 atë pasdite kur dikush aktivizon lidhjet hyrëse VPN, dhe regjistri i gabimeve fajëson bind në vend të rezervimit pas tij. Windows Routing and Remote Access aktivizon SSTP në atë moment, dhe dëgjuesi SSTP pretendon TCP 443 përmes stivit HTTP para se të autentifikohet ndonjë klient. Pretendimi mbetet në fuqi edhe kur mungon certifikata, emri është i gabuar ose çdo handshake refuzohet, kështu që një VPN ku askush nuk mund të hyjë vazhdon të zërë portin. Lexoni së pari tabelën e dëgjimit; PID-i që zotëron 443 vendos se cila nga rregullimet më poshtë është fare e hapur për ju.
Rezervimi i mbijeton një certifikate të thyer
SSTP e mbështjell PPP-në në një sesion TLS, prandaj i duhet 443 dhe prandaj kalon nëpër proxy që hedhin poshtë tunele të tjera. Dëgjuesi nuk është një socket që shërbimi VPN e hap për vete: SstpSvc e regjistron te drejtuesi HTTP i kernelit, kështu që porti mbetet i rezervuar sa kohë shërbimi funksionon. Ai regjistrim nuk e konsulton kurrë certifikatën, që do të thotë se një emër i skaduar, një subject që nuk përputhet ose asnjë certifikatë e lënë 443 të zënë. Dështimet pastaj ndahen në dy drejtime: handshake-t e refuzuar përfundojnë në regjistrin System nën RasSstp, ndërsa serveri web mund vetëm të raportojë se nuk arriti të bëjë bind.
netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"
Rreshti i parë kthen PID-in pronar; i dyti emërton shërbimin pas tij, dhe përgjigjja zakonisht është shërbimi HTTP ose stivi RRAS. Kur tasklist përgjigjet me një proces hosti të përbashkët, lexoni kolonën e shërbimit në vend që të hamendësoni nga emri i procesit.
Paralajmërimet e RasSstp ia vlen t’i lexosh vetëm pas kësaj, sepse përshkruajnë një handshake që dështoi dhe nuk thonë asgjë për rezervimin që shkaktoi përplasjen. Një pikë fundore VPN që refuzon çdo klient e zotëron portin gjithsesi. Trajtojeni regjistrin si pyetjen e dytë, jo të parën.
IIS ndan drejtuesin, Apache hap një socket
IIS i dorëzon bindings e tij të njëjtit drejtues kerneli që përdor SSTP, dhe ai drejtues i ndan lidhjet hyrëse sipas emrit të hostit dhe prefiksit URL, kështu që të dy shërbimeve mund t’u kërkohet të duan 443 pa dështuar asnjëri. Apache dhe nginx bëjnë të kundërtën: thërrasin bind në socketin e tyre, dhe sistemi operativ refuzon sepse adresa është zënë tashmë. Në asnjërën nga konfigurimet nuk ka asgjë të gabuar; ndryshimi qëndron në cila API e zotëron portin. Kjo është arsyeja pse aktivizimi i VPN rrëzon një faqe në një host dhe lë të paprekur një faqe identike në një host tjetër.
Kjo asimetri vendos formën e riparimit. Nëse IIS është tashmë dera e përparme, përplasja bëhet çështje prefiksesh, bindings dhe certifikatash. Nëse Apache është dera e përparme, ose ai largohet nga 443 ose e bën dëgjuesi SSTP, dhe seksioni tjetër mbulon të dyja lëvizjet.
Zgjidhni cili shërbim e mban 443
Porti i dëgjuesit jeton në një vlerë të vetme regjistri, një DWORD dhjetore nën çelësin e parametrave të Sstpsvc. Ndryshoni vlerën, rinisni Routing and Remote Access dhe konfirmoni nga tabela e dëgjimit se porti i vjetër është i lirë.
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
Zgjidhni një port që asgjë tjetër në host nuk e dëshiron, dhe shkruajeni në dhjetore: reg add e ruan DWORD-in saktësisht ashtu siç është shkruar, kështu që një vlerë e menduar si gjashtëmbëdhjetore përfundon si një port tjetër. Nëse pyetja thotë se vlera nuk ekziston, rreshti i dytë e krijon atë. Restart-Service RemoteAccess hedh jashtë të gjithë ata që janë të lidhur, gjë që ia vlen të planifikohet. Më pas ekzekutoni përsëri kontrollin e dëgjimit, sepse një zë i vjetëruar në 443 do të thotë që shërbimi mbajti regjistrimin e vjetër.
Zhvendosja e dëgjuesit ka një çmim që ndryshimi i regjistrit nuk e tregon. Klientët e zakonshëm SSTP thirrin 443, prandaj çdo profil klienti ka nevojë për portin e ri, dhe rrjedha nuk i ngjan më një kërkese web për çdo gjë që inspekton shtegun. Në një rrjet që toleron vetëm trafik që duket si HTTPS, kjo heq pjesën më të madhe të arsyes pse u zgjodh SSTP. Një popullsi e vogël dhe e menaxhuar klientësh e absorbon këtë; një bazë përdoruesish publike ose BYOD jo.
Lëvizja tjetër e mban 443 te IIS dhe e trajton Apache si një backend ku proxy përçon. Ruan parazgjedhjen e SSTP dhe lë një pronar për portin, me koston e kokave të përçuar, një adresë klienti që aplikacioni nuk e sheh më drejtpërdrejt dhe një backend që duhet të flasë protokollin që proxy dërgon në të vërtetë.
Vërtetoni pronarin, certifikatën dhe handshake-un me radhë
Një lidhje TCP e përfunduar vërteton se ekziston një dëgjues dhe asgjë tjetër, prandaj një skanim portesh mund të duket i shëndetshëm ndërsa tuneli vazhdon të dështojë. Katër fazat dështojnë në mënyra të ndryshme, dhe një riparim i drejtuar nga faza që nuk e theve ju e thellon zakonisht përplasjen. Punojini me radhë dhe ndaloni aty ku përgjigjja ndahet.
netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20
Rreshti i parë emërton PID-in që mban 443, dhe ai duhet të jetë shërbimi që sapo konfiguruat. I dyti liston certifikatat e makinës me subjects e tyre, kështu që një emër që nuk përputhet me adresën në profilin e klientit bie menjëherë në sy. Pyetja e ngjarjeve kthen regjistrime të fundit SSTP, dhe një handshake që nuk arrin kurrë autentifikimin PPP lë një regjistrim tjetër nga ai që autentifikohet dhe pastaj refuzohet. Faza e fundit është e dukshme vetëm te klienti, ku zëri ose raporton i lidhur ose emërton gabimin PPP.
Kur një host duhet të bëjë të dyja punët, zgjidhni me qëllim pronarin e 443 dhe shkruajeni zgjedhjen, sepse përndryshe personi tjetër që aktivizon një veçori do ta rizbulojë këtë përplasje. Ndarja e roleve mbetet përgjigjja më e pastër: një server web publik dhe një pikë fundore për akses në distancë mbajnë cikle të ndara patch-esh, certifikatash dhe rinisjesh, dhe ato cikle takohen sipas orarit të tyre. Në çdo rast, lini kontrollin e dëgjimit, shtegun e regjistrit dhe portin e zgjedhur në shënimin e dorëzimit.