Pse Port-Share i bën të gjithë vizitorët e faqes të duken si localhost

Çdo rresht në regjistrin e aksesit tregon të njëjtën adresë loopback, ndërsa faqja vetë ngarkohet dhe certifikata verifikohet saktë. Asgjë nuk është prishur në kuptimin e të qenit e paarritshme, dhe kjo është arsyeja pse kjo gjendje zgjat me muaj. Ajo që u prish është atribuimi: backend-i i web-it regjistron adresën e hopit që përcolli lidhjen, dhe çdo vendim i mëpasshëm që i besoi regjistrit trashëgoi të njëjtin përgjigje të gabuar.

Kontrollet më poshtë shkojnë nga kablloja brenda. Ndaloni te e para që shpjegon vlerën që shihni, sepse çdo hap i mëpasshëm supozon që të mëparshmit janë tashmë të vërtetë. Asnjëra prej tyre nuk kërkon të hamendësoni konfigurimin e pjesës së përparme.

Ndiqni dy lidhjet, jo rreshtin e regjistrit

Port-Share multiplekson dy protokolle në një dëgjues të vetëm TCP. OpenVPN inspekton bajtët e parë të një lidhjeje hyrëse, e mban atë kur duket si protokolli i tij dhe dorëzon çdo gjë tjetër te një destinacion i dytë. Ai destinacion është zakonisht një server web në të njëjtin host, kështu që socket-i i pranuar i serverit web e ka procesin OpenVPN si palë.

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

Komanda e parë tregon kush e zotëron dëgjuesin publik. E dyta tregon lidhjet që mbërrijnë në portin e backend-it, dhe adresa e palës së tyre është ajo që do të printojë regjistri i aksesit. Nëse ajo palë është loopback, regjistri është i saktë dhe informacioni humbi një shtresë më parë. Riemërtimi i fushës së regjistrit ose aktivizimi i një moduli IP klienti nuk do të rikuperojë një adresë që lidhja nuk e mbajti kurrë.

Kjo është kontrolli që vendos gjithçka tjetër. Nëse pala e backend-it është adresa e shfletuesit, ndarja e portit nuk është problemi juaj dhe është formati i regjistrit.

Përcjellja e transportit nuk është injektim i kokës

Përcjellësi lëviz bajtë. Nuk analizon HTTP, prandaj nuk mund të fusë një kokë në një kërkesë që nuk e lexon kurrë si kërkesë, dhe nuk mund të shtojë asgjë në një rrjedhë TLS që e kalon të paprekur. Një modul që pret një kokë proxy do të vazhdojë të presë një që asnjë komponent nuk e prodhon.

Dy mekanizma mund të mbajnë adresën origjinale, dhe të dy kërkojnë marrëveshje në të dy skajet. Protokolli PROXY shton një kokë të vogël në fillim të lidhjes, dhe backend-i duhet të jetë konfiguruar ta presë; një backend që nuk e pret do t'i trajtojë ato bajtë si fillimin e kërkesës dhe do të dështojë në mënyrë ngatërruese. Kokërat e besuara të proxy si X-Forwarded-For funksionojnë kur një proxy që kupton HTTP i vendos ato dhe backend-it i thuhet se cilat palë mund t'i pretendojnë.

Asnjëra nuk është automatike, dhe asnjëra nuk është e sigurt si parazgjedhje. Një backend që beson çdo kokë të përcjellë hyrëse lejon një klient të zgjedhë adresën e vet, gjë që e kthen një pasaktësi në regjistër në një anashkalim të kontrollit të aksesit. Ekzekutoni demonstrimin një herë në një host provë përpara se t'i besoni ndonjë kokë në një rrugë prodhimi.

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

Direktoria opsionale e hartëzimit të burimeve

Ndarja e portit ka një argument opsional direktorie që regjistron një hartëzim midis adresës origjinale të burimit dhe lidhjes përcjellëse, në platformat ku funksioni është implementuar. Pritet që ana e web-it të konsultojë atë hartëzim; nuk është një kokë dhe nuk injektohet në kërkesë.

Ai dizajn ia vlen të njihet, sepse shpjegon pse disa vendosje raportojnë adresa reale dhe të tjerat jo, me një konfigurim të pjesës së përparme në dukje identik. Ndryshimi është në anën pritëse, dhe zakonisht jeton në një modul ose një patch që shumica e serverëve web të paketuar nuk e aktivizojnë si parazgjedhje. Lexoni dokumentacionin e serverit tuaj web për grep-in e saktë që ofron, dhe konfirmoni që moduli është ngarkuar në vend që ta supozoni.

Nëse ndiqni këtë rrugë, trajtojeni si një integrim me dy gjysma: hartëzimi që shkruan përcjellësi dhe kërkimi që bën backend-i. Verifikoni të dyja, dhe konfirmoni që direktoria i mbijeton një rinisjeje dhe nuk rritet pa kufi në një dëgjues të zënë.

Vendosni cila komponentë garanton adresën

Përpara se të ndryshoni konfigurimin, emëroni komponentën që lejohet të pretendojë një adresë klienti dhe komponentët që lejohen t'i besojnë asaj. Një përgjigje e vetme e shkruar parandalon zhvendosjen e zakonshme, ku tre shtresa të ndryshme i besojnë secila një burimi tjetër.

Tre dizajne mbulojnë shumicën e nevojave. Mbani dëgjuesin publik dhe dëgjuesin e web-it të ndarë, në mënyrë që serveri web të shohë palë reale dhe të mos ekzistojë problem atribuimi. Vendosni përpara një proxy të kundërt që kupton HTTP, përfundoni ose analizoni kërkesën atje, dhe lëreni të vendosë një kokë të përcjellë për një backend që beson vetëm atë proxy. Ose mbani ndarjen e portit dhe pranoni që regjistrat tregojnë hopin, me rregulla aksesi të shkruara kundër identitetit të aplikacionit dhe jo kundër një adrese.

Ajo që nuk funksionon është trajtimi i një adrese loopback të përcjellë si provë që kërkesa ka origjinën në këtë makinë. Ky përfundim është saktësisht i kundërt: adresa është e pranishme pikërisht sepse një komponentë lokale krijoi lidhjen. Një rregull i shkruar kështu pranon këdo që mund të arrijë dëgjuesin.

Testoni rregullin, jo faqen

Një faqe që ngarkohet provon që rruga e përcjelljes funksionon dhe nuk thotë asgjë për atribuimin. Testoni konsumatorin e adresës: rregullin e aksesit, kufirin e shpejtësisë, hyrjen e auditimit, kërkimin gjeografik.

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

Krahasoni një kërkesë të jashtme të autorizuar me regjistrimet e të dyjave, të pjesës së përparme dhe të backend-it, dhe konfirmoni që një rregull që duhet të refuzojë vazhdon të refuzojë dhe ai që duhet të pranojë vazhdon të pranojë. Nëse rreshti i regjistrit është i saktë por rregulli vazhdon të sillet sikur të gjithë janë lokalë, rregulli lexon një fushë tjetër nga ajo që korrigjuat.

Përfundoni duke shkruar zinxhirin e atribuimit në shënimet e vendosjes: cili dëgjues, cili përcjellës, cila kokë ose hartëzim dhe cili backend është konfiguruar t'i besojë atij. Personi tjetër që lexon një rresht regjistri do t'i ketë nevojë të katërtat, dhe mungesa e atij shënimi është arsyeja pse i njëjti biletë rihapet një vit më vonë. Mbajeni pranë konfigurimit dhe jo në një fije bisede.