Kie regulo de Android-fajroŝirmilo devas loĝi kiam VPN estas ŝaltita
Nur unu VpnService povas esti aktiva, do fajroŝirmila aplikaĵo kaj VPN-a aplikaĵo ne stakiĝas. Trairu unu laborpeton kaj metu ĉiun regulon tie, kie ĝia trafiko vere pasas.
Vi havas unu frazon da politiko: ĉi tiu aplikaĵo rajtas atingi la laboran servon kaj nenion alian. La sekva demando aspektas kiel produkta elekto, sed ĝi estas demando pri loko, ĉar ĉiu ebla plenum-punkto vidas malsaman parton de la trafiko de la telefono. La enirejo vidas nur tion, kio eniras la tunelon. La filtrilo ĉe la telefono vidas nur tion, kion ĝi rajtas observi. Trapasi unu peton tra ambaŭ faras la respondon evidenta.
Komencu per la frazo, ne per la produkto
Etendu la postulon antaŭ ol elekti ion ajn. Tio signifas la pakaĵon kaj la profilon, en kiu ĝi funkcias, ĉar aplikaĵo en la labora profilo estas alia uzanto ol la sama aplikaĵo en la persona profilo. Ĝi signifas la celon: gastiganto, pordo kaj protokolo, ne servo-nomo. Ĝi signifas la DNS-vojon, kiu solvas tiun nomon, kaj ĝi signifas, kio devas okazi kiam la tunelo ne haveblas.
Skribite, la politiko por la ekzemplo havas kvar liniojn: la labora aplikaĵo rajtas atingi la laboran servon; la labora aplikaĵo rajtas atingi nenion alian; aliaj aplikaĵoj restas neŝanĝitaj; sen tunelo, la labora aplikaĵo estas rifuzata anstataŭ fali al rekta vojo. Ĉiu linio havas posedanton, kaj ne ĉiuj estas la sama posedanto.
Paŝo 1: kion la telefono mem povas plenumi
Android-fajroŝirmilo sen radikaj rajtoj estas VpnService, kiu kaptas trafikon loke, eĉ kiam malantaŭ ĝi ne estas fora tunelo. Android permesas unu aktivan VPN-servon por uzanto-profilo, do dua fajroŝirmila aplikaĵo ne ĉenumas malantaŭ la unua. Ĝi anstataŭas ĝin, kaj la interfaco, kiun la unua aplikaĵo filtris, malaperas.
Tial instali fajroŝirmilon apud VPN-kliento malofte donas la kombinaĵon, kiun homoj atendas. Se la fajroŝirmilo startas kaj la VPN malŝaltiĝas, nenio estis kombinita; la du interŝanĝis lokojn. Anstataŭigo de interfaco ne estas kunlaboro, kaj la simptomo estas tunelo, kiu konstante falas ĉiufoje, kiam la alia aplikaĵo malfermiĝas.
Subtenataj aranĝoj ekzistas: filtrado enkonstruita en la VPN-kliento, kiun vi jam uzas, administrataj platformaj kontroloj per regilo de aparata politiko aŭ labora profilo, aŭ arkitekturo, kiun la vendanto dokumentas. Ĉio alia estas eksperimento, kiu devas esti rekontrolita post ĉiu aplikaĵa ĝisdatigo.
Paŝo 2: kion la enirejo povas plenumi
Post kiam la trafiko estas malĉifrita ĉe la fora fino, la enirejo povas limigi plusenditajn pakaĵojn al aprobitaj adresoj, servoj aŭ aŭtentigitaj VPN-identoj. Tio estas vera plenumo por ĉio, kio eliras tra ĝi, kaj ĝi estas la ĝusta loko por limigi aliron al privataj subretoj.
Kion ĝi ne ricevas, estas la aplikaĵa idento de la telefono alkroĉita al ĉiu ordinara IP-pakaĵo. Pluraj aplikaĵoj kunhavigantaj unu tunelan adreson estas unu subjekto por la enirejo, krom se la dezajno donas al ili apartajn adresojn aŭ apartajn aŭtentigitajn identojn. Do regulo por uzanto ĉe la enirejo ne estas regulo por aplikaĵo ĉe la telefono, kiel ajn la administra konzolo nomas ĝin.
Paŝo 3: listigu tion, kio neniam alvenas
Aplikaĵo ekskludita el la VPN, kiu kontaktas proksiman aparaton, neniam atingas la enirejon, do elira fajroŝirmilo ne povas rifuzi pakaĵon, kiun ĝi neniam ricevas. La samo validas por neintenca rekta vojo dum interrompo kaj por envena eksponiĝo en la loka alirreto. Tiuj estas lokaj limoj laŭdifine.
Ankaŭ la malo validas: loka regulo, kiu permesas konekton, ne donas aliron tra la ACL de la privata reto ĉe la enirejo. Unu peto povas esti submetita al ambaŭ limoj, kaj plenumi unu diras nenion pri la alia.
Paŝo 4: atribuu ĉiun regulon al vojo
Metu la decidon en tabelon antaŭ ol agordi ion ajn, ĉar la malplenaj ĉeloj estas la loko, kie dezajnoj fiaskas.
| Vojo | Kiu povas ĝin plenumi | Blinda punkto |
|---|---|---|
| Labora aplikaĵo al la labora servo, tunelo aktiva | ACL de la enirejo laŭ adreso kaj servo, plus loka blokado de aliaj vojoj | La enirejo ne vidas, kiu aplikaĵo sendis la pakaĵon |
| Labora aplikaĵo al aliaj celoj, tunelo aktiva | Loka filtrilo konscia pri aplikaĵoj, aŭ la enirejo se tiuj celoj estas adresitaj tie | La loka filtrilo devas esti la aktiva VpnService |
| Labora aplikaĵo sen tunelo | Loka rifuzo, por ke la aplikaĵo ne povu preni rektan vojon | Postulas, ke la filtrilo postvivu la malaperon de la tunelo |
| Proksima LAN-aparato | Nur loka politiko | La enirejo neniam vidas ĝin |
La laborebla formo estas du limoj kun du taskoj. Loka limo konscia pri aplikaĵoj regas la konduton de la telefono, inkluzive de la rekta falo, kaj enireja limo regas forajn rimedojn. La enireja flanko povas permesi la laboran servon kaj rifuzi ĉiun alian privatan subreton, dum la politiko ĉe la telefono mem decidas pri rekta vojo, kiun la aplikaĵo alie prenus.
Paŝo 5: tenu la transporton viva, poste kontrolu
Kiun ajn lokan politikon vi elektas, ĝi devas permesi la transporton, kiu starigas kaj konservas la VPN-on. Blokado de tiu transporto lasas la telefonon sen tunelo kaj sen politiko, kio plenumas nenion kohere kaj malfacilas diagnozi, ĉar la aplikaĵo simple ne havas reton.
Poste kontrolu ĉiun linion de la origina frazo anstataŭ la ĝeneralan impreson: la labora aplikaĵo atingas la laboran servon, la sama aplikaĵo estas rifuzata ĉe alia celo, aplikaĵo ne labora kondutas kiel antaŭe, kaj kun la tunelo haltigita la labora aplikaĵo ne falas al rekta konekto. Kontrolu la DNS-vojon aparte, ĉar privata DNS aŭ ĉifrita solvilo povas preterpasi filtrilon, kiu inspektas nur adresojn.
Se unu el tiuj paŝoj ne plenumeblas ĉe la telefono, la postulo estas arkitektura demando kaj ne agordo de fajroŝirmilo. Dividi la politikon inter aparato, kiun vi kontrolas, kaj enirejo, kiun vi kontrolas, estas kutime la honesta respondo, kaj la dokumentaro pri Android VPN-konekteco estas la loko por konfirmi, kion la platformo permesos kaj ne permesos al unu servo.