De ce aplicația voastră de iPhone arată un IP, iar serverul înregistrează altul
O adresă de interfață, un punct final de socket și sursa pe care o înregistrează un server răspund la întrebări diferite. Un VPN adaugă context; nu le face un singur număr.
Sosesc tichete de suport care spun că aplicația arată o adresă în timp ce serverul a înregistrat alta, și apoi întreabă care dintre ele minte. Niciuna; sunt două observații a două lucruri diferite. O adresă legată de o interfață, o adresă legată de un socket și o adresă sursă văzută de un serviciu îndepărtat răspund la trei întrebări separate. Un VPN adaugă telefonului un context de rețea și nu reduce cele trei la un singur număr pentru tot dispozitivul. Citiți numele câmpurilor din tichet înainte de a citi adresele.
Ce descrie de obicei tichetul
Imaginați-vă un telefon în Wi-Fi cu un tunel ridicat. Interfața Wi-Fi are o adresă LAN, interfața tunelului are o adresă internă alocată, iar o cerere care iese prin tunel ajunge la un serviciu public din orice sursă care supraviețuiește oricărei traduceri pe drum. O aplicație care tipărește adresa internă și un server care înregistrează sursa tradusă raportează amândouă exact, iar cele două valori nu vor coincide niciodată.
Cele trei observații diferă prin ce pot dovedi, nu doar prin ce descriu.
| 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 |
Țineți acel tabel lângă codul care completează aceste valori într-un tichet, pentru că cea mai mare parte a confuziei de aici este o încurcătură de coloane, nu o defecțiune de rețea.
La ce poate și la ce nu poate răspunde un apel de socket
La nivel de API, getsockname raportează punctul final local legat în prezent de un anumit socket. Pentru un socket conectat, aceea este sursa pe care kernelul a ales-o pentru acea conexiune, ceea ce este deja mai specific decât orice listă de interfețe. Nu este o căutare de adresă publică, iar apelarea lui pe un socket nelegat nu vă spune aproape nimic. Orice returnează poate fi rescris mai târziu pe traseu, așa că doar observația serviciului însuși este autoritară cu privire la ce a primit serviciul.
Pe platformele Apple, partea de interfețe are o suprafață separată: setările tunelului listează adresele atribuite interfeței tunelului. Citirea lor vă spune cum a fost configurat tunelul, și nu vă spune ce traseu a urmat o anumită cerere, pentru că rutarea și regulile pe aplicație decid asta pentru fiecare conexiune.
Tunelul divizat face diferența vizibilă. O cerere poate ieși prin tunel în timp ce următoarea, îndreptată spre altă destinație sau altă familie de adrese, nu o face, așa că două rezultate ale aceleiași aplicații la câteva secunde pot fi sincere și diferite.
Alegeți observația care corespunde întrebării
Alegeți deliberat în loc să instrumentați totul. Pentru ce vede backendul, înregistrați sursa în backend, iar unde stă un proxy invers în față, citiți adresa clientului din antetul de redirecționare pe care implementarea voastră îl setează efectiv, nu din orice a trimis clientul.
Pentru a afla dacă tunelul este configurat, citiți interfața. Pentru a afla dacă traficul acestei aplicații l-a folosit, trimiteți trafic din acea aplicație către o destinație pe care o controlați și comparați sursa la ambele capete.
Regulile pe aplicație merită propria propoziție. Rezultatul unui browser este dovadă despre acel browser, iar un tunel administrat pe aplicație poate pune două aplicații pe același telefon pe trasee diferite în același moment. Verificarea acoperirii înseamnă trimiterea de trafic din aplicația în cauză, în familia de adrese în cauză.
Numele interfețelor nu sunt un detector
Nu folosiți nici un nume de interfață ca verificare VPN. Numele nu sunt un contract public, iar un telefon poate avea mai multe atașări în timp ce doar una dintre ele transportă cererea voastră.
Numiți câmpul după observația pe care o ține. local_interface_address, socket_local_endpoint și service_observed_source sunt stângace și fără ambiguitate, iar lipsa ambiguității este ce vă doriți când valoarea ajunge într-un tichet de suport o săptămână mai târziu. O singură coloană numită device IP le va colecta pe toate trei și apoi va fi crezută ca și cum ar fi una.
Țineți identitatea în afara coloanei de adresă
O ieșire VPN partajată nu este o identitate de utilizator, iar o adresă privată nu este o acreditare de acces. Ambele descriu un traseu și nu o persoană, iar tratarea oricăreia ca autentificare transformă un accident de rutare într-o decizie de autorizare.
Când cineva întreabă ce adresă are telefonul, răspunsul util este o întrebare despre ce conexiune și ce observator. Definiția getsockname merită citată pentru cazul din mijloc, pentru că rezolvă întrebarea socketului fără a pretinde că le rezolvă pe celelalte două.
Apoi notați care dintre cele trei trebuie chiar afișat de produsul vostru, și ștergeți celelalte două din interfață.