Hvorfor Port-Share får alle nettstedets besøkende til å se ut som localhost

Hver linje i tilgangsloggen viser samme loopback-adresse, mens siden selv lastes og sertifikatet valideres riktig. Ingenting er ødelagt i betydningen utilgjengelig, og derfor overlever dette i månedsvis. Det som gikk i stykker, er tilskrivningen: web-bakenden registrerer adressen til hoppet som videresendte forbindelsen, og hver senere beslutning som stolte på loggen, arvet det samme feil svaret.

Kontrollene nedenfor går fra kabelen og innover. Stopp ved den første som forklarer verdien du ser, fordi hvert senere trinn forutsetter at de tidligere allerede er sanne. Ingen av dem krever at du gjetter på frontend-konfigurasjonen.

Følg de to forbindelsene, ikke logglinjen

Port-Share multiplekser to protokoller på én TCP-lytter. OpenVPN undersøker de første bytene av en innkommende forbindelse, beholder den når den ser ut som dens egen protokoll, og overlater alt annet til en annen destinasjon. Den destinasjonen er vanligvis en webserver på samme vert, så webserverens aksepterte socket har OpenVPN-prosessen som motpart.

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

Den første kommandoen viser hvem som eier den offentlige lytteren. Den andre viser forbindelsene som ankommer backend-porten, og deres motpart-adresse er den tilgangsloggen vil skrive ut. Hvis den motparten er loopback, er loggen nøyaktig og informasjonen gikk tapt ett lag tidligere. Å gi loggfeltet nytt navn eller aktivere en klient-IP-modul vil ikke gjenopprette en adresse forbindelsen aldri bar.

Dette er kontrollen som avgjør alt annet. Hvis bakendens motpart er nettleserens adresse, er portdeling ikke problemet ditt, og loggformatet er det.

Transportvideresending er ikke header-injeksjon

Videresenderen flytter bytes. Den parser ikke HTTP, så den kan ikke sette inn en header i en forespørsel den aldri leser som en forespørsel, og den kan ikke legge noe til en TLS-strøm den sender videre urørt. En modul som forventer en proxy-header, vil fortsette å vente på en som ingen komponent produserer.

To mekanismer kan bære den opprinnelige adressen, og begge krever enighet i begge ender. PROXY-protokollen setter en liten header foran forbindelsen, og bakenden må være konfigurert til å forvente den; en bakende som ikke forventer den, vil behandle disse bytene som starten på forespørselen og feile på en forvirrende måte. Betrodde proxy-headere som X-Forwarded-For virker når en HTTP-bevisst proxy setter dem, og bakenden får beskjed om hvilke motparter som har lov til å hevde dem.

Ingen av dem er automatisk, og ingen av dem er sikker som standard. En bakende som tror på enhver innkommende videresendt header, lar en klient velge sin egen adresse, noe som gjør en unøyaktighet i loggen om til en omgåelse av tilgangskontrollen. Kjør demonstrasjonen én gang på en testvert før du stoler på noen header på en produksjonsvei.

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 valgfrie kildekartleggingsmappen

Portdeling har et valgfritt mappeargument som registrerer en kartlegging mellom den opprinnelige kildeadressen og videresendingsforbindelsen, på plattformer der funksjonen er implementert. Websiden forventes å konsultere den kartleggingen; det er ikke en header, og den injiseres ikke i forespørselen.

Det designet er verdt å kjenne, fordi det forklarer hvorfor noen installasjoner rapporterer ekte adresser og andre ikke, med tilsynelatende identisk frontend-konfigurasjon. Forskjellen er på mottakersiden, og den bor vanligvis i en modul eller en patch som de fleste pakkede webservere ikke aktiverer som standard. Les dokumentasjonen til webserveren din for den nøyaktige kroken den tilbyr, og bekreft at modulen er lastet i stedet for å anta det.

Hvis du går denne veien, behandle det som en integrasjon med to halvdeler: kartleggingen som videresenderen skriver, og oppslaget som bakenden utfører. Verifiser begge, og bekreft at mappen overlever en omstart og ikke vokser ubegrenset på en travel lytter.

Avgjør hvilken komponent som garanterer for adressen

Før du endrer konfigurasjonen, navngi komponenten som har lov til å hevde en klientadresse, og komponentene som har lov til å tro på den. Ett nedskrevet svar forhindrer den vanlige driften, der tre forskjellige lag hver stoler på en forskjellig kilde.

Tre design dekker de fleste behov. Hold den offentlige lytteren og web-lytteren atskilt, slik at webserveren ser ekte motparter og det ikke oppstår noe tilskrivningsproblem. Sett en HTTP-bevisst omvendt proxy foran, avslutt eller parse forespørselen der, og la den sette en videresendt header for en bakende som bare stoler på den proxyen. Eller behold portdelingen og aksepter at loggene viser hoppet, med tilgangsregler skrevet mot applikasjonsidentitet i stedet for en adresse.

Det som ikke virker, er å behandle en videresendt loopback-adresse som bevis på at forespørselen oppsto på denne maskinen. Den slutningen er nøyaktig omvendt: adressen er til stede nettopp fordi en lokal komponent opprettet forbindelsen. En regel skrevet slik slipper inn enhver som kan nå lytteren.

Test regelen, ikke siden

En side som lastes, beviser at videresendingsveien virker, og sier ingenting om tilskrivning. Test forbrukeren av adressen: tilgangsregelen, hastighetsbegrensningen, revisjonsoppføringen, 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

Sammenlign en autorisert ekstern forespørsel med både frontend- og bakendepostene, og bekreft at en regel som burde avvise fortsatt avviser, og en som burde tillate fortsatt tillater. Hvis logglinjen er riktig, men regelen fortsatt oppfører seg som om alle er lokale, leser regelen et annet felt enn det du rettet.

Avslutt med å skrive tilskrivningskjeden i utrullingsnotatene: hvilken lytter, hvilken videresender, hvilken header eller kartlegging og hvilken bakende som er konfigurert til å stole på den. Den neste personen som leser en logglinje, trenger alle fire, og fraværet av det notatet er hvordan samme sak gjenåpnes et år senere. Hold det ved siden av konfigurasjonen i stedet for i en chat-tråd.