Rozdělené tunelování pro klienty hotspotu není vyloučení podle aplikací

Dva požadavky, které znějí stejně, stejné nejsou: „vyluč tuto aplikaci z VPN“ a „pošli tento jeden cíl mimo VPN pro notebook na mém hotspotu“. První mění, jak si soket v telefonu vybírá síť. Druhý musí změnit rozhodnutí o předávání paketu, který přišel z jiného zařízení poté, co jej telefon už přijal. Záměna obou je důvod, proč klient hotspotu skončí s výjimkou, která se vždy vztahovala jen na vlastní prohlížeč telefonu.

Dvě otázky vlastní dva různé podsystémy

Android drží síťování aplikací a tethering oddělené. Sokety aplikací přiřazuje k síti zásobník konektivity a aplikace VPN rozhoduje, které z jejích vlastních soketů vstoupí do tunelu. Předávané pakety od připojeného klienta zpracovává podsystém tetheringu, který žádá netd o trasy, pravidla zásad a překlad na rozhraní směrem dolů.

Vyloučení podle aplikace se vyhodnocuje, když aplikace otevře soket. Předávaný paket se k této kontrole nikdy nedostane, protože nevznikl ze soketu aplikace v tomto zařízení. To je celý důvod, proč se obě nastavení nemohou navzájem nahradit, a není to chyba ani v jednom z nich.

Co vyloučení podle aplikace skutečně mění

Tvůrce VpnService může pojmenovat balíčky, které zůstávají mimo tunel, pomocí addDisallowedApplication, nebo pojmenovat jediné balíčky povolené uvnitř pomocí addAllowedApplication. Tyto aplikace pak otevírají sokety v podkladové síti, zatímco VPN dál vlastní výchozí trasu pro všechno ostatní.

Rozsah je přesný: vlastní sokety balíčku, v tomto zařízení, dokud je tunel aktivní. Neříká nic o předávaném provozu, nic o druhém zařízení a nic o paketech, které systém odesílá jménem tetheringu.

Není to ani řízení podle cíle. Vyloučení prohlížeče vylučuje každou adresu, na kterou se tento prohlížeč dostane, včetně té, kterou jste chtěli udržet uvnitř tunelu. Když požadavek jmenuje cíl, a ne aplikaci, je výběr aplikace špatný nástroj už ze své konstrukce.

Jak předávaný paket vypadá z pohledu telefonu

Paket klienta přichází na rozhraní hotspotu se soukromou zdrojovou adresou přidělenou telefonem, řekněme 192.168.43.20, a s veřejným cílem. Aby jej telefon předal, potřebuje trasu k nadřazenému spoji a pravidlo překladu, aby odpovědi našly cestu zpět, protože soukromá adresa klienta nemá v mobilní síti žádný význam.

Android to vyjadřuje pravidly zásad, která vybírají směrovací tabulku, a netd příslušné tabulky a pravidla znovu sestaví, když se sítě a VPN změní. Číslo tabulky, priorita pravidla nebo název rozhraní opsané z příspěvku na fóru nebo ze stejného modelu ve starší verzi nezakládá trvalé vlastnictví. Toto sestavování je také důvod, proč ručně psané pravidlo může hodinu fungovat a po dalším připojení přestat.

Jaká zásada vlastně výjimka pro hotspot potřebuje

Než se dotknete pravidla, zapište rozhodnutí jako zdroj, cíl a zamýšlenou cestu. Minimální podoba pro jeden schválený cíl vypadá takto:

Oba směry musí být úplné. Přímá větev potřebuje použitelnou trasu přes mobilní nadřazený spoj, který je právě aktuální; větev VPN potřebuje trasu tunelu plus povolení předávat. Jakýkoli překlad zdroje musí odpovídat zvolenému výstupu, protože NAT aplikovaný na rozhraní tunelu ukazuje adresu tunelu, a ne mobilní, a návratová cesta se pak neshoduje s odchozí cestou.

Odpovědi se musí dostat ke stejnému klientu níže pomocí sledovaného stavu nebo výslovné trasy, a počítadlo odchozích paketů nic z toho nedokazuje. Držte i vlastní vnější přenos VPN mimo rozsah výjimky, jinak pakety nosiče tunelu zdědí zásadu napsanou pro webový požadavek klienta.

Jedna zachycená adresa není cíl

Jediná adresa IPv4 přečtená z prohlížeče je snímek. Velké služby odpovídají z anycastu nebo z rotující sady okrajových adres, mnohé jsou dvouskladbové, a přihlašovací tok může zasáhnout hostitele pro ověřování a telemetrii, které stránka nikdy nezobrazí. Výjimka postavená kolem adresy, kterou jste náhodou viděli, se příště rozbije, když služba přerozdělí zátěž.

Použijte dokumentované adresy vlastníka služby nebo rozsah, který zveřejňuje, a počítejte s oběma rodinami adres. Pokud požadavek nelze vyjádřit jako stabilní sadu, je to pravděpodobně otázka zásad pro službu, a ne směrovací trik v telefonu.

Ověřte ze strany níže

Tři kontroly v tomto pořadí: vybraná služba z notebooku, běžný cíl, který musí zůstat uvnitř VPN, a aplikace v telefonu, která musí zůstat nedotčená. Potom to zopakujte po opětovném připojení a po změně nadřazeného spoje, protože právě tehdy se tabulky zásad znovu sestavují.

Pokud implementace sdílení v telefonu nedokáže tento kontrakt udržet přes opětovné připojení, přesuňte selektivní zásadu na podporovaný směrovač níže, místo abyste hromadili root pravidla v přístroji. Směrovač umí vyjádřit shodu zdroje a cíle se stabilním vlastníkem a dokumentace modulu tetheringu je správný odkaz na to, co telefon skutečně dělá.