Enrutamiento VPN por dominio frente a rutas IP: ¿cuál encaja?

Una ruta IP coincide con un prefijo de dirección, y el núcleo la aplica sin hacer más preguntas. Una regla de VPN basada en dominio coincide con un nombre, lo que significa que algo en la pila tiene que decidir qué direcciones significa ese nombre en este momento y mantener esa decisión al día. Son mecanismos distintos con modos de fallo distintos, y los proveedores usan la misma palabra para ambos. Compararlos en listas de funciones no va al grano; compárelos por lo que ocurre cuando cambia la respuesta.

La separación útil está entre una regla que resuelve y una regla que no.

Con qué coincide realmente cada regla

Una regla de prefijo coincide con direcciones de destino en una tabla de enrutamiento. Nada se resuelve, nada caduca, y la coincidencia es exacta para cada paquete. Una regla de dominio coincide con la petición de una aplicación de un nombre, que RFC 1034 define como un árbol de etiquetas y no como una dirección. Algunos productos resuelven el nombre una vez e instalan las direcciones resultantes como rutas, lo que convierte la regla en una regla IP con un temporizador de refresco adjunto.

Sepa cuál de los dos tiene antes de depurarlo, porque el fallo se ve completamente distinto en cada caso.

Dónde vive la regla de dominio en la pila

Si el producto implementa reglas de dominio mediante un proxy local, el tráfico tiene que llegar a ese proxy, y las aplicaciones que ignoran el proxy del sistema se saltan la regla por completo. Si las implementa resolviendo nombres y añadiendo rutas, las direcciones son tan frescas como el último refresco. Si engancha el resolutor, el comportamiento de DNS pasa a formar parte de la política de enrutamiento, y un resolutor de reserva puede deshacerlo en silencio.

Lea el modelo del proveedor y no la etiqueta del ajuste. Dos clientes con un cuadro llamado Split Tunnel pueden estar haciendo tres cosas distintas.

Compare qué se rompe

Tres cosas se rompen de formas distintas. Cambio de direcciones: un nombre de host de CDN puede resolverse a un conjunto de direcciones distinto en cuestión de minutos, así que una lista copiada envejece mal. Alcance de subdominios: una regla para example.com puede cubrir api.example.com o no, y la documentación suele ser explícita sobre cuál es el caso. Fallo de resolución: cuando el resolutor falla, un cliente que resuelve puede recurrir a tunelizar el tráfico o a enviarlo directamente.

Solo la segunda es una cuestión de configuración. Las otras dos son cuestiones de diseño sobre cuánto está dispuesto a adivinar el producto.

Cuándo el prefijo es la respuesta mejor

Para una subred privada estable, un prefijo explícito es más claro, más rápido y más fácil de auditar. También sobrevive a una caída del resolutor, porque nada tiene que resolverse. Recurra a una regla de dominio cuando el servicio esté alojado, cuando las direcciones roten o cuando realmente no pueda enumerar el conjunto de destinos. No recurra a ella solo porque el nombre de host sea lo que casualmente conoce.

Una lista estática adivinada es lo peor de ambos: parece mantenida y falla en silencio el día en que el proveedor añade un host.

Verifique con una petición nueva

Pruebe con una petición en frío tras una reconexión normal, porque una página en caché puede no tocar nunca la regla. Resuelva el nombre y luego compruebe adónde fue realmente la conexión. dig +short app.example.com da el conjunto de direcciones actual, y la lista de conexiones del cliente le dice qué interfaz llevó el flujo.

Repita tras el intervalo de refresco que documente el producto. Si el conjunto de direcciones se desplaza y la regla no lo sigue, ha encontrado el comportamiento real.

Mantenga también la política del resolutor por separado. Una regla de dominio necesita datos de nombre correctos, pero no decide por sí sola qué resolutor responde a la consulta.