Kvifor Port-Share får alle vitjande på nettstaden til å sjå ut som localhost

Kvar linje i tilgangsloggen viser same loopback-adresse, medan sida sjølv blir lasta og sertifikatet blir validert rett. Ingenting er øydelagt i tydinga utilgjengeleg, og difor overlever dette i månadsvis. Det som gjekk i stykket, er tildelinga: web-bakenden registrerer adressa til hoppet som videresende sambandet, og kvar seinare avgjerd som stolte på loggen, arva det same feil svaret.

Kontrollane nedanfor går frå kabelen og innover. Stopp ved den fyrste som forklarer verdien du ser, fordi kvart seinare steg føreset at dei tidlegare allereie er sanne. Ingen av dei krev at du gissar på frontend-konfigurasjonen.

Følg dei to sambanda, ikkje logglinja

Port-Share multipleksar to protokollar på éin TCP-lyttar. OpenVPN granskar dei fyrste byta av eit innkomande samband, held det når det ser ut som hans eigen protokoll, og overlèt alt anna til ein annan destinasjon. Den destinasjonen er vanlegvis ein webserver på same verten, så den aksepterte socketen til webserveren har OpenVPN-prosessen som motpart.

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

Den fyrste kommandoen viser kven som eig den offentlege lyttaren. Den andre viser sambanda som kjem til backend-porten, og motpartadressa deira er den tilgangsloggen vil skrive ut. Om den motparten er loopback, er loggen nøyaktig og informasjonen gjekk tapt eitt lag tidlegare. Å gje loggfeltet nytt namn eller slå på ein klient-IP-modul vil ikkje gjenopprette ei adresse som sambandet aldri bar.

Dette er kontrollen som avgjer alt anna. Om motparten til bakenden er adressa til nettlesaren, er portdeling ikkje problemet ditt, og loggformatet er det.

Transportvideresending er ikkje header-injeksjon

Videresendaren flyttar byte. Han parsar ikkje HTTP, så han kan ikkje setje inn ein header i ein førespurnad han aldri les som ein førespurnad, og han kan ikkje leggje noko til ein TLS-straum han sender vidare urørt. Ein modul som ventar på ein proxy-header, vil halde fram med å vente på ein som ingen komponent produserer.

To mekanismar kan bera den opphavlege adressa, og begge krev semje i begge endar. PROXY-protokollen set ein liten header framom sambandet, og bakenden må vere konfigurert til å vente på han; ein bakende som ikkje ventar på han, vil handsame desse byta som starten på førespurnaden og feile på ein forvirrande måte. Trudde proxy-headarar som X-Forwarded-For verkar når ein HTTP-medviten proxy set dei, og bakenden får beskjed om kva motpartar som har lov til å hevde dei.

Ingen av dei er automatisk, og ingen av dei er sikker som standard. Ein bakende som trur på kvar innkomande videresend header, lèt ein klient velje si eiga adresse, noko som gjer ein unøyaktigheit i loggen om til ei omgåing av tilgangskontrollen. Køyr demonstrasjonen éin gong på ein testvert før du stolar på nokon header på ein produksjonsveg.

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

Den valfrie kjeldekartleggingsmappa

Portdeling har eit valfritt mappeargument som registrerer ei kartlegging mellom den opphavlege kjeldeadressa og videresendingssambandet, på plattformer der funksjonen er implementert. Websida er venta å konsultere den kartlegginga; det er ikkje ein header, og ho blir ikkje injisert i førespurnaden.

Det designet er verdt å kjenne, fordi det forklarer kvifor nokre installasjonar rapporterer ekte adresser og andre ikkje, med tilsynelatande identisk frontend-konfigurasjon. Skilnaden er på mottakarsida, og han bur vanlegvis i ein modul eller ein patch som dei fleste pakka webserverar ikkje slår på som standard. Les dokumentasjonen til webserveren din for den nøyaktige kroken han tilbyr, og stadfest at modulen er lasta i staden for å anta det.

Om du går denne vegen, handsam det som ein integrasjon med to halvdelar: kartlegginga som videresendaren skriv, og oppslaget som bakenden gjer. Verifiser begge, og stadfest at mappa overlever ein omstart og ikkje veks ubegrensa på ein travel lyttar.

Avgjer kva komponent som garanterer for adressa

Før du endrar konfigurasjonen, nemn komponenten som har lov til å hevde ei klientadresse, og komponentane som har lov til å tru på henne. Eitt nedskrive svar hindrar den vanlege drifta, der tre ulike lag kvar stolar på ei ulik kjelde.

Tre design dekkjer dei fleste behov. Hald den offentlege lyttaren og web-lyttaren åtskilde, slik at webserveren ser ekte motpartar og det ikkje oppstår noko tildelingsproblem. Set ein HTTP-medviten omvend proxy framom, avslutt eller pars førespurnaden der, og læt han setje ein videresend header for ein bakende som berre stolar på den proxyen. Eller hald portdelinga og aksepter at loggane viser hoppet, med tilgangsreglar skrivne mot applikasjonsidentitet i staden for ei adresse.

Det som ikkje verkar, er å handsame ei videresend loopback-adresse som prov på at førespurnaden oppstod på denne maskina. Den slutninga er nøyaktig omvend: adressa er til stades nettopp fordi ein lokal komponent oppretta sambandet. Ein regel skriven slik slepp inn kven som helst som kan nå lyttaren.

Test regelen, ikkje sida

Ei side som blir lasta, provar at videresendingsvegen verkar, og seier ingenting om tildeling. Test forbrukaren av adressa: tilgangsregelen, hastigheitsavgrensinga, revisjonsoppføringa, geo-oppslaget.

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

Samanlikn ein autorisert ekstern førespurnad med både frontend- og backend-postane, og stadfest at ein regel som burde avvise framleis avviser, og ein som burde tillate framleis tillèt. Om logglinja er rett, men regelen framleis oppfører seg som om alle er lokale, les regelen eit anna felt enn det du retta.

Avslutt med å skrive tildelingskjeda i utrullingsnotata: kva lyttar, kva videresendar, kva header eller kartlegging og kva bakende som er konfigurert til å stole på henne. Den neste personen som les ei logglinje, treng alle fire, og fråværet av det notatet er korleis same saka blir opna på nytt eitt år seinare. Hald det ved sida av konfigurasjonen i staden for i ein chat-trad.