Pourquoi votre application iPhone affiche une IP et le serveur en enregistre une autre
Une adresse d'interface, un point de terminaison de socket et la source qu'un serveur enregistre répondent à des questions différentes. Un VPN ajoute du contexte ; il n'en fait pas un seul numéro.
Des tickets de support arrivent disant que l'application affiche une adresse alors que le serveur en a enregistré une autre, puis demandent laquelle des deux ment. Ni l'une ni l'autre ; ce sont deux observations de deux choses différentes. Une adresse liée à une interface, une adresse liée à une socket et une adresse source vue par un service distant répondent à trois questions distinctes. Un VPN ajoute un contexte réseau au téléphone et ne réduit pas ces trois à un seul numéro pour tout l'appareil. Lisez les noms des champs du ticket avant de lire les adresses.
Ce que le ticket décrit habituellement
Imaginez un téléphone en Wi-Fi avec un tunnel monté. L'interface Wi-Fi porte une adresse LAN, l'interface du tunnel porte une adresse interne attribuée, et une requête qui sort par le tunnel arrive à un service public depuis la source qui survit à toute traduction en chemin. Une application qui imprime l'adresse interne et un serveur qui enregistre la source traduite rapportent tous deux avec exactitude, et les deux valeurs ne coïncideront jamais.
Les trois observations diffèrent par ce qu'elles peuvent prouver, pas seulement par ce qu'elles décrivent.
| 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 |
Gardez ce tableau à côté du code qui remplit ces valeurs dans un ticket, car l'essentiel de la confusion ici est une inversion de colonnes et non une panne réseau.
Ce qu'un appel de socket peut et ne peut pas répondre
Au niveau de l'API, getsockname indique le point de terminaison local actuellement lié à une socket précise. Pour une socket connectée, c'est la source que le noyau a choisie pour cette connexion, ce qui est déjà plus précis que n'importe quelle liste d'interfaces. Ce n'est pas une recherche d'adresse publique, et l'appeler sur une socket non liée ne vous dit presque rien. Ce qu'il renvoie peut encore être réécrit plus loin dans le chemin, donc seule l'observation propre du service fait autorité sur ce que le service a reçu.
Sur les plateformes Apple, le côté interfaces dispose d'une surface distincte : les réglages du tunnel listent les adresses attribuées à l'interface du tunnel. Les lire vous dit comment le tunnel a été configuré, et cela ne vous dit pas quel chemin une requête donnée a pris, car le routage et les règles par application décident cela pour chaque connexion.
Le tunnel divisé rend l'écart visible. Une requête peut sortir par le tunnel tandis que la suivante, visant une autre destination ou famille d'adresses, ne le fait pas, si bien que deux résultats de la même application à quelques secondes d'intervalle peuvent être honnêtes et différents.
Choisissez l'observation qui correspond à la question
Choisissez délibérément au lieu d'instrumenter tout. Pour ce que voit le backend, enregistrez la source côté backend, et là où un proxy inverse se trouve devant, lisez l'adresse du client dans l'en-tête de transfert que votre déploiement définit réellement, et non dans quoi que ce soit que le client a envoyé.
Pour savoir si le tunnel est configuré, lisez l'interface. Pour savoir si le trafic de cette application l'a utilisé, envoyez du trafic depuis cette application vers une destination que vous contrôlez et comparez la source aux deux extrémités.
Les règles par application méritent leur propre phrase. Le résultat d'un navigateur est une preuve concernant ce navigateur, et un tunnel géré par application peut placer deux applications du même téléphone sur des chemins différents au même moment. Vérifier la couverture signifie envoyer du trafic depuis l'application concernée, dans la famille d'adresses concernée.
Les noms d'interface ne sont pas un détecteur
N'utilisez pas non plus un nom d'interface comme contrôle VPN. Les noms ne sont pas un contrat public, et un téléphone peut porter plusieurs rattachements alors qu'un seul transporte votre requête.
Nommez le champ d'après l'observation qu'il contient. local_interface_address, socket_local_endpoint et service_observed_source sont maladroits et sans ambiguïté, et l'absence d'ambiguïté est ce que vous voulez lorsque la valeur finit dans un ticket de support une semaine plus tard. Une seule colonne appelée device IP collectera les trois puis sera crue comme si elle n'en était qu'une.
Gardez l'identité hors de la colonne d'adresse
Une sortie VPN partagée n'est pas une identité d'utilisateur, et une adresse privée n'est pas un justificatif d'accès. Les deux décrivent un chemin et non une personne, et traiter l'une ou l'autre comme une authentification transforme un accident de routage en décision d'autorisation.
Quand quelqu'un demande quelle adresse a le téléphone, la réponse utile est une question sur quelle connexion et quel observateur. La définition de getsockname mérite d'être citée pour le cas intermédiaire, car elle règle la question de la socket sans prétendre régler les deux autres.
Ensuite, notez laquelle des trois votre produit doit réellement afficher, et supprimez les deux autres de l'interface.