Var en Android-brandväggsregel måste ligga när VPN är på
Bara en VpnService kan vara aktiv, så en brandväggsapp och en VPN-app staplas inte. Följ en arbetsbegäran och placera varje regel där trafiken faktiskt passerar.
Du har en enda mening policy: den här appen får nå arbetstjänsten och inget annat. Nästa fråga ser ut som ett produktval, men det är en platsfråga, eftersom varje möjlig tillämpningspunkt ser en annan delmängd av telefonens trafik. En gateway ser bara det som går in i tunneln. Ett filter på telefonsidan ser bara det det har tillåtelse att observera. Att föra en enda begäran genom båda gör svaret uppenbart.
Börja med meningen, inte med produkten
Utvidga kravet innan du väljer något. Det betyder paketet och profilen det körs i, eftersom en app i arbetsprofilen är en annan användare än samma app i den personliga profilen. Det betyder målet: värd, port och protokoll, inte ett tjänstenamn. Det betyder DNS-vägen som slår upp namnet, och det betyder vad som ska hända när tunneln inte är tillgänglig.
Nedskriven har policyn för exemplet fyra rader: arbetsappen får nå arbetstjänsten; arbetsappen får inte nå något annat; andra appar är oförändrade; utan tunnel nekas arbetsappen i stället för att falla tillbaka. Varje rad har en ägare, och de är inte alla samma ägare.
Steg 1: vad telefonen själv kan tillämpa
En Android-brandvägg utan root är en VpnService som fångar trafik lokalt, även när det inte finns någon fjärrtunnel bakom den. Android tillåter en aktiv VPN-tjänst per användarprofil, så en andra brandväggsapp kedjas inte bakom den första. Den ersätter den, och det gränssnitt som den första appen filtrerade försvinner.
Därför ger det sällan den kombination folk förväntar sig att installera en brandvägg bredvid en VPN-klient. Om brandväggen startar och VPN:en kopplas från kombinerades ingenting; de två bytte plats. Ett gränssnittsbyte är inte samarbete, och symtomet är en tunnel som ständigt faller när den andra appen öppnas.
Det finns ändå stödda upplägg: filtrering inbyggd i den VPN-klient du redan kör, hanterade plattformskontroller via en enhetsprincipkontroll eller arbetsprofil, eller en arkitektur som leverantören dokumenterar. Allt annat är ett experiment som måste verifieras igen efter varje appuppdatering.
Steg 2: vad gatewayen kan tillämpa
När trafiken har dekrypterats i fjärränden kan gatewayen begränsa vidarebefordrade paket till godkända adresser, tjänster eller autentiserade VPN-identiteter. Det är verklig tillämpning för allt som lämnar via den, och det är rätt plats att begränsa åtkomsten till privata subnät.
Det den inte får är telefonens appidentitet kopplad till varje vanligt IP-paket. Flera appar som delar en tunneladress är ett enda subjekt för gatewayen, om inte designen ger dem separata adresser eller separata autentiserade identiteter. En regel per användare i gatewayen är därför inte en regel per app i telefonen, hur administrationskonsolen än kallar den.
Steg 3: lista det som aldrig anländer
En app som är undantagen från VPN:en och kontaktar en enhet i närheten når aldrig gatewayen, så en utgående brandvägg kan inte neka ett paket den aldrig får. Samma sak gäller en oavsiktlig direktväg under ett avbrott och exponering inåt i det lokala åtkomstnätet. Det är lokala gränser per definition.
Det omvända gäller också: en lokal regel som tillåter en anslutning ger inte åtkomst genom gatewayens ACL för privata nät. En begäran kan omfattas av båda gränserna, och att uppfylla den ena säger inget om den andra.
Steg 4: tilldela varje regel en väg
Sätt beslutet i en tabell innan du konfigurerar något, eftersom de tomma cellerna är där designer fallerar.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
Den fungerande formen är två gränser med två uppgifter. En lokal appmedveten gräns styr telefonens beteende, inklusive den direkta återgången, och en gatewaygräns styr fjärrresurser. Gateway-sidan kan tillåta arbetstjänsten och neka varje annat privat subnät, medan policyn på telefonsidan själv avgör en direktväg som appen annars skulle kunna ta.
Steg 5: håll transporten vid liv och verifiera sedan
Vilken lokal policy du än landar i måste den tillåta den transport som etablerar och upprätthåller VPN:en. Att blockera den transporten lämnar telefonen utan tunnel och utan policy, vilket inte tillämpar något sammanhängande och är svårt att diagnostisera eftersom appen helt enkelt inte har något nätverk.
Verifiera sedan varje rad i den ursprungliga meningen i stället för helhetsintrycket: arbetsappen når arbetstjänsten, samma app nekas på ett annat mål, en app som inte är arbetsapp beter sig som förut, och med tunneln stoppad faller arbetsappen inte tillbaka till en direkt anslutning. Kontrollera DNS-vägen separat, eftersom privat DNS eller en krypterad resolver kan kringgå ett filter som bara inspekterar adresser.
Om ett av dessa steg inte kan uppfyllas i telefonen är kravet en arkitekturfråga och inte en brandväggsinställning. Att dela upp policyn mellan en enhet du kontrollerar och en gateway du kontrollerar är oftast det ärliga svaret, och Androids dokumentation om VPN-anslutning är platsen där du bekräftar vad plattformen vill och inte vill låta en enskild tjänst göra.