Zakaj Port-Share naredi, da vsi obiskovalci spletnega mesta izgledajo kot localhost

Vsaka vrstica v dnevniku dostopa prikazuje isti naslov loopback, medtem ko se stran sama naloži in se potrdilo pravilno preveri. Nič ni pokvarjeno v smislu nedosegljivosti in prav zato to traja mesece. Pokvarilo se je pripisovanje: spletno zaledje zabeleži naslov skoka, ki je povezavo posredoval, in vsaka poznejša odločitev, ki je zaupala dnevniku, je podedovala isti napačni odgovor.

Spodnji pregledi gredo od kabla navznoter. Ustavite se pri prvem, ki pojasni vrednost, ki jo vidite, ker vsak naslednji korak predpostavlja, da prejšnji že veljajo. Noben od njih ne zahteva ugibanja konfiguracije sprednjega dela.

Sledite dvema povezavama, ne vrstici dnevnika

Port-Share multipleksira dva protokola na enem poslušalcu TCP. OpenVPN pregleda prve bajte dohodne povezave, jo obdrži, ko je videti kot njegov lastni protokol, vse ostalo pa izroči drugemu cilju. Ta cilj je običajno spletni strežnik na istem gostitelju, zato ima sprejeti vtič spletnega strežnika proces OpenVPN za partnerja.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Prvi ukaz pokaže, kdo ima javnega poslušalca. Drugi pokaže povezave, ki prihajajo na vrata zaledja, in naslov njihovega partnerja je tisti, ki ga bo izpisal dnevnik dostopa. Če je ta partner loopback, je dnevnik natančen in informacija se je izgubila plast prej. Preimenovanje polja v dnevniku ali omogočanje modula za IP odjemalca ne bo povrnilo naslova, ki ga povezava ni nikoli nosila.

To je pregled, ki odloči vse ostalo. Če je partner zaledja naslov brskalnika, deljenje vrat ni vaš problem in je oblika dnevnika.

Posredovanje prevoza ni vbrizgavanje glave

Posredovalnik premika bajte. Ne razčlenjuje HTTP, zato ne more vstaviti glave v zahtevo, ki je nikoli ne bere kot zahteve, in ne more ničesar dodati toku TLS, ki ga spusti skozi nedotaknjen. Modul, ki pričakuje glavo posrednika, bo še naprej čakal na tisto, ki je nobena komponenta ne ustvari.

Izvorni naslov lahko nosita dva mehanizma in oba zahtevata soglasje na obeh straneh. Protokol PROXY na začetek povezave doda majhno glavo in zaledje mora biti konfigurirano, da jo pričakuje; zaledje, ki je ne pričakuje, bo te bajte obravnavalo kot začetek zahteve in spodletelo na zmeden način. Zaupanja vredne glave posrednika, kot je X-Forwarded-For, delujejo, ko jih nastavi posrednik, ki razume HTTP, in se zaledju pove, kateri partnerji jih smejo zatrjevati.

Nobeno ni samodejno in nobeno ni privzeto varno. Zaledje, ki verjame vsaki dohodni posredovani glavi, omogoča odjemalcu, da izbere svoj naslov, kar netočnost v dnevniku spremeni v obhod nadzora dostopa. Zaženite predstavitev enkrat na preskusnem gostitelju, preden zaupate kateri koli glavi na produkcijski poti.

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

Neobvezni imenik preslikave virov

Deljenje vrat ima neobvezen argument imenika, ki beleži preslikavo med prvotnim izvornim naslovom in posredovalno povezavo na platformah, kjer je funkcija izvedena. Pričakuje se, da bo spletna stran pregledala to preslikavo; to ni glava in se ne vbrizga v zahtevo.

Ta zasnova je vredna poznavanja, ker pojasnjuje, zakaj nekatera uvajanja poročajo resnične naslove in druga ne, ob navidez enaki konfiguraciji sprednjega dela. Razlika je na sprejemni strani in običajno živi v modulu ali popravku, ki ga večina pakiranih spletnih strežnikov privzeto ne omogoči. Preberite v dokumentaciji svojega spletnega strežnika, kateri natančni kavelj ponuja, in potrdite, da je modul naložen, namesto da bi to predpostavili.

Če uberete to pot, jo obravnavajte kot integracijo dveh polovic: preslikavo, ki jo zapiše posredovalnik, in iskanje, ki ga izvede zaledje. Preverite oboje in potrdite, da imenik preživi ponovni zagon in na zasedenem poslušalcu ne raste neomejeno.

Odločite, katera komponenta jamči za naslov

Preden spremenite konfiguracijo, poimenujte komponento, ki sme zatrjevati naslov odjemalca, in komponente, ki mu smejo verjeti. En zapisan odgovor prepreči običajni odmik, ko tri različne plasti zaupajo vsaka drugemu viru.

Tri zasnove pokrijejo večino potreb. Držite javnega poslušalca in spletnega poslušalca ločena, da spletni strežnik vidi resnične partnerje in ni težave s pripisovanjem. Spredaj postavite obratni posrednik, ki razume HTTP, zahtevo tam zaključite ali razčlenite in mu dovolite, da nastavi posredovano glavo za zaledje, ki zaupa samo temu posredniku. Ali obdržite deljenje vrat in sprejmite, da dnevniki kažejo skok, s pravili dostopa, pisanimi proti identiteti aplikacije, ne proti naslovu.

Kar ne deluje, je obravnavati posredovani naslov loopback kot dokaz, da je zahteva nastala na tem stroju. Ta sklep je natanko obraten: naslov je prisoten prav zato, ker je lokalna komponenta vzpostavila povezavo. Tako napisano pravilo spusti vsakogar, ki lahko doseže poslušalca.

Preizkusite pravilo, ne strani

Stran, ki se naloži, dokazuje, da pot posredovanja deluje, in o pripisovanju ne pove ničesar. Preizkusite potrošnika naslova: pravilo dostopa, omejitev hitrosti, vnos revizije, geografsko iskanje.

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

Primerjajte odobreno zunanjo zahtevo z zapisi sprednjega in zalednega dela ter potrdite, da pravilo, ki bi moralo zavrniti, še vedno zavrne, in tisto, ki bi moralo dovoliti, še vedno dovoli. Če je vrstica dnevnika pravilna, a se pravilo še vedno obnaša, kot da so vsi lokalni, pravilo bere drugo polje od tistega, ki ste ga popravili.

Končajte tako, da verigo pripisovanja zapišete v opombe k uvajanju: kateri poslušalec, kateri posredovalnik, katera glava ali preslikava in katero zaledje je konfigurirano, da mu zaupa. Naslednja oseba, ki bo prebrala vrstico dnevnika, bo potrebovala vse štiri, in prav odsotnost te opombe je razlog, da se ista zahteva leto pozneje znova odpre. Hranite jo ob konfiguraciji in ne v klepetalnem nizu.