Qué dice realmente REMOTE_ADDR de PHP detrás de una VPN

Alguien pregunta por qué un usuario de VPN aparece en el registro de la aplicación con una dirección que pertenece a la puerta de enlace, o con una dirección que cambió después de comer. La respuesta empieza por qué es ese valor: una entrada que el servidor web colocó en el entorno de la petición. No es una consulta al túnel, ni una identidad de certificado, ni la promesa de que el número pertenece a una sola persona. Leerlo como cualquiera de esas tres cosas produce respuestas seguras que están equivocadas de maneras distintas.

El valor viene del servidor, no del túnel

PHP recibe el entorno de la petición de lo que ejecutó el script. La referencia de variables de servidor de PHP describe estas entradas como creadas por el servidor web, con una disponibilidad que depende de cómo llegó la petición.

Un script que se ejecuta como hook de línea de comandos de la VPN es un contexto de ejecución completamente distinto. No tiene petición web, ni socket de cliente, ni REMOTE_ADDR, y por eso copiar código web dentro de un hook produce valores vacíos en lugar de valores erróneos. El hook tiene su propio entorno, poblado por el demonio, y está documentado por separado. Buscar REMOTE_ADDR ahí es buscar una variable que nunca se definió.

Tenga presente esa distinción antes de comparar dos registros. Puede estar comparando una petición de página con un hook, lo que no es una comparación en absoluto. Compruebe primero el contexto de ejecución y después la dirección.

Recorra la ruta de la petición antes de confiar en el número

La dirección reportada es el par de la conexión que vio el servidor web. Introduzca cualquier cosa entre el cliente y ese servidor y el par cambia. La traducción, la terminación y el balanceo mueven cada una la observación un salto más lejos del usuario.

Cuatro rutas habituales producen cuatro observaciones distintas.

Anote la ruta con el nombre del destino, la familia de direcciones y cada punto de traducción. Sin ese mapa, un valor correcto y un valor erróneo se ven idénticos en una línea de registro. Dos líneas de diagrama ahorran una tarde de discusión.

Solo se sustituye donde está configurado

Un servidor o un framework puede sustituir deliberadamente la dirección del cliente. El módulo remote-IP de Apache y el módulo real-IP de NGINX hacen exactamente eso, y el valor que recibe PHP depende de esa configuración y de los parámetros que se pasan al manejador del script.

Así que REMOTE_ADDR no es universalmente el par TCP intacto. Es el par tal como el servidor decidió reportarlo tras aplicar su propia política. Esa distinción decide si el valor es una prueba o un adorno.

Pregunte al responsable del servidor qué campo es autoritativo en este despliegue y cómo se conserva el par original cuando hay sustitución. Si nadie puede responder, el registro todavía no prueba nada.

No lea las cabeceras de reenvío con fe

Quien llama puede enviar él mismo cabeceras de reenvío. Tratar la primera entrada separada por comas como una dirección de usuario verificada es decidir creer a quien se conecte, justo lo contrario de para lo que sirve la cabecera. La cabecera describe una cadena, y solo una capa de confianza puede responder por esa cadena.

Use el soporte de proxies de confianza del servidor o del framework con la cadena de proxies real configurada, y deje que descarte los valores de fuentes ajenas a esa cadena. El análisis escrito a mano es donde viven la mayoría de los fallos interesantes.

Una dirección reportada por un proxy tampoco cambia el origen de los paquetes que ve un cortafuegos anterior. Mantenga los metadatos HTTP y el filtrado de red como observaciones separadas, porque responden a preguntas distintas.

Use la identidad de la aplicación para decidir

Para acceder a los registros de un usuario, apóyese en el principal autenticado y en las reglas de autorización de la aplicación. Una dirección interna puede reasignarse, y una dirección traducida puede representar a cientos de usuarios simultáneos. Ninguna de esas propiedades puede repararla una comprobación de dirección.

Si las operaciones necesitan vincular una petición a una sesión VPN, una la dirección observada y la marca de tiempo con los registros de sesión autoritativos según el modelo de traducción que documentó. Eso produce una asociación defendible; una dirección sola, no.

Para el diagnóstico, registre los pocos campos que necesita en lugar de toda la matriz del servidor, que puede llevar cabeceras y material de autenticación. La conclusión útil dice qué significa este valor en este despliegue, no qué valor se parece más a un cliente.