SSTPk 443 portua hartu zuen: zergatik ez den Apache abiatzen

Apache 443n erantzuteari uzten dio norbaitek sarrerako VPN konexioak gaitzen dituen arratsaldean, eta haren erroreen egunkariak bind-a leporatzen du, atzean dagoen erreserbaren ordez. Windows Routing and Remote Access-ek SSTP gaitzen du une horretan, eta SSTP entzuleak TCP 443 aldarrikatzen du HTTP pilaren bidez, edozein bezero autentifikatu baino lehen. Aldarrikapena indarrean mantentzen da ziurtagiria falta denean, izena okerra denean edo handshake guztiak baztertzen direnean ere, beraz inork sartu ezin duen VPN batek portua okupatuta edukitzen du. Irakurri lehenik entzute-taula; 443 dituen PID-ak erabakitzen du beheko konponketetatik zein dagoen zuretzat irekita.

Erreserbak ziurtagiri hautsi bat gainditzen du

SSTP-k PPP TLS saio baten barruan biltzen du, horregatik behar du 443 eta horregatik beste tunel batzuk baztertzen dituzten proxyen bidez igarotzen da. Entzulea ez da VPN zerbitzuak bere buruarentzat irekitzen duen socket bat: SstpSvc-k kernel HTTP kontrolatzailean erregistratzen du, beraz portua erreserbatuta geratzen da zerbitzua martxan dagoen bitartean. Erregistro horrek ez du inoiz ziurtagiria kontsultatzen, eta horrek esan nahi du iraungitako izen batek, bat ez datorren subject batek edo ziurtagiririk ez izateak 443 okupatuta uzten dutela. Hutsegiteak bi norabidetan banatzen dira orduan: baztertutako handshakeak System egunkarian sartzen dira RasSstp-en pean, eta web zerbitzariak ezin du besterik jakinarazi, ezin izan zuela lotu.

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

Lehen lerroak jabe den PID-a itzultzen du; bigarrenak atzean dagoen zerbitzuaren izena ematen du, eta erantzuna HTTP zerbitzua edo RRAS pila izan ohi da. Noiz tasklist ostalari prozesu partekatu batekin erantzuten duenean, irakurri zerbitzuaren zutabea, prozesuaren izenetik asmatu beharrean.

RasSstp abisuak geroago bakarrik merezi du irakurtzea, huts egin zuen handshake bat deskribatzen dutelako eta talka eragin zuen erreserbari buruz ezer ez dutelako esaten. Bezero guztiak baztertzen dituen VPN mutur batek portua oraindik ere badu. Egunerokoa bigarren galderatzat hartu, ez lehenengotzat.

IIS-k kontrolatzailea partekatzen du, Apachek socket bat irekitzen du

IIS-k bere bindings SSTP-k erabiltzen duen kernel kontrolatzaile berari ematen dizkio, eta kontrolatzaile horrek sarrerako konexioak ostalari-izenez eta URL aurrizkiz bereizten ditu, beraz bi zerbitzuei 443 nahi izatea eska dakieke, inor huts egin gabe. Apachek eta nginx-ek kontrakoa egiten dute: bind deitzen dute beren socket propioan, eta sistema eragileak ukatzen du helbidea jada okupatuta dagoelako. Bi konfigurazioetan ez dago ezer gaizki; aldea zein API den portuaren jabe da. Horregatik ere, VPN-a gaitzeak gune bat eraisten du ostalari batean eta gune berdin bat ukitu gabe uzten du beste batean.

Asimetria horrek konponketaren forma erabakitzen du. IIS jada sarrera-atea bada, talka aurrizki, bindings eta ziurtagirien auzi bilakatzen da. Apache bada sarrera-atea, edo hura 443tik mugitzen da edo SSTP entzulea mugitzen da, eta hurrengo atalak bi mugimenduak jorratzen ditu.

Aukeratu zein zerbitzuk eusten dion 443ri

