Per què la vostra aplicació d'iPhone mostra una IP i el servidor en registra una altra
Una adreça d'interfície, un punt final de sòcol i la font que registra un servidor responen preguntes diferents. Una VPN afegeix context; no les converteix en un sol número.
Arriben tiquets d'assistència que diuen que l'aplicació mostra una adreça mentre el servidor n'ha registrat una altra, i després pregunten quina de les dues menteix. No menteix cap; són dues observacions de dues coses diferents. Una adreça lligada a una interfície, una adreça lligada a un sòcol i una adreça d'origen vista per un servei remot responen tres preguntes separades. Una VPN afegeix un context de xarxa al telèfon i no col·lapsa aquestes tres en un sol número per a tot el dispositiu. Llegeix els noms dels camps del tiquet abans de llegir les adreces.
Què sol descriure el tiquet
Imagineu un telèfon en Wi-Fi amb un túnel aixecat. La interfície Wi-Fi té una adreça LAN, la interfície del túnel té una adreça interior assignada, i una petició que surt pel túnel arriba a un servei públic des de la font que sobrevisqui a qualsevol traducció pel camí. Una aplicació que imprimeix l'adreça interior i un servidor que registra la font traduïda informen tots dos amb precisió, i els dos valors no coincidiran mai.
Les tres observacions difereixen en què poden demostrar, no només en què descriuen.
| 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 |
Mantingueu aquesta taula al costat del codi que omple aquests valors en un tiquet, perquè la major part de la confusió aquí és una barreja de columnes i no una fallada de xarxa.
Què pot i què no pot respondre una crida de sòcol
A nivell d'API, getsockname informa del punt final local que actualment està lligat a un sòcol concret. Per a un sòcol connectat, aquesta és la font que el nucli va triar per a aquella connexió, cosa que ja és més específica que qualsevol llistat d'interfícies. No és una consulta d'adreça pública, i cridar-la en un sòcol no lligat no et diu gairebé res. El que retorni encara es pot reescriure més endavant al camí, així que només l'observació pròpia del servei és autoritativa sobre què ha rebut el servei.
A les plataformes d'Apple, el costat d'interfícies té una superfície separada: la configuració del túnel llista les adreces assignades a la interfície del túnel. Llegir-les et diu com es va configurar el túnel, i no et diu quin camí va prendre una petició concreta, perquè l'encaminament i les regles per aplicació ho decideixen per a cada connexió.
El túnel dividit fa visible la diferència. Una petició pot sortir pel túnel mentre que la següent, adreçada a una destinació o família d'adreces diferent, no ho fa, així que dos resultats de la mateixa aplicació amb segons de diferència poden ser honestos i diferents.
Trieu l'observació que coincideix amb la pregunta
Trieu deliberadament en lloc d'instrumentar-ho tot. Per al que veu el backend, registreu la font al backend, i on hi hagi un proxy invers al davant, llegiu l'adreça del client de la capçalera de reenviament que el vostre desplegament realment estableix, i no de res que hagi enviat el client.
Per saber si el túnel està configurat, llegiu la interfície. Per saber si el trànsit d'aquesta aplicació l'ha fet servir, envieu trànsit des d'aquesta aplicació a una destinació que controleu i compareu la font als dos extrems.
Les regles per aplicació mereixen la seva pròpia frase. Un resultat del navegador és evidència sobre aquell navegador, i un túnel gestionat per aplicació pot posar dues aplicacions al mateix telèfon en camins diferents en el mateix moment. Verificar la cobertura vol dir enviar trànsit des de l'aplicació en qüestió, en la família d'adreces en qüestió.
Els noms d'interfície no són un detector
Tampoc no feu servir un nom d'interfície com a comprovació de VPN. Els noms no són un contracte públic, i un telèfon pot tenir diverses connexions mentre només una porta la vostra petició.
Dona nom al camp segons l'observació que conté. local_interface_address, socket_local_endpoint i service_observed_source són maldestres i inequívocs, i inequívoc és el que vols quan el valor acaba en un tiquet d'assistència una setmana després. Una sola columna anomenada device IP recollirà les tres i després es confiarà en ella com si fos una.
Mantingueu la identitat fora de la columna d'adreça
Una sortida de VPN compartida no és una identitat d'usuari, i una adreça privada no és una credencial d'accés. Totes dues descriuen un camí i no una persona, i tractar qualsevol de les dues com a autenticació converteix un accident d'encaminament en una decisió d'autorització.
Quan algú pregunta quina adreça té el telèfon, la resposta útil és una pregunta sobre quina connexió i quin observador. La definició de getsockname val la pena citar-la per al cas del mig, perquè resol la qüestió del sòcol sense pretendre resoldre les altres dues.
Després anoteu quina de les tres el vostre producte realment ha de mostrar, i esborreu les altres dues de la interfície.