Hvorfor din iPhone-app viser én IP, mens serveren logger en anden
En interface-adresse, et socket-endepunkt og den kilde, en server registrerer, besvarer forskellige spørgsmål. En VPN tilføjer kontekst; den gør dem ikke til ét tal.
Der kommer supportbilletter, der siger, at appen viser én adresse, mens serveren har logget en anden, og derefter spørger, hvilken af dem der lyver. Ingen af dem gør; det er to observationer af to forskellige ting. En adresse bundet til et interface, en adresse bundet til en socket og en kildeadresse set af en fjern tjeneste besvarer tre adskilte spørgsmål. En VPN tilføjer en netværkskontekst til telefonen og kollapser ikke de tre til ét tal for hele enheden. Læs feltnavnene i billetten, før du læser adresserne.
Hvad billetten normalt beskriver
Forestil dig en telefon på Wi-Fi med en tunnel oppe. Wi-Fi-interfacet har en LAN-adresse, tunnelinterfacet har en tildelt indre adresse, og en anmodning, der forlader gennem tunnelen, ankommer til en offentlig tjeneste fra hvilken som helst kilde, der overlever en eventuel oversættelse undervejs. En app, der udskriver den indre adresse, og en server, der logger den oversatte kilde, rapporterer begge præcist, og de to værdier vil aldrig stemme overens.
De tre observationer adskiller sig i, hvad de kan bevise, ikke kun i, hvad 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 tabel ved siden af den kode, der fylder disse værdier i en billet, for det meste af forvirringen her er en kolonneforveksling og ikke en netværksfejl.
Hvad et socket-kald kan og ikke kan svare på
På API-niveau rapporterer getsockname det lokale endepunkt, der i øjeblikket er bundet til en bestemt socket. For en forbundet socket er det den kilde, som kernen valgte til den forbindelse, hvilket allerede er mere specifikt end enhver interface-liste. Det er ikke en opslagning af en offentlig adresse, og at kalde det på en ubundet socket fortæller dig næsten intet. Uanset hvad det returnerer, kan det stadig skrives om senere på vejen, så kun tjenestens egen observation er autoritativ om, hvad tjenesten modtog.
På Apple-platforme har interface-siden en separat flade: tunnelindstillinger viser de adresser, der er tildelt tunnelinterfacet. At læse dem fortæller dig, hvordan tunnelen blev konfigureret, og det fortæller dig ikke, hvilken vej en given anmodning tog, fordi routing og regler per app afgør det for hver forbindelse.
Opdelt tunneltrafik gør forskellen synlig. Én anmodning kan forlade gennem tunnelen, mens den næste, rettet mod en anden destination eller adressefamilie, ikke gør, så to resultater fra samme app med sekunders mellemrum kan være ærlige og forskellige.
Vælg den observation, der passer til spørgsmålet
Vælg bevidst i stedet for at instrumentere alt. For hvad backend ser, skal du logge kilden i backend, og hvor en omvendt proxy står foran, skal du læse klientadressen fra det videresendelseshoved, din udrulning faktisk sætter, og ikke fra noget, klienten har sendt.
For om tunnelen er konfigureret, læs interfacet. For om denne apps trafik brugte den, send trafik fra den app til en destination, du kontrollerer, og sammenlign kilden i begge ender.
Regler per app fortjener deres egen sætning. Et browserresultat er bevis om den browser, og en administreret tunnel per app kan sætte to apps på samme telefon på forskellige veje i samme øjeblik. At verificere dækning betyder at sende trafik fra den pågældende app, i den pågældende adressefamilie.
Interface-navne er ikke en detektor
Brug heller ikke et interface-navn som VPN-tjek. Navnene er ikke en offentlig kontrakt, og en telefon kan have flere tilslutninger, mens kun én af dem bærer din anmodning.
Navngiv feltet efter den observation, det rummer. local_interface_address, socket_local_endpoint og service_observed_source er klodsede og entydige, og entydigt er, hvad du vil have, når værdien ender i en supportbillet en uge senere. Én kolonne kaldet device IP vil samle alle tre og derefter blive betroet, som om den var én.
Hold identitet ude af adressekolonnen
En delt VPN-udgang er ikke en brugeridentitet, og en privat adresse er ikke en adgangsoplysning. Begge beskriver en vej snarere end en person, og at behandle en af dem som autentificering gør en routingulykke til en autorisationsbeslutning.
Når nogen spørger, hvilken adresse telefonen har, er det nyttige svar et spørgsmål om hvilken forbindelse og hvilken observatør. Definitionen af getsockname er værd at citere for det midterste tilfælde, fordi den afgør socket-spørgsmålet uden at foregive at afgøre de to andre.
Skriv derefter ned, hvilken af de tre dit produkt faktisk skal vise, og slet de to andre fra brugerfladen.