SSTP 443 портын басып алды: Apache неге қосылмайды

Apache 443-те жауап беруді біреу кіріс VPN байланыстарын қосқан түстен кейін тоқтатады, және оның қателер журналы bind-ті, ал оның артындағы резервтеуді емес, кінәлайды. Windows Routing and Remote Access сол сәтте SSTP-ні қосады, ал SSTP тыңдаушысы кез келген клиент аутентификацияланбай тұрып HTTP стек арқылы TCP 443-ті талап етеді. Сертификат жоқ болса, атау қате болса немесе әрбір handshake қабылданбаса да талап күшінде қалады, сондықтан ешкім кіре алмайтын VPN портты бәрібір ұстап тұрады. Алдымен тыңдау кестесін оқыңыз; 443-ті ұстап тұрған PID төмендегі түзетулердің қайсысы сізге ашық екенін шешеді.

Резервтеу бүлінген сертификаттан ұзақ өмір сүреді

SSTP PPP-ні TLS сессиясына орайды, сондықтан оған 443 керек және сондықтан ол басқа туннельдерді тастайтын проксилер арқылы өтеді. Тыңдаушы — VPN қызметі өзі үшін ашатын socket емес: SstpSvc оны ядроның HTTP драйверіне тіркейді, сондықтан қызмет жұмыс істеп тұрғанша порт резервтелген күйде қалады. Бұл тіркеу сертификаттан ешқашан сұрамайды, яғни мерзімі өткен атау, сәйкес емес subject немесе мүлдем сертификаттың болмауы 443-ті басып алынған күйде қалдырады. Содан кейін ақаулар екі бағытқа бөлінеді: қабылданбаған handshake-тер System журналына RasSstp астында түседі, ал веб-сервер тек bind жасай алмағанын хабарлай алады.

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 керісінше жасайды: олар өз socket-терінде bind шақырады, ал операциялық жүйе мекенжай әлдеқашан алынған деп бас тартады. Екі конфигурацияның ешқайсысында қате жоқ; айырмашылық мынада, портты қай API иеленеді. Сол себепті VPN-ді қосу бір хосттағы бір сайтты құлатады, ал екінші хосттағы дәл сондай сайтқа тиіспейді.

Бұл асимметрия жөндеудің нысанын анықтайды. Егер IIS әлдеқашан алдыңғы есік болса, қақтығыс префикстер, bindings және сертификаттар туралы сұраққа айналады. Егер Apache алдыңғы есік болса, ол не 443-тен кетеді, не SSTP тыңдаушысы кетеді, және келесі бөлім екі қадамды да қамтиды.

443-ті қай қызмет ұстап қалатынын таңдаңыз

Тыңдаушы порты бір ғана реестр мәнінде тұрады, Sstpsvc параметрлер кілті астындағы ондық DWORD. Мәнді өзгертіңіз, 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

Бірінші жол 443-ті ұстап тұрған PID-ті атайды, және бұл жаңа ғана конфигурациялаған қызмет болуы керек. Екіншісі машина сертификаттарын олардың subject-терімен тізімдейді, сондықтан клиент профиліндегі мекенжайға сәйкес келмейтін атау бірден көзге түседі. Оқиға сұранысы соңғы SSTP жазбаларын қайтарады, ал PPP аутентификациясына ешқашан жетпейтін handshake аутентификацияланып, содан кейін қабылданбағаннан өзгеше жазба қалдырады. Соңғы кезең тек клиентте көрінеді, онда жазба не қосылғанын хабарлайды, не PPP қатесін атайды.

Бір хост екі жұмысты да атқаруы керек болса, 443-тің иегерін әдейі таңдап, таңдауды жазып қойыңыз, әйтпесе қандай да бір мүмкіндікті қосатын келесі адам бұл қақтығысты қайта ашады. Рөлдерді бөлу ең таза жауап болып қалады: жалпыға ашық веб-сервер мен қашықтан қатынау шеткі нүктесінің патч, сертификат және қайта іске қосу циклдері бөлек, және бұл циклдер өз кестесімен кездеседі. Қалай болғанда да, тапсыру жазбасында тыңдау тексерісін, реестр жолын және таңдалған портты қалдырыңыз.