Kur turi gyventi Android ugniasienės taisyklė, kai VPN įjungtas
Aktyvus gali būti tik vienas VpnService, todėl ugniasienės programėlė ir VPN programėlė nesikloja. Pereikite vieną darbo užklausą ir įdėkite kiekvieną taisyklę ten, kur jos srautas tikrai praeina.
Turite vieną politikos sakinį: ši programėlė gali pasiekti darbo paslaugą ir nieko daugiau. Kitas klausimas atrodo kaip produkto pasirinkimas, bet tai vietos klausimas, nes kiekvienas galimas vykdymo taškas mato skirtingą telefono srauto dalį. Tinklų sietuvas mato tik tai, kas patenka į tunelį. Telefono pusės filtras mato tik tai, ką jam leidžiama stebėti. Vienos užklausos pravedimas per abu padaro atsakymą akivaizdų.
Pradėkite nuo sakinio, ne nuo produkto
Išplėskite reikalavimą prieš ką nors rinkdamiesi. Tai reiškia paketą ir profilį, kuriame jis veikia, nes darbo profilio programėlė yra kitas naudotojas nei ta pati programėlė asmeniniame profilyje. Tai reiškia paskirties vietą: mazgas, prievadas ir protokolas, o ne paslaugos pavadinimas. Tai reiškia DNS kelią, kuris išsprendžia tą vardą, ir tai reiškia, kas turi nutikti, kai tunelio nėra.
Užrašyta pavyzdžio politika yra keturios eilutės: darbo programėlė gali pasiekti darbo paslaugą; ji negali pasiekti nieko kito; kitos programėlės lieka nepakitusios; be tunelio darbo programėlei atsisakoma, o ne leidžiama nukristi į tiesioginį kelią. Kiekviena eilutė turi savininką, ir ne visos turi tą patį savininką.
1 žingsnis: ką gali įgyvendinti pats telefonas
Android ugniasienė be root yra VpnService, kuris srautą pagauna vietoje, net kai už jo nėra nuotolinio tunelio. Android leidžia vieną aktyvią VPN paslaugą vienam naudotojo profiliui, todėl antroji ugniasienės programėlė nesijungia už pirmosios. Ji ją pakeičia, ir sąsaja, kurią pirmoji programėlė filtruodavo, dingsta.
Štai kodėl ugniasienės įdiegimas šalia VPN kliento retai duoda tai, ko žmonės tikisi. Jei ugniasienė paleidžiama, o VPN atsijungia, nieko nebuvo sujungta; abi pasikeitė vietomis. Sąsajos pakeitimas nėra bendradarbiavimas, o simptomas yra tunelis, kuris nuolat krinta kiekvieną kartą atidarius kitą programėlę.
Palaikomų išdėstymų būna: filtravimas, integruotas į jau naudojamą VPN klientą, valdomos platformos kontrolės per įrenginio politikos valdiklį ar darbo profilį, arba architektūra, kurią dokumentuoja gamintojas. Visa kita yra eksperimentas, kurį reikia iš naujo patikrinti po kiekvieno programėlės atnaujinimo.
2 žingsnis: ką gali įgyvendinti tinklų sietuvas
Kai srautas iššifruojamas tolimajame gale, tinklų sietuvas gali apriboti perduodamus paketus patvirtintais adresais, paslaugomis ar autentifikuotomis VPN tapatybėmis. Tai tikras vykdymas viskam, kas pro jį išeina, ir tai yra tinkama vieta apriboti prieigą prie privačių potinkių.
Ko jis negauna, yra telefono programėlės tapatybė, prijungta prie kiekvieno įprasto IP paketo. Kelios programėlės, dalijančios vieną tunelio adresą, tinklų sietuvui yra vienas subjektas, nebent dizainas suteikia joms atskirus adresus ar atskiras autentifikuotas tapatybes. Todėl taisyklė vienam naudotojui tinklų sietuvo pusėje nėra taisyklė vienai programėlei telefone, kad ir kaip ją vadintų valdymo konsolė.
3 žingsnis: išvardykite, kas niekada neatvyksta
Programėlė, neįtraukta į VPN ir susisiekianti su netoliese esančiu įrenginiu, niekada nepasiekia tinklų sietuvo, todėl išėjimo ugniasienė negali atmesti paketo, kurio niekada negauna. Tas pats galioja netyčiniam tiesioginiam keliui sutrikimo metu ir įeinančiam poveikiui vietiniame prieigos tinkle. Tai vietinės ribos pagal apibrėžimą.
Ir atvirkščiai: vietinė taisyklė, leidžianti ryšį, nesuteikia prieigos per tinklų sietuvo privataus tinklo ACL. Viena užklausa gali būti pavaldi abiem riboms, o vienos patenkinimas nieko nesako apie kitą.
4 žingsnis: priskirkite kiekvieną taisyklę keliui
Įdėkite sprendimą į lentelę prieš ką nors konfigūruodami, nes tuščios ląstelės yra vieta, kur dizainas žlunga.
| Kelias | Kas gali jį įgyvendinti | Aklinoji vieta |
|---|---|---|
| Darbo programėlė į darbo paslaugą, tunelis veikia | Tinklų sietuvo ACL pagal adresą ir paslaugą, plius vietinis kitų kelių blokavimas | Tinklų sietuvas nemato, kuri programėlė išsiuntė paketą |
| Darbo programėlė į kitas paskirties vietas, tunelis veikia | Vietinis programėles suprantantis filtras arba tinklų sietuvas, jei tos paskirties vietos ten adresuotos | Vietinis filtras turi būti aktyvus VpnService |
| Darbo programėlė be tunelio | Vietinis atsisakymas, kad programėlė negalėtų pasirinkti tiesioginio kelio | Reikalauja, kad filtras išgyventų tunelio dingimą |
| Netoliese esantis LAN įrenginys | Tik vietinė politika | Tinklų sietuvas to niekada nemato |
Veikianti forma yra dvi ribos su dviem užduotimis. Vietinė programėles suprantanti riba valdo telefono elgesį, įskaitant tiesioginį nukritimą, o tinklų sietuvo riba valdo nuotolinius išteklius. Sietuvo pusė gali leisti darbo paslaugą ir atmesti kiekvieną kitą privatų potinkį, o telefono pusės politika pati sprendžia dėl tiesioginio kelio, kurį programėlė kitu atveju pasirinktų.
5 žingsnis: palaikykite transportą gyvą, tada patikrinkite
Kokią bebūtų vietinę politiką pasirinkę, ji turi leisti transportą, kuris nustato ir palaiko VPN. To transporto blokavimas palieka telefoną be tunelio ir be politikos, o tai nieko nuosekliai neįgyvendina ir sunkiai diagnozuojama, nes programėlė tiesiog neturi tinklo.
Tada patikrinkite kiekvieną pradinio sakinio eilutę, o ne bendrą įspūdį: darbo programėlė pasiekia darbo paslaugą, ta pati programėlė atmetama kitoje paskirties vietoje, ne darbo programėlė elgiasi kaip anksčiau, o sustabdžius tunelį darbo programėlė nenukrinta į tiesioginį ryšį. DNS kelią patikrinkite atskirai, nes privatus DNS ar šifruotas sprendėjas gali apeiti filtrą, kuris tikrina tik adresus.
Jei vieno iš šių žingsnių telefone neįmanoma įgyvendinti, reikalavimas yra architektūros klausimas, o ne ugniasienės nustatymas. Politikos padalijimas tarp jūsų valdomo įrenginio ir jūsų valdomo tinklų sietuvo paprastai yra sąžiningas atsakymas, o Android VPN ryšio dokumentacija yra vieta, kur patvirtinate, ką platforma leis ir ko neleis vienai paslaugai.