Waarom je iPhone-app het ene IP toont en de server het andere logt
Een interfaceadres, een socket-eindpunt en de bron die een server vastlegt, beantwoorden verschillende vragen. Een VPN voegt context toe; het maakt er geen één getal van.
Er komen supporttickets binnen die zeggen dat de app het ene adres toont terwijl de server het andere heeft gelogd, en dan vragen welke van de twee liegt. Geen van beide; het zijn twee waarnemingen van twee verschillende dingen. Een adres dat aan een interface is gebonden, een adres dat aan een socket is gebonden en een bronadres dat een externe dienst ziet, beantwoorden drie afzonderlijke vragen. Een VPN voegt een netwerkcontext aan de telefoon toe en voegt die drie niet samen tot één getal voor het hele apparaat. Lees de veldnamen in het ticket voordat je de adressen leest.
Wat het ticket meestal beschrijft
Stel je een telefoon op Wi-Fi voor met een tunnel omhoog. De Wi-Fi-interface heeft een LAN-adres, de tunnelinterface heeft een toegewezen intern adres, en een verzoek dat via de tunnel naar buiten gaat, komt bij een openbare dienst aan vanuit welke bron dan ook die een vertaling onderweg overleeft. Een app die het interne adres afdrukt en een server die de vertaalde bron logt, rapporteren beide nauwkeurig, en de twee waarden zullen nooit overeenkomen.
De drie waarnemingen verschillen in wat ze kunnen bewijzen, niet alleen in wat ze beschrijven.
| 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 |
Houd die tabel naast de code die deze waarden in een ticket vult, want het meeste van de verwarring hier is een kolomverwisseling en geen netwerkstoring.
Wat een socket-aanroep wel en niet kan beantwoorden
Op API-niveau meldt getsockname het lokale eindpunt dat momenteel aan een specifieke socket is gebonden. Voor een verbonden socket is dat de bron die de kernel voor die verbinding koos, wat al specifieker is dan welke interfacelijst dan ook. Het is geen opzoeking van een openbaar adres, en het aanroepen op een niet-gebonden socket vertelt je bijna niets. Wat het ook teruggeeft, kan later onderweg nog worden herschreven, dus alleen de eigen waarneming van de dienst is gezaghebbend over wat de dienst heeft ontvangen.
Op Apple-platforms heeft de interfacekant een apart oppervlak: tunnelinstellingen sommen de adressen op die aan de tunnelinterface zijn toegewezen. Ze lezen vertelt je hoe de tunnel is geconfigureerd, en het vertelt je niet welk pad een bepaald verzoek nam, omdat routering en regels per app dat per verbinding beslissen.
Gesplitst tunnelen maakt het gat zichtbaar. Het ene verzoek kan via de tunnel naar buiten gaan terwijl het volgende, gericht op een andere bestemming of adresfamilie, dat niet doet, dus twee resultaten van dezelfde app seconden uit elkaar kunnen eerlijk en verschillend zijn.
Kies de waarneming die bij de vraag past
Kies bewust in plaats van alles te instrumenteren. Voor wat de backend ziet, log de bron in de backend, en waar een reverse proxy ervoor staat, lees het clientadres uit de doorgifteheader die je deployment werkelijk zet, en niet uit iets wat de client heeft gestuurd.
Of de tunnel is geconfigureerd, lees je aan de interface af. Of het verkeer van deze app hem heeft gebruikt, ontdek je door verkeer van die app naar een bestemming te sturen die je beheert en de bron aan beide uiteinden te vergelijken.
Regels per app verdienen hun eigen zin. Een browserresultaat is bewijs over die browser, en een beheerde tunnel per app kan twee apps op dezelfde telefoon op hetzelfde moment op verschillende paden zetten. Dekking verifiëren betekent verkeer sturen vanuit de betreffende app, in de betreffende adresfamilie.
Interfacenamen zijn geen detector
Gebruik ook geen interfacenaam als VPN-controle. De namen zijn geen openbaar contract, en een telefoon kan meerdere aansluitingen hebben terwijl slechts één daarvan je verzoek draagt.
Noem het veld naar de waarneming die het bevat. local_interface_address, socket_local_endpoint en service_observed_source zijn onhandig en ondubbelzinnig, en ondubbelzinnig is wat je wilt wanneer de waarde een week later in een supportticket belandt. Eén kolom met de naam device IP verzamelt alle drie en wordt dan vertrouwd alsof het er één is.
Houd identiteit buiten de adreskolom
Een gedeelde VPN-uitgang is geen gebruikersidentiteit, en een privéadres is geen toegangsbewijs. Beide beschrijven een pad en niet een persoon, en een van beide als authenticatie behandelen maakt van een routeringsongeval een autorisatiebeslissing.
Wanneer iemand vraagt welk adres de telefoon heeft, is het nuttige antwoord een vraag over welke verbinding en welke waarnemer. De definitie van getsockname is het citeren waard voor het middelste geval, omdat ze de socketvraag beslecht zonder te doen alsof ze de andere twee beslecht.
Schrijf vervolgens op welke van de drie je product werkelijk moet tonen, en verwijder de andere twee uit de interface.