Hvor en Android-brannmurregel hører hjemme når en VPN er slått på
Bare én VpnService kan være aktiv, så en brannmur-app og en VPN-app legger seg ikke oppå hverandre. Følg én arbeidsforespørsel og plasser hver regel der trafikken faktisk passerer.
Du sitter med én setning policy: denne appen får nå arbeidstjenesten, og ikke noe annet. Det neste spørsmålet ser ut som et produktvalg, men det handler om hvor regelen skal ligge, fordi hvert mulig håndhevingspunkt ser en annen del av trafikken fra telefonen. Gatewayen ser bare det som kommer inn i tunnelen. Filteret på telefonsiden ser bare det det har tillatelse til å observere. Kjører vi én forespørsel gjennom begge, blir svaret tydelig.
Ta utgangspunkt i setningen, ikke produktet
Utvid kravet før du velger noe som helst. Det betyr pakken og profilen den kjører under, fordi en app i arbeidsprofilen er en annen bruker enn den samme appen i den personlige profilen. Det betyr målet: vert, port og protokoll, ikke et tjenestenavn. Det betyr DNS-veien som slår opp navnet, og det betyr hva som skal skje når tunnelen ikke er tilgjengelig.
Nedskrevet består policyen for eksempelet av fire linjer: arbeidsappen får nå arbeidstjenesten; den får ikke nå noe annet; andre apper er uendret; uten tunnel avvises arbeidsappen framfor å falle tilbake på en direkte rute. Hver linje har en eier, og det er ikke den samme eieren hele veien.
Trinn 1: hva telefonen selv kan håndheve
En Android-brannmur uten root er en VpnService som fanger trafikken lokalt, selv når det ikke ligger en ekstern tunnel bak den. Android tillater én aktiv VPN-tjeneste per brukerprofil, så en annen brannmur-app kjedes ikke bak den første. Den erstatter den, og grensesnittet den første appen filtrerte, forsvinner.
Derfor gir det sjelden det oppsettet folk ser for seg, å installere en brannmur ved siden av en VPN-klient. Starter brannmuren og VPN-en kobles ut, ble ingenting slått sammen; de to byttet plass. Å skifte ut et grensesnitt er ikke samarbeid, og symptomet er en tunnel som stadig faller hver gang den andre appen åpnes.
Støttede løsninger finnes: filtrering innebygd i VPN-klienten du allerede bruker, styrte plattformkontroller via en enhets policy-kontroller eller arbeidsprofil, eller en arkitektur som leverandøren dokumenterer. Alt annet er et eksperiment som må verifiseres på nytt etter hver oppdatering av appen.
Trinn 2: hva gatewayen kan håndheve
Når trafikken er dekryptert i den andre enden, kan gatewayen begrense videresendte pakker til godkjente adresser, tjenester eller autentiserte VPN-identiteter. Det er reell håndheving for alt som går ut derfra, og det er riktig sted å begrense tilgangen til private subnett.
Det den ikke mottar, er telefonen sin app-identitet knyttet til hver vanlig IP-pakke. Flere apper som deler én tunneladresse, er ett subjekt for gatewayen, med mindre designet gir dem egne adresser eller egne autentiserte identiteter. En regel per bruker i gatewayen er derfor ikke en regel per app på telefonen, uansett hva administrasjonskonsollen kaller den.
Trinn 3: før opp det som aldri kommer fram
En app som er holdt utenfor VPN-en og kontakter en enhet i nærheten, når aldri gatewayen, så en utgående brannmur kan ikke avvise en pakke den aldri mottar. Det samme gjelder en utilsiktet direkte rute under et avbrudd og inngående eksponering på det lokale tilgangsnettet. Dette er lokale grenser per definisjon.
Det motsatte gjelder også: en lokal regel som tillater en tilkobling, gir ikke tilgang gjennom gatewayens ACL for det private nettet. Én forespørsel kan være underlagt begge grensene, og å oppfylle den ene sier ingenting om den andre.
Trinn 4: knytt hver regel til en rute
Legg avgjørelsen i en tabell før du konfigurerer noe, fordi de tomme cellene er der designene svikter.
| Rute | Hvem kan håndheve den | Blindpunkt |
|---|---|---|
| Arbeidsapp til arbeidstjenesten, tunnel oppe | Gateway-ACL på adresse og tjeneste, i tillegg til lokal blokkering av andre ruter | Gatewayen ser ikke hvilken app som sendte pakken |
| Arbeidsapp til andre mål, tunnel oppe | Lokalt app-bevisst filter, eller gatewayen dersom disse målene er adressert der | Det lokale filteret må være den aktive VpnService |
| Arbeidsapp uten tunnel | Lokal avvisning, slik at appen ikke kan velge en direkte rute | Forutsetter at filteret tåler at tunnelen forsvinner |
| LAN-enhet i nærheten | Bare lokal policy | Gatewayen ser den aldri |
Den formen som fungerer, er to grenser med to oppgaver. En lokal app-bevisst grense styrer oppførselen til telefonen, inkludert det direkte tilbakefallet, og en gateway-grense styrer eksterne ressurser. Gateway-siden kan tillate arbeidstjenesten og avvise alle andre private subnett, mens policyen på telefonsiden selv avgjør en direkte rute som appen ellers kunne tatt.
Trinn 5: hold transporten i live, og verifiser
Uansett hvilken lokal policy du lander på, må den tillate transporten som etablerer og vedlikeholder VPN-en. Blokkerer du den transporten, blir telefonen stående uten tunnel og uten policy, noe som ikke håndhever noe på en sammenhengende måte og er vanskelig å diagnostisere, fordi appen rett og slett ikke har nett.
Deretter verifiserer du hver linje i den opprinnelige setningen i stedet for helhetsinntrykket: arbeidsappen når arbeidstjenesten, den samme appen avvises på et annet mål, en app som ikke er arbeid, oppfører seg som før, og med tunnelen stoppet faller ikke arbeidsappen tilbake på en direkte tilkobling. Sjekk DNS-veien separat, fordi privat DNS eller en kryptert resolver kan omgå et filter som bare undersøker adresser.
Kan ett av disse trinnene ikke oppfylles på telefonen, er kravet et arkitekturspørsmål og ikke en brannmurinnstilling. Å fordele policyen mellom en enhet du kontrollerer og en gateway du kontrollerer, er som regel det ærlige svaret, og Android-dokumentasjonen om VPN-tilkoblinger er stedet der du bekrefter hva plattformen vil og ikke vil tillate for én tjeneste.