Dlaczego aplikacja na iPhone'a pokazuje jeden IP, a serwer rejestruje inny
Adres interfejsu, punkt końcowy gniazda i źródło, które rejestruje serwer, odpowiadają na różne pytania. VPN dodaje kontekst; nie czyni z nich jednej liczby.
Przychodzą zgłoszenia do pomocy technicznej, w których napisano, że aplikacja pokazuje jeden adres, a serwer zapisał inny, i pytają, który z nich kłamie. Żaden; to dwie obserwacje dwóch różnych rzeczy. Adres przypisany do interfejsu, adres przypisany do gniazda i adres źródłowy widziany przez zdalną usługę odpowiadają na trzy osobne pytania. VPN dodaje telefonowi kontekst sieciowy i nie sprowadza tych trzech do jednej liczby dla całego urządzenia. Przeczytaj nazwy pól w zgłoszeniu, zanim przeczytasz adresy.
Co zwykle opisuje zgłoszenie
Wyobraź sobie telefon w sieci Wi-Fi z podniesionym tunelem. Interfejs Wi-Fi ma adres LAN, interfejs tunelu ma przypisany adres wewnętrzny, a żądanie wychodzące przez tunel dociera do usługi publicznej z tego źródła, które przetrwa jakiekolwiek tłumaczenie po drodze. Aplikacja wypisująca adres wewnętrzny i serwer rejestrujący przetłumaczone źródło raportują oba dokładnie, i te dwie wartości nigdy się nie zgodzą.
Trzy obserwacje różnią się tym, co mogą udowodnić, a nie tylko tym, co opisują.
| 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 |
Trzymaj tę tabelę obok kodu, który wpisuje te wartości do zgłoszenia, bo większość zamieszania to tu pomylenie kolumn, a nie awaria sieci.
Na co wywołanie gniazda może i nie może odpowiedzieć
Na poziomie API getsockname zgłasza lokalny punkt końcowy aktualnie przypisany do konkretnego gniazda. Dla połączonego gniazda jest to źródło, które jądro wybrało dla tego połączenia, co jest już bardziej konkretne niż jakakolwiek lista interfejsów. To nie jest wyszukiwanie publicznego adresu, a wywołanie go na nieprzypisanym gnieździe nie mówi prawie nic. Cokolwiek zwróci, może zostać później przepisane na ścieżce, więc tylko własna obserwacja usługi jest miarodajna co do tego, co usługa otrzymała.
Na platformach Apple strona interfejsów ma osobną powierzchnię: ustawienia tunelu wymieniają adresy przypisane do interfejsu tunelu. Ich odczyt mówi, jak skonfigurowano tunel, i nie mówi, którą ścieżką poszło dane żądanie, bo routing i reguły dla poszczególnych aplikacji rozstrzygają to dla każdego połączenia.
Tunel dzielony uwidacznia tę lukę. Jedno żądanie może wyjść przez tunel, a następne, skierowane do innego celu lub innej rodziny adresów, nie, więc dwa wyniki tej samej aplikacji w odstępie sekund mogą być uczciwe i różne.
Wybierz obserwację, która pasuje do pytania
Wybieraj świadomie, zamiast mierzyć wszystko. Dla tego, co widzi backend, rejestruj źródło w backendzie, a tam, gdzie z przodu stoi odwrotne proxy, czytaj adres klienta z nagłówka przekazywania, który twoje wdrożenie rzeczywiście ustawia, a nie z czegokolwiek, co wysłał klient.
Aby wiedzieć, czy tunel jest skonfigurowany, czytaj interfejs. Aby wiedzieć, czy ruch tej aplikacji go użył, wyślij ruch z tej aplikacji do celu, który kontrolujesz, i porównaj źródło na obu końcach.
Reguły dla poszczególnych aplikacji zasługują na własne zdanie. Wynik przeglądarki jest dowodem o tej przeglądarce, a zarządzany tunel dla poszczególnych aplikacji może umieścić dwie aplikacje na tym samym telefonie na różnych ścieżkach w tej samej chwili. Weryfikacja pokrycia oznacza wysłanie ruchu z danej aplikacji, w danej rodzinie adresów.
Nazwy interfejsów nie są detektorem
Nie używaj też nazwy interfejsu jako sprawdzenia VPN. Nazwy nie są publicznym kontraktem, a telefon może mieć kilka połączeń, podczas gdy tylko jedno z nich niesie twoje żądanie.
Nazwij pole po obserwacji, którą przechowuje. local_interface_address, socket_local_endpoint i service_observed_source są niezgrabne i jednoznaczne, a jednoznaczność jest tym, czego chcesz, gdy wartość tydzień później trafia do zgłoszenia do pomocy technicznej. Jedna kolumna o nazwie device IP zbierze wszystkie trzy, a potem będzie się jej ufać tak, jakby była jedną.
Trzymaj tożsamość poza kolumną adresu
Wspólne wyjście VPN nie jest tożsamością użytkownika, a adres prywatny nie jest poświadczeniem dostępu. Oba opisują ścieżkę, a nie osobę, i traktowanie któregokolwiek z nich jako uwierzytelnienia zamienia wypadek routingu w decyzję o autoryzacji.
Gdy ktoś pyta, jaki adres ma telefon, użyteczna odpowiedź to pytanie o to, które połączenie i który obserwator. Definicję getsockname warto zacytować dla środkowego przypadku, bo rozstrzyga kwestię gniazda, nie udając, że rozstrzyga pozostałe dwie.
Potem zapisz, który z trzech twój produkt naprawdę musi pokazywać, i usuń pozostałe dwa z interfejsu.