Gde pravilo Android firewall-a mora da stoji kada je VPN uključen
Samo jedan VpnService može biti aktivan, pa se firewall aplikacija i VPN aplikacija ne slažu u niz. Prođite kroz jedan radni zahtev i smestite svako pravilo tamo gde saobraćaj zaista prolazi.
Imate jednu rečenicu politike: ova aplikacija sme da dosegne radni servis i ništa drugo. Sledeće pitanje izgleda kao izbor proizvoda, ali je pitanje mesta, jer svaka moguća tačka primene vidi drugi podskup saobraćaja telefona. Gateway vidi samo ono što ulazi u tunel. Filter na telefonu vidi samo ono što mu je dozvoljeno da posmatra. Provlačenje jednog zahteva kroz obe tačke čini odgovor očiglednim.
Počnite od rečenice, ne od proizvoda
Razvijte zahtev pre nego što bilo šta izaberete. To znači paket i profil u kome radi, jer je aplikacija u radnom profilu drugi korisnik od iste aplikacije u ličnom profilu. To znači odredište: host, port i protokol, a ne naziv servisa. To znači DNS putanju koja razrešava taj naziv i znači šta treba da se dogodi kada tunel nije dostupan.
Zapisana, politika za primer ima četiri reda: radna aplikacija sme da dosegne radni servis; radna aplikacija ne sme ništa drugo; ostale aplikacije su nepromenjene; bez tunela radnoj aplikaciji se odbija pristup umesto da pređe na direktnu vezu. Svaki red ima vlasnika, i nisu svi isti vlasnik.
Korak 1: šta sam telefon može da primeni
Android firewall bez root prava je VpnService koji hvata saobraćaj lokalno, čak i kada iza njega nema udaljenog tunela. Android dozvoljava samo jedan aktivni VPN servis po korisničkom profilu, pa se druga firewall aplikacija ne nadovezuje na prvu. Ona je zamenjuje, a interfejs koji je prva aplikacija filtrirala nestaje.
Zato instaliranje firewall-a pored VPN klijenta retko daje kombinaciju koju ljudi očekuju. Ako firewall krene a VPN se isključi, ništa nije spojeno; njih dvoje su zamenili mesta. Zamena interfejsa nije saradnja, a simptom je tunel koji stalno pada kad god se otvori druga aplikacija.
Podržani rasporedi ipak postoje: filtriranje ugrađeno u VPN klijent koji već koristite, upravljane platforme kontrole kroz kontroler politike uređaja ili radni profil, ili arhitektura koju proizvođač dokumentuje. Sve ostalo je eksperiment koji mora iznova da se proveri posle svakog ažuriranja aplikacije.
Korak 2: šta gateway može da primeni
Kada se saobraćaj dekriptuje na drugom kraju, gateway može da ograniči prosleđene pakete na odobrene adrese, servise ili autentifikovane VPN identitete. To je stvarna primena za sve što izlazi kroz njega, i pravo mesto za ograničavanje pristupa privatnim podmrežama.
Ono što ne dobija jeste identitet aplikacije telefona vezan za svaki običan IP paket. Nekoliko aplikacija koje dele jednu adresu tunela su jedan subjekat za gateway, osim ako im dizajn ne da odvojene adrese ili odvojene autentifikovane identitete. Pravilo po korisniku na gateway-u zato nije pravilo po aplikaciji na telefonu, kako god ga konzola za upravljanje nazivala.
Korak 3: popišite šta nikada ne stiže
Aplikacija isključena iz VPN-a koja kontaktira obližnji uređaj nikada ne stiže do gateway-a, pa izlazni firewall ne može da odbije paket koji nikada ne primi. Isto važi za nenamernu direktnu rutu tokom ispada i za ulaznu izloženost na lokalnoj pristupnoj mreži. To su lokalne granice po definiciji.
Važi i obrnuto: lokalno pravilo koje dozvoljava vezu ne daje pristup kroz ACL privatne mreže gateway-a. Jedan zahtev može biti podložan obema granicama, a ispunjavanje jedne ne govori ništa o drugoj.
Korak 4: dodelite svakom pravilu putanju
Stavite odluku u tabelu pre nego što bilo šta konfigurišete, jer su prazne ćelije mesta na kojima dizajni propadaju.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
Oblik koji funkcioniše su dve granice sa dva posla. Lokalna granica svesna aplikacija upravlja ponašanjem telefona, uključujući direktni fallback, a gateway granica upravlja udaljenim resursima. Strana gateway-a može da dozvoli radni servis i odbije svaku drugu privatnu podmrežu, dok politika na telefonu sama odlučuje o direktnoj putanji koju bi aplikacija inače mogla da izabere.
Korak 5: održite transport živim, pa proverite
Koju god lokalnu politiku da izaberete, ona mora da propušta transport koji uspostavlja i održava VPN. Blokiranje tog transporta ostavlja telefon bez tunela i bez politike, što ništa ne primenjuje dosledno i teško se dijagnostikuje jer aplikacija jednostavno nema mrežu.
Zatim proverite svaki red originalne rečenice, a ne opšti utisak: radna aplikacija doseže radni servis, ista aplikacija je odbijena na drugom odredištu, aplikacija koja nije radna ponaša se kao pre, a sa zaustavljenim tunelom radna aplikacija ne prelazi na direktnu vezu. Proverite DNS putanju odvojeno, jer privatni DNS ili šifrovani resolver mogu da zaobiđu filter koji proverava samo adrese.
Ako neki od tih koraka ne može da se ispuni na telefonu, zahtev je arhitektonsko pitanje, a ne podešavanje firewall-a. Deljenje politike između uređaja koji kontrolišete i gateway-a koji kontrolišete obično je iskren odgovor, a Android dokumentacija o VPN povezivanju je mesto gde se potvrđuje šta platforma hoće i neće dozvoliti jednom servisu.