SSTP 443-portni egallab oldi: nega Apache ishga tushmaydi

Apache 443-da javob berishni kimdir kiruvchi VPN ulanishlarni yoqqan o’sha tushdan keyin to’xtatadi va uning xato jurnali orqadagi zahira emas, bind aybdor deb ko’rsatadi. Windows Routing and Remote Access o’sha paytda SSTP-ni yoqadi, SSTP tinglovchisi esa biron mijoz autentifikatsiya qilinishidan oldin HTTP steki orqali TCP 443-ni talab qiladi. Sertifikat yo’q bo’lsa, nom noto’g’ri bo’lsa yoki har bir handshake rad etilsa ham talab kuchda qoladi, shuning uchun hech kim kira olmaydigan VPN ham portni egallab turadi. Avval tinglash jadvalini o’qing; 443-ni egallagan PID quyidagi tuzatishlardan qaysi biri siz uchun ochiq ekanini hal qiladi.

Zahira buzilgan sertifikatdan uzoq yashaydi

SSTP PPP-ni TLS sessiyasiga o’raydi, shuning uchun unga 443 kerak va shuning uchun u boshqa tunnellarni tashlab yuboradigan proksilardan o’tadi. Tinglovchi VPN xizmati o’zi uchun ochadigan socket emas: SstpSvc uni yadro HTTP drayveriga ro’yxatdan o’tkazadi, shuning uchun xizmat ishlab turgancha port zahiralangan qoladi. Bu ro’yxat sertifikatdan hech qachon so’ramaydi, ya’ni muddati o’tgan nom, mos kelmaydigan subject yoki sertifikat umuman yo’qligi 443-ni band qilib qo’yadi. Keyin nosozliklar ikki tomonga bo’linadi: rad etilgan handshake’lar RasSstp ostida System jurnaliga tushadi, veb-server esa faqat bind qila olmaganini xabar qilishi mumkin.

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

Birinchi qator egalik qiluvchi PID-ni qaytaradi; ikkinchisi uning orqasidagi xizmatni nomlaydi va javob odatda HTTP xizmati yoki RRAS steki bo’ladi. Qachon tasklist umumiy xost jarayoni bilan javob bersa, jarayon nomidan taxmin qilmasdan xizmat ustunini o’qing.

RasSstp ogohlantirishlarini faqat shundan keyin o’qishga arziydi, chunki ular muvaffaqiyatsiz handshake’ni tasvirlaydi va to’qnashuvga sabab bo’lgan zahira haqida hech narsa demaydi. Har bir mijozni rad etadigan VPN oxirgi nuqtasi portni baribir egallab turadi. Jurnalni birinchi emas, ikkinchi savol deb biling.

IIS drayverni bo’lishadi, Apache socket ochadi

IIS o’z bindings-larini SSTP ishlatadigan o’sha yadro drayveriga topshiradi va bu drayver kiruvchi ulanishlarni xost nomi va URL prefiksi bo’yicha ajratadi, shuning uchun ikkala xizmatdan ham 443-ni xohlashni so’rash mumkin va hech biri ishdan chiqmaydi. Apache va nginx buning aksini qiladi: o’z socket-larida bind chaqiradi va manzil allaqachon band bo’lgani uchun operatsion tizim rad etadi. Ikkala konfiguratsiyada ham xato yo’q; farq qaysi API portni egallashida. Shuning uchun VPN-ni yoqish bir xostda bitta saytni yiqitadi, boshqa xostdagi aynan shunday saytga esa tegmaydi.

Bu nosimmetriklik tuzatish shaklini belgilaydi. Agar IIS allaqachon old eshik bo’lsa, to’qnashuv prefikslar, bindings va sertifikatlar masalasiga aylanadi. Agar Apache old eshik bo’lsa, yo u 443-dan chekinadi, yo SSTP tinglovchisi, va keyingi bo’lim ikkala qadamni qamrab oladi.

443-ni qaysi xizmat ushlab qolishini tanlang

