SSTP 443-cü portu tutdu: Apache niyə işə düşmür

Apache 443-də cavab verməyi elə bir günorta dayandırır ki, kimsə daxil olan VPN bağlantılarını aktivləşdirir və onun xəta jurnalı altındakı rezervasiyanı deyil, bind əməliyyatını günahlandırır. Windows Routing and Remote Access həmin anda SSTP funksiyasını aktivləşdirir və SSTP dinləyicisi hər hansı müştəri autentifikasiya olunmadan əvvəl TCP 443-ü HTTP yığını vasitəsilə iddia edir. Bu iddia sertifikat olmadıqda, ad səhv olduqda və ya hər handshake rədd edildikdə belə qüvvədə qalır, yəni heç kimin daxil ola bilmədiyi VPN yenə də portda qalır. Əvvəlcə dinləmə cədvəlini oxuyun; 443-ü saxlayan PID aşağıdakı düzəlişlərdən hansının sizin üçün ümumiyyətlə açıq olduğunu müəyyən edir.

Rezervasiya sınıq sertifikatdan da uzun yaşayır

SSTP PPP-ni TLS sessiyasına bükür, buna görə 443 lazımdır və buna görə digər tunelləri atan proxy serverlərindən keçir. Dinləyici VPN xidmətinin özü üçün açdığı socket deyil: SstpSvc onu kernel HTTP sürücüsünə qeyd edir, yəni xidmət işlədiyi müddətdə port rezerv qalır. Bu qeyd sertifikata heç vaxt baxmır, yəni vaxtı keçmiş ad, uyğun olmayan subject və ya ümumiyyətlə sertifikatın olmaması 443-ü tutulmuş saxlayır. Uğursuzluqlar sonra iki istiqamətə bölünür: rədd edilən handshakelər System jurnalında RasSstp altında qalır, veb server isə yalnız bağlana bilmədiyini bildirə bilir.

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

Birinci sətir sahib PID-i qaytarır; ikinci onun arxasındakı xidməti adlandırır və cavab adətən HTTP xidməti ya RRAS yığını olur. tasklist ortaq host prosesi ilə cavab verəndə proses adından təxmin etmək əvəzinə xidmət sütununu oxuyun.

RasSstp xəbərdarlıqlarını yalnız bundan sonra oxumağa dəyər, çünki onlar uğursuz olmuş handshakei təsvir edir və toqquşmaya səbəb olan rezervasiya barədə heç nə demir. Hər müştərini rədd edən VPN endpointi yenə də portun sahibidir. Jurnala ikinci sual kimi baxın, birinci kimi yox.

IIS sürücünü bölüşür, Apache socket açır

IIS öz bindings-lərini SSTP-nin istifadə etdiyi eyni kernel sürücüsünə verir və həmin sürücü daxil olan bağlantıları host adına və URL prefiksinə görə ayırır, yəni hər iki xidmətə 443-ü istəmək tapşırıla bilər və heç biri uğursuz olmaz. Apache və nginx bunun əksini edir: öz socketlərində bind çağırırlar və əməliyyat sistemi imtina edir, çünki ünvan artıq tutulub. İki konfiqurasiyanın heç birində səhv yoxdur; fərq ondadır ki, port hansı API-yə aiddir. Buna görə də VPN-in aktivləşdirilməsi bir hostda bir saytı yerə salır, digər hostdakı eyni sayta isə toxunmur.

Bu asimmetriya təmirin formasını müəyyən edir. Əgər giriş qapısı artıq IIS-dirsə, toqquşma prefikslər, bindings-lər və sertifikatlar haqqında suala çevrilir. Əgər giriş qapısı Apache-dirsə, ya o 443-dən çıxır, ya da SSTP dinləyicisi çıxır və növbəti bölmə hər iki hərəkəti əhatə edir.

443-ü hansı xidmətin saxlayacağını seçin

