Ce que REMOTE_ADDR de PHP vous dit vraiment derrière un VPN
C’est une valeur fournie par votre serveur web, pas une consultation du tunnel. Suivez le chemin de la requête, vérifiez qui peut la réécrire et gardez l’identité dans l’application.
Quelqu’un demande pourquoi un utilisateur VPN apparaît dans le journal de l’application avec une adresse qui appartient à la passerelle, ou avec une adresse qui a changé après le déjeuner. La réponse commence par ce qu’est cette valeur : une entrée que le serveur web a placée dans l’environnement de la requête. Ce n’est pas une interrogation du tunnel, ni une identité de certificat, ni la promesse que le numéro appartient à une seule personne. La lire comme l’une de ces trois choses produit des réponses assurées qui sont fausses de différentes manières.
La valeur vient du serveur, pas du tunnel
PHP reçoit l’environnement de la requête de ce qui a exécuté le script. La référence des variables serveur de PHP décrit ces entrées comme créées par le serveur web, avec une disponibilité qui dépend de la façon dont la requête est arrivée.
Un script exécuté comme hook en ligne de commande du VPN est un contexte d’exécution entièrement différent. Il n’a pas de requête web, pas de socket client et pas de REMOTE_ADDR, ce qui explique que du code web copié dans un hook produise des valeurs vides plutôt que fausses. Le hook a son propre environnement, rempli par le démon, et il est documenté séparément. Chercher REMOTE_ADDR à cet endroit, c’est chercher une variable qui n’a jamais été définie.
Gardez cette distinction en tête avant de comparer deux journaux. Vous comparez peut-être une requête de page avec un hook, ce qui n’est pas une comparaison du tout. Vérifiez d’abord le contexte d’exécution, l’adresse ensuite.
Parcourez le chemin de la requête avant de faire confiance au nombre
L’adresse signalée est le pair de la connexion que le serveur web a vue. Intercalez quoi que ce soit entre le client et ce serveur, et le pair change. Traduction, terminaison et répartition déplacent chacune l’observation d’un saut plus loin de l’utilisateur.
Quatre chemins courants produisent quatre observations différentes.
| 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 |
Notez le chemin avec le nom de destination, la famille d’adresses et chaque point de traduction. Sans cette carte, une valeur correcte et une valeur fausse se ressemblent à l’identique dans une ligne de journal. Deux lignes de schéma épargnent un après-midi de discussion.
Le remplacement n’a lieu que là où il est configuré
Un serveur ou un framework peut remplacer délibérément l’adresse du client. Le module remote-IP d’Apache et le module real-IP de NGINX le font tous les deux, et la valeur que PHP reçoit dépend de cette configuration ainsi que des paramètres transmis au gestionnaire de script.
REMOTE_ADDR n’est donc pas universellement le pair TCP intact. C’est le pair tel que le serveur a choisi de le signaler après avoir appliqué sa propre politique. Cette distinction décide si la valeur est une preuve ou une décoration.
Demandez au responsable du serveur quel champ fait foi dans ce déploiement et comment le pair d’origine est conservé lorsque le remplacement a lieu. Si personne ne peut répondre, le journal n’est encore la preuve de rien.
Ne lisez pas les en-têtes de transfert sur parole
Un appelant peut envoyer lui-même des en-têtes de transfert. Traiter la première entrée séparée par une virgule comme une adresse utilisateur vérifiée revient à croire quiconque se connecte, soit l’inverse de ce à quoi sert l’en-tête. L’en-tête décrit une chaîne, et seule une couche de confiance peut garantir cette chaîne.
Utilisez la prise en charge des proxys de confiance du serveur ou du framework avec la chaîne de proxys réelle configurée, et laissez-la écarter les valeurs provenant de sources hors de cette chaîne. L’analyse écrite à la main est là où vivent la plupart des défaillances intéressantes.
Une adresse signalée par un proxy ne change pas non plus la source des paquets que voit un pare-feu en amont. Gardez les métadonnées HTTP et le filtrage réseau comme des observations distinctes, car elles répondent à des questions différentes.
Utilisez l’identité applicative pour décider
Pour accéder aux données d’un utilisateur, appuyez-vous sur le principal authentifié et sur les règles d’autorisation de l’application. Une adresse interne peut être réattribuée, et une adresse traduite peut représenter des centaines d’utilisateurs simultanés. Aucune de ces propriétés ne peut être réparée par un contrôle d’adresse.
Si l’exploitation doit rattacher une requête à une session VPN, joignez l’adresse observée et l’horodatage aux enregistrements de session faisant foi selon le modèle de traduction que vous avez documenté. Cela produit une association défendable ; une adresse seule, non.
Pour le diagnostic, journalisez les quelques champs nécessaires plutôt que tout le tableau serveur, qui peut contenir des en-têtes et du matériel d’authentification. La conclusion utile dit ce que cette valeur signifie dans ce déploiement, pas quelle valeur ressemble le plus à un client.