SSTP otti portin 443: miksi Apache ei käynnisty
Epäonnistuva sivusto ei ole se, joka pitää 443:a. Windowsin SSTP varaa portin HTTP-pinon kautta: siirrä kuuntelija, laita IIS eteen tai siirrä sivusto.
Apache lakkaa vastaamasta 443:ssa sinä iltapäivänä, jolloin joku ottaa käyttöön saapuvat VPN-yhteydet, ja sen virheloki syyttää bindia eikä sen takana olevaa varausta. Windows Routing and Remote Access kytkee SSTP päälle juuri sillä hetkellä, ja SSTP-kuuntelija vaatii TCP 443:n HTTP-pinon kautta ennen kuin yksikään asiakas todennetaan. Vaatimus pysyy voimassa, vaikka varmenne puuttuisi, nimi olisi väärä tai jokainen handshake hylättäisiin, joten VPN, johon kukaan ei voi kirjautua, pitää porttia yhä varattuna. Lue ensin kuuntelutaulukko; 443:n omistava PID ratkaisee, mikä alla olevista korjauksista on sinulle ylipäätään avoinna.
Varaus elää rikkinäisen varmenteen yli
SSTP käärii PPP:n TLS-istunnon sisään, siksi se tarvitsee 443:n ja siksi se kulkee välityspalvelinten läpi, jotka pudottavat muita tunneleita. Kuuntelija ei ole socket, jonka VPN-palvelu avaa itselleen: SstpSvc rekisteröi sen ytimen HTTP-ohjaimeen, joten portti pysyy varattuna niin kauan kuin palvelu on käynnissä. Se rekisteröinti ei koskaan kysy varmenteelta mitään, mikä tarkoittaa, että vanhentunut nimi, sopimaton subject tai kokonaan puuttuva varmenne jättää 443:n varatuksi. Virheet jakautuvat sitten kahteen suuntaan: hylätyt handshaket päätyvät System-lokiin RasSstp-otsikon alle, kun taas verkkopalvelin voi vain ilmoittaa, ettei se saanut sidottua.
netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"
Ensimmäinen rivi palauttaa omistavan PID:n; toinen nimeää sen takana olevan palvelun, ja vastaus on yleensä HTTP-palvelu tai RRAS-pino. Kun tasklist vastaa jaetulla isäntäprosessilla, lue palvelusarake sen sijaan että arvaisit prosessin nimestä.
RasSstp-varoituksia kannattaa lukea vasta sen jälkeen, koska ne kuvaavat epäonnistunutta handshakea eivätkä kerro mitään törmäyksen aiheuttaneesta varauksesta. VPN-päätepiste, joka hylkää jokaisen asiakkaan, omistaa portin silti. Käsittele lokia toisena kysymyksenä, ei ensimmäisenä.
IIS jakaa ohjaimen, Apache avaa socketin
IIS luovuttaa bindings-määrityksensä samalle ytimen ohjaimelle, jota SSTP käyttää, ja se ohjain erottelee saapuvat yhteydet isäntänimen ja URL-etuliitteen mukaan, joten molemmilta palveluilta voidaan pyytää 443:a ilman että kumpikaan epäonnistuu. Apache ja nginx tekevät päinvastoin: ne kutsuvat bindia omalla socketillaan, ja käyttöjärjestelmä kieltäytyy, koska osoite on jo varattu. Kummassakaan kokoonpanossa ei ole mitään väärää; ero on siinä, mikä API omistaa portin. Siksi myös VPN:n käyttöönotto kaataa yhden sivuston yhdellä isännällä ja jättää identtisen sivuston toisella isännällä koskemattomaksi.
Tämä epäsymmetria määrää korjauksen muodon. Jos IIS on jo etuovi, törmäyksestä tulee kysymys etuliitteistä, bindings-määrityksistä ja varmenteista. Jos Apache on etuovi, joko se siirtyy pois 443:lta tai SSTP-kuuntelija siirtyy, ja seuraava osio käsittelee molemmat siirrot.
Valitse, mikä palvelu pitää 443:n
Kuuntelijan portti elää yhdessä rekisteriarvossa, desimaalisessa DWORDissa Sstpsvc-parametrien avaimen alla. Muuta arvoa, käynnistä Routing and Remote Access uudelleen ja varmista kuuntelutaulukosta, että vanha portti on vapaa.
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
Valitse portti, jota mikään muu isännällä ei halua, ja kirjoita se desimaalina: reg add tallentaa DWORDin täsmälleen niin kuin se on kirjoitettu, joten kuusitoistakantaiseksi tarkoitettu arvo päätyy toiseksi portiksi. Jos kysely sanoo, ettei arvoa ole, toinen rivi luo sen. Restart-Service RemoteAccess pudottaa kaikki yhteydessä olevat, mikä kannattaa aikatauluttaa. Aja kuuntelutarkistus sen jälkeen uudelleen, koska 443:ssa oleva vanhentunut merkintä tarkoittaa, että palvelu piti vanhan rekisteröintinsä.
Kuuntelijan siirtämisellä on hinta, jota rekisterimuutos ei näytä. Tavalliset SSTP-asiakkaat valitsevat 443:n, joten jokainen asiakasprofiili tarvitsee uuden portin, ja kulku lakkaa muistuttamasta verkkopyyntöä kaikelle, mikä tarkastelee polkua. Verkossa, joka sietää vain HTTPS:ltä näyttävää liikennettä, se poistaa suurimman osan syystä, miksi SSTP valittiin. Pieni, hallittu asiakaskanta nielee tämän; julkinen tai BYOD-käyttäjäkunta ei.
Toinen siirto pitää 443:n IIS:llä ja kohtelee Apachea back endinä, johon välityspalvelin välittää. Se säilyttää SSTP:n oletuksen ja jättää portille yhden omistajan, mutta maksaa välitetyt otsakkeet, asiakasosoitteen, jota sovellus ei enää näe suoraan, ja back endin, jonka on puhuttava protokollaa, jota välityspalvelin todella lähettää.
Todista omistaja, varmenne ja handshake tässä järjestyksessä
Valmis TCP-yhteys todistaa, että kuuntelija on olemassa, eikä mitään muuta, siksi porttiskannaus voi näyttää terveeltä, vaikka tunneli epäonnistuu yhä. Neljä vaihetta epäonnistuvat eri tavoin, ja korjaus, joka kohdistuu vaiheeseen, jota et rikkonut, yleensä syventää törmäystä. Käy ne läpi järjestyksessä ja pysähdy siihen, missä vastaus haarautuu.
netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20
Ensimmäinen rivi nimeää 443:a pitävän PID:n, ja sen pitäisi olla palvelu, jonka juuri määritit. Toinen luettelee konevarmenteet subjecteineen, joten nimi, joka ei vastaa asiakasprofiilin osoitetta, pistää heti silmään. Tapahtumakysely palauttaa viimeaikaiset SSTP-tietueet, ja handshake, joka ei koskaan yllä PPP-todennukseen, jättää erilaisen tietueen kuin se, joka todennetaan ja sitten hylätään. Viimeinen vaihe näkyy vain asiakkaalla, jossa merkintä joko ilmoittaa yhdistetyksi tai nimeää PPP-virheen.
Kun yhden isännän on tehtävä molemmat työt, valitse 443:n omistaja tietoisesti ja kirjoita valinta muistiin, koska muuten seuraava ominaisuuden käyttöönottaja löytää tämän törmäyksen uudelleen. Roolien erottaminen pysyy siistimpänä vastauksena: julkisella verkkopalvelimella ja etäkäytön päätepisteellä on erilliset paikkaus-, varmenne- ja uudelleenkäynnistyssyklit, ja ne syklit kohtaavat omalla aikataulullaan. Kummassakin tapauksessa jätä kuuntelutarkistus, rekisteripolku ja valittu portti luovutusmuistioon.