SSTP зае порт 443: защо Apache не стартира

Apache спира да отговаря на 443 онзи следобед, когато някой включи входящите VPN връзки, а дневникът му за грешки обвинява bind, а не резервацията зад него. Windows Routing and Remote Access включва SSTP в този момент, и слушателят на SSTP претендира за TCP 443 през стека HTTP преди който и да е клиент да се автентикира. Претенцията остава в сила дори когато сертификатът липсва, името е грешно или всеки handshake се отказва, така че VPN, в което никой не може да влезе, продължава да заема порта. Първо прочетете таблицата за слушане; PID, който притежава 443, решава кое от долните поправки изобщо ви е отворено.

Резервацията преживява счупен сертификат

SSTP обвива PPP в TLS сесия, затова се нуждае от 443 и затова минава през прокси сървъри, които изхвърлят други тунели. Слушателят не е socket, който услугата VPN отваря за себе си: SstpSvc го регистрира при драйвера HTTP на ядрото, така че портът остава резервиран, докато услугата работи. Тази регистрация никога не се допитва до сертификата, което означава, че изтекло име, несъответстващ subject или никакъв сертификат оставят 443 зает. След това отказите се делят в две посоки: отказаните handshake-ове попадат в дневника System под RasSstp, а уеб сървърът може само да съобщи, че не е успял да се обвърже.

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

Първият ред връща притежаващия PID; вторият именува услугата зад него, а отговорът обикновено е услугата HTTP или стекът RRAS. Когато tasklist отговори със споделен процес на хоста, четете колоната за услуга, вместо да гадаете по името на процеса.

Предупрежденията на RasSstp си струва да се четат само след това, защото описват неуспешен handshake и не казват нищо за резервацията, причинила конфликта. Крайна точка на VPN, която отказва всеки клиент, все още притежава порта. Третирайте дневника като втори въпрос, а не първи.

IIS споделя драйвера, Apache отваря socket

IIS предава своите bindings на същия драйвер на ядрото, който използва SSTP, и този драйвер разделя входящите връзки по име на хост и префикс на URL, така че и двете услуги могат да бъдат помолени да искат 443, без никоя да се провали. Apache и nginx правят обратното: извикват bind на собствения си socket, и операционната система отказва, защото адресът вече е зает. Нищо в нито една от конфигурациите не е грешно; разликата е в това кой 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 като backend, към който проксито препраща. Той запазва стойността по подразбиране на SSTP и оставя един собственик на порта, на цената на препратени заглавки, адрес на клиента, който приложението вече не вижда директно, и backend, който трябва да говори протокола, който проксито действително изпраща.

Докажете собственика, сертификата и handshake-а по ред

Завършена TCP връзка доказва само че съществува слушател и нищо друго, затова сканирането на портове може да изглежда здраво, докато тунелът още се проваля. Четирите етапа се провалят по различни начини, и поправка, насочена към етапа, който не сте счупили, обикновено задълбочава конфликта. Минете през тях по ред и спрете там, където отговорът се разделя.

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

Първият ред именува PID, който държи 443, и това трябва да е услугата, която току-що конфигурирахте. Вторият изброява сертификатите на машината с техните subject, така че име, което не съвпада с адреса в клиентския профил, веднага изпъква. Заявката за събития връща скорошни записи на SSTP, а handshake, който никога не стига до удостоверяване по PPP, оставя различен запис от онзи, който се удостоверява и после бива отказан. Последният етап се вижда само на клиента, където записът или съобщава свързано, или именува грешката по PPP.

Когато един хост трябва да върши и двете работи, изберете собственика на 443 съзнателно и запишете избора, защото иначе следващият човек, който включи дадена функция, ще открие този конфликт наново. Разделянето на ролите остава по-чистият отговор: публичен уеб сървър и крайна точка за отдалечен достъп носят отделни цикли на пачове, сертификати и рестарти, и тези цикли се срещат по свой собствен график. Във всеки случай оставете в бележката за предаване проверката за слушане, пътя в регистъра и избрания порт.