Por que a túa aplicación de iPhone mostra unha IP e o servidor rexistra outra
Un enderezo de interface, un extremo de socket e a orixe que rexistra un servidor responden a preguntas distintas. Unha VPN engade contexto; non as converte nun só número.
Chegan tickets de soporte que din que a aplicación mostra un enderezo mentres o servidor rexistrou outro, e despois preguntan cal dos dous mente. Non mente ningún; son dúas observacións de dúas cousas distintas. Un enderezo ligado a unha interface, un enderezo ligado a un socket e un enderezo de orixe visto por un servizo remoto responden a tres preguntas separadas. Unha VPN engade un contexto de rede ao teléfono e non colapsa eses tres nun só número para todo o dispositivo. Le os nomes dos campos do ticket antes de ler os enderezos.
Que adoita describir o ticket
Imaxina un teléfono en Wi-Fi cun túnel levantado. A interface Wi-Fi ten un enderezo LAN, a interface do túnel ten un enderezo interno asignado, e unha petición que sae polo túnel chega a un servizo público desde a orixe que sobreviva a calquera tradución no camiño. Unha aplicación que imprime o enderezo interno e un servidor que rexistra a orixe traducida informan ambos con precisión, e os dous valores nunca coincidirán.
As tres observacións difiren no que poden demostrar, non só no 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 |
Manteña esa táboa xunto ao código que enche estes valores nun ticket, porque a maior parte da confusión aquí é unha confusión de columnas e non un fallo de rede.
Que pode e que non pode responder unha chamada de socket
A nivel de API, getsockname informa do punto final local que está actualmente ligado a un socket concreto. Para un socket conectado, esa é a orixe que o núcleo escolleu para esa conexión, o que xa é máis específico que calquera listaxe de interfaces. Non é unha consulta de enderezo público, e chamalo sobre un socket non ligado non che di case nada. O que devolva pode reescribirse máis adiante na ruta, así que só a observación propia do servizo é autoritativa sobre o que recibiu o servizo.
Nas plataformas de Apple, o lado das interfaces ten unha superficie aparte: os axustes do túnel listan os enderezos asignados á interface do túnel. Leelas diche como se configurou o túnel, e non che di que camiño tomou unha petición concreta, porque o encamiñamento e as regras por aplicación deciden iso para cada conexión.
O túnel dividido fai visible a diferenza. Unha petición pode saír polo túnel mentres que a seguinte, dirixida a un destino ou unha familia de enderezos distinta, non o fai, así que dous resultados da mesma aplicación con segundos de diferenza poden ser honestos e distintos.
Escolle a observación que corresponde á pregunta
Escolle a propósito en lugar de instrumentalo todo. Para o que ve o backend, rexistra a orixe no backend, e onde haxa un proxy inverso diante, le o enderezo do cliente da cabeceira de reenvío que o teu despregamento realmente establece, e non de nada que enviase o cliente.
Para saber se o túnel está configurado, le a interface. Para saber se o tráfico desta aplicación o usou, envía tráfico desde esa aplicación a un destino que controles e compara a orixe nos dous extremos.
As regras por aplicación merecen a súa propia frase. O resultado dun navegador é evidencia sobre ese navegador, e un túnel xestionado por aplicación pode pór dúas aplicacións no mesmo teléfono en camiños distintos no mesmo momento. Verificar a cobertura significa enviar tráfico desde a aplicación en cuestión, na familia de enderezos en cuestión.
Os nomes de interface non son un detector
Tampouco uses un nome de interface como comprobación de VPN. Os nomes non son un contrato público, e un teléfono pode ter varios enlaces mentres só un deles leva a túa petición.
Nomea o campo segundo a observación que contén. local_interface_address, socket_local_endpoint e service_observed_source son torpes e inequívocos, e inequívoco é o que queres cando o valor acaba nun ticket de soporte unha semana despois. Unha soa columna chamada device IP reunirá as tres e despois confiarase nela coma se fose unha.
Manteña a identidade fóra da columna de enderezo
Unha saída de VPN compartida non é unha identidade de usuario, e un enderezo privado non é unha credencial de acceso. Ambos describen un camiño e non unha persoa, e tratar calquera dos dous como autenticación converte un accidente de encamiñamento nunha decisión de autorización.
Cando alguén pregunta que enderezo ten o teléfono, a resposta útil é unha pregunta sobre que conexión e que observador. A definición de getsockname merece citarse para o caso intermedio, porque resolve a cuestión do socket sen pretender resolver as outras dúas.
Despois anota cal das tres necesita realmente mostrar o teu produto, e borra as outras dúas da interface.