Hvor en Android-firewallregel skal bo, når en VPN er tændt
Kun én VpnService kan være aktiv, så en firewall-app og en VPN-app stables ikke. Gå gennem én arbejdsanmodning og sæt hver regel der, hvor dens trafik faktisk passerer.
Du har én sætning politik: denne app må nå arbejdstjenesten og intet andet. Det næste spørgsmål ligner et produktvalg, men det er et spørgsmål om placering, fordi hvert muligt håndhævelsespunkt ser en forskellig del af telefonens trafik. Gatewayen ser kun det, der går ind i tunnelen. Filteret på telefonsiden ser kun det, det har lov til at iagttage. At køre én anmodning gennem begge gør svaret indlysende.
Start med sætningen, ikke produktet
Udvid kravet, før du vælger noget. Det betyder pakken og den profil, den kører i, fordi en app i arbejdsprofilen er en anden bruger end den samme app i den personlige profil. Det betyder destinationen: vært, port og protokol, ikke et tjenestenavn. Det betyder den DNS-vej, der opløser navnet, og det betyder, hvad der skal ske, når tunnelen ikke er tilgængelig.
Skrevet ned er politikken for eksemplet fire linjer: arbejdsappen må nå arbejdstjenesten; arbejdsappen må ikke nå noget andet; andre apps er uændrede; uden tunnel afvises arbejdsappen i stedet for at falde tilbage til en direkte vej. Hver linje har en ejer, og det er ikke den samme ejer hele vejen.
Trin 1: hvad telefonen selv kan håndhæve
En Android-firewall uden root er en VpnService, der fanger trafik lokalt, også når der ikke er nogen fjern tunnel bag den. Android tillader én aktiv VPN-tjeneste pr. brugerprofil, så en anden firewall-app kædes ikke bag den første. Den erstatter den, og det interface, den første app filtrerede, forsvinder.
Derfor giver det sjældent den kombination, folk forventer, at installere en firewall ved siden af en VPN-klient. Hvis firewallen starter, og VPN’en afbrydes, blev intet kombineret; de to byttede plads. En udskiftning af interfacet er ikke samarbejde, og symptomet er en tunnel, der hele tiden falder, hver gang den anden app åbnes.
Understøttede ordninger findes: filtrering indbygget i den VPN-klient, du allerede kører, administrerede platformskontroller via en enhedspolitikcontroller eller arbejdsprofil, eller en arkitektur, producenten dokumenterer. Alt andet er et eksperiment, der skal verificeres igen efter hver appopdatering.
Trin 2: hvad gatewayen kan håndhæve
Når trafikken er dekrypteret i den fjerne ende, kan gatewayen begrænse videresendte pakker til godkendte adresser, tjenester eller autentificerede VPN-identiteter. Det er egentlig håndhævelse for alt, der forlader den vej, og det er det rigtige sted at begrænse adgang til private subnets.
Det, den ikke modtager, er telefonens app-identitet knyttet til hver almindelig IP-pakke. Flere apps, der deler én tunneladresse, er ét subjekt for gatewayen, medmindre designet giver dem separate adresser eller separate autentificerede identiteter. En regel pr. bruger i gatewayen er derfor ikke en regel pr. app på telefonen, uanset hvad administrationskonsollen kalder den.
Trin 3: list det, der aldrig ankommer
En app, der er udelukket fra VPN’en og kontakter en enhed i nærheden, når aldrig gatewayen, så en udgående firewall kan ikke afvise en pakke, den aldrig modtager. Det samme gælder en utilsigtet direkte rute under et udfald og indgående eksponering på det lokale adgangsnetværk. Det er lokale grænser pr. definition.
Det omvendte gælder også: en lokal regel, der tillader en forbindelse, giver ikke adgang gennem gatewayens ACL for det private netværk. Én anmodning kan være underlagt begge grænser, og at opfylde den ene siger intet om den anden.
Trin 4: tildel hver regel en vej
Sæt beslutningen i en tabel, før du konfigurerer noget, fordi de tomme celler er der, hvor design fejler.
| Vej | Hvem kan håndhæve den | Blindt punkt |
|---|---|---|
| Arbejdsapp til arbejdstjenesten, tunnel oppe | Gateway-ACL på adresse og tjeneste plus en lokal blokering af andre veje | Gatewayen kan ikke se, hvilken app der sendte pakken |
| Arbejdsapp til andre destinationer, tunnel oppe | Lokalt app-bevidst filter, eller gatewayen hvis de destinationer er adresseret der | Det lokale filter skal være den aktive VpnService |
| Arbejdsapp uden tunnel | Lokal afvisning, så appen ikke kan tage en direkte vej | Kræver, at filteret overlever, at tunnelen forsvinder |
| LAN-enhed i nærheden | Kun lokal politik | Gatewayen ser den aldrig |
Den form, der virker, er to grænser med to opgaver. En lokal app-bevidst grænse styrer telefonens adfærd, inklusive det direkte tilbagefald, og en gateway-grænse styrer fjerne ressourcer. Gateway-siden kan tillade arbejdstjenesten og afvise alle andre private subnets, mens politikken på telefonsiden selv afgør en direkte vej, som appen ellers kunne tage.
Trin 5: hold transporten i live, og verificér så
Uanset hvilken lokal politik du vælger, skal den tillade den transport, der etablerer og vedligeholder VPN’en. Blokeres den transport, står telefonen uden tunnel og uden politik, hvilket ikke håndhæver noget sammenhængende og er svært at diagnosticere, fordi appen simpelthen ikke har noget netværk.
Verificér derefter hver linje i den oprindelige sætning i stedet for det samlede indtryk: arbejdsappen når arbejdstjenesten, den samme app afvises på en anden destination, en app, der ikke er arbejde, opfører sig som før, og med tunnelen stoppet falder arbejdsappen ikke tilbage til en direkte forbindelse. Tjek DNS-vejen separat, fordi privat DNS eller en krypteret resolver kan omgå et filter, der kun undersøger adresser.
Hvis et af disse trin ikke kan opfyldes på telefonen, er kravet et arkitekturspørgsmål og ikke en firewallindstilling. At dele politikken mellem en enhed, du kontrollerer, og en gateway, du kontrollerer, er som regel det ærlige svar, og Android-dokumentationen om VPN-forbindelser er stedet, hvor du bekræfter, hvad platformen vil og ikke vil lade én tjeneste gøre.