¿Solo inclusión o solo exclusión: qué opción por defecto?
Elige el valor por defecto antes de construir la lista: tuneliza solo lo que nombres, o tuneliza todo y recorta las excepciones. Después prueba la aplicación que nadie había añadido.
Abre la sección de enrutamiento de tu cliente VPN y verás dos controles de forma distinta que a menudo llevan la misma etiqueta. Uno te pide enumerar los destinos que pertenecen al túnel, y todo lo demás sigue usando la red local. El otro da por hecho que todo va por el túnel y pregunta qué hay que recortar. Ambos te dan un túnel funcional en la primera prueba, y ambos se mantienen añadiendo líneas a una lista, y por eso la diferencia sigue siendo invisible hasta que alguien instala algo nuevo.
La elección es un valor por defecto, no una función. Decídela antes de que la lista tenga veinte entradas.
Lee el valor por defecto en el cliente, no en el folleto
WireGuard hace la decisión inusualmente visible, porque AllowedIPs es una lista de inclusión y nada más. Un par con 0.0.0.0/0, ::/0 tuneliza todo; un par con 10.20.0.0/16 tuneliza solo eso. No existe sintaxis de exclusión, así que si quieres dejar fuera una subred tendrás que enumerar todos los demás prefijos o añadir enrutamiento por políticas fuera de la interfaz.
OpenVPN llega al mismo punto desde el otro lado, con redirect-gateway def1 instalando un túnel completo y directivas route explícitas que añaden o sobrescriben prefijos concretos. Los clientes comerciales suelen esconder ambos detrás de una casilla y una tabla de destinos, así que lee cuál de los dos edita realmente la tabla antes de fiarte de la etiqueta.
La pregunta no es cómo se llama la casilla. La pregunta es qué le ocurre a un paquete cuyo destino no aparece en ninguna de las dos listas. Responde eso por escrito, y el resto de la configuración se deduce de ahí. Si te saltas la pregunta, el primer fallo sin explicación lo decidirá quien ese día esté más cerca del cliente.
Sigue una aplicación que nadie añadió
En un diseño de solo inclusión esa aplicación va directa, por la red local, con el DNS local. En un diseño de solo exclusión pasa por el túnel, según lo que permita el servidor, y esa suele ser la diferencia entre una herramienta SaaS nueva que funciona el primer día y un ticket que dice que la VPN la rompió.
Ninguno de los dos valores es más seguro por sí solo. La inclusión reduce lo que transporta el túnel y convierte la red local en el camino de menor resistencia; la exclusión toma el túnel como camino normal y trata las excepciones como excepciones, lo que se acerca más a lo que la mayoría de las políticas corporativas pretende de verdad.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Fíjate en qué tipo de objeto enumera la plataforma
El VpnService.Builder de Android expone una lista de aplicaciones permitidas y una lista de aplicaciones prohibidas como dos modelos separados, y las reglas por aplicación eligen por paquete en lugar de por destino. Un navegador incluido en una lista así arrastra cada destino que abre, lo que es una granularidad distinta de una tabla de rutas y no puede arreglar un solo sitio roto dentro de una aplicación que funciona.
Los clientes de escritorio suelen mezclar ambos tipos en una sola interfaz, así que comprueba si la fila que añades es un paquete, un nombre de host o un prefijo. Fallan de formas distintas y se resuelven en lugares distintos. Una fila de nombre de host suele convertirse en una ruta más un nombre, mientras que una fila de paquete se convierte en una decisión de política dentro del cliente. Anota cuál de las dos añadiste, porque quien depure más tarde dará por hecho la otra.
Prueba el estado de fallo, no solo el camino feliz
Una aplicación excluida del túnel no obtiene automáticamente un acceso directo limpio. Si el cliente además aplica una regla que bloquea sin VPN, el tráfico excluido puede descartarse por completo, lo que parece una aplicación rota más que una decisión de enrutamiento. Prueba ese caso a propósito en vez de descubrirlo por el informe de un usuario.
Después revisa DNS e IPv6 como puntos separados. Un túnel que solo transporta IPv4 deja a una aplicación capaz de v6 un camino para rodearlo, y el DNS dividido decide si los nombres internos se resuelven para tráfico que no va por el túnel en absoluto. Ejecuta una aplicación listada, una no listada, una consulta de nombre y una reconexión, y guarda los resultados junto a la configuración.
Escribe el valor por defecto donde lo encuentre la siguiente persona
Deja constancia del valor elegido, las excepciones y quién es su responsable en el mismo sitio que el perfil del cliente, porque el siguiente administrador añadirá una entrada sin leer este razonamiento. Anota la fecha y el motivo de cada excepción, para que una excepción obsoleta de un sitio ya arreglado se pueda retirar con confianza. Una lista sin motivos crece para siempre.
Cuando alguien informa de un único destino roto, cambia la excepción y no la base. Dar la vuelta al valor por defecto para arreglar un solo sitio mueve en silencio cada aplicación no listada al otro lado del túnel.