Waar een Android-firewallregel moet leven als een VPN aan staat
Slechts één VpnService kan actief zijn, dus een firewall-app en een VPN-app stapelen niet. Loop één werkverzoek door en zet elke regel waar het verkeer echt langskomt.
U hebt één zin beleid: deze app mag de werkdienst bereiken, en niets anders. De volgende vraag lijkt een productkeuze, maar het is een vraag over plaats, want elk mogelijk handhavingspunt ziet een ander deel van het verkeer van de telefoon. De gateway ziet alleen wat de tunnel binnenkomt. Het filter aan de telefoonkant ziet alleen wat het mag waarnemen. Eén verzoek door beide laten lopen maakt het antwoord duidelijk.
Begin bij de zin, niet bij het product
Werk de eis uit voordat u iets kiest. Dat betekent het pakket en het profiel waarin het draait, want een app in het werkprofiel is een andere gebruiker dan dezelfde app in het persoonlijke profiel. Dat betekent de bestemming: host, poort en protocol, niet een dienstnaam. Dat betekent het DNS-pad dat die naam oplost, en het betekent wat er moet gebeuren als de tunnel niet beschikbaar is.
Opgeschreven heeft het beleid voor het voorbeeld vier regels: de werkapp mag de werkdienst bereiken; de werkapp mag niets anders bereiken; andere apps blijven ongewijzigd; zonder tunnel wordt de werkapp geweigerd in plaats van terug te vallen op een directe route. Elke regel heeft een eigenaar, en dat is niet overal dezelfde eigenaar.
Stap 1: wat de telefoon zelf kan handhaven
Een Android-firewall zonder root is een VpnService die verkeer lokaal onderschept, ook als er geen externe tunnel achter zit. Android staat één actieve VPN-dienst per gebruikersprofiel toe, dus een tweede firewall-app schakelt niet achter de eerste. Hij vervangt die, en de interface die de eerste app filterde verdwijnt.
Daarom levert een firewall naast een VPN-client zelden de combinatie op die mensen verwachten. Als de firewall start en de VPN verbreekt, is er niets gecombineerd; de twee hebben van plaats gewisseld. Een interface vervangen is geen samenwerking, en het symptoom is een tunnel die steeds wegvalt zodra de andere app wordt geopend.
Ondersteunde opstellingen bestaan wel: filtering ingebouwd in de VPN-client die u al gebruikt, beheerde platformbesturing via een apparaatbeleidscontroller of werkprofiel, of een architectuur die de leverancier documenteert. Al het andere is een experiment dat na elke app-update opnieuw moet worden geverifieerd.
Stap 2: wat de gateway kan handhaven
Zodra het verkeer aan de andere kant is ontsleuteld, kan de gateway doorgestuurde pakketten beperken tot goedgekeurde adressen, diensten of geauthenticeerde VPN-identiteiten. Dat is echte handhaving voor alles wat eruit gaat, en het is de juiste plek om toegang tot privé-subnetten te beperken.
Wat hij niet ontvangt, is de app-identiteit van de telefoon die aan elk gewoon IP-pakket hangt. Meerdere apps die één tunneladres delen zijn één subject voor de gateway, tenzij het ontwerp hun aparte adressen of aparte geauthenticeerde identiteiten geeft. Een regel per gebruiker bij de gateway is dus geen regel per app op de telefoon, hoe de beheerconsole het ook noemt.
Stap 3: noem wat nooit aankomt
Een app die van de VPN is uitgesloten en een apparaat dichtbij benadert, bereikt de gateway nooit, dus een uitgaande firewall kan een pakket niet weigeren dat hij nooit ontvangt. Hetzelfde geldt voor een onbedoelde directe route tijdens een storing en voor inkomende blootstelling op het lokale toegangsnetwerk. Dat zijn lokale grenzen per definitie.
Het omgekeerde geldt ook: een lokale regel die een verbinding toestaat, geeft geen toegang via de ACL van het privénetwerk van de gateway. Eén verzoek kan aan beide grenzen onderworpen zijn, en het ene vervullen zegt niets over het andere.
Stap 4: wijs elke regel aan een pad toe
Zet de beslissing in een tabel voordat u iets configureert, want de lege cellen zijn waar ontwerpen falen.
| Pad | Wie het kan handhaven | Blinde vlek |
|---|---|---|
| Werkapp naar de werkdienst, tunnel actief | Gateway-ACL op adres en dienst, plus een lokale blokkade van andere paden | De gateway ziet niet welke app het pakket stuurde |
| Werkapp naar andere bestemmingen, tunnel actief | Lokaal app-bewust filter, of de gateway als die bestemmingen daar geadresseerd zijn | Het lokale filter moet de actieve VpnService zijn |
| Werkapp zonder tunnel | Lokale weigering, zodat de app geen directe route kan nemen | Vereist dat het filter het verdwijnen van de tunnel overleeft |
| LAN-apparaat dichtbij | Alleen lokaal beleid | De gateway ziet het nooit |
De vorm die werkt, is twee grenzen met twee taken. Een lokale app-bewuste grens stuurt het gedrag van de telefoon, inclusief de directe terugval, en een gatewaygrens stuurt de externe bronnen. De gatewaykant kan de werkdienst toestaan en elk ander privé-subnet weigeren, terwijl het beleid aan de telefoonkant zelf beslist over een directe route die de app anders zou nemen.
Stap 5: houd het transport in leven en verifieer dan
Welk lokaal beleid u ook kiest, het moet het transport toestaan dat de VPN opzet en onderhoudt. Dat transport blokkeren laat de telefoon zonder tunnel en zonder beleid achter, wat niets samenhangend handhaaft en moeilijk te diagnosticeren is, omdat de app simpelweg geen netwerk heeft.
Verifieer daarna elke regel van de oorspronkelijke zin in plaats van de algemene indruk: de werkapp bereikt de werkdienst, dezelfde app wordt op een andere bestemming geweigerd, een app die geen werk is gedraagt zich als voorheen, en met de tunnel gestopt valt de werkapp niet terug op een directe verbinding. Controleer het DNS-pad apart, want privé-DNS of een versleutelde resolver kan een filter omzeilen dat alleen adressen inspecteert.
Als een van die stappen op de telefoon niet kan worden vervuld, is de eis een architectuurvraag en geen firewallinstelling. Het beleid verdelen tussen een apparaat dat u beheert en een gateway die u beheert is meestal het eerlijke antwoord, en de Android-documentatie over VPN-verbindingen is de plek om te bevestigen wat het platform één dienst wel en niet toestaat.