Entzulearen portua erregistro-balio bakarrean bizi da, DWORD hamartar bat Sstpsvc parametroen gakoaren pean. Aldatu balioa, berrabiarazi Routing and Remote Access, eta egiaztatu entzute-taulan portu zaharra libre dagoela.

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

Aukeratu ostalarian beste inork nahi ez duen portu bat, eta idatzi hamartarrez: reg add DWORD-a idatzita dagoen bezala gordetzen du, beraz hamaseitar gisa pentsatutako balio bat beste portu bat bezala amaitzen da. Kontsultak balioa ez dela existitzen badio, bigarren lerroak sortzen du. Restart-Service RemoteAccess konektatuta dauden guztiak kanporatzen ditu, eta hori programatzea merezi du. Exekutatu berriro entzute-egiaztapena geroago, 443n dagoen sarrera zaharkitu batek zerbitzuak bere erregistro zaharra mantendu duela esan nahi duelako.

Entzulea mugitzeak erregistroaren aldaketak erakusten ez duen prezioa du. SSTP bezero arruntek 443 deitzen dute, beraz bezero-profil bakoitzak portu berria behar du, eta fluxuak web eskaera baten antza izateari uzten dio bidea ikuskatzen duen edozerentzat. HTTPS itxura duen trafikoa soilik onartzen duen sare batean, horrek SSTP aukeratzeko arrazoiaren zatirik handiena kentzen du. Bezero-populazio txiki eta kudeatua horretara egokitzen da; erabilera publikoko edo BYOD erabiltzaile-basea ez.

Beste mugimenduak 443 IIS-rekin mantentzen du eta Apache proxyak birbidaltzen dion backend gisa hartzen du. SSTP lehenetsia gordetzen du eta portuaren jabe bakarra uzten du, birbidalitako goiburuak, aplikazioak zuzenean ikusten ez duen bezero-helbidea eta proxyak benetan bidaltzen duen protokoloa hitz egin behar duen backend baten truke.

Egiaztatu jabea, ziurtagiria eta handshakea hurrenez hurren

Osatutako TCP konexio batek entzule bat badagoela frogatzen du eta besterik ez, horregatik portu-eskaner batek osasuntsu dirudi tunelak huts egiten jarraitzen duen bitartean. Lau etapak modu desberdinetan huts egiten dute, eta hautsi ez duzun etapari zuzendutako konponketa batek talka sakontzen du normalean. Landu itzazu hurrenez hurren eta gelditu erantzuna desbideratzen den tokian.

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

Lehen lerroak 443 duen PID-aren izena ematen du, eta konfiguratu berri duzun zerbitzua izan beharko luke. Bigarrenak makinaziurtagiriak zerrendatzen ditu beren subjectekin, beraz bezero-profilaren helbidearekin bat ez datorren izen bat berehala nabarmentzen da. Gertaeren kontsultak SSTP erregistro berriak itzultzen ditu, eta PPP autentifikaziora inoiz iristen ez den handshake batek autentifikatu eta gero baztertzen denak ez bezalako erregistroa uzten du. Azken etapa bezeroan soilik da ikusgai, non sarrerak konektatuta dagoela jakinarazten duen edo PPP errorearen izena ematen duen.

Ostalari bakar batek bi lanak egin behar dituenean, aukeratu 443ren jabea nahita eta idatzi erabakia, bestela funtzio bat gaitzen duen hurrengo pertsonak talka hau berriro aurkituko baitu. Rolak bereiztea erantzun garbiena izaten jarraitzen du: web zerbitzari publiko batek eta urrutiko sarbideko mutur batek adabaki, ziurtagiri eta berrabiarazte ziklo bereiziak daramatzate, eta ziklo horiek beren egutegiaren arabera elkartzen dira. Edozein modutan, utzi entzute-egiaztapena, erregistroaren bidea eta aukeratutako portua gainditze-oharrean.