Por qué un comodín en una directiva route de OpenVPN no puede funcionar

La intención es razonable: enviar todo lo de un dominio de empresa por el túnel y dejar el resto tranquilo. La directiva que se edita instala rutas, y una ruta no tiene ningún concepto de nombre de host con el que coincidir. Cada intento de escribir un comodín en ella produce o bien un error de análisis o, peor, una ruta que hoy funciona por casualidad porque el nombre se resolvió a una sola dirección. Se está pidiendo a dos mecanismos distintos que hagan el trabajo del otro.

Qué instala una ruta y qué nunca lee

Una entrada de ruta dice que un prefijo de destino es alcanzable a través de una interfaz. El núcleo compara los paquetes con esos prefijos, así que los únicos identificadores implicados son direcciones y máscaras. Un nombre de host nunca aparece en la decisión de reenvío, y por eso no se puede comparar allí ningún patrón.

OpenVPN puede aceptar un nombre resoluble en algunos parámetros de ruta, y esa tolerancia es una fuente de confusión. El nombre se resuelve mientras se aplica la configuración, produciendo una o más direcciones que se convierten en rutas ordinarias. Después de eso, el nombre desaparece por completo de la imagen.

Así que una ruta construida a partir de un nombre es una instantánea, no una regla. Cubre aquello a lo que ese nombre se resolvió en el momento en que arrancó el túnel, que es exactamente el comportamiento que no quiere para una familia de hosts que cambia. Un registro que se mueva mañana deja la ruta apuntando a ayer.

Cuando el destino es realmente un prefijo

Si el objetivo es una red privada conocida, escriba el prefijo. Para un ejemplo del espacio de documentación, un solo host y una subred se ven así:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Ambas entradas nombran direcciones y máscaras, y ambas sobreviven a los cambios de DNS porque nada en ellas depende de un nombre. Esa es toda la ventaja: la ruta es una afirmación sobre la topología y no sobre una búsqueda que ocurrió una vez.

No extrapole un prefijo grande a partir de una sola respuesta DNS. Un nombre de host que se resuelve a una dirección no le dice nada sobre el tamaño de la red que hay detrás, y un prefijo adivinado es la forma en que un túnel acaba capturando tráfico que nadie pretendía enviar por él. Pregunte al propietario de la red por el prefijo real en lugar de inferirlo de una búsqueda.

Cuando la unidad de trabajo es un nombre de host

Seleccionar por dominio requiere algo que lea el dominio, es decir, un componente de capa de aplicación. La respuesta habitual es un proxy HTTP que vive al otro lado del túnel, con el cliente eligiendo qué peticiones enviarle.

Un archivo de configuración de proxy puede expresar esa elección. Las reglas ilustrativas de abajo envían un dominio y sus subdominios a un proxy y todo lo demás directo:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

La comparación de nombre exacto cubre el dominio en sí, y la comparación de sufijo cubre sus hijos sin coincidir con un nombre que simplemente termina en caracteres similares. Ambas son necesarias, y omitir una produce una regla que parece correcta y se salta el vértice o a un impostor.

Estas reglas eligen un proxy; no lo crean y no cambian ninguna ruta del sistema operativo. La dirección del proxy sigue necesitando su propio camino por el túnel, y las peticiones marcadas como directas siguen la política de enrutamiento que la máquina ya tiene.

Qué no cubre la opción de proxy

Los programas que ignoran la configuración de proxy del navegador no se verán afectados por nada de esto. Las herramientas de línea de comandos, los actualizadores y las aplicaciones con su propia pila de red toman la tabla de rutas, no el archivo PAC, así que esos casos necesitan un mecanismo por aplicación compatible u otro diseño. Inventaríe los clientes que importan antes de prometer que la regla del navegador cubre el flujo de trabajo.

Volver directo tampoco es una vía de escape. Si la política de enrutamiento de la máquina ya envía todo al túnel, una petición marcada como directa se queda dentro, porque la elección de proxy y la tabla de rutas son decisiones distintas tomadas en capas distintas.

La resolución de nombres es una tercera cuestión separada. Elegir qué peticiones van a un proxy no dice nada sobre qué resolutor las responde, y tratar ambas como un solo ajuste produce fugas que son invisibles hasta que alguien prueba desde fuera. Decida dónde se responde cada consulta y escriba esa decisión junto a la regla de proxy. Un resolutor que cambia porque el túnel se levantó moverá la respuesta en silencio.

Probar ambos caminos, no solo el feliz

Pruebe un nombre de host que debería coincidir, un nombre de host que no debería, y el vértice del dominio, ya que el vértice es el caso que más a menudo se escapa de una regla solo de sufijo. Luego confirme qué camino tomó realmente cada petición en lugar de inferirlo de si la página cargó.

Por último, pruebe la rama de fallo. Un proxy que no es alcanzable debería fallar de una manera que haya decidido de antemano, en lugar de volver en silencio a una conexión directa. La referencia de opciones de red documenta los parámetros de ruta con precisión; la mitad de dominio de este diseño vive por completo fuera de ella.