Hva PHPs REMOTE_ADDR faktisk forteller deg bak en VPN
Det er en verdi webseveren din leverte, ikke et oppslag i tunnelen. Gå gjennom forespørselens vei, kontroller hvem som kan skrive den om, og behold identiteten i applikasjonen.
Noen spør hvorfor en VPN-bruker dukker opp i applikasjonsloggen med en adresse som tilhører gatewayen, eller med en adresse som endret seg etter lunsj. Svaret begynner med hva verdien er: en oppføring som webseveren la i forespørselsmiljøet. Det er ikke et oppslag i tunnelen, ikke en sertifikatidentitet og ikke et løfte om at nummeret tilhører én person. Å lese det som en av de tre gir selvsikre svar som er feil på ulike måter.
Verdien kommer fra serveren, ikke fra tunnelen
PHP mottar forespørselsmiljøet fra det som kjørte skriptet. PHP-referansen for servervariabler beskriver disse oppføringene som laget av webseveren, med en tilgjengelighet som avhenger av hvordan forespørselen kom inn.
Et skript som kjøres som kommandolinje-hook i VPN-en, er en helt annen kjørekontekst. Det har ingen webforespørsel, ingen klientsocket og ingen REMOTE_ADDR, og derfor gir kopiert webkode i en hook tomme verdier i stedet for feil. Hooken har sitt eget miljø, fylt av daemonen, og det er dokumentert separat. Å strekke seg etter REMOTE_ADDR der er å strekke seg etter en variabel som aldri ble satt.
Hold den forskjellen i tankene før du sammenligner to logger. Du sammenligner kanskje en sideforespørsel med en hook, og det er ikke en sammenligning i det hele tatt. Kontroller kjørekonteksten først og adressen etterpå.
Gå forespørselens vei før du stoler på nummeret
Den rapporterte adressen er peer for den tilkoblingen webseveren så. Sett noe mellom klienten og den serveren, og peeren endres. Oversettelse, terminering og lastbalansering flytter hver observasjonen ett hopp lenger vekk fra brukeren.
Fire vanlige veier gir fire ulike observasjoner.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
Skriv ned veien med destinasjonsnavnet, adressefamilien og hvert oversettelsespunkt. Uten det kartet ser en riktig og en feil verdi identiske ut i en logglinje. To linjer diagram sparer en ettermiddag med diskusjon.
Erstatning skjer bare der den er konfigurert
En server eller et rammeverk kan bevisst erstatte klientadressen. Apaches remote-IP-modul og NGINX' real-IP-modul gjør begge dette, og verdien PHP mottar avhenger av den konfigurasjonen pluss parameterne som sendes til skripthandleren.
REMOTE_ADDR er altså ikke universelt den urørte TCP-peeren. Det er peeren slik serveren valgte å rapportere den etter å ha brukt sin egen policy. Den forskjellen avgjør om verdien er bevis eller dekorasjon.
Spør servereieren hvilket felt som er autoritativt i denne installasjonen, og hvordan den opprinnelige peeren bevares når erstatning skjer. Hvis ingen kan svare, er loggen ennå ikke bevis for noe.
Ikke les videresendingsheadere på tillit
En kallende part kan sende videresendingsheadere selv. Å behandle den første kommaadskilte oppføringen som en verifisert brukeradresse er å bestemme seg for å tro på hvem som helst som kobler til, som er det motsatte av hva headeren er til for. Headeren beskriver en kjede, og bare et klarert lag kan gå god for den kjeden.
Bruk serverens eller rammeverkets støtte for klarerte proxyer med den faktiske proxykjeden konfigurert, og la den forkaste verdier fra kilder utenfor den kjeden. Håndskrevet parsing er der de fleste interessante feilene bor.
En proxyrapportert adresse endrer heller ikke pakkekilden som en brannmur lenger opp ser. Hold HTTP-metadata og nettverksfiltrering som separate observasjoner, fordi de svarer på ulike spørsmål.
Bruk applikasjonens identitet til beslutninger
For tilgang til en brukers poster må du stole på den autentiserte principalen og applikasjonens autorisasjonsregler. En intern adresse kan tildeles på nytt, og én oversatt adresse kan stå for hundrevis av samtidige brukere. Ingen av disse egenskapene kan en adressekontroll reparere.
Hvis drift trenger å knytte en forespørsel til en VPN-økt, koble den observerte adressen og tidsstempelet til autoritative øktposter etter oversettelsesmodellen du har dokumentert. Det gir en assosiasjon du kan forsvare; en adresse alene gjør det ikke.
Logg for diagnostikk de få feltene du trenger i stedet for hele serverarrayet, som kan bære headere og autentiseringsmateriale. Den nyttige konklusjonen sier hva denne verdien betyr i denne installasjonen, ikke hvilken verdi som ligner mest på en klient.