Por que un comodín nunha directiva route de OpenVPN non pode funcionar

a ruta instala prefixos de enderezo, así que un patrón de nome de host non ten con que coincidir. Use un prefixo para as redes e un proxy ou un ficheiro PAC cando os dominios deban decidir.

A intención é razoable: enviar todo o dun dominio de empresa polo túnel e deixar o resto tranquilo. A directiva que se edita instala rutas, e unha ruta non ten ningún concepto de nome de host co que coincidir. Cada intento de escribir un comodín nela produce ou un erro de análise ou, peor, unha ruta que hoxe funciona por casualidade porque o nome se resolveu nunha soa dirección. Estase pedindo a dous mecanismos distintos que fagan o traballo do outro.

Que instala unha ruta e que nunca le

Unha entrada de ruta di que un prefixo de destino é alcanzable a través dunha interface. O núcleo compara os paquetes con eses prefixos, así que os únicos identificadores implicados son enderezos e máscaras. Un nome de host nunca aparece na decisión de reenvío, e por iso non se pode comparar alí ningún patrón.

OpenVPN pode aceptar un nome resoluble nalgúns parámetros de ruta, e esa tolerancia é unha fonte de confusión. O nome resólvese mentres se aplica a configuración, producindo unha ou máis direccións que se converten en rutas ordinarias. Despois diso, o nome desaparece por completo da imaxe.

Así que unha ruta construída a partir dun nome é unha instantánea, non unha regra. Cobre aquilo ao que ese nome se resolveu no momento en que arrincou o túnel, que é exactamente o comportamento que non quere para unha familia de hosts que cambia. Un rexistro que se mova mañá deixa a ruta apuntando a onte.

Cando o destino é realmente un prefixo

Se o obxectivo é unha rede privada coñecida, escriba o prefixo. Para un exemplo do espazo de documentación, un só host e unha subrede vense así:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Ambas as entradas nomean enderezos e máscaras, e ambas sobreviven aos cambios de DNS porque nada nelas depende dun nome. Esa é toda a vantaxe: a ruta é unha afirmación sobre a topoloxía e non sobre unha busca que ocorreu unha vez.

Non extrapole un prefixo grande a partir dunha soa resposta DNS. Un nome de host que se resolve nunha dirección non lle di nada sobre o tamaño da rede que hai detrás, e un prefixo adiviñado é a forma en que un túnel acaba capturando tráfico que ninguén pretendía enviar por el. Pregunte ao propietario da rede polo prefixo real en lugar de inferilo dunha busca.

Cando a unidade de traballo é un nome de host

Seleccionar por dominio require algo que lea o dominio, é dicir, un compoñente de capa de aplicación. A resposta habitual é un proxy HTTP que vive no outro lado do túnel, co cliente escollendo que peticións lle envía.

Un ficheiro de configuración de proxy pode expresar esa elección. As regras ilustrativas de abaixo envían un dominio e os seus subdominios a un proxy e todo o demais 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";
}

A comparación de nome exacto cobre o dominio en si, e a comparación de sufixo cobre os seus fillos sen coincidir cun nome que simplemente remata en caracteres similares. Ambas son necesarias, e omitir unha produce unha regra que parece correcta e salta o vértice ou un impostor.

Estas regras elixen un proxy; non o crean e non cambian ningunha ruta do sistema operativo. O enderezo do proxy segue necesitando o seu propio camiño polo túnel, e as peticións marcadas como directas seguen a política de encamiñamento que a máquina xa ten.

Que non cobre a opción de proxy

Os programas que ignoran a configuración de proxy do navegador non se verán afectados por nada disto. As ferramentas de liña de ordes, os actualizadores e as aplicacións coa súa propia pila de rede toman a táboa de rutas, non o ficheiro PAC, así que eses casos necesitan un mecanismo por aplicación compatible ou outro deseño. Inventaríe os clientes que importan antes de prometer que a regra do navegador cobre o fluxo de traballo.

Volver directo tampouco é unha vía de escape. Se a política de encamiñamento da máquina xa envía todo ao túnel, unha petición marcada como directa queda dentro, porque a elección de proxy e a táboa de rutas son decisións distintas tomadas en capas distintas.

A resolución de nomes é unha terceira cuestión separada. Escoller que peticións van a un proxy non di nada sobre que resolutor as responde, e tratar ambas as cousas como un só axuste produce fugas que son invisibles ata que alguén proba desde fóra. Decida onde se responde cada consulta e escriba esa decisión xunto á regra de proxy. Un resolutor que cambia porque o túnel se levantou moverá a resposta en silencio.

Probar ambos os camiños, non só o feliz

Probe un nome de host que debería coincidir, un nome de host que non debería, e o vértice do dominio, xa que o vértice é o caso que máis a miúdo se escapa dunha regra só de sufixo. Logo confirme que camiño tomou realmente cada petición en lugar de inferilo de se a páxina cargou.

Por último, probe a rama de fallo. Un proxy que non é alcanzable debería fallar dun xeito que decidise de antemán, en lugar de volver en silencio a unha conexión directa. A referencia de opcións de rede documenta os parámetros de ruta con precisión; a metade de dominio deste deseño vive por completo fóra dela.

Artigos relacionados