Por qué tu aplicación de iPhone muestra una IP y el servidor registra otra
Una dirección de interfaz, un extremo de socket y la fuente que registra un servidor responden a preguntas distintas. Una VPN añade contexto; no las convierte en un solo número.
Llegan tickets de soporte que dicen que la aplicación muestra una dirección mientras el servidor registró otra, y luego preguntan cuál de las dos miente. No miente ninguna; son dos observaciones de dos cosas distintas. Una dirección vinculada a una interfaz, una dirección vinculada a un socket y una dirección de origen vista por un servicio remoto responden a tres preguntas separadas. Una VPN añade un contexto de red al teléfono y no colapsa esas tres en un solo número para todo el dispositivo. Lee los nombres de los campos del ticket antes de leer las direcciones.
Qué suele describir el ticket
Imagina un teléfono en Wi-Fi con un túnel levantado. La interfaz Wi-Fi tiene una dirección LAN, la interfaz del túnel tiene una dirección interna asignada, y una petición que sale por el túnel llega a un servicio público desde la fuente que sobreviva a cualquier traducción en el camino. Una aplicación que imprime la dirección interna y un servidor que registra la fuente traducida informan ambos con precisión, y los dos valores nunca coincidirán.
Las tres observaciones difieren en lo que pueden demostrar, no solo en lo que describen.
| Observation | What it describes | What it cannot prove |
|---|---|---|
| An address on a local interface | One configured attachment: Wi-Fi, cellular or a tunnel | The source a remote site receives |
| A socket's local endpoint | The binding used by that one connection | The address after translation further along |
| The peer address at a service | What arrived at that observation point | Any other interface on the phone |
Mantén esa tabla junto al código que rellena estos valores en un ticket, porque la mayor parte de la confusión aquí es una confusión de columnas y no un fallo de red.
Qué puede y qué no puede responder una llamada de socket
A nivel de API, getsockname informa del punto final local que está actualmente vinculado a un socket concreto. Para un socket conectado, esa es la fuente que el núcleo eligió para esa conexión, lo cual ya es más específico que cualquier listado de interfaces. No es una consulta de dirección pública, y llamarlo sobre un socket no vinculado no te dice casi nada. Lo que devuelva puede reescribirse más adelante en la ruta, así que solo la observación propia del servicio es autoritativa sobre lo que recibió el servicio.
En las plataformas de Apple, el lado de las interfaces tiene una superficie aparte: los ajustes del túnel listan las direcciones asignadas a la interfaz del túnel. Leerlas te dice cómo se configuró el túnel, y no te dice qué camino tomó una petición concreta, porque el enrutamiento y las reglas por aplicación lo deciden para cada conexión.
El túnel dividido hace visible la diferencia. Una petición puede salir por el túnel mientras que la siguiente, dirigida a un destino o una familia de direcciones distinta, no lo hace, así que dos resultados de la misma aplicación con segundos de diferencia pueden ser honestos y distintos.
Elige la observación que corresponde a la pregunta
Elige a propósito en lugar de instrumentarlo todo. Para lo que ve el backend, registra la fuente en el backend, y donde haya un proxy inverso delante, lee la dirección del cliente de la cabecera de reenvío que tu despliegue realmente establece, y no de nada que haya enviado el cliente.
Para saber si el túnel está configurado, lee la interfaz. Para saber si el tráfico de esta aplicación lo usó, envía tráfico desde esa aplicación a un destino que controles y compara la fuente en ambos extremos.
Las reglas por aplicación merecen su propia frase. El resultado de un navegador es evidencia sobre ese navegador, y un túnel gestionado por aplicación puede poner dos aplicaciones en el mismo teléfono en caminos distintos en el mismo momento. Verificar la cobertura significa enviar tráfico desde la aplicación en cuestión, en la familia de direcciones en cuestión.
Los nombres de interfaz no son un detector
Tampoco uses un nombre de interfaz como comprobación de VPN. Los nombres no son un contrato público, y un teléfono puede tener varios enlaces mientras solo uno de ellos lleva tu petición.
Nombra el campo según la observación que contiene. local_interface_address, socket_local_endpoint y service_observed_source son torpes e inequívocos, e inequívoco es lo que quieres cuando el valor acaba en un ticket de soporte una semana después. Una sola columna llamada device IP reunirá las tres y luego se confiará en ella como si fuera una.
Mantén la identidad fuera de la columna de dirección
Una salida de VPN compartida no es una identidad de usuario, y una dirección privada no es una credencial de acceso. Ambas describen un camino y no a una persona, y tratar cualquiera de las dos como autenticación convierte un accidente de enrutamiento en una decisión de autorización.
Cuando alguien pregunta qué dirección tiene el teléfono, la respuesta útil es una pregunta sobre qué conexión y qué observador. La definición de getsockname merece citarse para el caso intermedio, porque resuelve la cuestión del socket sin pretender resolver las otras dos.
Luego anota cuál de las tres necesita realmente mostrar tu producto, y borra las otras dos de la interfaz.