Hvor en Android-brannmurregel må bo når en VPN er på
Bare én VpnService kan være aktiv, så en brannmur-app og en VPN-app stabler seg ikke. Gå gjennom én arbeidsforespørsel og sett hver regel der trafikken dens faktisk passerer.
Du har én setning med policy: denne appen får nå arbeidstjenesten, og ingenting annet. Det neste spørsmålet ser ut som et produktvalg, men det er et spørsmål om plassering, fordi hvert mulige håndhevelsespunkt ser en annen del av telefonens trafikk. Gatewayen ser bare det som går inn i tunnelen. Filteret på telefonsiden ser bare det det har lov til å observere. Å kjøre én forespørsel gjennom begge gjør svaret åpenbart.
Start med setningen, ikke produktet
Utvid kravet før du velger noe. Det betyr pakken og profilen den kjører i, fordi en app i arbeidsprofilen er en annen bruker enn den samme appen i den personlige profilen. Det betyr destinasjonen: vert, port og protokoll, ikke et tjenestenavn. Det betyr DNS-veien som løser navnet, og det betyr hva som skal skje når tunnelen ikke er tilgjengelig.
Skrevet ned har policyen for eksempelet fire linjer: arbeidsappen får nå arbeidstjenesten; den får ikke nå noe annet; andre apper er uendret; uten tunnel avvises arbeidsappen i stedet for å falle tilbake til en direkte vei. Hver linje har en eier, og det er ikke samme eier overalt.
Trinn 1: hva telefonen selv kan håndheve
En Android-brannmur uten root er en VpnService som fanger trafikk lokalt, også når det ikke ligger en ekstern tunnel bak. Android tillater én aktiv VPN-tjeneste per brukerprofil, så en andre brannmur-app kjedes ikke bak den første. Den erstatter den, og grensesnittet den første appen filtrerte forsvinner.
Derfor gir det sjelden kombinasjonen folk forventer å installere en brannmur ved siden av en VPN-klient. Hvis brannmuren starter og VPN-en kobles fra, ble ingenting kombinert; de to byttet plass. Utskifting av et grensesnitt er ikke samarbeid, og symptomet er en tunnel som faller hele tiden hver gang den andre appen åpnes.
Støttede oppsett finnes: filtrering innebygd i VPN-klienten du allerede kjører, administrerte plattformkontroller via en enhets policy-kontroller eller arbeidsprofil, eller en arkitektur leverandøren dokumenterer. Alt annet er et eksperiment som må verifiseres på nytt etter hver appoppdatering.
Trinn 2: hva gatewayen kan håndheve
Når trafikken er dekryptert i den fjerne enden, kan gatewayen begrense videresendte pakker til godkjente adresser, tjenester eller autentiserte VPN-identiteter. Det er ekte håndhevelse for alt som går ut der, og det er riktig sted å begrense tilgang til private subnett.
Det den ikke mottar, er telefonens app-identitet festet til hver vanlige IP-pakke. Flere apper som deler én tunneladresse er ett subjekt for gatewayen, med mindre designet gir dem separate adresser eller separate autentiserte identiteter. En regel per bruker i gatewayen er derfor ikke en regel per app på telefonen, uansett hva administrasjonskonsollen kaller den.
Trinn 3: list opp det som aldri kommer fram
En app som er utelukket fra 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 vei under et avbrudd og inngående eksponering på det lokale aksessnettet. 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: tildel hver regel en vei
Sett beslutningen i en tabell før du konfigurerer noe, fordi de tomme cellene er der design feiler.
| Vei | Hvem kan håndheve den | Blindson |
|---|---|---|
| Arbeidsapp til arbeidstjenesten, tunnel oppe | Gateway-ACL på adresse og tjeneste, pluss en lokal blokkering av andre veier | Gatewayen ser ikke hvilken app som sendte pakken |
| Arbeidsapp til andre destinasjoner, tunnel oppe | Lokalt app-bevisst filter, eller gatewayen hvis disse destinasjonene er adressert der | Det lokale filteret må være den aktive VpnService |
| Arbeidsapp uten tunnel | Lokal avvisning, slik at appen ikke kan ta en direkte vei | Krever at filteret overlever at tunnelen forsvinner |
| LAN-enhet i nærheten | Bare lokal policy | Gatewayen ser den aldri |
Den formen som virker, er to grenser med to oppgaver. En lokal app-bevisst grense styrer telefonens atferd, 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 vei som appen ellers kunne ta.
Trinn 5: hold transporten i live, og verifiser så
Uansett hvilken lokal policy du velger, må den tillate transporten som etablerer og vedlikeholder VPN-en. Blokkeres den transporten, står telefonen uten tunnel og uten policy, noe som ikke håndhever noe sammenhengende og er vanskelig å diagnostisere, fordi appen rett og slett ikke har nett.
Verifiser deretter hver linje i den opprinnelige setningen i stedet for helhetsinntrykket: arbeidsappen når arbeidstjenesten, den samme appen avvises på en annen destinasjon, en app som ikke er arbeid oppfører seg som før, og med tunnelen stoppet faller ikke arbeidsappen tilbake til en direkte tilkobling. Sjekk DNS-veien separat, fordi privat DNS eller en kryptert resolver kan omgå et filter som bare undersøker adresser.
Hvis ett av disse trinnene ikke kan oppfylles på telefonen, er kravet et arkitekturspørsmål og ikke en brannmurinnstilling. Å dele policyen mellom en enhet du kontrollerer og en gateway du kontrollerer er vanligvis det ærlige svaret, og Android-dokumentasjonen om VPN-tilkoblinger er stedet for å bekrefte hva plattformen vil og ikke vil tillate én tjeneste.