Dinləyici portu tək bir registry dəyərində yaşayır — Sstpsvc parametrlər açarı altında onluq DWORD. Dəyəri dəyişin, Routing and Remote Access xidmətini yenidən başladın və dinləmə cədvəlindən köhnə portun boş olduğunu təsdiqləyin.

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

Hostda başqa heç kimin istəmədiyi portu seçin və onu onluq yazın: reg add DWORD-u tam yazıldığı kimi saxlayır, yəni onaltılıq kimi nəzərdə tutulan dəyər başqa port kimi düşür. Sorğu dəyərin mövcud olmadığını deyirsə, ikinci sətir onu yaradır. Restart-Service RemoteAccess bağlı olan hər kəsi atır, bunu planlaşdırmağa dəyər. Sonra dinləmə yoxlamasını yenidən aparın, çünki 443-də köhnəlmiş giriş xidmətin köhnə qeydini saxladığını bildirir.

Dinləyicini köçürməyin registry düzəlişinin göstərmədiyi bir qiyməti var. Adi SSTP müştəriləri 443-ə zəng edir, yəni hər müştəri profilinə yeni port lazımdır və axın yolu yoxlayan hər şey üçün veb sorğusuna bənzəməyi dayandırır. Yalnız HTTPS-ə bənzəyən trafikə dözən şəbəkədə bu, SSTP-nin seçilmə səbəbinin çoxunu aradan qaldırır. Kiçik, idarə olunan müştəri kütləsi bunu qəbul edir; açıq və ya BYOD istifadəçi bazası etmir.

Digər hərəkət 443-ü IIS-də saxlayır və Apache-ni proxy-nin yönləndirdiyi backend kimi qəbul edir. Bu, SSTP standartını qoruyur və port üçün bir sahib qoyur; qarşılığında yönləndirilmiş başlıqlar, tətbiqin artıq birbaşa görmədiyi müştəri ünvanı və proxy-nin həqiqətən göndərdiyi protokolu danışmalı olan backend gəlir.

Sahibi, sertifikatı və handshakei ardıcıllıqla sübut edin

Tamamlanmış TCP bağlantısı yalnız dinləyicinin mövcud olduğunu sübut edir və başqa heç nəyi, buna görə port skanı sağlam görünə bilər, halbuki tunel hələ də uğursuz olur. Dörd mərhələ fərqli şəkildə uğursuz olur və sizin pozmadığınız mərhələyə yönəlmiş təmir adətən toqquşmanı dərinləşdirir. Onları ardıcıllıqla işləyin və cavabın ayrıldığı yerdə dayanın.

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

Birinci sətir 443-ü saxlayan PID-i adlandırır və bu, yenicə konfiqurasiya etdiyiniz xidmət olmalıdır. İkinci maşın sertifikatlarını subject-ləri ilə sadalayır, yəni müştəri profilindəki ünvana uyğun olmayan ad dərhal gözə dəyir. Hadisə sorğusu son SSTP qeydlərini qaytarır və PPP autentifikasiyasına heç çatmayan handshake autentifikasiyadan keçib sonra rədd ediləndən fərqli qeyd buraxır. Son mərhələ yalnız müştəridə görünür, orada giriş ya qoşulduğunu bildirir, ya da PPP xətasını adlandırır.

Bir host hər iki işi görməlidirsə, 443-ün sahibini qəsdən seçin və seçimi yazın, çünki əks halda hansısa funksiyanı aktivləşdirən növbəti şəxs bu toqquşmanı yenidən kəşf edəcək. Rolları ayırmaq daha təmiz cavab olaraq qalır: açıq veb server və uzaq giriş endpointi ayrı yamaq, sertifikat və yenidən başlatma dövrləri daşıyır və bu dövrlər öz cədvəlləri üzrə görüşür. Hər halda, təhvil qeydində dinləmə yoxlamasını, registry yolunu və seçilmiş portu buraxın.