Kur jādzīvo Android ugunsmūra noteikumam, kad VPN ir ieslēgts
Aktīvs var būt tikai viens VpnService, tāpēc ugunsmūra lietotne un VPN lietotne nesakraujas. Izstaigājiet vienu darba pieprasījumu un ievietojiet katru noteikumu tur, kur tā plūsma patiešām iet.
Jums ir viens politikas teikums: šī lietotne drīkst sasniegt darba pakalpojumu un neko citu. Nākamais jautājums izskatās pēc produkta izvēles, bet tas ir vietas jautājums, jo katrs iespējamais izpildes punkts redz citu tālruņa plūsmas daļu. Vārteja redz tikai to, kas ieiet tunelī. Tālruņa puses filtrs redz tikai to, ko tam atļauts novērot. Viena pieprasījuma izlaišana caur abiem padara atbildi acīmredzamu.
Sāciet ar teikumu, nevis ar produktu
Izvērsiet prasību, pirms kaut ko izvēlaties. Tas nozīmē pakotni un profilu, kurā tā darbojas, jo darba profila lietotne ir cits lietotājs nekā tā pati lietotne personīgajā profilā. Tas nozīmē galamērķi: resursdators, ports un protokols, nevis pakalpojuma nosaukums. Tas nozīmē DNS ceļu, kas atrisina šo nosaukumu, un tas nozīmē, kas jādara, kad tunelis nav pieejams.
Uzrakstīta parauga politika ir četras rindas: darba lietotne drīkst sasniegt darba pakalpojumu; tā nedrīkst sasniegt neko citu; citas lietotnes paliek nemainīgas; bez tuneļa darba lietotnei atsaka, nevis ļauj tai iekrist tiešā ceļā. Katrai rindai ir īpašnieks, un ne visiem ir viens un tas pats īpašnieks.
1. solis: ko var īstenot pats tālrunis
Android ugunsmūris bez root ir VpnService, kas uztver plūsmu lokāli, arī tad, ja aiz tā nav attālināta tuneļa. Android atļauj vienu aktīvu VPN pakalpojumu vienam lietotāja profilam, tāpēc otra ugunsmūra lietotne nepievienojas aiz pirmās. Tā to aizstāj, un saskarne, ko pirmā lietotne filtrēja, pazūd.
Tāpēc ugunsmūra uzstādīšana blakus VPN klientam reti dod to kombināciju, ko cilvēki gaida. Ja ugunsmūris startē un VPN atvienojas, nekas netika apvienots; abi samainījās vietām. Saskarnes aizstāšana nav sadarbība, un simptoms ir tunelis, kas nemitīgi krīt katru reizi, kad tiek atvērta otra lietotne.
Atbalstīti izkārtojumi pastāv: filtrēšana, kas iebūvēta jau lietotajā VPN klientā, pārvaldītas platformas kontroles, izmantojot ierīces politikas kontrolieri vai darba profilu, vai arhitektūra, ko dokumentē ražotājs. Viss pārējais ir eksperiments, kas pēc katra lietotnes atjauninājuma jāpārbauda no jauna.
2. solis: ko var īstenot vārteja
Kad plūsma ir atšifrēta tālajā galā, vārteja var ierobežot pārsūtītās paketes ar apstiprinātām adresēm, pakalpojumiem vai autentificētām VPN identitātēm. Tā ir īsta izpilde visam, kas caur to iziet, un tā ir pareizā vieta, kur ierobežot piekļuvi privātiem apakštīkliem.
To, ko tā nesaņem, ir tālruņa lietotnes identitāte, kas piesaistīta katrai parastajai IP pakaķei. Vairākas lietotnes, kas dala vienu tuneļa adresi, vārtejai ir viens subjekts, ja vien dizains tām nedod atsevišķas adreses vai atsevišķas autentificētas identitātes. Tāpēc noteikums uz lietotāju vārtejā nav noteikums uz lietotni tālrunī, lai kā to dēvētu pārvaldības konsole.
3. solis: uzskaitiet, kas nekad nenonāk
Lietotne, kas izslēgta no VPN un sazinās ar tuvumā esošu ierīci, nekad nenonāk vārtejā, tāpēc izejas ugunsmūris nevar atteikt pakaķi, ko tas nekad nesaņem. Tas pats attiecas uz nejaušu tiešu ceļu pārtraukuma laikā un uz ienākošu iedarbību vietējā piekļuves tīklā. Tās ir vietējas robežas pēc definīcijas.
Un otrādi: vietējs noteikums, kas atļauj savienojumu, nedod piekļuvi caur vārtejas privātā tīkla ACL. Viens pieprasījums var būt pakļauts abām robežām, un vienas izpilde neko nepasaka par otru.
4. solis: piešķiriet katru noteikumu ceļam
Ielieciet lēmumu tabulā, pirms kaut ko konfigurējat, jo tukšās ailes ir vieta, kur dizaini sabrūk.
| Ceļš | Kas to var īstenot | Aklā zona |
|---|---|---|
| Darba lietotne uz darba pakalpojumu, tunelis ieslēgts | Vārtejas ACL pēc adreses un pakalpojuma, plus vietēja citu ceļu bloķēšana | Vārteja neredz, kura lietotne nosūtīja pakaķi |
| Darba lietotne uz citiem galamērķiem, tunelis ieslēgts | Vietējs filtrs, kas pazīst lietotnes, vai vārteja, ja šie galamērķi tur ir adresēti | Vietējam filtram jābūt aktīvam VpnService |
| Darba lietotne bez tuneļa | Vietējs atteikums, lai lietotne nevarētu izvēlēties tiešu ceļu | Prasa, lai filtrs pārdzīvotu tuneļa pazušanu |
| Tuvumā esoša LAN ierīce | Tikai vietēja politika | Vārteja to nekad neredz |
Strādājošā forma ir divas robežas ar diviem uzdevumiem. Vietējā robeža, kas pazīst lietotnes, pārvalda tālruņa uzvedību, tostarp tiešo kritienu, un vārtejas robeža pārvalda attālinātos resursus. Vārtejas puse var atļaut darba pakalpojumu un atteikt katru citu privāto apakštīklu, kamēr tālruņa puses politika pati izlemj par tiešo ceļu, kuru lietotne citādi izvēlētos.
5. solis: uzturiet transportu dzīvu, tad pārbaudiet
Lai kādu vietējo politiku jūs izvēlētos, tai jāatļauj transports, kas izveido un uztur VPN. Šī transporta bloķēšana atstāj tālruni bez tuneļa un bez politikas, kas neko konsekventi neīsteno un ir grūti diagnosticējama, jo lietotnei vienkārši nav tīkla.
Pēc tam pārbaudiet katru sākotnējā teikuma rindu, nevis kopējo iespaidu: darba lietotne sasniedz darba pakalpojumu, tā pati lietotne tiek atteikta citā galamērķī, lietotne, kas nav darba, uzvedas kā iepriekš, un ar apturētu tuneli darba lietotne neiekrīt tiešā savienojumā. Pārbaudiet DNS ceļu atsevišķi, jo privāts DNS vai šifrēts atrisinātājs var apiet filtru, kas pārbauda tikai adreses.
Ja kādu no šiem soļiem tālrunī nav iespējams izpildīt, prasība ir arhitektūras jautājums, nevis ugunsmūra iestatījums. Politikas sadalīšana starp ierīci, ko jūs kontrolējat, un vārteju, ko jūs kontrolējat, parasti ir godīgā atbilde, un Android VPN savienojamības dokumentācija ir vieta, kur apstiprināt, ko platforma atļaus un ko neļaus vienam pakalpojumam.