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 одговори као заједнички host процес, читајте колону услуге уместо да погађате из назива процеса.

RasSstp упозорења вреди читати тек након тога, јер описују неуспешан handshake и не говоре ништа о резервацији која је изазвала судар. VPN крајња тачка која одбија сваког клијента и даље држи порт. Третирајте дневник као друго питање, а не прво.

IIS дели драјвер, Apache отвара socket

IIS предаје своје bindings истом драјверу језгра који користи SSTP, а тај драјвер раздваја долазне везе по имену хоста и URL префиксу, па се обема услугама може рећи да желе 443 без да иједна падне. Apache и nginx раде супротно: позивају bind на сопственом socket-у, а оперативни систем одбија јер је адреса већ заузета. Ни у једној конфигурацији нема ничег погрешног; разлика је у томе који API држи порт. Зато и укључивање VPN-а обори једну страницу на једном хосту, а идентичну страницу на другом хосту остави нетакнутом.

Ова асиметрија одређује облик поправке. Ако је IIS већ улазна врата, судар постаје питање префикса, bindings и сертификата. Ако је Apache улазна врата, или се он помера са 443 или то чини SSTP слушач, а следеће поглавље покрива оба потеза.

Изаберите која услуга задржава 443

Порт слушача живи у једној registry вредности, децималном 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 значи да је услуга задржала стару регистрацију.

Премештање слушача има цену коју измена registry-ја не показује. Обични 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 и запишите одлуку, јер ће иначе следећа особа која укључи неку функцију поново открити овај судар. Раздвајање улога остаје чистији одговор: јавни веб сервер и крајња тачка за даљински приступ носе одвојене циклусе закрпа, сертификата и рестарта, а ти циклуси се срећу по сопственом распореду. У сваком случају, у белешку о предаји оставите проверу слушања, путању у registry-ју и изабрани порт.