SSTP a luat portul 443: de ce Apache nu pornește

Apache încetează să răspundă pe 443 în după-amiaza în care cineva activează conexiunile VPN de intrare, iar jurnalul de erori dă vina pe bind în locul rezervării din spate. Windows Routing and Remote Access activează SSTP în acel moment, iar listenerul SSTP revendică TCP 443 prin stiva HTTP înainte ca vreun client să se autentifice. Revendicarea rămâne valabilă chiar dacă lipsește certificatul, numele este greșit sau fiecare handshake este respins, așa că un VPN în care nu poate intra nimeni ocupă în continuare portul. Citiți mai întâi tabelul de ascultare; PID-ul care deține 443 decide care dintre remediile de mai jos vă este măcar deschis.

Rezervarea supraviețuiește unui certificat stricat

SSTP înfășoară PPP într-o sesiune TLS, de aceea are nevoie de 443 și de aceea trece prin proxy-uri care aruncă alte tuneluri. Listenerul nu este un socket pe care serviciul VPN îl deschide pentru sine: SstpSvc îl înregistrează la driverul HTTP al nucleului, așa că portul rămâne rezervat cât timp serviciul rulează. Acea înregistrare nu consultă niciodată certificatul, ceea ce înseamnă că un nume expirat, un subject nepotrivit sau niciun certificat lasă 443 ocupat. Eșecurile se împart apoi în două direcții: handshake-urile respinse ajung în jurnalul System sub RasSstp, în timp ce serverul web poate doar raporta că nu a putut face bind.

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

Prima linie returnează PID-ul proprietar; a doua numește serviciul din spatele lui, iar răspunsul este de obicei serviciul HTTP sau stiva RRAS. Când tasklist răspunde cu un proces gazdă partajat, citiți coloana serviciului în loc să ghiciți după numele procesului.

Avertismentele RasSstp merită citite abia după aceea, fiindcă descriu un handshake eșuat și nu spun nimic despre rezervarea care a cauzat coliziunea. Un endpoint VPN care respinge fiecare client deține totuși portul. Tratați jurnalul ca a doua întrebare, nu ca prima.

IIS partajează driverul, Apache deschide un socket

IIS predă bindings-urile sale aceluiași driver de nucleu pe care îl folosește SSTP, iar acel driver separă conexiunile de intrare după numele gazdei și prefixul URL, așa că ambele servicii pot fi puse să vrea 443 fără ca vreunul să eșueze. Apache și nginx fac invers: apelează bind pe propriul socket, iar sistemul de operare refuză pentru că adresa este deja ocupată. Nimic din niciuna dintre configurații nu este greșit; diferența stă în ce API deține portul. De aceea activarea VPN-ului dărâmă un site pe o gazdă și lasă neatins un site identic pe altă gazdă.

Această asimetrie decide forma reparației. Dacă IIS este deja ușa din față, coliziunea devine o chestiune de prefixe, bindings și certificate. Dacă Apache este ușa din față, fie el se mută de pe 443, fie o face listenerul SSTP, iar secțiunea următoare acoperă ambele mișcări.

Alegeți ce serviciu păstrează 443

Portul listenerului locuiește într-o singură valoare de registry, un DWORD zecimal sub cheia de parametri a Sstpsvc. Schimbați valoarea, reporniți Routing and Remote Access și confirmați din tabelul de ascultare că portul vechi este liber.

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

Alegeți un port pe care nimic altceva de pe gazdă nu îl vrea, și tastați-l în zecimal: reg add stochează DWORD-ul exact așa cum este scris, așa că o valoare gândită ca hexazecimal ajunge ca alt port. Dacă interogarea spune că valoarea nu există, a doua linie o creează. Restart-Service RemoteAccess scoate afară toți cei conectați, ceea ce merită programat. Rulați din nou verificarea de ascultare după aceea, pentru că o intrare veche pe 443 înseamnă că serviciul și-a păstrat înregistrarea veche.

Mutarea listenerului are un preț pe care modificarea din registry nu îl arată. Clienții SSTP obișnuiți apelează 443, deci fiecare profil de client are nevoie de portul nou, iar fluxul nu mai seamănă cu o cerere web pentru nimic care inspectează calea. Într-o rețea care tolerează doar trafic ce pare HTTPS, asta elimină cea mai mare parte a motivului pentru care SSTP a fost ales. O populație mică și administrată de clienți absoarbe asta; o bază publică sau BYOD nu.

Cealaltă mișcare păstrează 443 la IIS și tratează Apache ca un backend către care proxy-ul redirecționează. Păstrează implicitul SSTP și lasă un singur proprietar pentru port, cu prețul antetelor redirecționate, al unei adrese de client pe care aplicația nu o mai vede direct și al unui backend care trebuie să vorbească protocolul pe care proxy-ul îl trimite efectiv.

Demonstrați proprietarul, certificatul și handshake-ul în ordine

O conexiune TCP finalizată dovedește că există un listener și nimic altceva, de aceea o scanare de porturi poate părea sănătoasă în timp ce tunelul încă eșuează. Cele patru etape eșuează în moduri diferite, iar o reparație îndreptată spre etapa pe care nu ați stricat-o adâncește de obicei coliziunea. Parcurgeți-le în ordine și opriți-vă acolo unde răspunsul diverge.

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

Prima linie numește PID-ul care ține 443, iar acesta ar trebui să fie serviciul pe care tocmai l-ați configurat. A doua listează certificatele de mașină împreună cu subjects-urile lor, așa că un nume care nu se potrivește cu adresa din profilul clientului iese imediat în evidență. Interogarea de evenimente returnează înregistrări SSTP recente, iar un handshake care nu ajunge niciodată la autentificarea PPP lasă o înregistrare diferită de cea care se autentifică și apoi este refuzată. Ultima etapă este vizibilă doar pe client, unde intrarea raportează conectat sau numește eroarea PPP.

Când o singură gazdă trebuie să facă ambele treburi, alegeți deliberat proprietarul lui 443 și notați alegerea, altfel următoarea persoană care activează o funcție va redescoperi această coliziune. Separarea rolurilor rămâne răspunsul mai curat: un server web public și un endpoint de acces la distanță poartă cicluri separate de patch-uri, certificate și reporniri, iar acele cicluri se întâlnesc după propriul calendar. În orice caz, lăsați verificarea de ascultare, calea din registry și portul ales în nota de predare.