Kde musí pravidlo firewallu v Androidu žít, když je VPN zapnutá
Aktivní může být jen jeden VpnService, takže aplikace firewallu a aplikace VPN se na sebe nevrší. Projděte jeden pracovní požadavek a umístěte každé pravidlo tam, kudy jeho provoz skutečně prochází.
Máte jednu větu zásady: tato aplikace smí dosáhnout na pracovní službu a na nic jiného. Další otázka vypadá jako volba produktu, ale je to otázka umístění, protože každý možný vynucovací bod vidí jinou část provozu telefonu. Brána vidí jen to, co vstoupí do tunelu. Filtr na straně telefonu vidí jen to, co mu je dovoleno pozorovat. Provedení jednoho požadavku oběma cestami dělá odpověď zřejmou.
Začněte větou, ne produktem
Rozviňte požadavek dřív, než cokoli vyberete. Znamená to balíček a profil, ve kterém běží, protože aplikace v pracovním profilu je jiný uživatel než stejná aplikace v osobním profilu. Znamená to cíl: hostitel, port a protokol, ne název služby. Znamená to cestu DNS, která to jméno překládá, a znamená to, co se má stát, když tunel není k dispozici.
Zapsaná zásada pro příklad má čtyři řádky: pracovní aplikace smí dosáhnout pracovní služby; pracovní aplikace nesmí dosáhnout ničeho jiného; ostatní aplikace zůstávají beze změny; bez tunelu se pracovní aplikaci odmítne, místo aby spadla na přímou cestu. Každý řádek má vlastníka a ne všichni jsou stejný vlastník.
Krok 1: co dokáže vynutit samotný telefon
Android firewall bez rootu je VpnService, který zachytává provoz lokálně, i když za ním není žádný vzdálený tunel. Android povoluje jednu aktivní službu VPN na uživatelský profil, takže druhá aplikace firewallu se za první neřetězí. Nahrazuje ji a rozhraní, které první aplikace filtrovala, zmizí.
Proto instalace firewallu vedle VPN klienta jen zřídka přinese kombinaci, kterou lidé očekávají. Když firewall nastartuje a VPN se odpojí, nic se nespojilo; oba si vyměnily místa. Nahrazení rozhraní není spolupráce a příznakem je tunel, který neustále padá pokaždé, když se otevře druhá aplikace.
Podporovaná uspořádání existují: filtrování zabudované ve VPN klientovi, který už používáte, spravované ovládací prvky platformy přes správce zásad zařízení nebo pracovní profil, nebo architektura, kterou dokumentuje výrobce. Všechno ostatní je experiment, který je nutné znovu ověřit po každé aktualizaci aplikace.
Krok 2: co dokáže vynutit brána
Jakmile je provoz na vzdáleném konci dešifrován, může brána omezit předávané pakety na schválené adresy, služby nebo ověřené identity VPN. To je skutečné vynucení pro vše, co tudy odchází, a je to správné místo pro omezení přístupu k privátním podsítím.
Co nedostává, je identita aplikace z telefonu připojená ke každému běžnému IP paketu. Několik aplikací sdílejících jednu adresu tunelu je pro bránu jeden subjekt, pokud jim návrh nedá oddělené adresy nebo oddělené ověřené identity. Pravidlo na uživatele na bráně tedy není pravidlem na aplikaci v telefonu, ať ho konzole pro správu nazývá jakkoli.
Krok 3: vypište, co nikdy nedorazí
Aplikace vyloučená z VPN, která kontaktuje blízké zařízení, se k bráně nikdy nedostane, takže výstupní firewall nemůže odmítnout paket, který nikdy nedostane. Totéž platí pro nezamýšlenou přímou cestu během výpadku a pro příchozí expozici v místní přístupové síti. To jsou místní hranice podle definice.
Obráceně to platí také: místní pravidlo, které povolí spojení, nedává přístup přes ACL privátní sítě brány. Jeden požadavek může podléhat oběma hranicím a splnění jedné nic neříká o druhé.
Krok 4: přiřaďte každé pravidlo cestě
Dejte rozhodnutí do tabulky, než cokoli nakonfigurujete, protože prázdné buňky jsou místem, kde návrhy selhávají.
| Cesta | Kdo ji může vynutit | Slepé místo |
|---|---|---|
| Pracovní aplikace k pracovní službě, tunel běží | ACL brány na adresu a službu, plus místní blokace ostatních cest | Brána nevidí, která aplikace paket odeslala |
| Pracovní aplikace k jiným cílům, tunel běží | Místní filtr rozlišující aplikace, nebo brána, pokud jsou ty cíle adresovány tam | Místní filtr musí být aktivní VpnService |
| Pracovní aplikace bez tunelu | Místní odmítnutí, aby aplikace nemohla zvolit přímou cestu | Vyžaduje, aby filtr přežil zmizení tunelu |
| Blízké zařízení v LAN | Jen místní zásada | Brána to nikdy nevidí |
Funkční podoba jsou dvě hranice se dvěma úlohami. Místní hranice rozlišující aplikace řídí chování telefonu včetně přímého pádu a hranice brány řídí vzdálené zdroje. Strana brány může povolit pracovní službu a odmítnout každou jinou privátní podsíť, zatímco zásada na straně telefonu rozhoduje sama o přímé cestě, kterou by aplikace jinak vzala.
Krok 5: udržte transport živý a pak ověřte
Ať zvolíte jakoukoli místní zásadu, musí povolit transport, který VPN navazuje a udržuje. Zablokování tohoto transportu nechá telefon bez tunelu a bez zásady, což nic koherentně nevynucuje a špatně se diagnostikuje, protože aplikace prostě nemá síť.
Pak ověřte každý řádek původní věty, ne celkový dojem: pracovní aplikace dosáhne na pracovní službu, stejné aplikaci je odepřen přístup na jiný cíl, aplikace, která není pracovní, se chová jako dřív, a při zastaveném tunelu pracovní aplikace nespadne na přímé spojení. Cestu DNS zkontrolujte zvlášť, protože privátní DNS nebo šifrovaný resolver může obejít filtr, který kontroluje jen adresy.
Pokud jeden z těchto kroků nelze na telefonu splnit, požadavek je otázka architektury, ne nastavení firewallu. Rozdělit zásadu mezi zařízení, které ovládáte, a bránu, kterou ovládáte, je obvykle poctivá odpověď, a dokumentace k připojení VPN v Androidu je místem, kde potvrdíte, co platforma jedné službě dovolí a co ne.