Znacznik VPN w urządzeniu czy adres wyjścia: co co dowodzi?
Znacznik sieci odczytany w urządzeniu i adres widziany przez serwer to różne dowody. Zdecyduj, którego potrzebuje twoje pytanie.
Aplikacja w telefonie i zdalny serwer zaczynają od różnych faktów i żaden nie może pożyczyć faktów drugiego. Aplikacja może zapytać system operacyjny o sieć, której używa, podczas gdy serwer wie tylko to, co przychodzi przez połączenie. Uruchomienie własnego punktu końcowego przepisuje drugi i pozostawia pierwszy nietknięty. To, który z nich odpowie na twoje pytanie, zależy od samego pytania.
Dwa punkty obserwacji, dwa rodzaje dowodów
Dowód lokalny opisuje urządzenie. Obejmuje interfejs przenoszący ruch, transport zgłaszany przez platformę i to, o co może pytać wywołująca aplikacja. Dowód zdalny opisuje połączenie: adres źródłowy, protokół, czas i wszystko, co aplikacja zdecyduje się wysłać. Żaden punkt obserwacji nie jest nadzbiorem drugiego.
Mieszanie obu daje twierdzenia, które brzmią precyzyjnie i których nie można sprawdzić. Znacznik dowodzi czegoś o obiekcie sieciowym w urządzeniu, a nie o tym, jak zdalna usługa klasyfikuje żądanie.
Zanim zaczniesz spierać się o wykrywanie, zapisz, którego punktu dotyczy pytanie. Czy chodzi o to, czy konkretna aplikacja potrafi stwierdzić, że tunel jest aktywny, czy o to, czy usługa potrafi wywnioskować, skąd przyszło żądanie? To odrębne dochodzenia, a odpowiedź na jedno nic nie mówi o drugim.
Co może zgłosić lokalny interfejs platformy
Android oferuje konkretny znacznik. Obiekt NetworkCapabilities może zgłaszać TRANSPORT_VPN, a hasTransport sprawdza, czy ten transport jest obecny na obiekcie. Aplikacja pobiera obiekt z usługi łączności i czyta go, z zastrzeżeniem uprawnienia do stanu sieci.
Wynikiem są lokalne informacje platformy, a nie wyszukiwanie w zakresach adresów dostawcy. Opisuje sieć używaną przez wywołującą aplikację.
Liczą się dwie granice. Reguła podzielonego tunelu, która wyklucza aplikację, może dać na tym samym telefonie inną odpowiedź niż ta, którą widzi kolega, ponieważ aplikacja może być związana gdzie indziej. Znacznik istnieje też dlatego, że system operacyjny modeluje interfejsy VPN, a nie dlatego, że zbiera go jakaś konkretna aplikacja. To, czy aplikacja czyta to pole, przekazuje je dalej czy ignoruje, jest właściwością tej aplikacji. Jej manifest i dokumentacja to jedyne wiarygodne źródła w tej sprawie.
adb shell dumpsys connectivity | grep -i -m5 vpn
Co może widzieć zdalna usługa
Serwer widzi adres źródłowy połączenia, transport i czas, a adres może wzbogacić danymi rejestru lub trasowania. Może też odebrać wszystko, co wyśle aplikacja, w tym lokalizację, gdy aplikacja o nią poprosi, a użytkownik się zgodzi. Te kanały są odrębne i tylko jeden przypomina wyszukiwanie adresu.
Adres zarejestrowany u dostawcy hostingu sugeruje tunel, a zarejestrowany w sieci domowej sugeruje połączenie domowe. Oba są statystycznymi wskazówkami, nie faktami o urządzeniu.
Adres domowy nie umieszcza osoby pod tym adresem, a adres hostingu nie podaje nazwy operatora ani kraju. Usługa, która traktuje wnioskowanie jako pewność, czasem się pomyli, nie mogąc tego wykryć. Jeśli wymaganiem jest niezawodność, a nie heurystyka, dane adresowe nie mogą jej zapewnić, a projekt, który to przyznaje, jest uczciwszy niż ten, który ukrywa domysł.
| Dowód | Na co odpowiada | Czego nie może pokazać |
|---|---|---|
| Lokalny znacznik transportu | Czy ten obiekt sieciowy to VPN | Kto obsługuje wyjście lub gdzie jest urządzenie |
| Zdalny adres źródłowy | Który adres dotarł do usługi | Czy urządzenie ma też tunel |
| Ładunek aplikacji | Co aplikacja wybrała do wysłania | Wszystko, czego aplikacja nie wysłała |
Dlaczego samodzielnie hostowane wyjście zmienia tylko jedną stronę
Uruchomienie własnego punktu końcowego zmienia adres źródłowy widziany przez zdalną usługę, co może przenieść go poza zakresy, które ta usługa wiąże z komercyjnymi dostawcami. W lokalnym modelu sieci nic się nie zmienia, ponieważ tunel pozostaje tunelem, a system operacyjny nadal go zgłasza.
Jedna strona dowodów się porusza, druga pozostaje nieruchoma. Szczelina między nimi to miejsce, w którym pękają oczekiwania.
Przeglądarka to trzeci przypadek z własnymi interfejsami i ograniczeniami. Treść webowa nie może odczytać natywnego obiektu możliwości, a traktowanie funkcji mobilnego systemu operacyjnego jako dostępnej dla strony internetowej to błąd kategorii. Jeśli pytanie dotyczy strony internetowej, zbadaj, co strona naprawdę może uzyskać, zamiast przepisywać API platformy.
Decyduj według pytania, które zadajesz
Jeśli pytanie brzmi, czy konkretna aplikacja może obserwować stan tunelu, interfejs platformy jest właściwym miejscem, a odpowiedź leży w kodzie i uprawnieniach tej aplikacji. Jeśli pytanie brzmi, co usługa może wywnioskować, dowodem są metadane połączenia. Pytania prawnego ani umownego nie rozstrzyga żadne z nich.
Nazwij pytanie jednym zdaniem, zanim cokolwiek zbierzesz. To zdanie decyduje, który punkt obserwacji się liczy, i powstrzymuje dochodzenie przed zboczeniem w inną dyskusję.
Oznacz każdą obserwację według jej źródła, gdy o niej raportujesz, ponieważ twierdzenia bez oznaczenia nie można zweryfikować. Lokalny znacznik i wnioskowanie z adresu są oba użyteczne i żadne nie jest rozstrzygające, dlatego scalanie ich w jeden werdykt jest błędem.
Gdy usługa odrzuca autoryzowane połączenie, skorzystaj z jej obsługiwanej ścieżki weryfikacji, zamiast zmieniać lokalne ustawienie, aby ukryć sygnał. Usunięcie jednej obserwacji nigdy nie dowodzi, że pozostałe zniknęły.