Kvar ein Android-brannmurregel må bu når ein VPN er på
Berre éin VpnService kan vera aktiv, så ein brannmur-app og ein VPN-app stablar seg ikkje. Gå gjennom éin arbeidsførespurnad og set kvar regel der trafikken hans faktisk passerer.
Du har éin setning med politikk: denne appen får nå arbeidstenesta, og ingenting anna. Det neste spørsmålet ser ut som eit produktval, men det er eit spørsmål om stad, fordi kvart mogleg handhevingpunkt ser ein annan del av trafikken til telefonen. Gatewayen ser berre det som går inn i tunnelen. Filteret på telefonsida ser berre det det har løyve til å følgje med på. Å køyre éin førespurnad gjennom begge gjer svaret opplagt.
Start med setninga, ikkje produktet
Utvid kravet før du vel noko. Det tyder pakken og profilen han køyrer i, fordi ein app i arbeidsprofilen er ein annan brukar enn den same appen i den personlege profilen. Det tyder destinasjonen: vert, port og protokoll, ikkje eit tenestenamn. Det tyder DNS-vegen som løyser namnet, og det tyder kva som skal skje når tunnelen ikkje er tilgjengeleg.
Skrive ned har politikken for dømet fire linjer: arbeidsappen får nå arbeidstenesta; han får ikkje nå noko anna; andre apper er uendra; utan tunnel blir arbeidsappen avvist i staden for å falle tilbake til ein direkte veg. Kvar linje har ein eigar, og det er ikkje same eigaren overalt.
Steg 1: kva telefonen sjølv kan handheve
Ein Android-brannmur utan root er ein VpnService som fangar trafikk lokalt, også når det ikkje ligg ein ekstern tunnel bak. Android tillèt éi aktiv VPN-teneste per brukarprofil, så ein andre brannmur-app blir ikkje kjeda bak den første. Han erstattar han, og grensesnittet den første appen filtrerte forsvinn.
Difor gir det sjeldan kombinasjonen folk ventar å installere ein brannmur ved sida av ein VPN-klient. Viss brannmuren startar og VPN-en blir kopla frå, vart ingenting kombinert; dei to bytte plass. Utskifting av eit grensesnitt er ikkje samarbeid, og symptomet er ein tunnel som fell heile tida kvar gong den andre appen blir opna.
Støtta oppsett finst: filtrering innebygd i VPN-klienten du alt køyrer, styrte plattformkontrollar via ein einingspolitikk-kontrollar eller arbeidsprofil, eller ein arkitektur leverandøren dokumenterer. Alt anna er eit eksperiment som må stadfestast på nytt etter kvar appoppdatering.
Steg 2: kva gatewayen kan handheve
Når trafikken er dekryptert i den fjerne enden, kan gatewayen avgrense vidaresende pakkar til godkjende adresser, tenester eller autentiserte VPN-identitetar. Det er ekte handheving for alt som går ut der, og det er rett stad å avgrense tilgang til private subnett.
Det han ikkje mottek, er app-identiteten til telefonen fest til kvar vanlege IP-pakke. Fleire apper som deler éi tunneladresse er eitt subjekt for gatewayen, med mindre designet gir dei separate adresser eller separate autentiserte identitetar. Ein regel per brukar i gatewayen er difor ikkje ein regel per app på telefonen, kva administrasjonskonsollen enn kallar han.
Steg 3: list opp det som aldri kjem fram
Ein app som er utelukka frå VPN-en og kontaktar eining i nærleiken, når aldri gatewayen, så ein utgåande brannmur kan ikkje avvise ein pakke han aldri mottek. Det same gjeld ein utilsikta direkte veg under eit avbrot og inngåande eksponering på det lokale aksessnettet. Dette er lokale grenser per definisjon.
Det motsette gjeld òg: ein lokal regel som tillèt ei tilkopling, gir ikkje tilgang gjennom ACL-en for det private nettet på gatewayen. Éin førespurnad kan vere underlagd begge grensene, og å oppfylle den eine seier ingenting om den andre.
Steg 4: tildel kvar regel ein veg
Set avgjerda i ein tabell før du konfigurerer noko, fordi dei tomme cellene er der design sviktar.
| Veg | Kven kan handheve han | Blindflekk |
|---|---|---|
| Arbeidsapp til arbeidstenesta, tunnel oppe | Gateway-ACL på adresse og teneste, pluss lokal blokkering av andre vegar | Gatewayen ser ikkje kva app som sende pakken |
| Arbeidsapp til andre destinasjonar, tunnel oppe | Lokalt app-medvite filter, eller gatewayen viss desse destinasjonane er adresserte der | Det lokale filteret må vere den aktive VpnService |
| Arbeidsapp utan tunnel | Lokal avvising, slik at appen ikkje kan ta ein direkte veg | Krev at filteret overlever at tunnelen forsvinn |
| LAN-eining i nærleiken | Berre lokal politikk | Gatewayen ser ho aldri |
Den forma som verkar, er to grenser med to oppgåver. Ei lokal app-medviten grense styrer åtferda til telefonen, inkludert det direkte tilbakefallet, og ei gateway-grense styrer eksterne ressursar. Gateway-sida kan tillate arbeidstenesta og avvise alle andre private subnett, medan politikken på telefonsida sjølv avgjer ein direkte veg som appen elles kunne ta.
Steg 5: hald transporten i live, og stadfest så
Kva lokal politikk du enn vel, må han tillate transporten som etablerer og held VPN-en. Blir den transporten blokkert, står telefonen utan tunnel og utan politikk, noko som ikkje handhevar noko samanhengande og er vanskeleg å diagnostisere, fordi appen rett og slett ikkje har nett.
Stadfest deretter kvar linje i den opphavlege setninga i staden for heilskapsinntrykket: arbeidsappen når arbeidstenesta, den same appen blir avvist på ein annan destinasjon, ein app som ikkje er arbeid, oppfører seg som før, og med tunnelen stogga fell ikkje arbeidsappen tilbake til ei direkte tilkopling. Sjekk DNS-vegen separat, fordi privat DNS eller ein kryptert løysar kan omgå eit filter som berre granskar adresser.
Viss eitt av desse stega ikkje kan oppfyllast på telefonen, er kravet eit arkitekturspørsmål og ikkje ei brannmurinnstilling. Å dele politikken mellom ei eining du kontrollerer og ein gateway du kontrollerer er vanlegvis det ærlege svaret, og Android-dokumentasjonen om VPN-tilkoplingar er staden for å stadfeste kva plattformen vil og ikkje vil tillate éi teneste.