Wêrom Port-Share alle websidebesikers as localhost lit lykje

Elke rigel yn it tagongslogboek lit itselde loopback-adres sjen, wylst de side sels lade en it sertifikaat goed ferifiearre wurdt. Neat is stikken yn 'e sin dat it net berikber is, en dêrom oerlibbet dit moannenlang. Wat brutsen is, is de taskriuwing: de web-backend registrearret it adres fan 'e hop dy't de ferbining trochstjoerde, en elk letter beslút dat it logboek fertroude, erve itselde ferkearde antwurd.

De kontrôles hjirûnder geane fan 'e kabel nei binnen. Stop by de earste dy't de wearde ferklearret dy't jo sjogge, want elke lettere stap giet derfan út dat de eardere al wier binne. Gjin fan harren freget om de front-end-konfiguraasje te rieden.

Folgje de twa ferbiningen, net de logboekrigel

Port-Share multiplexet twa protokollen op ien TCP-harker. OpenVPN ûndersiket de earste bytes fan in ynkommende ferbining, hâldt it as it op syn eigen protokol liket, en jout al it oare oan in twadde bestimming. Dy bestimming is meastentiids in webserver op deselde host, sadat de akseptearre socket fan 'e webserver it OpenVPN-proses as peer hat.

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

It earste kommando lit sjen wa't de publike harker hat. It twadde lit de ferbiningen sjen dy't by de backend-poarte oankomme, en har peer-adres is datjinge dat it tagongslogboek printsje sil. As dy peer loopback is, is it logboek akkuraat en is de ynformaasje in laach earder ferlern gien. It werneamen fan it logboekfjild of it ynskeakeljen fan in klant-IP-module sil gjin adres weromkrije dat de ferbining nea droegen hat.

Dit is de kontrôle dy't al it oare beslút. As de peer fan 'e backend it adres fan 'e browser is, is poartdiele net jo probleem en is it logboekformaat dat wol.

Ferfiertrochstjoering is gjin header-ynjeksje

De trochstjoerder ferpleatst bytes. It parset gjin HTTP, dus it kin gjin header yn in fersyk ynfoegje dat it nea as fersyk lêst, en it kin neat tafoegje oan in TLS-stream dy't it ûnoantaat trochlitte. In module dy't in proxy-header ferwachtet, bliuwt wachtsjen op ien dy't gjin komponint produsearret.

Twa meganismen kinne it oarspronklike adres drage, en beide ferlangje oerienstimming oan beide kanten. It PROXY-protokol set in lytse header foar de ferbining en de backend moat konfigurearre wêze om dy te ferwachtsjen; in backend dy't dy net ferwachtet, sil dy bytes as it begjin fan it fersyk behannelje en op in betiizjende manier mislearje. Fertroude proxy-headers lykas X-Forwarded-For wurkje as in HTTP-bewuste proxy se set en de backend ferteld wurdt hokker peers se beweare meie.

Gjin fan beide is automatysk, en gjin fan beide is standert feilich. In backend dy't elke ynkommende trochstjoerde header leaut, lit in klant syn eigen adres kieze, wat in ûnkrektens yn it logboek omsette yn in omgong fan tagongskontrôle. Fiermearje de demonstraasje ien kear op in testhost foardat jo ienige header op in produksjepaad fertrouwe.

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

De opsjonele boarnemapping-map

Poartdiele hat in opsjoneel mapargumint dat in mapping tusken it oarspronklike boarneadres en de trochstjoerferbining registrearret, op platfoarms dêr't de funksje ymplemintearre is. It is de bedoeling dat de webkant dy mapping rieplachtet; it is gjin header, en it wurdt net yn it fersyk ynjette.

Dat ûntwerp is it wurdich om te kennen, want it ferklearret wêrom't guon ynstallaasjes echte adressen rapportearje en oare net, mei skynber identike front-end-konfiguraasje. It ferskil sit oan 'e ûntfangende kant, en it wennet meastentiids yn in module of patch dy't de measte ferpakte webservers net standert ynskeakelje. Lês de dokumintaasje fan jo webserver foar de krekte hook dy't it biedt, en befêstigje dat de module laden is ynstee fan it oan te nimmen.

As jo dit paad nimme, behannelje it as in yntegraasje fan twa helten: de mapping dy't de trochstjoerder skriuwt en it sykjen dat de backend docht. Ferifiearje beide, en befêstigje dat de map in herstart oerlibbet en net ûnbeheind groeit op in drokke harker.

Beslút hokker komponint it adres garandearret

Foardat jo de konfiguraasje feroarje, neam it komponint dat in klantadres beweare mei en de komponinten dy't it leauwe meie. Ien opskreaun antwurd foarkomt de gewoane drift, wêrby't trije ferskillende lagen elk in oare boarne fertrouwe.

Trije ûntwerpen dekke de measte behoeften. Hâld de publike harker en de webharker apart, sadat de webserver echte peers sjocht en der gjin taskriuwingsprobleem bestiet. Set in HTTP-bewuste omkearde proxy foar, beëinigje of parse it fersyk dêr, en lit it in trochstjoerde header sette foar in backend dy't allinne dy proxy fertrouwt. Of hâld poartdiele en akseptearje dat logboeken de hop sjen litte, mei tagongsregels skreaun tsjin 'e applikaasje-identiteit ynstee fan in adres.

Wat net wurket, is in trochstjoerd loopback-adres behannelje as bewiis dat it fersyk op dizze masine ûntstien is. Dy konklúzje is krekt oarsom: it adres is der krekt om't in lokale komponint de ferbining makke hat. In regel dy't sa skreaun is, lit elkenien ta dy't de harker berikke kin.

Test de regel, net de side

In side dy't lade, bewiist dat it trochstjoerpaad wurket en seit neat oer taskriuwing. Test de brûker fan it adres: de tagongsregel, de taryflimyt, de auditierier, it geo-sykjen.

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

Fergelykje in autorisearre ekstern fersyk mei sawol de front-end- as de backend-registraasjes, en befêstigje dat in regel dy't wegerje moat noch altyd wegeret en ien dy't talitte moat noch altyd talit. As de logboekrigel korrekt is mar de regel him noch altyd hâldt as wiene alle minsken lokaal, lêst de regel in oar fjild as datjinge dat jo reparearre hawwe.

Einigje troch de taskriuwingsketen yn 'e ynsetnotysjes te skriuwen: hokker harker, hokker trochstjoerder, hokker header of mapping, en hokker backend konfigurearre is om dy te fertrouwen. De folgjende persoan dy't in logboekrigel lêst, sil alle fjouwer nedich wêze, en it ûntbrekken fan dy notysje is hoe't deselde kaart in jier letter wer iepenet. Hâld it njonken de konfiguraasje ynstee fan yn in chatried.