Tunelowanie dzielone dla klientów hotspotu to nie wykluczanie per aplikacja
Wykluczenie aplikacji z VPN zmienia tylko telefon. Podłączony laptop potrzebuje własnej reguły przekazywania, dopasowanej po źródle, celu i NAT.
Dwa wymagania, które brzmią tak samo, nie są takie same: „wyklucz tę aplikację z VPN” i „wyślij ten jeden cel poza VPN dla laptopa w moim hotspocie”. Pierwsze zmienia sposób, w jaki gniazdo w telefonie wybiera sieć. Drugie musi zmienić decyzję o przekazywaniu pakietu, który przyszedł z innego urządzenia po tym, jak telefon już go przyjął. Mylenie obu prowadzi do tego, że klient hotspotu kończy z wyjątkiem, który zawsze dotyczył tylko przeglądarki samego telefonu.
Dwa podsystemy odpowiadają za dwa pytania
Android trzyma sieć aplikacji i tethering osobno. Gniazda aplikacji są przypisywane do sieci przez stos łączności, a aplikacja VPN decyduje, które z jej własnych gniazd wchodzą do tunelu. Przekazywane pakiety od podłączonego klienta obsługuje podsystem tetheringu, który prosi netd o trasy, reguły polityki i tłumaczenie na interfejsie niższego poziomu.
Wykluczenie per aplikacja jest oceniane, gdy aplikacja otwiera gniazdo. Przekazywany pakiet nigdy nie dociera do tego sprawdzenia, ponieważ nie powstał w gnieździe aplikacji na tym urządzeniu. To jest cały powód, dla którego oba ustawienia nie mogą się wzajemnie zastąpić, i nie jest to błąd w żadnym z nich.
Co wykluczenie per aplikacja naprawdę zmienia
Kreator VpnService może nazwać pakiety pozostające poza tunelem za pomocą addDisallowedApplication albo nazwać jedyne pakiety dozwolone wewnątrz za pomocą addAllowedApplication. Te aplikacje otwierają wtedy gniazda w sieci podstawowej, podczas gdy VPN nadal posiada trasę domyślną dla wszystkiego innego.
Zakres jest precyzyjny: własne gniazda pakietu, na tym urządzeniu, dopóki tunel jest podniesiony. Nie mówi nic o przekazywanym ruchu, nic o drugim urządzeniu i nic o pakietach, które system wysyła w imieniu tetheringu.
To nie jest też kontrola celu. Wykluczenie przeglądarki wyklucza każdy adres, do którego ta przeglądarka dociera, w tym ten, który chciałeś zatrzymać w tunelu. Gdy wymaganie nazywa cel, a nie aplikację, selektor aplikacji jest z założenia niewłaściwym narzędziem.
Jak przekazywany pakiet wygląda dla telefonu
Pakiet klienta przychodzi na interfejs hotspotu z prywatnym adresem źródłowym nadanym przez telefon, powiedzmy 192.168.43.20, i publicznym celem. Aby go przekazać, telefon potrzebuje trasy do łącza nadrzędnego i reguły tłumaczenia, żeby odpowiedzi znalazły drogę powrotną, ponieważ prywatny adres klienta nic nie znaczy w sieci komórkowej.
Android wyraża to regułami polityki, które wybierają tabelę routingu, a netd odbudowuje odpowiednie tabele i reguły, gdy zmieniają się sieci i VPN-y. Numer tabeli, priorytet reguły lub nazwa interfejsu skopiowane z postu na forum albo z tego samego modelu w starszym wydaniu nie ustanawiają trwałego władania. Ta odbudowa jest też powodem, dla którego reguła napisana ręcznie może działać godzinę i zatrzymać się po następnym ponownym połączeniu.
Jakiej polityki naprawdę potrzebuje wyjątek dla hotspotu
Zanim dotkniesz reguły, zapisz decyzję jako źródło, cel i zamierzoną drogę. Minimalna postać dla jednego zatwierdzonego celu wygląda tak:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Oba kierunki muszą być kompletne. Gałąź bezpośrednia potrzebuje użytecznej trasy przez komórkowe łącze nadrzędne, które akurat jest bieżące; gałąź VPN potrzebuje trasy tunelu oraz zgody na przekazywanie. Każde tłumaczenie źródła musi pasować do wybranego wyjścia, ponieważ NAT zastosowany na interfejsie tunelu pokazuje adres tunelu, a nie komórkowy, i wtedy droga powrotna nie zgadza się z drogą wyjścia.
Odpowiedzi muszą dotrzeć do tego samego klienta po stronie odbiorczej przez śledzony stan lub jawną trasę, a licznik pakietów wychodzących niczego z tego nie dowodzi. Trzymaj też własny transport zewnętrzny VPN poza zakresem wyjątku, inaczej pakiety nośne tunelu dziedziczą politykę napisaną dla żądania sieciowego klienta.
Jeden przechwycony adres to nie cel
Jeden adres IPv4 odczytany z przeglądarki to migawka. Duże usługi odpowiadają z anycast lub z obracającego się zestawu adresów brzegowych, wiele jest dwustosowych, a proces logowania może dotknąć hostów uwierzytelniania i telemetrii, których strona nigdy nie pokazuje. Wyjątek zbudowany wokół adresu, który przypadkiem zobaczyłeś, psuje się przy następnym równoważeniu obciążenia przez usługę.
Używaj udokumentowanych adresów właściciela usługi lub zakresu, który publikuje, i uwzględnij obie rodziny adresów. Jeśli wymagania nie da się wyrazić jako stabilnego zestawu, to prawdopodobnie pytanie o politykę dla usługi, a nie sztuczka routingu w telefonie.
Sprawdź od strony odbiorczej
Trzy kontrole w tej kolejności: wybrana usługa z laptopa, zwykły cel, który musi zostać w VPN, oraz aplikacja telefonu, która musi pozostać nietknięta. Potem powtórz po ponownym połączeniu i po zmianie łącza nadrzędnego, bo wtedy tabele polityki są odbudowywane.
Jeśli implementacja udostępniania w telefonie nie potrafi utrzymać tej umowy przez ponowne połączenie, przenieś politykę selektywną na obsługiwany router po stronie odbiorczej, zamiast gromadzić reguły root na urządzeniu. Router potrafi wyrazić dopasowanie źródła i celu ze stabilnym właścicielem, a dokumentacja modułu tetheringu jest właściwym źródłem tego, co telefon naprawdę robi.