Kus peab Androidi tulemüüri reegel asuma, kui VPN on sees
Aktiivne saab olla ainult üks VpnService, seega tulemüürirakendus ja VPN-rakendus ei kuhju. Käige läbi üks töötaotlus ja pange iga reegel sinna, kus selle liiklus tegelikult möödub.
Teil on üks lause poliitikat: see rakendus tohib jõuda tööteenuseni ja mitte millegi muuni. Järgmine küsimus näib tootevalikuna, kuid on asukoha küsimus, sest iga võimalik jõustamispunkt näeb telefoni liiklusest erinevat osa. Lüüs näeb ainult seda, mis tunnelisse siseneb. Telefoni poolne filter näeb ainult seda, mida tal on lubatud jälgida. Ühe päringu mõlemast läbi laskmine teeb vastuse ilmselgeks.
Alusta lausest, mitte tootest
Laienda nõuet enne, kui midagi valid. See tähendab paketti ja profiili, milles see töötab, sest tööprofiili rakendus on teine kasutaja kui sama rakendus isiklikus profiilis. See tähendab sihtkohta: host, port ja protokoll, mitte teenuse nimi. See tähendab DNS-teed, mis selle nime lahendab, ja see tähendab, mis peab juhtuma siis, kui tunnel pole saadaval.
Kirja panduna on näite poliitika neli rida: töörakendus tohib jõuda tööteenuseni; töörakendus ei tohi jõuda kuhugi mujale; teised rakendused jäävad muutmata; tunnelita keeldutakse töörakendusest, selle asemel et see langeks otseteele. Igal real on omanik ja kõik need ei ole sama omanik.
Samm 1: mida suudab telefon ise jõustada
Root-õigusteta Androidi tulemüür on VpnService, mis püüab liiklust kohapeal, isegi kui selle taga pole kaugtunnelit. Android lubab ühe aktiivse VPN-teenuse kasutajaprofiili kohta, seega teine tulemüürirakendus ei aheldu esimese taha. See asendab selle ja liides, mida esimene rakendus filtreeris, kaob.
Seepärast annab tulemüüri paigaldamine VPN-kliendi kõrvale harva selle kombinatsiooni, mida inimesed ootavad. Kui tulemüür käivitub ja VPN katkeb, ei olnud midagi ühendatud; need kaks vahetasid kohti. Liidese asendamine ei ole koostöö ja sümptom on tunnel, mis kukub pidevalt iga kord, kui teine rakendus avatakse.
Toetatud lahendused on olemas: juba kasutatavasse VPN-kliendisse sisse ehitatud filtreerimine, seadme poliitikaohjuriga või tööprofiiliga hallatavad platvormikontrollid või tarnija dokumenteeritud arhitektuur. Kõik muu on katse, mida tuleb pärast iga rakenduse uuendust uuesti kontrollida.
Samm 2: mida suudab jõustada lüüs
Kui liiklus on kaugemas otsas dekrüpteeritud, saab lüüs piirata edastatavaid pakette heakskiidetud aadresside, teenuste või autenditud VPN-identiteetidega. See on tõeline jõustamine kõige suhtes, mis sealt väljub, ja see on õige koht eravõrkude juurdepääsu piiramiseks.
Mida see ei saa, on telefoni rakenduse identiteet, mis on kinnitatud iga tavalise IP-paketi külge. Mitu rakendust, mis jagavad üht tunneliaadressi, on lüüsi jaoks üks subjekt, kui disain ei anna neile eraldi aadresse või eraldi autenditud identiteete. Seega kasutajapõhine reegel lüüsil ei ole rakendusepõhine reegel telefonil, ükskõik kuidas halduskonsool seda nimetab.
Samm 3: loetle, mis ei saabu kunagi
VPN-ist välja jäetud rakendus, mis võtab ühendust lähedal asuva seadmega, ei jõua kunagi lüüsini, seega väljuv tulemüür ei saa keelduda paketist, mida see kunagi ei saa. Sama kehtib soovimatu otsetee kohta katkestuse ajal ja kohalikus juurdepääsuvõrgus toimuva sissetuleva kokkupuute kohta. Need on määratluse järgi kohalikud piirid.
Ka vastupidine kehtib: ühendust lubav kohalik reegel ei anna juurdepääsu lüüsi eravõrgu ACL-i kaudu. Üks päring võib alluda mõlemale piirile ja ühe täitmine ei ütle teise kohta midagi.
Samm 4: määra iga reegel teele
Pane otsus tabelisse enne, kui midagi seadistad, sest tühjad lahtrid on koht, kus disainid ebaõnnestuvad.
| Tee | Kes saab selle jõustada | Pimeala |
|---|---|---|
| Töörakendus tööteenuseni, tunnel üleval | Lüüsi ACL aadressi ja teenuse järgi, pluss kohalik blokeering teistel teedel | Lüüs ei näe, milline rakendus paketi saatis |
| Töörakendus teistele sihtkohtadele, tunnel üleval | Rakendusi teadvustav kohalik filter või lüüs, kui need sihtkohad on seal adresseeritud | Kohalik filter peab olema aktiivne VpnService |
| Töörakendus ilma tunnelita | Kohalik keeld, et rakendus ei saaks võtta otseteed | Nõuab, et filter elaks üle tunneli kadumise |
| Lähedal asuv LAN-seade | Ainult kohalik poliitika | Lüüs ei näe seda kunagi |
Toimiv kuju on kaks piiri kahe tööga. Rakendusi teadvustav kohalik piir juhib telefoni käitumist, sealhulgas otsest langust, ja lüüsi piir juhib kaugresursse. Lüüsi pool saab lubada tööteenust ja keelduda igast teisest eravõrgust, samal ajal kui telefoni poolne poliitika otsustab ise otsetee üle, mille rakendus muidu võtaks.
Samm 5: hoia transport elus, siis kontrolli
Millise kohaliku poliitika ka valid, see peab lubama transporti, mis VPN-i loob ja hoiab. Selle transpordi blokeerimine jätab telefoni ilma tunnelita ja ilma poliitikata, mis ei jõusta midagi sidusalt ja mida on raske diagnoosida, sest rakendusel lihtsalt pole võrku.
Seejärel kontrolli algse lause iga rida, mitte üldmuljet: töörakendus jõuab tööteenuseni, sama rakendus keelatakse teisel sihtkohal, rakendus, mis pole töö jaoks, käitub nagu varem, ja peatatud tunneliga ei lange töörakendus otsesele ühendusele. Kontrolli DNS-teed eraldi, sest privaatne DNS või krüpteeritud lahendaja võib mööda minna filtrist, mis kontrollib ainult aadresse.
Kui mõnda neist sammudest ei saa telefonil täita, on nõue arhitektuuriküsimus, mitte tulemüüri seade. Poliitika jagamine seadme, mida te kontrollite, ja lüüsi, mida te kontrollite, vahel on tavaliselt aus vastus, ja Androidi VPN-ühenduvuse dokumentatsioon on koht, kus kinnitada, mida platvorm ühel teenusel lubab ja mida mitte.