Zašto Port-Share čini da svi posjetioci web stranice izgledaju kao localhost

Svaki red u pristupnom logu prikazuje istu loopback adresu, dok se stranica učita i certifikat uspješno provjeri. Ništa nije pokvareno u smislu nedostupnosti, i zato ovo preživljava mjesecima. Pokvarilo se pripisivanje: web pozadina bilježi adresu hopa koji je proslijedio vezu, a svaka naredna odluka koja je vjerovala logu naslijedila je isti pogrešan odgovor.

Provjere ispod idu od kabla prema unutra. Zaustavite se na prvoj koja objašnjava vrijednost koju vidite, jer svaki kasniji korak pretpostavlja da su prethodni već tačni. Nijedna od njih ne zahtijeva nagađanje o konfiguraciji prednjeg dijela.

Slijedite dvije veze, a ne red u logu

Port-Share multipleksira dva protokola na jednom TCP slušaču. OpenVPN pregleda prve bajtove dolazne veze, zadrži je kada izgleda kao njegov vlastiti 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 ko posjeduje javni slušač. Druga pokazuje veze koje dolaze na port pozadine, a adresa njihovog partnera je ona koju će pristupni log ispisati. Ako je taj partner loopback, log je tačan i informacija je izgubljena jedan sloj ranije. Preimenovanje polja u logu ili uključivanje modula za IP klijenta neće vratiti adresu koju veza nikada nije nosila.

Ovo je provjera koja odlučuje sve ostalo. Ako je partner pozadine adresa pregledača, dijeljenje porta nije vaš problem, nego format loga.

Prosljeđivanje transporta nije ubacivanje zaglavlja

Prosljeđivač premješta bajtove. Ne parsira HTTP, pa ne može ubaciti zaglavlje u zahtjev koji nikada ne čita kao zahtjev, niti može dodati bilo šta TLS toku koji propušta netaknut. Modul koji očekuje proxy zaglavlje nastavit će čekati ono koje nijedna komponenta ne proizvodi.

Originalnu adresu mogu nositi dva mehanizma, a oba zahtijevaju saglasnost na obje 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 tretirat će te bajtove kao početak zahtjeva i neuspjeti na zbunjujuć način. Pouzdana proxy zaglavlja poput X-Forwarded-For rade kada ih postavlja proxy koji razumije HTTP i kada se pozadini kaže koji partneri smiju tvrditi da su ta zaglavlja.

Ni jedno nije automatski i ni jedno nije sigurno po defaultu. Pozadina koja vjeruje svakom dolaznom proslijeđenom zaglavlju dopušta klijentu da odabere vlastitu adresu, što netačnost u logu pretvara u zaobilaženje kontrole pristupa. Izvedite demonstraciju jednom na testnom hostu prije nego povjerujete bilo kojem zaglavlju na produkcijskoj putanji.

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

Opcionalni direktorij mapiranja izvora

Dijeljenje porta ima opcionalni argument direktorija koji bilježi mapiranje između originalne izvorne adrese i veze prosljeđivanja, na platformama gdje je funkcija implementirana. Očekuje se da web strana konsultuje to mapiranje; to nije zaglavlje i ne ubacuje se u zahtjev.

Taj dizajn vrijedi znati jer objašnjava zašto neka postavljanja prijavljuju stvarne adrese a neka ne, uz naizgled identičnu konfiguraciju prednjeg dijela. 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 umjesto da to pretpostavljate.

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

Odlučite koja komponenta jamči za adresu

Prije nego promijenite konfiguraciju, imenujte komponentu kojoj je dopušteno tvrditi adresu klijenta i komponente koje smiju tome vjerovati. Jedinstven zapisan odgovor sprječava uobičajeno odstupanje, u kojem tri različita sloja vjeruju 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 naprijed obrnuti proxy koji razumije HTTP, prekinite ili parsirajte zahtjev tamo i dopustite mu da postavi proslijeđeno zaglavlje za pozadinu koja vjeruje samo tom proxyju. Ili zadržite dijeljenje porta i prihvatite da logovi pokazuju hop, s pravilima pristupa napisanim prema identitetu aplikacije, a ne prema adresi.

Ono što ne funkcioniše je tretiranje proslijeđene loopback adrese kao dokaza da je zahtjev 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 doći do slušača.

Testirajte pravilo, ne stranicu

Stranica koja se učita dokazuje da put prosljeđ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šteni vanjski zahtjev s oba zapisa, prednjim i stražnjim, i potvrdite da pravilo koje bi trebalo odbiti još uvijek odbija, a ono koje bi trebalo propustiti još uvijek propušta. Ako je red u logu 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 napomene za postavljanje: koji slušač, koji prosljeđivač, koje zaglavlje ili mapiranje i koja je pozadina konfigurisana da mu vjeruje. Sljedećoj osobi koja pročita red u logu trebat će sva četiri, a odsustvo te napomene je način na koji isti tiket ponovo otvara se godinu kasnije. Držite je uz konfiguraciju, a ne u chat niti.