Che cosa dice davvero REMOTE_ADDR di PHP dietro una VPN
È un valore fornito dal server web, non un’interrogazione del tunnel. Segui il percorso della richiesta, controlla chi può riscriverlo e tieni l’identità nell’applicazione.
Qualcuno chiede perché un utente VPN compaia nel log dell’applicazione con un indirizzo che appartiene al gateway, oppure con un indirizzo cambiato dopo pranzo. La risposta parte da che cosa è quel valore: una voce che il server web ha inserito nell’ambiente della richiesta. Non è un’interrogazione del tunnel, non è un’identità di certificato e non è la promessa che il numero appartenga a una sola persona. Leggerlo come una di queste tre cose produce risposte sicure che sono sbagliate in modi diversi.
Il valore viene dal server, non dal tunnel
PHP riceve l’ambiente della richiesta da ciò che ha eseguito lo script. Il riferimento alle variabili del server di PHP descrive queste voci come create dal server web, con una disponibilità che dipende da come è arrivata la richiesta.
Uno script eseguito come hook da riga di comando della VPN è un contesto di esecuzione del tutto diverso. Non ha richiesta web, non ha socket client e non ha REMOTE_ADDR, ed è per questo che copiare codice web in un hook produce valori vuoti invece che sbagliati. L’hook ha un proprio ambiente, popolato dal demone, ed è documentato separatamente. Cercare REMOTE_ADDR lì significa cercare una variabile che non è mai stata impostata.
Tieni presente questa distinzione prima di confrontare due log. Potresti confrontare una richiesta di pagina con un hook, e non sarebbe affatto un confronto. Controlla prima il contesto di esecuzione e poi l’indirizzo.
Percorri il percorso della richiesta prima di fidarti del numero
L’indirizzo riportato è il peer della connessione che il server web ha visto. Inserisci qualcosa tra il client e quel server e il peer cambia. Traduzione, terminazione e bilanciamento spostano ciascuna l’osservazione di un salto più lontano dall’utente.
Quattro percorsi comuni producono quattro osservazioni diverse.
| 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 |
Annota il percorso con il nome di destinazione, la famiglia di indirizzi e ogni punto di traduzione. Senza quella mappa, un valore corretto e un valore sbagliato sembrano identici in una riga di log. Due righe di schema risparmiano un pomeriggio di discussione.
La sostituzione avviene solo dove è configurata
Un server o un framework può sostituire deliberatamente l’indirizzo del client. Il modulo remote-IP di Apache e il modulo real-IP di NGINX fanno entrambi questo, e il valore che PHP riceve dipende da quella configurazione e dai parametri passati al gestore dello script.
Quindi REMOTE_ADDR non è universalmente il peer TCP intatto. È il peer come il server ha scelto di riportarlo dopo aver applicato la propria politica. Questa distinzione decide se il valore è una prova o un ornamento.
Chiedi al responsabile del server quale campo è autorevole in questo deployment e come viene conservato il peer originale quando avviene la sostituzione. Se nessuno sa rispondere, il log non è ancora prova di nulla.
Non leggere le intestazioni di inoltro sulla fiducia
Un chiamante può inviare da sé le intestazioni di inoltro. Trattare la prima voce separata da virgole come indirizzo utente verificato è decidere di credere a chiunque si connetta, cioè l’opposto di ciò a cui serve l’intestazione. L’intestazione descrive una catena, e solo uno strato fidato può garantire quella catena.
Usa il supporto ai proxy fidati del server o del framework con la catena di proxy reale configurata, e lascia che scarti i valori provenienti da fonti esterne a quella catena. L’analisi scritta a mano è dove vive la maggior parte dei guasti interessanti.
Un indirizzo riportato da un proxy non cambia nemmeno l’origine dei pacchetti che vede un firewall a monte. Tieni i metadati HTTP e il filtraggio di rete come osservazioni separate, perché rispondono a domande diverse.
Usa l’identità dell’applicazione per decidere
Per l’accesso ai dati di un utente, affidati al principal autenticato e alle regole di autorizzazione dell’applicazione. Un indirizzo interno può essere riassegnato, e un indirizzo tradotto può rappresentare centinaia di utenti simultanei. Nessuna di queste proprietà può essere riparata da un controllo dell’indirizzo.
Se le operazioni devono collegare una richiesta a una sessione VPN, unisci l’indirizzo osservato e la marca temporale ai registri di sessione autorevoli secondo il modello di traduzione che hai documentato. Questo produce un’associazione difendibile; un indirizzo da solo no.
Per la diagnosi, registra i pochi campi che ti servono invece dell’intero array del server, che può contenere intestazioni e materiale di autenticazione. La conclusione utile dice che cosa significa questo valore in questo deployment, non quale valore assomiglia di più a un client.