Kje mora pravilo požarnega zidu Android stati, ko je VPN vklopljen
Aktiven je lahko samo en VpnService, zato se aplikacija požarnega zidu in aplikacija VPN ne združita. Prehodite eno delovno zahtevo in vsako pravilo postavite tja, kjer promet resnično prehaja.
Imate en stavek politike: ta aplikacija lahko doseže delovno storitev in nič drugega. Naslednje vprašanje je videti kot izbira izdelka, a je vprašanje mesta, ker vsaka možna točka uveljavljanja vidi drugo podmnožico prometa telefona. Prehod vidi samo tisto, kar vstopi v tunel. Filter na strani telefona vidi samo tisto, kar mu je dovoljeno opazovati. Če eno zahtevo speljete skozi obe, postane odgovor očiten.
Začnite s stavkom, ne z izdelkom
Zahtevo razširite, preden karkoli izberete. To pomeni paket in profil, v katerem teče, ker je aplikacija v delovnem profilu drug uporabnik kot ista aplikacija v osebnem profilu. To pomeni cilj: gostitelj, vrata in protokol, ne ime storitve. To pomeni pot DNS, ki to ime razreši, in pomeni, kaj naj se zgodi, ko tunel ni na voljo.
Zapisana politika za primer ima štiri vrstice: delovna aplikacija lahko doseže delovno storitev; delovna aplikacija ne sme doseči ničesar drugega; druge aplikacije ostanejo nespremenjene; brez tunela je delovni aplikaciji zavrnjen dostop, namesto da bi prešla na neposredno povezavo. Vsaka vrstica ima lastnika in niso vse isti lastnik.
Korak 1: kaj lahko uveljavi telefon sam
Požarni zid Android brez roota je VpnService, ki promet zajame lokalno, tudi ko za njim ni oddaljenega tunela. Android dovoljuje eno aktivno storitev VPN na uporabniški profil, zato se druga aplikacija požarnega zidu ne vključi za prvo. Nadomesti jo in vmesnik, ki ga je prva aplikacija filtrirala, izgine.
Zato namestitev požarnega zidu poleg odjemalca VPN redko da kombinacijo, ki jo ljudje pričakujejo. Če se požarni zid zažene in se VPN odklopi, se ni nič združilo; ta dva sta zamenjala mesti. Zamenjava vmesnika ni sodelovanje, simptom pa je tunel, ki vedno znova pade, ko odprete drugo aplikacijo.
Podprte ureditve vendarle obstajajo: filtriranje, vgrajeno v odjemalec VPN, ki ga že uporabljate, upravljani nadzori platforme prek krmilnika pravil naprave ali delovnega profila, ali arhitektura, ki jo dokumentira dobavitelj. Vse drugo je poskus, ki ga je treba po vsaki posodobitvi aplikacije znova preveriti.
Korak 2: kaj lahko uveljavi prehod
Ko je promet na oddaljenem koncu dešifriran, lahko prehod omeji posredovane pakete na odobrene naslove, storitve ali overjene identitete VPN. To je resnično uveljavljanje za vse, kar izstopi skozi njega, in je pravo mesto za omejevanje dostopa do zasebnih podomrežij.
Česar pa ne prejme, je identiteta aplikacije telefona, pripeta k vsakemu običajnemu paketu IP. Več aplikacij, ki si deli en naslov tunela, je za prehod en subjekt, razen če jim zasnova dodeli ločene naslove ali ločene overjene identitete. Pravilo na uporabnika na prehodu torej ni pravilo na aplikacijo v telefonu, ne glede na to, kako ga imenuje konzola za upravljanje.
Korak 3: naštejte, kaj nikoli ne prispe
Aplikacija, izključena iz VPN, ki vzpostavi stik z napravo v bližini, nikoli ne doseže prehoda, zato izhodni požarni zid ne more zavrniti paketa, ki ga nikoli ne prejme. Enako velja za nenamerno neposredno pot med izpadom in za vhodno izpostavljenost v lokalnem dostopovnem omrežju. To so lokalne meje po definiciji.
Velja tudi obratno: lokalno pravilo, ki povezavo dovoli, ne podeli dostopa skozi ACL zasebnega omrežja prehoda. Ena zahteva je lahko podvržena obema mejama, izpolnitev ene pa o drugi ne pove ničesar.
Korak 4: vsakemu pravilu dodelite pot
Odločitev postavite v preglednico, preden karkoli konfigurirate, ker so prazne celice mesta, kjer zasnove spodletijo.
| 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 |
Delujoča oblika sta dve meji z dvema nalogama. Lokalna meja, ki pozna aplikacije, upravlja vedenje telefona, vključno z neposrednim obhodom, meja prehoda pa upravlja oddaljene vire. Stran prehoda lahko dovoli delovno storitev in zavrne vsako drugo zasebno podomrežje, medtem ko se politika na strani telefona sama odloči o neposredni poti, ki bi jo aplikacija sicer lahko ubrala.
Korak 5: ohranite promet živ, nato preverite
Ne glede na lokalno politiko, ki jo izberete, mora prepuščati promet, ki VPN vzpostavi in vzdržuje. Blokiranje tega prometa pusti telefon brez tunela in brez politike, kar ničesar ne uveljavlja dosledno in je težko diagnosticirati, ker aplikacija preprosto nima omrežja.
Nato preverite vsako vrstico prvotnega stavka, ne splošnega vtisa: delovna aplikacija doseže delovno storitev, isti aplikaciji je na drugem cilju zavrnjen dostop, nedelovna aplikacija se obnaša kot prej, ob ustavljenem tunelu pa delovna aplikacija ne preide na neposredno povezavo. Pot DNS preverite ločeno, ker lahko zasebni DNS ali šifriran razreševalnik obide filter, ki pregleduje samo naslove.
Če katerega od teh korakov v telefonu ni mogoče izpolniti, je zahteva vprašanje arhitekture in ne nastavitev požarnega zidu. Razdelitev politike med napravo, ki jo nadzirate, in prehodom, ki ga nadzirate, je običajno pošten odgovor, dokumentacija o povezljivosti VPN v Androidu pa je kraj, kjer potrdite, kaj bo platforma eni storitvi dovolila in česa ne.