Hoekom Port-Share alle webwerfbesoekers soos localhost laat lyk

Elke reël in die toegangslog wys dieselfde loopback-adres, terwyl die bladsy self laai en die sertifikaat reg verifieer. Niks is stukkend in die sin dat dit onbereikbaar is nie, en daarom oorleef hierdie een maande lank. Wat gebreek het, is toeskrywing: die web-agterkant teken die adres aan van die hop wat die verbinding deurgestuur het, en elke stroomaf besluit wat die log vertrou het, het dieselfde verkeerde antwoord geërf.

Die kontroles hieronder loop van die draad na binne. Stop by die eerste een wat die waarde wat jy sien verklaar, want elke latere stap aanvaar dat die vroeëre reeds waar is. Nie een van hulle vereis dat jy die front-end-konfigurasie raai nie.

Volg die twee verbindings, nie die logreël nie

Port sharing multipliseer twee protokolle op een TCP-luisteraar. OpenVPN ondersoek die eerste grepe van 'n inkomende verbinding, hou dit wanneer dit soos sy eie protokol lyk, en gee enigiets anders aan 'n tweede bestemming oor. Daardie bestemming is gewoonlik 'n webbediener op dieselfde gasheer, so die webbediener se aanvaarde sok het die OpenVPN-proses as sy eweknie.

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

Die eerste opdrag wys wie die openbare luisteraar besit. Die tweede wys die verbindings wat by die agterkant-poort aankom, en hul eweknie-adres is die een wat die toegangslog sal druk. As daardie eweknie loopback is, is die log akkuraat en het die inligting 'n laag vroeër verlore gegaan. Om die logveld te hernoem of 'n kliënt-IP-module te aktiveer, sal nie 'n adres terugkry wat die verbinding nooit gedra het nie.

Dit is die kontrole wat alles anders bepaal. As die agterkant se eweknie die blaaier se adres is, is port sharing nie jou probleem nie en is die logformaat dit.

Deurstuur van vervoer is nie kopskrifinlywing nie

Die deurstuurder skuif grepe. Dit ontleed nie HTTP nie, so dit kan nie 'n kopskrif in 'n versoek invoeg wat hy nooit as 'n versoek lees nie, en dit kan niks by 'n TLS-stroom voeg wat hy onaangeraak deurlaat nie. 'n Module wat 'n proxy-kopskrif verwag, sal bly wag vir een wat geen komponent produseer nie.

Twee meganismes kan die oorspronklike adres dra, en albei vereis ooreenkoms aan beide kante. Die PROXY-protokol voeg 'n klein kopskrif by die verbinding, en die agterkant moet ingestel wees om dit te verwag; 'n agterkant wat dit nie verwag nie, sal daardie grepe as die begin van die versoek behandel en op 'n verwarrende manier faal. Vertroude proxy-kopskrifte soos X-Forwarded-For werk wanneer 'n HTTP-bewuste proxy hulle stel en die agterkant vertel word watter eweknieë dit mag beweer.

Nie een is outomaties nie, en nie een is by verstek veilig nie. 'n Agterkant wat enige inkomende deurgestuurde kopskrif glo, laat 'n kliënt sy eie adres kies, wat 'n onakkuraatheid in die log in 'n omsylding van toegangsbeheer verander. Voer die demonstrasie een keer op 'n stoomgasheer uit voordat jy enige kopskrif op 'n produksiepad vertrou.

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

Die opsionele bronkartering-gids

Port sharing het 'n opsionele gidsargument wat 'n kartering tussen die oorspronklike bronadres en die deurstuurverbinding aanteken, op platforms waar die funksie geïmplementeer is. Die webkant word verwag om daardie kartering te raadpleeg; dit is nie 'n kopskrif nie, en dit word nie in die versoek ingevoeg nie.

Daardie ontwerp is die moeite werd om te ken, want dit verduidelik waarom sommige ontplooiings werklike adresse rapporteer en ander nie, met oënskynlik identiese front-end-konfigurasie. Die verskil lê aan die ontvangende kant, en dit woon gewoonlik in 'n module of pleister wat die meeste verpakte webbedieners nie by verstek aktiveer nie. Lees jou webbediener se dokumentasie vir die presiese haak wat dit bied, en bevestig dat die module gelaai is eerder as om dit te aanvaar.

As jy hierdie roete volg, behandel dit as 'n integrasie met twee helftes: die kartering wat die deurstuurder skryf en die opsoek wat die agterkant doen. Verifieer albei, en bevestig dat die gids 'n herbegin oorleef en nie op 'n besige luisteraar onbeperk groei nie.

Besluit watter komponent vir die adres instaan

Voordat jy die konfigurasie verander, noem die komponent wat 'n kliëntadres mag beweer en die komponente wat dit mag glo. 'n Enkele antwoord wat neergeskryf is, verhoed die gewone wegdrywing waarin drie verskillende lae elk 'n ander bron vertrou.

Drie ontwerpe dek die meeste behoeftes. Hou die openbare luisteraar en die web-luisteraar apart, sodat die webbediener werklike eweknieë sien en daar geen toeskrywingsprobleem bestaan nie. Sit 'n HTTP-bewuste omgekeerde proxy voor, termineer of ontleed die versoek daar, en laat dit 'n deurgestuurde kopskrif stel vir 'n agterkant wat net daardie proxy vertrou. Of hou port sharing en aanvaar dat logs die hop wys, met toegangsreëls wat teen toepassingsidentiteit eerder as 'n adres geskryf is.

Wat nie werk nie, is om 'n deurgestuurde loopback-adres as bewys te behandel dat die versoek op hierdie masjien ontstaan het. Daardie afleiding is presies omgekeerd: die adres is juis daar omdat 'n plaaslike komponent die verbinding gemaak het. 'n Reël wat so geskryf is, laat enigiemand toe wat die luisteraar kan bereik.

Toets die reël, nie die bladsy nie

'n Bladsy wat laai, bewys die deurstuurpad werk en sê niks oor toeskrywing nie. Toets die verbruiker van die adres: die toegangsreël, die tempobeperking, die ouditinskrywing, die geo-opsoek.

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

Vergelyk 'n gemagtigde eksterne versoek met beide die front-end- en agterkant-rekords, en bevestig dat 'n reël wat behoort te weier, steeds weier, en een wat behoort toe te laat, steeds toelaat. As die logreël korrek is maar die reël tree steeds op asof almal plaaslik is, lees die reël 'n ander veld as die een wat jy reggemaak het.

Sluit af deur die toeskrywingsketting in die ontplooiingsnotas te skryf: watter luisteraar, watter deurstuurder, watter kopskrif of kartering, en watter agterkant ingestel is om dit te vertrou. Die volgende persoon wat 'n logreël lees, sal al vier nodig hê, en die afwesigheid van daardie nota is hoe dieselfde kaartjie 'n jaar later weer oopgaan. Hou dit langs die konfigurasie eerder as in 'n kletsdraad.