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 усвідомлено й записуйте вибір, інакше наступна людина, яка ввімкне якусь функцію, знову виявить цей конфлікт. Розділення ролей лишається чистішою відповіддю: публічний веб-сервер і кінцева точка віддаленого доступу несуть окремі цикли патчів, сертифікатів і перезапусків, і ці цикли зустрічаються за власним графіком. У будь-якому разі залиште в записці про передачу перевірку прослуховування, шлях у реєстрі та вибраний порт.