La documentación del túnel dividido necesita una regla DNS junto a cada ruta
Una ruta decide por dirección, un resolutor decide por nombre. Documente ambos selectores por flujo, cada uno con una prueba, o la nota falla cuando el DNS se mueve.
Una nota de túnel dividido que dice "el tráfico de oficina pasa por la VPN" ha documentado una decisión e implicado otras tres. En la capa de paquetes, una tabla de enrutamiento elige una interfaz por dirección de destino; en la capa de nombres, un resolutor elige un servidor por consulta, y las dos elecciones se hacen de forma independiente. Por eso un prefijo correctamente documentado todavía puede producir una máquina que resuelve un nombre interno a una dirección pública, o que no resuelve nada mientras la ruta parece perfecta.
Dos selectores, un intento de conexión
Cuando una aplicación se conecta a files.corp.example, ocurren dos búsquedas antes de que exista un paquete. El resolutor decide qué servidor recibe la consulta, usando dominios de búsqueda, dominios de enrutamiento por enlace o una regla explícita de perfil. La tabla de enrutamiento decide después adónde va la dirección resultante, usando la coincidencia de prefijo más larga con el destino.
Nada conecta esas dos decisiones. Una zona privada puede responder con 10.20.4.11 mientras la tabla de enrutamiento envía 10.20.0.0/16 al túnel, y la conexión funciona. Gire cualquiera de las dos y falla de una manera que se parece a la otra: una política DNS correcta más una ruta ausente da un nombre resuelto y un tiempo de espera, mientras que una ruta correcta más un resolutor público da una dirección que se enruta limpiamente al lugar equivocado.
El DNS de horizonte dividido lo hace más agudo. El mismo nombre puede devolver una dirección privada del resolutor interno y una dirección pública del que mira a internet, así que una nota que solo registra el prefijo no puede predecir qué dirección usará realmente el cliente. Escriba la ruta del resolutor o la dirección es una suposición.
Qué deja fuera una nota solo de ruta
Un registro solo de ruta es inútil para el fallo más común del túnel dividido: los nombres. El usuario informa de que la intranet no carga, el túnel está levantado y el prefijo está presente. Quien tome el ticket no tiene registro de qué resolutor debería haber respondido, ni forma de distinguir un sufijo de búsqueda incorrecto de un servidor bloqueado, ni una línea base con la que comparar.
La segunda omisión es la lista de excepciones. Un diseño de túnel dividido se define tanto por lo que queda fuera del túnel como por lo que entra en él, y los rangos excluidos suelen ser los primeros en romperse, porque una ruta local más específica o un filtro del lado del cliente pueden anular la intención sin tocar el perfil.
La tercera es el lado lejano del túnel. Una ruta de cliente solo pone el paquete en el cable; la puerta de enlace todavía tiene que reenviarlo y tener un camino de vuelta. La guía de reenvío de strongSwan recuerda que las reglas de reenvío y cortafuegos en la puerta de enlace son parte de la función, no parte de la fontanería que puede dar por supuesta.
Los campos que hacen ejecutable la nota
Una fila por flujo, y un flujo es un destino más un nombre más un propietario. Estos son los campos que sobreviven al contacto con un incidente real:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
La fila "dónde vive" es la que la gente se salta. Un prefijo empujado por el servidor, una ruta añadida por un perfil de cliente y una ruta escrita en un shell difieren en quién puede cambiarlas y en si sobreviven a una reconexión. Sin ese campo, el siguiente ingeniero no puede decir cuál de las tres está mirando.
Una prueba por regla, no una por túnel
Cada fila necesita dos comprobaciones inocuas: una que ejercita la ruta y otra que ejercita el nombre. Para la ruta, solicite algo que deba cruzar el túnel y confirme la ruta en lugar del alcance, por ejemplo tracert -d 10.20.4.11 en Windows o ip route get 10.20.4.11 en Linux. Para el nombre, consulte el nombre privado y registre qué servidor respondió, usando resolvectl query files.corp.example o dig files.corp.example contra el resolutor que la nota nombra.
Añada también una expectativa negativa: qué debería pasar cuando el túnel está caído. Una aplicación excluida en un dispositivo Android o iOS con el bloqueo sin VPN activado puede no tener conectividad en absoluto, y un cliente de escritorio puede dejar la misma aplicación funcionando mientras el túnel se reconecta. Registrar la respuesta prevista convierte "la VPN me rompió la aplicación" en una afirmación comprobable.
Mantenga el registro con la configuración
Guarde la nota junto al perfil que describe y versiónela con ese perfil. Un documento en un wiki que nadie actualiza es un rumor; una tabla en el mismo repositorio que las rutas empujadas y la política del resolutor puede revisarse en el mismo cambio.
Cuando algo se rompe, compare la ruta aplicada y el resolutor efectivo con el registro antes de añadir otra excepción. Dos de las tres causas comunes — una regla antigua de espacio de nombres y un proceso auxiliar fuera de la política de la aplicación — parecen exactamente un fallo de VPN y son invisibles si la nota solo enumera prefijos.
Antes de dar la nota por terminada, confirme que responde por escrito a esto: qué prefijo, para qué familia de direcciones; qué espacio de nombres privado, respondido por qué resolutor; qué nombres se quedan deliberadamente públicos; dónde se configura cada regla y quién la posee; y el único comando que demuestra la ruta y el que demuestra el nombre. Si falta alguno, el siguiente incidente se diagnosticará desde cero.