Ten unha soa frase de política: esta aplicación pode chegar ao servizo de traballo e a nada máis. A seguinte pregunta parece unha escolla de produto, pero é unha pregunta de lugar, porque cada punto de aplicación posible ve unha parte distinta do tráfico do teléfono. A pasarela só ve o que entra no túnel. O filtro do lado do teléfono só ve o que se lle permite observar. Pasar unha solicitude polos dous fai obvia a resposta.

Comece pola frase, non polo produto

Desenvolva o requisito antes de escoller nada. Iso significa o paquete e o perfil no que se executa, porque unha aplicación do perfil de traballo é un usuario distinto da mesma aplicación no perfil persoal. Significa o destino: host, porto e protocolo, non un nome de servizo. Significa a ruta DNS que resolve ese nome, e significa que debe ocorrer cando o túnel non está dispoñible.

Escrita, a política do exemplo ten catro liñas: a aplicación de traballo pode chegar ao servizo de traballo; non pode chegar a nada máis; as outras aplicacións quedan igual; sen túnel, denégase a aplicación de traballo en vez de caer nunha ruta directa. Cada liña ten un dono, e non todas son o mesmo dono.

Paso 1: que pode aplicar o propio teléfono

Un cortalumes de Android sen root é un VpnService que captura o tráfico localmente, mesmo cando non hai ningún túnel remoto detrás. Android permite un só servizo VPN activo por perfil de usuario, así que unha segunda aplicación de cortalumes non se encadea detrás da primeira. Substitúea, e a interface que filtraba a primeira aplicación desaparece.

Por iso instalar un cortalumes xunto a un cliente VPN poucas veces produce a combinación que a xente espera. Se o cortalumes arrinca e o VPN desconéctase, non se combinou nada; os dous trocaron de sitio. Substituír unha interface non é cooperar, e o síntoma é un túnel que cae unha e outra vez cada vez que se abre a outra aplicación.

Existen disposicións admitidas: filtrado integrado no cliente VPN que xa usa, controis de plataforma xestionados mediante un controlador de políticas do dispositivo ou un perfil de traballo, ou unha arquitectura que o fabricante documente. Calquera outra cousa é un experimento que hai que volver verificar tras cada actualización da aplicación.

Paso 2: que pode aplicar a pasarela

Unha vez que o tráfico se descifra no extremo remoto, a pasarela pode restrinxir os paquetes reenviados a enderezos, servizos ou identidades VPN autenticadas aprobadas. Iso é aplicación real para todo o que sae por ela, e é o lugar correcto para limitar o acceso a subredes privadas.

O que non recibe é a identidade da aplicación do teléfono pegada a cada paquete IP ordinario. Varias aplicacións que comparten un enderezo de túnel son un só suxeito para a pasarela, agás que o deseño lles dea enderezos separados ou identidades autenticadas separadas. Por iso unha regra por usuario na pasarela non é unha regra por aplicación no teléfono, diga o que diga a consola de administración.

Paso 3: enumere o que nunca chega

Unha aplicación excluída do VPN que contacta un dispositivo próximo nunca chega á pasarela, así que un cortalumes de saída non pode denegar un paquete que nunca recibe. O mesmo vale para unha ruta directa non desexada durante unha caída e para a exposición entrante na rede de acceso local. Son límites locais por definición.

O contrario tamén é certo: unha regra local que permite unha conexión non concede acceso a través da ACL de rede privada da pasarela. Unha solicitude pode estar suxeita a ambos os límites, e satisfacer un non di nada do outro.

Paso 4: asigne cada regra a unha ruta

Ponza a decisión nunha táboa antes de configurar nada, porque as celas baleiras son onde fallan os deseños.

RutaQuen pode aplicalaPunto cego
Aplicación de traballo ao servizo de traballo, túnel activoACL da pasarela por enderezo e servizo, máis un bloqueo local das outras rutasA pasarela non ve que aplicación enviou o paquete
Aplicación de traballo a outros destinos, túnel activoFiltro local consciente das aplicacións, ou a pasarela se eses destinos están enderezados alíO filtro local debe ser o VpnService activo
Aplicación de traballo sen túnelDenegación local, para que a aplicación non poida tomar unha ruta directaEsixe que o filtro sobreviva á desaparición do túnel
Dispositivo LAN próximoSó política localA pasarela nunca o ve

A forma que funciona son dous límites con dous traballos. Un límite local consciente das aplicacións goberna o comportamento do teléfono, incluída a caída directa, e un límite de pasarela goberna os recursos remotos. O lado da pasarela pode permitir o servizo de traballo e denegar calquera outra subrede privada, mentres a política do teléfono decide pola súa conta sobre unha ruta directa que a aplicación podería tomar doutro xeito.

Paso 5: manteña vivo o transporte e despois verifique

Sexa cal sexa a política local que escolla, debe permitir o transporte que establece e mantén o VPN. Bloquear ese transporte deixa o teléfono sen túnel e sen política, o que non aplica nada de forma coherente e é difícil de diagnosticar, porque a aplicación simplemente non ten rede.

Despois verifique cada liña da frase orixinal en vez da impresión xeral: a aplicación de traballo chega ao servizo de traballo, a mesma aplicación é denegada noutro destino, unha aplicación que non é de traballo compórtase como antes, e co túnel detido a aplicación de traballo non cae a unha conexión directa. Comprobe a ruta DNS por separado, porque un DNS privado ou un resolutor cifrado poden saltar un filtro que só inspecciona enderezos.

Se un deses pasos non se pode satisfacer no teléfono, o requisito é unha cuestión de arquitectura e non un axuste de cortalumes. Repartir a política entre un dispositivo que vostede controla e unha pasarela que vostede controla adoita ser a resposta honesta, e a documentación de conectividade VPN de Android é o lugar onde confirmar que permitirá e que non permitirá a plataforma a un só servizo.

Artigos relacionados