Zašto Port-Share čini da svi posetioci sajta izgledaju kao localhost

Svaki red u dnevniku pristupa prikazuje istu loopback adresu, dok se stranica učitava i sertifikat se ispravno proverava. Ništa nije pokvareno u smislu nedostupnosti i zato ovo preživljava mesecima. Pokvarilo se pripisivanje: web pozadina beleži adresu skoka koji je prosledio vezu, a svaka kasnija odluka koja je verovala dnevniku nasledila je isti pogrešan odgovor.

Provere ispod idu od kabla prema unutra. Zaustavite se na prvoj koja objašnjava vrednost koju vidite, jer svaki kasniji korak pretpostavlja da su prethodni već tačni. Nijedna od njih ne zahteva nagađanje konfiguracije prednjeg dela.

Pratite dve veze, a ne red u dnevniku

Port-Share multipleksira dva protokola na jednom TCP slušaču. OpenVPN pregleda prve bajtove dolazne veze, zadrži je kad izgleda kao njegov sopstveni protokol, a sve ostalo predaje drugom odredištu. To odredište je obično web server na istom hostu, pa prihvaćeni socket web servera ima OpenVPN proces kao svog partnera.

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

Prva komanda pokazuje kome pripada javni slušač. Druga pokazuje veze koje dolaze na port pozadine, a adresa njihovog partnera je ona koju će dnevnik pristupa ispisati. Ako je taj partner loopback, dnevnik je tačan i informacija je izgubljena jedan sloj ranije. Preimenovanje polja u dnevniku ili uključivanje modula za IP klijenta neće vratiti adresu koju veza nikada nije nosila.

Ovo je provera koja odlučuje sve ostalo. Ako je partner pozadine adresa pregledača, deljenje porta nije vaš problem, nego format dnevnika.

Prosleđivanje transporta nije ubacivanje zaglavlja

Prosleđivač premešta bajtove. Ne parsira HTTP, pa ne može da ubaci zaglavlje u zahtev koji nikada ne čita kao zahtev, niti može da doda bilo šta TLS toku koji propušta netaknut. Modul koji očekuje proxy zaglavlje nastaviće da čeka ono koje nijedna komponenta ne proizvodi.

Originalnu adresu mogu da nose dva mehanizma i oba zahtevaju saglasnost na obe strane. PROXY protokol dodaje malo zaglavlje na početak veze, a pozadina mora biti konfigurisana da ga očekuje; pozadina koja ga ne očekuje tretiraće te bajtove kao početak zahteva i neuspeti na zbunjujuć način. Pouzdana proxy zaglavlja poput X-Forwarded-For rade kada ih postavlja proxy koji razume HTTP i kada se pozadini kaže koji partneri smeju da ih tvrde.

Nijedno nije automatsko i nijedno nije sigurno po defaultu. Pozadina koja veruje svakom dolaznom prosleđenom zaglavlju dopušta klijentu da odabere sopstvenu adresu, što netačnost u dnevniku pretvara u zaobilaženje kontrole pristupa. Izvedite demonstraciju jednom na testnom hostu pre nego što poverujete bilo kom zaglavlju na produkcijskom putu.

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

Opcioni direktorijum mapiranja izvora

Deljenje porta ima opcioni argument direktorijuma koji beleži mapiranje između originalne izvorne adrese i veze prosleđivanja, na platformama gde je ta funkcija implementirana. Očekuje se da web strana konsultuje to mapiranje; to nije zaglavlje i ne ubacuje se u zahtev.

Taj dizajn vredi znati jer objašnjava zašto neka postavljanja prijavljuju stvarne adrese a neka ne, uz naizgled identičnu konfiguraciju prednjeg dela. Razlika je na strani primanja i obično živi u modulu ili zakrpi koju većina pakovanih web servera ne uključuje po defaultu. Pročitajte dokumentaciju svog web servera za tačnu kuku koju nudi i potvrdite da je modul učitan umesto da to pretpostavljate.

Ako krenete tim putem, tretirajte to kao integraciju s dve polovine: mapiranje koje piše prosleđivač i pretragu koju izvodi pozadina. Proverite oboje i potvrdite da direktorijum preživljava restart i da ne raste neograničeno na zauzetom slušaču.

Odlučite koja komponenta jamči za adresu

Pre nego što promenite konfiguraciju, imenujte komponentu kojoj je dopušteno tvrditi adresu klijenta i komponente koje smeju tome da veruju. Jedan zapisan odgovor sprečava uobičajeno odstupanje u kojem tri različita sloja veruju različitom izvoru.

Tri dizajna pokrivaju većinu potreba. Držite javni slušač i web slušač odvojeno, tako da web server vidi stvarne partnere i nema problema s pripisivanjem. Postavite napred obrnuti proxy koji razume HTTP, prekinite ili parsirajte zahtev tu i dopustite mu da postavi prosleđeno zaglavlje za pozadinu koja veruje samo tom proxyju. Ili zadržite deljenje porta i prihvatite da dnevnici pokazuju skok, s pravilima pristupa pisanim prema identitetu aplikacije, a ne prema adresi.

Ono što ne funkcioniše jeste tretirati prosleđenu loopback adresu kao dokaz da je zahtev nastao na ovom računaru. Taj zaključak je upravo obrnut: adresa je prisutna upravo zato što je lokalna komponenta uspostavila vezu. Pravilo napisano tako propušta svakoga ko može da dođe do slušača.

Testirajte pravilo, ne stranicu

Stranica koja se učita dokazuje da put prosleđivanja radi i ne govori ništa o pripisivanju. Testirajte potrošača adrese: pravilo pristupa, ograničenje brzine, zapis u reviziji, geo pretragu.

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

Uporedite ovlašćeni spoljni zahtev s oba zapisa, prednjim i stražnjim, i potvrdite da pravilo koje bi trebalo da odbije još uvek odbija, a ono koje bi trebalo da propusti još uvek propušta. Ako je red u dnevniku tačan ali se pravilo i dalje ponaša kao da su svi lokalni, pravilo čita drugo polje od onoga koje ste popravili.

Završite tako što ćete lanac pripisivanja upisati u beleške za postavljanje: koji slušač, koji prosleđivač, koje zaglavlje ili mapiranje i koja je pozadina konfigurisana da mu veruje. Sledećoj osobi koja pročita red u dnevniku trebaće sva četiri, a odsustvo te beleške je način na koji isti tiket ponovo otvara se godinu kasnije. Držite je uz konfiguraciju, a ne u chat niti.