Zergatik Port-Share-k webgunearen bisitari guztiak localhost balira bezala erakusten dituen
Backendak birbidalketa-jauzia ikusten du, ez nabigatzailea. Egiazta ezazu non galtzen den iturburu-helbidea, eta erabaki gero zein osagairi eman dakiokeen bermea.
Sarbide-erregistroko lerro bakoitzak loopback helbide bera erakusten du, orria bera kargatzen den eta ziurtagiria behar bezala egiaztatzen den bitartean. Ez dago ezer hautsita eskuraezintasunaren zentzuan, eta horregatik irauten du honek hilabeteetan. Hautsi dena esleipena da: web backendak konexioa birbidali zuen jauziaren helbidea erregistratzen du, eta erregistroan fidatu zen ondorengo erabaki bakoitzak erantzun oker bera heredatu zuen.
Beheko egiaztapenak kabletik barrurantz doaz. Gelditu ikusten duzun balioa azaltzen duen lehenengoan, ondorengo urrats bakoitzak aurrekoak jada egiazkoak direla suposatzen baitu. Horietako batek ere ez du front-endaren konfigurazioa asmatzea eskatzen.
Jarraitu bi konexioei, ez erregistro-lerroari
Port-Share-k bi protokolo multiplexatzen ditu TCP entzule bakarrean. OpenVPN sarrerako konexio baten lehen byteak aztertzen ditu, bere protokoloa dirudienean gordetzen du, eta beste edozer bigarren helmuga batera pasatzen du. Helmuga hori normalean ostalari bereko web zerbitzaria da, beraz web zerbitzariaren onartutako socket-ak OpenVPN prozesua du pare gisa.
ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'
Lehen komandoak erakusten du nork duen entzule publikoa. Bigarrenak backendaren portura iristen diren konexioak erakusten ditu, eta haien parearen helbidea da sarbide-erregistroak inprimatuko duena. Pare hori loopback bada, erregistroa zehatza da eta informazioa geruza bat lehenago galdu zen. Erregistro-eremua berrizendatzeak edo bezero-IP modulu bat gaitzeak ez du konexioak inoiz eraman ez zuen helbiderik berreskuratuko.
Hau da gainerako guztia erabakitzen duen egiaztapena. Backendaren parea nabigatzailearen helbidea bada, portuaren partekatzea ez da zure arazoa eta erregistroaren formatua da.
Garraioaren birbidalketa ez da goiburuaren injekzioa
Birbidaltzaileak byteak mugitzen ditu. Ez du HTTPrik analizatzen, beraz ezin du goibururik sartu inoiz eskaera gisa irakurtzen ez duen eskaera batean, eta ezin du ezer gehitu ukitu gabe pasatzen duen TLS korronte bati. Proxy goiburua espero duen modulu batek inongo osagaik sortzen ez duen baten zain jarraituko du.
Bi mekanismok eraman dezakete jatorrizko helbidea, eta biek bi muturretan adostasuna behar dute. PROXY protokoloak goiburu txiki bat gehitzen dio konexioari hasieran, eta backendak hura espero izateko konfiguratuta egon behar du; hura espero ez duen backendak byte horiek eskaeraren hasiera gisa hartuko ditu eta modu nahasgarrian huts egingo du. X-Forwarded-For bezalako proxy goiburu fidagarriek HTTP ulertzen duen proxy batek ezartzen dituenean eta backendari zein parek baiezta ditzaketen esaten zaionean funtzionatzen dute.
Bietako bat ere ez da automatikoa, eta bietakoren bat ere ez da segurua lehenespenez. Sarrerako birbidalitako goiburu edozein sinesten duen backendak bezeroari bere helbidea aukeratzeko aukera ematen dio, eta horrek erregistroko zehaztasun-eza sarbide-kontroleko saihesbide bihurtzen du. Exekutatu demostrazioa behin proba-ostalari batean, ekoizpen-bide batean edozein goiburu fidatu aurretik.
curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3
Iturburu-mapatze direktorio aukerakoa
Portuaren partekatzeak direktorio-argumentu aukerako bat du, jatorrizko iturburu-helbidearen eta birbidalketa-konexioaren arteko mapeatzea erregistratzen duena, ezaugarria inplementatuta dagoen plataformetan. Web aldeak mapeatze horri kontsultatu behar dio; ez da goiburu bat, eta ez da eskaeran injektatzen.
Diseinu hori ezagutzea merezi du, zergatik hedapen batzuek benetako helbideak jakinarazten dituzten eta beste batzuek ez, itxuraz berdinak diren front-end konfigurazioekin. Aldea harrera aldean dago, eta normalean ontziratutako web zerbitzari gehienek lehenespenez gaitzen ez duten modulu edo adabaki batean bizi da. Irakurri zure web zerbitzariaren dokumentazioa eskaintzen duen kako zehatzaz, eta egiazta ezazu modulua kargatuta dagoela suposatu beharrean.
Bide hori hartzen baduzu, tratatu bi erdiz osatutako integrazio gisa: birbidaltzaileak idazten duen mapeatzea eta backendak egiten duen bilaketa. Egiaztatu biak, eta egiazta ezazu direktorioak berrabiaraztea gainditzen duela eta entzule lanpetu batean mugarik gabe hazten ez dela.
Erabaki zein osagaik ematen dion bermea helbideari
Konfigurazioa aldatu aurretik, izenda itzazu bezero-helbide bat baiezta dezakeen osagaia eta hura sinetsi dezaketen osagaiak. Idatzitako erantzun bakar batek ohiko noraeza eragozten du, hiru geruza desberdinek bakoitzak iturburu desberdin batean fidatzen direnean.
Hiru diseinuk estaltzen dituzte behar gehienak. Mantendu entzule publikoa eta web entzulea bereizita, web zerbitzariak benetako pareak ikus ditzan eta esleipen-arazorik egon ez dadin. Jarri aurrean HTTP ulertzen duen alderantzizko proxy bat, amaitu edo analiza ezazu eskaera han, eta utzi birbidalitako goiburu bat ezartzen bakarra proxy horretan fidatzen den backend batentzat. Edo mantendu portuaren partekatzea eta onartu erregistroek jauzia erakusten dutela, sarbide-arauak aplikazioaren identitatearen aurka idatzita helbide baten ordez.
Funtzionatzen ez duena birbidalitako loopback helbidea eskaera makina honetan sortu zela frogatzeko ebidentzia gisa tratatzea da. Ondorio hori guztiz kontrakoa da: helbidea hain zuzen ere osagai lokal batek konexioa egin zuelako dago. Horrela idatzitako arau batek entzulera irits daitekeen edonor onartzen du.
Probatu araua, ez orria
Kargatzen den orriak birbidalketa-bidea funtzionatzen duela frogatzen du eta ez du ezer esaten esleipenari buruz. Probatu helbidearen kontsumitzailea: sarbide-araua, tasa-muga, auditoria-sarrera, geo-bilaketa.
curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log
Konparatu baimendutako kanpoko eskaera bat front-end zein backend erregistroekin, eta egiazta ezazu ukatu beharko lukeen arauak oraindik ukatzen duela eta onartu beharko lukeenak oraindik onartzen duela. Erregistro-lerroa zuzena bada baina arauak oraindik denak lokal balira bezala jokatzen badu, arauak zuzenketan jarri zenuen eremua ez den beste bat irakurtzen du.
Amaitu esleipen-katea hedapen-oharretan idatzita: zein entzule, zein birbidaltzaile, zein goiburu edo mapeatze, eta zein backend dagoen konfiguratuta hura fidatzeko. Erregistro-lerro bat irakurriko duen hurrengo pertsonak laurak beharko ditu, eta ohar horren ezak berriz irekitzen du tiket berdina urtebete geroago. Eutsi konfigurazioaren ondoan, ez txat-hari batean.