Perché la tua app iPhone mostra un IP e il server ne registra un altro
Un indirizzo di interfaccia, un endpoint di socket e la sorgente che un server registra rispondono a domande diverse. Una VPN aggiunge contesto; non ne fa un unico numero.
Arrivano ticket di assistenza che dicono che l'app mostra un indirizzo mentre il server ne ha registrato un altro, e poi chiedono quale dei due mente. Nessuno dei due; sono due osservazioni di due cose diverse. Un indirizzo legato a un'interfaccia, un indirizzo legato a un socket e un indirizzo di origine visto da un servizio remoto rispondono a tre domande separate. Una VPN aggiunge un contesto di rete al telefono e non riduce quei tre a un unico numero per tutto il dispositivo. Leggi i nomi dei campi del ticket prima di leggere gli indirizzi.
Che cosa descrive di solito il ticket
Immagina un telefono in Wi-Fi con un tunnel attivo. L'interfaccia Wi-Fi ha un indirizzo LAN, l'interfaccia del tunnel ha un indirizzo interno assegnato, e una richiesta che esce dal tunnel arriva a un servizio pubblico dalla sorgente che sopravvive a qualsiasi traduzione lungo il percorso. Un'app che stampa l'indirizzo interno e un server che registra la sorgente tradotta riportano entrambi con precisione, e i due valori non coincideranno mai.
Le tre osservazioni differiscono in ciò che possono dimostrare, non solo in ciò che descrivono.
| 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 |
Tieni quella tabella accanto al codice che riempie questi valori in un ticket, perché gran parte della confusione qui è un incrocio di colonne e non un guasto di rete.
A cosa può e non può rispondere una chiamata di socket
A livello di API, getsockname riporta l'endpoint locale attualmente legato a un socket specifico. Per un socket connesso è la sorgente che il kernel ha scelto per quella connessione, il che è già più specifico di qualsiasi elenco di interfacce. Non è una ricerca di indirizzo pubblico, e chiamarlo su un socket non legato non ti dice quasi nulla. Qualunque cosa restituisca può ancora essere riscritta più avanti nel percorso, quindi solo l'osservazione del servizio stesso è autorevole su ciò che il servizio ha ricevuto.
Sulle piattaforme Apple il lato interfacce ha una superficie separata: le impostazioni del tunnel elencano gli indirizzi assegnati all'interfaccia del tunnel. Leggerle ti dice come è stato configurato il tunnel, e non ti dice quale percorso ha preso una data richiesta, perché l'instradamento e le regole per app lo decidono per ogni connessione.
Il tunnel diviso rende visibile la differenza. Una richiesta può uscire dal tunnel mentre la successiva, diretta a un'altra destinazione o famiglia di indirizzi, non lo fa, così due risultati della stessa app a pochi secondi di distanza possono essere onesti e diversi.
Scegli l'osservazione che corrisponde alla domanda
Scegli deliberatamente invece di strumentare tutto. Per ciò che vede il backend, registra la sorgente nel backend, e dove davanti c'è un proxy inverso, leggi l'indirizzo del client dall'intestazione di inoltro che il tuo deployment imposta davvero, e non da qualunque cosa abbia inviato il client.
Per sapere se il tunnel è configurato, leggi l'interfaccia. Per sapere se il traffico di questa app lo ha usato, invia traffico da quell'app verso una destinazione che controlli e confronta la sorgente ai due estremi.
Le regole per app meritano una frase propria. Il risultato di un browser è una prova su quel browser, e un tunnel gestito per app può mettere due app sullo stesso telefono su percorsi diversi nello stesso momento. Verificare la copertura significa inviare traffico dall'app in questione, nella famiglia di indirizzi in questione.
I nomi delle interfacce non sono un rilevatore
Non usare nemmeno un nome di interfaccia come controllo VPN. I nomi non sono un contratto pubblico, e un telefono può avere diversi collegamenti mentre solo uno di essi porta la tua richiesta.
Dai al campo il nome dell'osservazione che contiene. local_interface_address, socket_local_endpoint e service_observed_source sono goffi e inequivocabili, e l'inequivocabilità è ciò che vuoi quando il valore finisce in un ticket di assistenza una settimana dopo. Una sola colonna chiamata device IP raccoglierà tutte e tre e poi ci si fiderà come se fosse una.
Tieni l'identità fuori dalla colonna dell'indirizzo
Un'uscita VPN condivisa non è un'identità utente, e un indirizzo privato non è una credenziale di accesso. Entrambi descrivono un percorso e non una persona, e trattare l'uno o l'altro come autenticazione trasforma un incidente di instradamento in una decisione di autorizzazione.
Quando qualcuno chiede quale indirizzo abbia il telefono, la risposta utile è una domanda su quale connessione e quale osservatore. La definizione di getsockname vale la pena di citarla per il caso intermedio, perché risolve la questione del socket senza pretendere di risolvere le altre due.
Poi annota quale dei tre il tuo prodotto deve davvero mostrare, ed elimina gli altri due dall'interfaccia.