Hvorfor Port-Share får alle webstedsbesøgende til at se ud som localhost

Hver linje i adgangsloggen viser den samme loopback-adresse, mens siden selv indlæses, og certifikatet valideres korrekt. Intet er i stykker i betydningen utilgængeligt, og derfor overlever dette i månedsvis. Det, der gik i stykker, er tilskrivningen: webbackenden registrerer adressen på det hop, der videresendte forbindelsen, og enhver efterfølgende beslutning, der stolede på loggen, arvede det samme forkerte svar.

Kontrollerne nedenfor går fra kablet og indad. Stop ved den første, der forklarer den værdi, du ser, fordi hvert senere trin forudsætter, at de tidligere allerede er sande. Ingen af dem kræver, at du gætter på frontend-konfigurationen.

Følg de to forbindelser, ikke loglinjen

Port-Share multiplekser to protokoller på én TCP-lytter. OpenVPN undersøger de første bytes af en indgående forbindelse, beholder den, når den ligner dens egen protokol, og giver alt andet videre til en anden destination. Den destination er normalt en webserver på samme vært, så webserverens accepterede socket har OpenVPN-processen som peer.

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

Den første kommando viser, hvem der ejer den offentlige lytter. Den anden viser de forbindelser, der ankommer til backend-porten, og deres peer-adresse er den, adgangsloggen vil udskrive. Hvis den peer er loopback, er loggen korrekt, og informationen gik tabt et lag tidligere. At omdøbe logfeltet eller aktivere et klient-IP-modul vil ikke genskabe en adresse, som forbindelsen aldrig bar.

Det er den kontrol, der afgør alt andet. Hvis backendens peer er browserens adresse, er portdeling ikke dit problem, og logformatet er.

Transportvideresendelse er ikke header-injektion

Videresenderen flytter bytes. Den parser ikke HTTP, så den kan ikke indsætte en header i en anmodning, den aldrig læser som en anmodning, og den kan ikke tilføje noget til en TLS-strøm, den sender videre urørt. Et modul, der forventer en proxy-header, vil blive ved med at vente på en, som ingen komponent producerer.

To mekanismer kan bære den oprindelige adresse, og begge kræver enighed i begge ender. PROXY-protokollen sætter en lille header foran forbindelsen, og backenden skal være konfigureret til at forvente den; en backend, der ikke forventer den, vil behandle de bytes som starten på anmodningen og fejle på en forvirrende måde. Betroede proxy-headere som X-Forwarded-For virker, når en HTTP-bevidst proxy sætter dem, og backenden får at vide, hvilke peers der må hævde dem.

Ingen af dem er automatisk, og ingen af dem er sikker som standard. En backend, der tror på enhver indgående videresendt header, lader en klient vælge sin egen adresse, hvilket gør en unøjagtighed i loggen til en omgåelse af adgangskontrollen. Kør demonstrationen én gang på en staging-vært, før du stoler på nogen header på en produktionsvej.

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 kildekortlægningsmappe

Portdeling har et valgfrit mappeargument, der registrerer en kortlægning mellem den oprindelige kildeadresse og videresendelsesforbindelsen, på platforme hvor funktionen er implementeret. Websiden forventes at konsultere den kortlægning; det er ikke en header, og den injiceres ikke i anmodningen.

Det design er værd at kende, fordi det forklarer, hvorfor nogle installationer rapporterer rigtige adresser og andre ikke, med tilsyneladende identisk frontend-konfiguration. Forskellen er på modtagersiden, og den bor normalt i et modul eller en patch, som de fleste pakkede webservere ikke aktiverer som standard. Læs din webservers dokumentation for den præcise hook, den tilbyder, og bekræft, at modulet er indlæst i stedet for at antage det.

Hvis du går den vej, så behandl det som en integration med to halvdele: kortlægningen, som videresenderen skriver, og opslaget, som backenden udfører. Verificér begge, og bekræft, at mappen overlever en genstart og ikke vokser ubegrænset på en travl lytter.

Beslut, hvilken komponent der garanterer for adressen

Før du ændrer konfigurationen, navngiv den komponent, der må hævde en klientadresse, og de komponenter, der må tro på den. Et enkelt nedskrevet svar forhindrer den sædvanlige drift, hvor tre forskellige lag hver stoler på en forskellig kilde.

Tre designs dækker de fleste behov. Hold den offentlige lytter og weblytteren adskilt, så webserveren ser rigtige peers, og der ikke opstår noget tilskrivningsproblem. Sæt en HTTP-bevidst omvendt proxy foran, afslut eller pars anmodningen der, og lad den sætte en videresendt header for en backend, der kun stoler på den proxy. Eller behold portdelingen og accepter, at loggene viser hoppet, med adgangsregler skrevet mod applikationsidentitet i stedet for en adresse.

Det, der ikke virker, er at behandle en videresendt loopback-adresse som bevis for, at anmodningen opstod på denne maskine. Den slutning er præcis omvendt: adressen er til stede netop, fordi en lokal komponent oprettede forbindelsen. En regel skrevet sådan lukker enhver ind, der kan nå lytteren.

Test reglen, ikke siden

En side, der indlæses, beviser, at videresendelsesvejen virker, og siger intet om tilskrivning. Test adressens forbruger: adgangsreglen, hastighedsgrænsen, revisionsposten, geo-opslaget.

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 autoriseret ekstern anmodning med både frontend- og backend-posterne, og bekræft, at en regel, der burde afvise, stadig afviser, og en, der burde tillade, stadig tillader. Hvis loglinjen er korrekt, men reglen stadig opfører sig, som om alle er lokale, læser reglen et andet felt end det, du rettede.

Afslut med at skrive tilskrivningskæden i udrulningsnoterne: hvilken lytter, hvilken videresender, hvilken header eller kortlægning og hvilken backend der er konfigureret til at stole på den. Den næste person, der læser en loglinje, får brug for alle fire, og fraværet af den note er, hvordan den samme sag genåbnes et år senere. Hold den ved siden af konfigurationen i stedet for i en chat-tråd.