SSTP võttis pordi 443: miks Apache ei käivitu

Apache lakkab 443-le vastamast sel pärastlõunal, kui keegi lubab sissetulevad VPN-ühendused, ja selle vealogi süüdistab sidumist, mitte taga olevat broneeringut. Windows Routing and Remote Access lülitab sel hetkel sisse SSTP, ja SSTP kuulaja nõuab TCP 443 HTTP-pinu kaudu enne, kui ükski klient autenditakse. Nõue kehtib ka siis, kui sertifikaat puudub, nimi on vale või iga handshake lükatakse tagasi, nii et VPN, kuhu keegi sisse logida ei saa, hoiab ikka porti hõivatuna. Lugege kõigepealt kuulamis tabelit; PID, mis 443-le kuulub, otsustab, milline allolevatest parandustest on teile üldse avatud.

Broneering elab katkise sertifikaadi üle

SSTP mässib PPP TLS-sessiooni sisse, seepärast on tal 443 vaja ja seepärast läbib see puhverservereid, mis teisi tunneleid maha viskavad. Kuulaja ei ole socket, mille VPN-teenus ise avab: SstpSvc registreerib selle kerneli HTTP-draiveris, nii et port jääb reserveerituks seni, kuni teenus töötab. See registreering ei konsulteeri kunagi sertifikaadiga, mis tähendab, et aegunud nimi, sobimatu subject või hoopis sertifikaadi puudumine jätab 443 hõivatuks. Tõrked jagunevad siis kahte suunda: tagasilükatud handshake’id jõuavad System-logisse RasSstp all, samas kui veebiserver saab vaid teatada, et ei suutnud siduda.

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

Esimene rida tagastab omanik-PID-i; teine nimetab selle taga oleva teenuse, ja vastuseks on tavaliselt HTTP-teenus või RRAS-pinu. Kui tasklist vastab jagatud hostiprotsessiga, lugege teenuse veergu, selle asemel et protsessi nime järgi oletada.

RasSstp hoiatusi tasub lugeda alles pärast seda, sest need kirjeldavad ebaõnnestunud handshake’i ega ütle midagi broneeringu kohta, mis kokkupõrke põhjustas. VPN-i lõpp-punkt, mis iga kliendi tagasi lükkab, omab porti ikka. Käsitlege logi teise küsimusena, mitte esimesena.

IIS jagab draiverit, Apache avab socketi

IIS annab oma bindings-id samale kerneldraiverile, mida SSTP kasutab, ja see draiver jaotab sissetulevad ühendused hostinime ja URL-i prefiksi järgi, nii et mõlemat teenust saab paluda 443-le, ilma et kumbki neist ebaõnnestuks. Apache ja nginx teevad vastupidist: nad kutsuvad bind-i oma socketil, ja operatsioonisüsteem keeldub, sest aadress on juba hõivatud. Kummaski konfiguratsioonis pole midagi valesti; erinevus seisneb selles, milline API seda porti omab. Seepärast ka VPN-i lubamine kukutab ühe saidi ühel hostil ja jätab identse saidi teisel hostil puutumata.

See asümmeetria määrab paranduse kuju. Kui IIS on juba esiuks, muutub kokkupõrge prefiksite, bindings-ite ja sertifikaatide küsimuseks. Kui Apache on esiuks, kas liigub tema 443-lt ära või teeb seda SSTP kuulaja, ja järgmine osa käsitleb mõlemat liigutust.

Valige, milline teenus jääb 443 juurde

Kuulaja port elab ühesainsas registriväärtuses, kümnendkohalisel DWORD-il Sstpsvc parameetrite võtme all. Muutke väärtust, taaskäivitage Routing and Remote Access ja kinnitage kuulamis tabelist, et vana port on vaba.

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

Valige port, mida miski muu hostil ei taha, ja trükkige see kümnendkohalisena: reg add salvestab DWORD-i täpselt nii, nagu kirjutatud, nii et kuueteistkümnendkohana mõeldud väärtus maandub teise pordina. Kui päring ütleb, et väärtust ei ole, loob teine rida selle. Restart-Service RemoteAccess viskab välja kõik, kes on ühendatud, mida tasub planeerida. Käivitage seejärel kuulamis kontroll uuesti, sest 443-l olev aegunud kirje tähendab, et teenus jättis oma vana registreeringu alles.

Kuulaja liigutamisel on hind, mida registri muudatus ei näita. Tavalised SSTP kliendid valivad 443, nii et iga kliendiprofiil vajab uut porti, ja voog lakkab meenutamast veebipäringut kõigele, mis teed uurib. Võrgus, mis talub ainult HTTPS-i moodi liiklust, eemaldab see suurema osa põhjusest, miks SSTP valiti. Väike, hallatav kliendipopulatsioon neelab selle alla; avalik või BYOD kasutajabaas mitte.

Teine liigutus hoiab 443 IIS-i juures ja kohtleb Apache’i backendina, kuhu puhverserver edasi suunab. See säilitab SSTP vaikeväärtuse ja jätab pordile ühe omaniku, edasisuunatud päiste, kliendi aadressi, mida rakendus enam otseselt ei näe, ja backendi hinnaga, mis peab rääkima protokolli, mida puhverserver tegelikult saadab.

Tõestage omanik, sertifikaat ja handshake järjekorras

Lõpuleviidud TCP-ühendus tõestab, et kuulaja on olemas, ja ei midagi muud, seepärast võib pordiskaneerimine tunduda terve, samal ajal kui tunnel ikka ei tööta. Neli etappi ebaõnnestuvad erineval moel, ja parandus, mis on suunatud etapile, mida te ei rikkunud, süvendab tavaliselt kokkupõrget. Töötage need järjekorras läbi ja peatuge seal, kus vastus lahkneb.

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

Esimene rida nimetab PID-i, mis hoiab 443, ja see peaks olema teenus, mille te just seadistasite. Teine loetleb masinasertifikaadid koos nende subjectitega, nii et nimi, mis ei vasta kliendiprofiili aadressile, paistab kohe silma. Sündmuste päring tagastab hiljutised SSTP kirjed, ja handshake, mis ei jõua kunagi PPP autentimiseni, jätab teistsuguse kirje kui see, mis autenditakse ja seejärel tagasi lükatakse. Viimane etapp on nähtav ainult kliendil, kus kirje kas teatab ühendatud olekust või nimetab PPP vea.

Kui üks host peab tegema mõlemat tööd, valige 443 omanik teadlikult ja kirjutage valik üles, sest muidu avastab järgmine inimene, kes funktsiooni lubab, selle kokkupõrke uuesti. Rollide eraldamine jääb puhtamaks vastuseks: avalikul veebiserveril ja kaugjuurdepääsu lõpp-punktil on eraldi paikamise, sertifikaatide ja taaskäivitamise tsüklid, ja need tsüklid kohtuvad oma ajakava järgi. Igal juhul jätke üleandmismärkmesse kuulamis kontroll, registri tee ja valitud port.