¿Es más simple el túnel completo que una larga lista de túnel dividido?

Una lista de túnel dividido empieza con tres aplicaciones y acaba cubriendo la mayor parte del equipo, y cada línea nueva es la excepción de alguien. En ese punto la lista se ha convertido en silencio en un valor predeterminado con pasos extra. El túnel completo invierte la disposición: todo entra en el túnel salvo que una exclusión documentada diga lo contrario. Que eso sea más simple depende de la pasarela y de los servicios locales que rompería.

Empiece por contar las reglas que mantiene

Cuente las entradas y luego cuente cuántas tienen un propietario con nombre y una fecha de última verificación. El segundo número es el que importa, porque una excepción que nadie posee no puede evaluarse cuando el software al que hace referencia se renombra o se sustituye. Las reglas ligadas a una ruta de ejecutable fallan en silencio tras una actualización, y el fallo parece una VPN inestable en lugar de una regla obsoleta. Escriba la lista antes de tener una opinión sobre ella.

Cada entrada debería responder a tres preguntas: qué se rompe sin ella, quién lo decidió y cómo notaría que el motivo ha caducado. Las entradas que no pueden responder a las tres son candidatas a borrarse en vez de migrarse, y borrarlas primero hace honesta la comparación posterior.

Si la mayoría de las entradas encaminan una parte grande del tráfico, ya está ejecutando un túnel completo con una carga de mantenimiento adjunta. La decisión entonces es dónde vive el valor predeterminado, no si debe haber uno.

Compruebe si la pasarela puede soportar el valor predeterminado

El túnel completo mueve cada paquete a un solo dispositivo, lo que cambia a la vez la carga de CPU de ese dispositivo, la tabla conntrack, la traducción de direcciones y el requisito de ancho de banda de subida. Una pasarela que servía cómodamente unas cuantas subredes internas puede que no se dimensionara para toda la navegación de un usuario. Mire el mayor número de sesiones simultáneas que espera en vez del promedio, porque el pico es lo que se rompe primero.

ip -s link show dev tun0
conntrack -C
ss -s

Mida la misma carga antes y después del cambio en lugar de razonar a partir de especificaciones. Una sola tarde de uso normal en un equipo mostrará si la pasarela está cerca de un límite, y no cuesta nada comparado con descubrirlo un lunes por la mañana.

Compruebe también la MTU de la ruta de extremo a extremo, porque un valor predeterminado completo expone cada aplicación al tamaño máximo de paquete del túnel. Aplicaciones que funcionaban fuera del túnel ahora pueden depender de un comportamiento de fragmentación que nunca tuvo que considerar.

Confirme que los servicios locales y el DNS privado siguen funcionando

Enumere lo que debe quedarse local por protocolo y no por nombre de aplicación: protocolos de descubrimiento para impresoras y pantallas, un puente de casa inteligente, la página de administración de un router, un servidor de desarrollo local alcanzado por un nombre que solo se resuelve en la LAN. Esas cosas se rompen cuando la ruta predeterminada empieza a apuntar a un túnel, y se rompen en silencio porque nada registra un error en el cliente.

El DNS privado es la otra dependencia. Si los nombres internos se resolvían antes con el resolutor del túnel, nada cambia; si se resolvían localmente, un valor predeterminado completo tiene que llevarlos a un resolutor que conozca las zonas. Pruebe un nombre interno y uno público después del cambio en vez de suponer que la lista de resolutores sobrevivió.

Escriba las excepciones locales en el perfil que las posee. Una excepción guardada solo en la memoria de alguien es lo primero que pierde la siguiente migración.

Migre un perfil y verifique los límites

Cambie el perfil a través de su propia configuración en lugar de superponer un valor predeterminado nuevo sobre rutas manuales que dejaron experimentos anteriores. Esas rutas sobrantes son la causa habitual de una migración que parece funcionar y se comporta de forma inconsistente un día después. Mantenga disponible el perfil antiguo para que revertir sea una selección y no una reconstrucción.

Luego verifique dos límites por separado: que los destinos públicos y privados funcionen ambos, y que el tráfico no deseado no salga fuera del túnel. Una carga de página correcta demuestra lo primero y no dice nada de lo segundo.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Repita la comprobación tras una reconexión y tras una caída, porque un interruptor que bloquea el tráfico durante una caída es una propiedad distinta de una ruta que después se restaura correctamente. El diseño más simple es aquel cuya cobertura real todavía puede explicar después de que cambie una aplicación o una red.