Hvorfor iPhone-appen din viser én IP og serveren logger en annen
En grensesnittadresse, et socket-endepunkt og kilden serveren registrerer svarer på forskjellige spørsmål. En VPN legger til kontekst; den gjør dem ikke til ett tall.
Det kommer supportbilletter som sier at appen viser én adresse mens serveren loggførte en annen, og deretter spør hvilken av dem som lyver. Ingen av dem; det er to observasjoner av to forskjellige ting. En adresse bundet til et grensesnitt, en adresse bundet til en socket og en kildeadresse sett av en ekstern tjeneste svarer på tre separate spørsmål. En VPN legger til en nettverkskontekst på telefonen og slår ikke sammen de tre til ett tall for hele enheten. Les feltnavnene i billetten før du leser adressene.
Hva billetten vanligvis beskriver
Se for deg en telefon på Wi-Fi med en tunnel oppe. Wi-Fi-grensesnittet har en LAN-adresse, tunnelgrensesnittet har en tildelt indre adresse, og en forespørsel som går ut gjennom tunnelen, kommer til en offentlig tjeneste fra hvilken som helst kilde som overlever en eventuell oversettelse underveis. En app som skriver ut den indre adressen, og en server som logger den oversatte kilden, rapporterer begge nøyaktig, og de to verdiene vil aldri stemme overens.
De tre observasjonene skiller seg i hva de kan bevise, ikke bare i hva de beskriver.
| 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 |
Hold den tabellen ved siden av koden som fyller disse verdiene inn i en billett, for det meste av forvirringen her er en kolonneforveksling og ikke en nettverksfeil.
Hva et socket-kall kan og ikke kan svare på
På API-nivå rapporterer getsockname det lokale endepunktet som for øyeblikket er bundet til en bestemt socket. For en tilkoblet socket er det kilden kjernen valgte for den tilkoblingen, noe som allerede er mer spesifikt enn enhver grensesnittliste. Det er ikke et oppslag av offentlig adresse, og å kalle det på en ubundet socket forteller deg nesten ingenting. Uansett hva det returnerer, kan det senere skrives om på veien, så bare tjenestens egen observasjon er autoritativ om hva tjenesten mottok.
På Apple-plattformer har grensesnittsiden en egen flate: tunnelinnstillingene lister adressene som er tildelt tunnelgrensesnittet. Å lese dem forteller deg hvordan tunnelen ble konfigurert, og det forteller deg ikke hvilken vei en gitt forespørsel tok, fordi ruting og regler per app avgjør det for hver tilkobling.
Delt tunnellering gjør gapet synlig. Én forespørsel kan gå ut gjennom tunnelen mens den neste, rettet mot en annen destinasjon eller adressefamilie, ikke gjør det, så to resultater fra samme app med sekunders mellomrom kan være ærlige og forskjellige.
Velg observasjonen som passer til spørsmålet
Velg bevisst i stedet for å instrumentere alt. For det backend ser, logg kilden i backend, og der en omvendt proxy står foran, les klientadressen fra videresendingshodet utrullingen din faktisk setter, og ikke fra noe klienten sendte.
For å vite om tunnelen er konfigurert, les grensesnittet. For å vite om trafikken til denne appen brukte den, send trafikk fra den appen til en destinasjon du kontrollerer og sammenlign kilden i begge ender.
Regler per app fortjener sin egen setning. Et nettleserresultat er bevis om den nettleseren, og en administrert tunnel per app kan sette to apper på samme telefon på forskjellige veier i samme øyeblikk. Å verifisere dekning betyr å sende trafikk fra den aktuelle appen, i den aktuelle adressefamilien.
Grensesnittnavn er ikke en detektor
Ikke bruk et grensesnittnavn som VPN-sjekk heller. Navnene er ikke en offentlig kontrakt, og en telefon kan ha flere tilkoblinger mens bare én av dem bærer forespørselen din.
Gi feltet navn etter observasjonen det holder. local_interface_address, socket_local_endpoint og service_observed_source er klossete og entydige, og entydig er det du vil ha når verdien ender i en støttebillett en uke senere. Én kolonne kalt device IP vil samle alle tre og deretter bli trodd på som om den var én.
Hold identitet utenfor adressekolonnen
En delt VPN-utgang er ikke en brukeridentitet, og en privat adresse er ikke en tilgangsopplysning. Begge beskriver en vei og ikke en person, og å behandle en av dem som autentisering gjør en ruteulykke om til en autorisasjonsbeslutning.
Når noen spør hvilken adresse telefonen har, er det nyttige svaret et spørsmål om hvilken tilkobling og hvilken observatør. Definisjonen av getsockname er verdt å sitere for midtcasen, fordi den avgjør socket-spørsmålet uten å late som den avgjør de to andre.
Skriv deretter ned hvilken av de tre produktet ditt faktisk trenger å vise, og slett de to andre fra grensesnittet.