SSTP заняў порт 443: чаму Apache не запускаецца

Apache перастае адказваць на 443 у той дзень, калі хтосьці ўключае ўваходныя VPN-злучэнні, а яго журнал памылак вінаваціць bind, а не рэзерваванне за ім. Windows Routing and Remote Access уключае SSTP у гэты момант, і слухач SSTP заяўляе TCP 443 праз стек HTTP яшчэ да таго, як любы кліент пройдзе аўтэнтыфікацыю. Заяўка застаецца ў сіле нават пры адсутнасці сертыфіката, няправільным імені ці адхіленні кожнага рукапаціскання, таму VPN, у які ніхто не можа ўвайсці, усё роўна займае порт. Спачатку прачытайце табліцу праслухоўвання; PID, які валодае 443, вырашае, якое з пададзеных ніжэй выпраўленняў вам наогул даступнае.

Рэзерваванне перажывае зламаны сертыфікат

SSTP загортвае PPP у сеанс TLS, таму яму патрэбны 443 і таму ён праходзіць праз проксі, якія адкідаюць іншыя тунэлі. Слухач — не сокет, які служба VPN адкрывае для сябе: SstpSvc рэгіструе яго ў драйверы HTTP ядра, таму порт застаецца зарэзерваваным, пакуль служба працуе. Гэтая рэгістрацыя ніколі не звяртаецца да сертыфіката, гэта значыць пратэрмінаванае імя, неадпаведны subject або поўная адсутнасць сертыфіката пакідаюць 443 занятым. Далей збоі дзеляцца на два кірункі: адхіленыя рукапацісканні трапляюць у журнал System пад RasSstp, а вэб-сервер можа толькі паведаміць, што не здолеў прывязацца.

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

Першы радок вяртае ўласны PID; другі называе службу за ім, і адказам звычайна ёсць служба HTTP або стек RRAS. Калі tasklist адказвае агульным працэсам вузла, чытайце слупок службы, а не ўгадвайце па назве працэсу.

Папярэджанні RasSstp варта чытаць толькі пасля гэтага, бо яны апісваюць няўдалае рукапацісканне і нічога не кажуць пра рэзерваванне, што выклікала канфлікт. Канчатковы пункт VPN, які адхіляе кожнага кліента, усё роўна валодае портам. Успрымайце журнал як другое пытанне, а не першае.

IIS дзеліць драйвер, Apache адкрывае сокет

IIS перадае свае bindings таму ж драйверу ядра, які выкарыстоўвае SSTP, і гэты драйвер раздзяляе ўваходныя злучэнні паводле імені вузла і прэфікса URL, таму абедзвюм службам можна загадаць хацець 443, і ні адна з іх не адмовіць. Apache і nginx робяць наадварот: выклікаюць bind на ўласным сокеце, і аперацыйная сістэма адмаўляе, бо адрас ужо заняты. Ні ў адной з канфігурацый няма нічога памылковага; розніца ў тым, які API валодае портам. Менавіта таму ўключэнне VPN звальвае адзін сайт на адным вузле і пакідае некранутым ідэнтычны сайт на іншым.

Гэтая асіметрыя вызначае форму выпраўлення. Калі IIS ужо ёсць уваходнымі дзвярыма, канфлікт становіцца пытаннем прэфіксаў, bindings і сертыфікатаў. Калі ўваходныя дзверы — Apache, то або ён сыходзіць з 443, або гэта робіць слухач SSTP, і наступны раздзел ахоплівае абодва крокі.

Выберыце, якая служба збярэжэ 443

Порт слухача жыве ў адзіным значэнні рэестра — дзесятковым DWORD пад ключом параметраў Sstpsvc. Змяніце значэнне, перазапусціце Routing and Remote Access і па табліцы праслухоўвання пераканайцеся, што стары порт вольны.

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

Выберыце порт, які больш нікому на вузле не патрэбны, і ўвядзіце яго ў дзесятковым выглядзе: reg add захоўвае DWORD роўна так, як яго запісана, таму значэнне, задуманае як шаснаццатковае, апынецца іншым портам. Калі запыт кажа, што значэння няма, другі радок яго стварае. Restart-Service RemoteAccess скідае ўсіх падключаных, што варта запланаваць. Пасля гэтага яшчэ раз выканайце праверку праслухоўвання, бо састарэлы запіс на 443 азначае, што служба захавала старую рэгістрацыю.

Перанос слухача мае цану, якую праўка рэестра не паказвае. Звычайныя кліенты SSTP набіраюць 443, таму кожнаму профілю кліента патрэбны новы порт, і паток перастае нагадваць вэб-запыт для ўсяго, што вывучае шлях. У сетцы, якая церпіць толькі трафік, падобны на HTTPS, гэта прыбірае большую частку прычыны, з якой выбіралі SSTP. Невялікая кіраваная аўдыторыя кліентаў гэта вытрымае; публічная база карыстальнікаў або BYOD — не.

Іншы крок пакідае 443 за IIS і лічыць Apache бэкендам, куды проксі перанакіроўвае запыты. Ён захоўвае тыповае значэнне SSTP і пакідае ў порта аднаго ўладальніка цаной перададзеных загалоўкаў, адраса кліента, які праграма больш не бачыць напрамую, і бэкенда, што мусіць гаварыць пратаколам, які проксі сапраўды дасылае.

Давядзіце ўладальніка, сертыфікат і рукапацісканне па парадку

Завершанае TCP-злучэнне даказвае толькі існаванне слухача і нічога больш, таму сканаванне партоў можа выглядаць здаровым, пакуль тунэль усё яшчэ адмаўляе. Чатыры этапы адмаўляюць па-рознаму, і выпраўленне, нацэленае на этап, які вы не ламалі, звычайна паглыбляе канфлікт. Прайдзіце іх па парадку і спыніцеся там, дзе адказ разыходзіцца.

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

Першы радок называе PID, што трымае 443, і гэта мусіць быць служба, якую вы толькі што наладзілі. Другі пералічвае сертыфікаты машыны з іх subject, таму імя, што не збягаецца з адрасам у профілі кліента, адразу кідаецца ў вочы. Запыт падзей вяртае свежыя запісы SSTP, а рукапацісканне, якое так і не даходзіць да аўтэнтыфікацыі PPP, пакідае іншы запіс, чым тое, што праходзіць праверку і потым адхіляецца. Апошні этап бачны толькі на кліенце, дзе запіс паведамляе пра падключэнне або называе памылку PPP.

Калі адзін вузел мусіць выконваць абедзве работы, выбірайце ўладальніка 443 усвядомлена і запісвайце выбар, інакш наступны чалавек, які ўключыць якую-небудзь функцыю, зноў выявіць гэты канфлікт. Падзел роляў застаецца чысцейшым адказам: публічны вэб-сервер і канчатковы пункт аддаленага доступу нясуць асобныя цыклы латак, сертыфікатаў і перазапускаў, і гэтыя цыклы сустракаюцца паводле ўласнага графіка. У любым разе пакіньце ў нататцы пра перадачу праверку праслухоўвання, шлях у рэестры і выбраны порт.