Tinglovchi porti bitta reyestr qiymatida yashaydi, Sstpsvc parametrlar kaliti ostidagi o’nlik DWORD. Qiymatni o’zgartiring, Routing and Remote Access xizmatini qayta ishga tushiring va tinglash jadvalidan eski port bo’sh ekanini tasdiqlang.

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

Xostda boshqa hech kim xohlamaydigan portni tanlang va uni o’nlikda yozing: reg add DWORD-ni aynan yozilganidek saqlaydi, shuning uchun o’n oltilik deb o’ylangan qiymat boshqa port bo’lib tushadi. Agar so’rov qiymat yo’q desa, ikkinchi qator uni yaratadi. Restart-Service RemoteAccess ulanganlarning hammasini chiqarib yuboradi, buni rejalashtirishga arziydi. Keyin tinglash tekshiruvini yana bajaring, chunki 443-dagi eski yozuv xizmat eski ro’yxatini saqlab qolganini bildiradi.

Tinglovchini ko’chirishning reyestr o’zgarishi ko’rsatmaydigan narxi bor. Oddiy SSTP mijozlari 443-ni teradi, shuning uchun har bir mijoz profili yangi portga muhtoj, va oqim yo’lni tekshiradigan har qanday narsa uchun veb-so’rovga o’xshamay qo’yadi. Faqat HTTPS-ga o’xshash trafikni toqat qiladigan tarmoqda bu SSTP tanlanishining ko’p sababini olib tashlaydi. Kichik, boshqariladigan mijozlar to’plami buni qabul qiladi; ommaviy yoki BYOD foydalanuvchi bazasi yo’q.

Boshqa qadam 443-ni IIS-da ushlab, Apache-ni proksi yo’naltiradigan backend deb ko’radi. Bu SSTP standartini saqlaydi va portga bitta egasini qoldiradi, evaziga yo’naltirilgan sarlavhalar, ilova endi to’g’ridan-to’g’ri ko’rmaydigan mijoz manzili va proksi haqiqatda yuboradigan protokolni gapirishi kerak bo’lgan backend.

Egasi, sertifikat va handshake’ni tartib bilan isbotlang

Tugallangan TCP ulanish faqat tinglovchi borligini isbotlaydi, boshqa hech narsani emas, shuning uchun tunnel hali ham ishlamayotganda port skanerlash sog’lom ko’rinishi mumkin. To’rt bosqich turli yo’llar bilan ishlamaydi, va siz buzmaganingiz bosqichga qaratilgan tuzatish odatda to’qnashuvni chuqurlashtiradi. Ularni tartib bilan bajaring va javob ajraladigan joyda to’xtang.

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

Birinchi qator 443-ni ushlab turgan PID-ni nomlaydi va bu siz hozir sozlagan xizmat bo’lishi kerak. Ikkinchisi mashina sertifikatlarini ularning subjects bilan sanab o’tadi, shuning uchun mijoz profilidagi manzilga to’g’ri kelmaydigan nom darhol ko’zga tashlanadi. Hodisalar so’rovi so’nggi SSTP yozuvlarini qaytaradi, PPP autentifikatsiyasiga hech qachon yetib bormaydigan handshake esa autentifikatsiya qilinib, keyin rad etilganidan boshqacha yozuv qoldiradi. Oxirgi bosqich faqat mijozda ko’rinadi, u yerda yozuv yo ulanganini bildiradi, yo PPP xatosini nomlaydi.

Bitta xost ikkala ishni qilishi kerak bo’lsa, 443 egasini ongli ravishda tanlang va tanlovni yozib qo’ying, aks holda biron xususiyatni yoqadigan keyingi odam bu to’qnashuvni qaytadan topadi. Rollarni ajratish eng toza javob bo’lib qoladi: ommaviy veb-server va masofaviy kirish oxirgi nuqtasi alohida yamoq, sertifikat va qayta ishga tushirish davrlarini olib yuradi, va bu davrlar o’z jadvali bo’yicha uchrashadi. Har holda, topshirish eslatmasida tinglash tekshiruvini, reyestr yo’lini va tanlangan portni qoldiring.