Interruptor por aplicación frente a bloqueo de todo el dispositivo: qué cambia

Un interruptor por aplicación suena como la opción prudente: solo el cliente de trabajo pierde su red cuando cae el túnel, y todo lo demás sigue funcionando. Luego alguien nota que el navegador personal cargó una página de todos modos, que el auxiliar de sincronización del mismo paquete seguía reintentando y que un nombre en caché seguía resolviéndose a una dirección que nunca tocó el túnel. La etiqueta de la función y el conjunto de conexiones que realmente protege son dos cosas distintas. Determine primero el conjunto protegido, porque ese conjunto decide si la aplicación por aplicación o el bloqueo de todo el dispositivo es la descripción honesta.

Empiece por el conjunto, no por la etiqueta

Una política por aplicación protege aplicaciones seleccionadas. Un bloqueo de dispositivo apunta a un límite de red más amplio, normalmente con excepciones documentadas para impresión local, tráfico de gestión o portales cautivos. Ninguna de las dos etiquetas está completa hasta que pueda responder tres preguntas: qué ocurre con las aplicaciones excluidas, qué ocurre con los auxiliares que esas aplicaciones inician y qué ocurre con las conexiones abiertas mientras la protección no está disponible.

Escriba esas respuestas antes de tocar cualquier ajuste del cliente. Si el requisito es "este cliente de nóminas nunca debe hablar con internet fuera del túnel, y mi navegador sí puede", el conjunto es pequeño y la aplicación por aplicación encaja. Si el requisito es "nada en este dispositivo llega a internet sin protección, excepto el servicio de actualizaciones", ninguna política por aplicación lo producirá, porque las aplicaciones que no nombró son el problema.

La aplicación por aplicación coincide con identificadores, no con nombres de programa

Android expone la VPN por aplicación mediante paquetes, y su documentación de VpnService describe cómo interactúa eso con el funcionamiento siempre activo y el bloqueo. iOS configura la VPN por aplicación mediante un perfil de gestión y coincide por aplicación o por dominio. Windows y Linux no tienen ninguna ruta por proceso, así que la misma idea se aproxima con una regla de cortafuegos limitada a un programa o con una regla que coincide con el usuario propietario.

El límite es el identificador, y los identificadores son fáciles de esquivar. Una aplicación que entrega una URL al navegador del sistema, o abre un documento en un visor, cruza a un proceso que su política nunca nombró. Una opción de terminar al caer tampoco es un filtro de paquetes: mata la aplicación que configuró, mientras un proceso hijo, un trabajador de cola o una pestaña del navegador pueden mantener vivo un socket existente.

El bloqueo cubre lo que una política por aplicación no puede ver

El bloqueo de todo el dispositivo elimina la elección. Cada paquete saliente que no pertenece al túnel se descarta, incluido el tráfico de procesos que su política de aplicaciones nunca conoció. En Android eso es VPN siempre activa combinada con el ajuste de bloquear conexiones, y la aplicación ocurre en el sistema, no en la ventana del cliente. En un escritorio es una regla de cortafuegos persistente o una ruta predeterminada apuntada a una puerta de enlace inalcanzable.

El coste es que todo lo demás se detiene, así que las excepciones pasan a formar parte del diseño en lugar de ser un añadido. Impresoras locales, descubrimiento de servicios, inicios de sesión en portales cautivos, agentes de gestión y actualizaciones del sistema operativo necesitan cada uno un agujero documentado, porque cada uno es un camino que permanece abierto cuando el túnel está caído. El bloqueo es solo tan fuerte como la entrada más corta de esa lista.

DNS, IPv6 y los auxiliares en segundo plano esconden las fugas

Que una aplicación protegida no resuelva un nombre no demuestra que las respuestas en caché o el tráfico IP directo estén bloqueados. Si el resolutor sigue siendo alcanzable fuera del túnel, el nombre se resuelve y la conexión falla, lo que parece un interruptor que funciona y no lo es. Peor aún, un registro en caché puede apuntar a una dirección que el túnel no transporta, así que la conexión sale directamente mientras la aplicación informa de un error de VPN.

IPv6 necesita su propia regla en cada plataforma que lo ejecuta, porque una regla de descarte para v4 no cubre una ruta v6. En el móvil, un ajuste de DNS privado puede mover la resolución a un canal cifrado que la política del dispositivo no inspecciona. Y los auxiliares en segundo plano son el culpable habitual en el escritorio: un proceso de actualización o de bandeja de sincronización arranca antes que el cliente VPN y mantiene su propia conexión, así que nunca ve la ruta cambiada.

Pruebe tres aplicaciones y dos transiciones

Ejecute cada fila dos veces, una con un nombre de host y otra con una dirección literal, y una más por IPv6 si la red lo ofrece. Un aprobado significa que la aplicación incluida se detuvo, la excluida se comportó como usted escribió y el auxiliar no se escapó. Anote el comportamiento directo que decidió que era aceptable, para que el siguiente administrador distinga una excepción deliberada de un fallo.

Luego describa el resultado en una frase que nombre las aplicaciones y las condiciones, por ejemplo: el cliente de nóminas no tiene ruta fuera del túnel, el navegador es directo por diseño y todo lo demás se detiene cuando el túnel está caído. Si esa frase es difícil de escribir, la política sigue siendo dos políticas que luchan entre sí.