Rozdelené tunelovanie pre klientov hotspotu nie je vylúčenie podľa aplikácií
Vylúčenie aplikácie z VPN mení len telefón. Pripojený notebook potrebuje vlastné pravidlo preposielania, zladené podľa zdroja, cieľa a NAT.
Dve požiadavky, ktoré znejú rovnako, nie sú rovnaké: „vylúč túto aplikáciu z VPN“ a „pošli tento jeden cieľ mimo VPN pre notebook na mojom hotspote“. Prvá mení, ako si soket v telefóne vyberá sieť. Druhá musí zmeniť rozhodnutie o preposielaní paketu, ktorý prišiel z iného zariadenia po tom, čo ho telefón už prijal. Zámena oboch je dôvod, prečo klient hotspotu skončí s výnimkou, ktorá vždy platila len pre vlastný prehliadač telefónu.
Dve otázky vlastnia dva rôzne podsystémy
Android drží sieťovanie aplikácií a tethering oddelene. Sokety aplikácií priraďuje k sieti zásobník konektivity a aplikácia VPN rozhoduje, ktoré z jej vlastných soketov vstúpia do tunela. Preposielané pakety od pripojeného klienta spracúva podsystém tetheringu, ktorý žiada netd o trasy, pravidlá politiky a preklad na rozhraní smerom nadol.
Vylúčenie podľa aplikácie sa vyhodnocuje, keď aplikácia otvorí soket. Preposielaný paket sa k tejto kontrole nikdy nedostane, pretože nevznikol zo soketu aplikácie v tomto zariadení. To je celý dôvod, prečo sa dve nastavenia nemôžu navzájom nahradiť, a nie je to chyba ani v jednom z nich.
Čo vylúčenie podľa aplikácie skutočne mení
Tvorca VpnService môže pomenovať pakety, ktoré zostávajú mimo tunela, pomocou addDisallowedApplication, alebo pomenovať jediné pakety povolené vnútri pomocou addAllowedApplication. Tieto aplikácie potom otvárajú sokety v podkladovej sieti, zatiaľ čo VPN naďalej vlastní predvolenú trasu pre všetko ostatné.
Rozsah je presný: vlastné sokety paketu, v tomto zariadení, kým je tunel aktívny. Nehovorí nič o preposielanej prevádzke, nič o druhom zariadení a nič o paketoch, ktoré systém odosiela v mene tetheringu.
Nie je to ani riadenie podľa cieľa. Vylúčenie prehliadača vylučuje každú adresu, na ktorú sa tento prehliadač dostane, vrátane tej, ktorú ste chceli udržať vnútri tunela. Keď požiadavka pomenuje cieľ, a nie aplikáciu, je výber aplikácie nesprávny nástroj už zo svojej konštrukcie.
Ako vyzerá preposielaný paket z pohľadu telefónu
Paket klienta prichádza na rozhranie hotspotu so súkromnou zdrojovou adresou pridelenou telefónom, povedzme 192.168.43.20, a s verejným cieľom. Aby ho telefón preposlal, potrebuje trasu k nadradenému spojeniu a pravidlo prekladu, aby odpovede našli cestu späť, pretože súkromná adresa klienta nemá v mobilnej sieti žiadny význam.
Android to vyjadruje pravidlami politiky, ktoré vyberajú smerovaciu tabuľku, a netd príslušné tabuľky a pravidlá znovu zostaví, keď sa siete a VPN zmenia. Číslo tabuľky, priorita pravidla alebo názov rozhrania odpísané z príspevku na fóre alebo z toho istého modelu v staršom vydaní nezakladajú trvalé vlastníctvo. Toto zostavovanie je aj dôvod, prečo ručne napísané pravidlo môže hodinu fungovať a po ďalšom pripojení prestať.
Akú politiku výnimka pre hotspot skutočne potrebuje
Skôr než sa dotknete pravidla, zapíšte rozhodnutie ako zdroj, cieľ a zamýšľanú cestu. Minimálna podoba pre jeden schválený cieľ vyzerá takto:
| 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 smery musia byť úplné. Priama vetva potrebuje použiteľnú trasu cez mobilné nadradené spojenie, ktoré je práve aktuálne; vetva VPN potrebuje trasu tunela plus povolenie preposielať. Akýkoľvek preklad zdroja musí zodpovedať zvolenému výstupu, pretože NAT aplikovaný na rozhraní tunela ukazuje adresu tunela, a nie mobilnú, a návratová cesta sa potom nezhoduje s odchádzajúcou cestou.
Odpovede sa musia dostať k tomu istému klientovi nižšie cez sledovaný stav alebo výslovnú trasu, a počítadlo odchádzajúcich paketov nič z toho nedokazuje. Držte aj vlastnú vonkajšiu prepravu VPN mimo rozsahu výnimky, inak pakety nosiča tunela zdedia politiku napísanú pre webovú požiadavku klienta.
Jedna zachytená adresa nie je cieľ
Jediná adresa IPv4 prečítaná z prehliadača je snímka. Veľké služby odpovedajú z anycastu alebo z rotujúceho súboru okrajových adries, mnohé sú s dvojitým zásobníkom, a prihlasovací tok môže zasiahnuť hostiteľov overovania a telemetrie, ktoré stránka nikdy nezobrazí. Výnimka postavená okolo adresy, ktorú ste náhodou videli, sa nabudúce rozbije, keď služba prerozdelí záťaž.
Použite dokumentované adresy vlastníka služby alebo rozsah, ktorý zverejňuje, a počítajte s oboma rodinami adries. Ak požiadavku nemožno vyjadriť ako stabilnú množinu, je to pravdepodobne otázka politiky pre službu, a nie smerovací trik v telefóne.
Overte zo strany nižšie
Tri kontroly v tomto poradí: vybraná služba z notebooku, bežný cieľ, ktorý musí zostať vo VPN, a aplikácia v telefóne, ktorá musí zostať nedotknutá. Potom to zopakujte po opätovnom pripojení a po zmene nadradeného spojenia, pretože práve vtedy sa tabuľky politiky znovu zostavujú.
Ak implementácia zdieľania v telefóne nedokáže udržať tento kontrakt cez opätovné pripojenie, presuňte selektívnu politiku na podporovaný smerovač nižšie, namiesto hromadenia root pravidiel v prístroji. Smerovač dokáže vyjadriť zhodu zdroja a cieľa so stabilným vlastníkom, a dokumentácia modulu tetheringu je správny odkaz na to, čo telefón skutočne robí.