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 осознанно и записывайте выбор, иначе следующий человек, включающий какую-нибудь функцию, заново обнаружит этот конфликт. Разделение ролей остаётся более чистым ответом: публичный веб-сервер и точка удалённого доступа несут отдельные циклы патчей, сертификатов и перезапусков, и эти циклы встречаются по собственному графику. В любом случае оставьте в записке о передаче проверку прослушивания, путь в реестре и выбранный порт.