Dove deve vivere una regola del firewall Android quando un VPN è attivo

Hai una sola frase di politica: questa app può raggiungere il servizio di lavoro, e nient’altro. La domanda successiva sembra una scelta di prodotto, ma è una domanda di luogo, perché ogni possibile punto di applicazione vede una parte diversa del traffico del telefono. Il gateway vede solo ciò che entra nel tunnel. Il filtro lato telefono vede solo ciò che gli è consentito osservare. Far passare una sola richiesta da entrambi rende ovvia la risposta.

Parti dalla frase, non dal prodotto

Espandi il requisito prima di scegliere qualsiasi cosa. Significa il pacchetto e il profilo in cui gira, perché un’app nel profilo di lavoro è un utente diverso dalla stessa app nel profilo personale. Significa la destinazione: host, porta e protocollo, non un nome di servizio. Significa il percorso DNS che risolve quel nome, e significa cosa deve accadere quando il tunnel non è disponibile.

Scritta, la politica dell’esempio ha quattro righe: l’app di lavoro può raggiungere il servizio di lavoro; non può raggiungere nient’altro; le altre app restano invariate; senza tunnel l’app di lavoro viene negata invece di ricadere su un percorso diretto. Ogni riga ha un proprietario, e non sono tutti lo stesso proprietario.

Passo 1: cosa può applicare il telefono stesso

Un firewall Android senza root è un VpnService che cattura il traffico localmente, anche quando dietro non c’è alcun tunnel remoto. Android consente un solo servizio VPN attivo per profilo utente, quindi una seconda app firewall non si concatena dietro la prima. La sostituisce, e l’interfaccia che la prima app filtrava scompare.

Per questo installare un firewall accanto a un client VPN raramente produce la combinazione che le persone si aspettano. Se il firewall parte e il VPN si disconnette, non è stato combinato nulla; i due hanno scambiato posto. Sostituire un’interfaccia non è cooperare, e il sintomo è un tunnel che cade di continuo ogni volta che si apre l’altra app.

Esistono disposizioni supportate: filtraggio integrato nel client VPN che già usi, controlli di piattaforma gestiti tramite un controller di criteri del dispositivo o un profilo di lavoro, o un’architettura documentata dal fornitore. Tutto il resto è un esperimento da riverificare dopo ogni aggiornamento dell’app.

Passo 2: cosa può applicare il gateway

Una volta che il traffico è decifrato all’estremità remota, il gateway può limitare i pacchetti inoltrati a indirizzi, servizi o identità VPN autenticate approvati. È applicazione reale per tutto ciò che ne esce, ed è il posto giusto per limitare l’accesso alle sottoreti private.

Ciò che non riceve è l’identità dell’app del telefono attaccata a ogni pacchetto IP ordinario. Più app che condividono un indirizzo di tunnel sono un solo soggetto per il gateway, a meno che il progetto dia loro indirizzi separati o identità autenticate separate. Quindi una regola per utente sul gateway non è una regola per app sul telefono, comunque la chiami la console di gestione.

Passo 3: elenca ciò che non arriva mai

Un’app esclusa dal VPN che contatta un dispositivo vicino non raggiunge mai il gateway, quindi un firewall in uscita non può negare un pacchetto che non riceve mai. Lo stesso vale per un percorso diretto non voluto durante un’interruzione e per l’esposizione in ingresso sulla rete di accesso locale. Sono confini locali per definizione.

Vale anche il contrario: una regola locale che consente una connessione non concede accesso tramite l’ACL della rete privata del gateway. Una richiesta può essere soggetta a entrambi i confini, e soddisfarne uno non dice nulla sull’altro.

Passo 4: assegna ogni regola a un percorso

Metti la decisione in una tabella prima di configurare qualsiasi cosa, perché le celle vuote sono il punto in cui i progetti falliscono.

La forma che funziona sono due confini con due compiti. Un confine locale consapevole delle app governa il comportamento del telefono, inclusa la ricaduta diretta, e un confine gateway governa le risorse remote. Il lato gateway può consentire il servizio di lavoro e negare ogni altra sottorete privata, mentre la politica lato telefono decide da sola su un percorso diretto che l’app potrebbe altrimenti prendere.

Passo 5: tieni vivo il trasporto, poi verifica

Qualunque politica locale tu scelga, deve consentire il trasporto che stabilisce e mantiene il VPN. Bloccare quel trasporto lascia il telefono senza tunnel e senza politica, il che non applica nulla in modo coerente ed è difficile da diagnosticare, perché l’app semplicemente non ha rete.

Poi verifica ogni riga della frase originale invece dell’impressione generale: l’app di lavoro raggiunge il servizio di lavoro, la stessa app viene negata su un’altra destinazione, un’app che non è di lavoro si comporta come prima, e con il tunnel fermo l’app di lavoro non ricade su una connessione diretta. Controlla il percorso DNS separatamente, perché un DNS privato o un resolver cifrato possono aggirare un filtro che ispeziona solo gli indirizzi.

Se uno di questi passi non può essere soddisfatto sul telefono, il requisito è una questione di architettura e non un’impostazione del firewall. Dividere la politica tra un dispositivo che controlli e un gateway che controlli è di solito la risposta onesta, e la documentazione Android sulla connettività VPN è il posto dove confermare cosa la piattaforma permetterà e non permetterà a un solo servizio.