On ha de viure una regla de tallafoc d’Android quan el VPN està actiu

Teniu una frase de política: aquesta aplicació pot arribar al servei de feina i a res més. La pregunta següent sembla una tria de producte, però és una pregunta de lloc, perquè cada punt d’aplicació possible veu una part diferent del trànsit del telèfon. La passarel·la només veu el que entra al túnel. El filtre del costat del telèfon només veu el que se li permet observar. Fer passar una sol·licitud per tots dos fa evident la resposta.

Comenceu per la frase, no pel producte

Amplieu el requisit abans de triar res. Això vol dir el paquet i el perfil on s’executa, perquè una aplicació del perfil de feina és un usuari diferent de la mateixa aplicació al perfil personal. Vol dir la destinació: amfitrió, port i protocol, no un nom de servei. Vol dir el camí DNS que resol aquest nom, i vol dir què ha de passar quan el túnel no està disponible.

Escrita, la política de l’exemple té quatre línies: l’aplicació de feina pot arribar al servei de feina; no pot arribar a res més; les altres aplicacions queden igual; sense túnel, l’aplicació de feina es denega en lloc de caure a un camí directe. Cada línia té un propietari, i no totes són el mateix propietari.

Pas 1: què pot aplicar el telèfon mateix

Un tallafoc d’Android sense root és un VpnService que captura el trànsit localment, fins i tot quan no hi ha cap túnel remot darrere. Android permet un sol servei VPN actiu per perfil d’usuari, així que una segona aplicació de tallafoc no s’encadena darrere de la primera. La substitueix, i la interfície que filtrava la primera aplicació desapareix.

Per això instal·lar un tallafoc al costat d’un client VPN poques vegades produeix la combinació que la gent espera. Si el tallafoc arrenca i el VPN es desconnecta, no s’ha combinat res; els dos han canviat de lloc. Substituir una interfície no és cooperar, i el símptoma és un túnel que cau una vegada i una altra cada cop que s’obre l’altra aplicació.

Hi ha disposicions suportades: filtratge integrat al client VPN que ja feu servir, controls de plataforma gestionats mitjançant un controlador de polítiques del dispositiu o un perfil de feina, o una arquitectura que el fabricant documenti. Qualsevol altra cosa és un experiment que cal tornar a verificar després de cada actualització d’aplicació.

Pas 2: què pot aplicar la passarel·la

Un cop el trànsit es desxifra a l’extrem llunyà, la passarel·la pot restringir els paquets reenviats a adreces, serveis o identitats VPN autenticades aprovades. Això és aplicació real per a tot el que en surt, i és el lloc correcte per limitar l’accés a subxarxes privades.

El que no rep és la identitat de l’aplicació del telèfon enganxada a cada paquet IP ordinari. Diverses aplicacions que comparteixen una adreça de túnel són un sol subjecte per a la passarel·la, tret que el disseny les doti d’adreces separades o identitats autenticades separades. Per tant, una regla per usuari a la passarel·la no és una regla per aplicació al telèfon, digui el que digui la consola de gestió.

Pas 3: lliste el que no arriba mai

Una aplicació exclosa del VPN que contacta un dispositiu proper no arriba mai a la passarel·la, així que un tallafoc de sortida no pot denegar un paquet que no rep. El mateix val per a un camí directe no volgut durant una caiguda i per a l’exposició entrant a la xarxa d’accés local. Són límits locals per definició.

El contrari també és cert: una regla local que permet una connexió no atorga accés a través de l’ACL de xarxa privada de la passarel·la. Una sol·licitud pot estar subjecta a tots dos límits, i satisfer-ne un no diu res de l’altre.

Pas 4: assigneu cada regla a un camí

Poseu la decisió en una taula abans de configurar res, perquè les caselles buides són on fallen els dissenys.

La forma que funciona són dos límits amb dues feines. Un límit local conscient de les aplicacions governa el comportament del telèfon, inclosa la caiguda directa, i un límit de passarel·la governa els recursos remots. El costat de la passarel·la pot permetre el servei de feina i denegar qualsevol altra subxarxa privada, mentre que la política del telèfon pren la seva pròpia decisió sobre un camí directe que l’aplicació podria prendre altrament.

Pas 5: manteniu viu el transport i després verifiqueu

Sigui quina sigui la política local que trieu, ha de permetre el transport que estableix i manté el VPN. Bloquejar aquest transport deixa el telèfon sense túnel i sense política, cosa que no aplica res de coherent i és difícil de diagnosticar, perquè l’aplicació simplement no té xarxa.

Després verifiqueu cada línia de la frase original en lloc de la impressió general: l’aplicació de feina arriba al servei de feina, la mateixa aplicació és denegada en una altra destinació, una aplicació que no és de feina es comporta com abans, i amb el túnel aturat l’aplicació de feina no cau a una connexió directa. Comproveu el camí DNS per separat, perquè un DNS privat o un resolutor xifrat poden saltar-se un filtre que només inspecciona adreces.

Si un d’aquests passos no es pot satisfer al telèfon, el requisit és una qüestió d’arquitectura i no un paràmetre de tallafoc. Repartir la política entre un dispositiu que controleu i una passarel·la que controleu sol ser la resposta honesta, i la documentació de connectivitat VPN d’Android és el lloc on confirmar què permetrà i què no permetrà la plataforma a un sol servei.