Per què un comodí en una directiva route d’OpenVPN no pot funcionar

La intenció és raonable: enviar-ho tot d’un domini d’empresa pel túnel i deixar la resta tranquil·la. La directiva que s’edita instal·la rutes, i una ruta no té cap concepte de nom d’amfitrió amb què coincidir. Cada intent d’escriure-hi un comodí produeix o bé un error d’anàlisi o, pitjor, una ruta que avui funciona per casualitat perquè el nom es va resoldre en una sola adreça. S’està demanant a dos mecanismes diferents que facin la feina l’un de l’altre.

Què instal·la una ruta i què no llegeix mai

Una entrada de ruta diu que un prefix de destinació és abastable a través d’una interfície. El nucli compara els paquets amb aquests prefixos, així que els únics identificadors implicats són adreces i màscares. Un nom d’amfitrió no apareix mai en la decisió de reenviament, i per això no s’hi pot comparar cap patró.

OpenVPN pot acceptar un nom resoluble en alguns paràmetres de ruta, i aquesta tolerància és una font de confusió. El nom es resol mentre s’aplica la configuració, produint una o més adreces que esdevenen rutes ordinàries. Després d’això, el nom desapareix del tot de la imatge.

Així, una ruta construïda a partir d’un nom és una instantània, no una regla. Cobreix allò a què aquell nom es va resoldre en el moment en què el túnel va arrencar, que és exactament el comportament que no voleu per a una família d’amfitrions que canvia. Un registre que es mou demà deixa la ruta assenyalant ahir.

Quan la destinació és realment un prefix

Si l’objectiu és una xarxa privada coneguda, escriviu el prefix. Per a un exemple d’espai de documentació, un sol amfitrió i una subxarxa es veuen així:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Totes dues entrades nomenen adreces i màscares, i totes dues sobreviuen als canvis de DNS perquè res en elles depèn d’un nom. Aquest és tot l’avantatge: la ruta és una afirmació sobre la topologia i no sobre una consulta que va passar una vegada.

No extrapoleu cap prefix gran a partir d’una sola resposta DNS. Un nom d’amfitrió que es resol en una adreça no us diu res sobre la mida de la xarxa que hi ha darrere, i un prefix endevinat és com un túnel acaba capturant trànsit que ningú no pretenia enviar-hi. Demaneu el prefix real al propietari de la xarxa en lloc d’inferir-lo d’una consulta.

Quan la unitat de treball és un nom d’amfitrió

Seleccionar per domini requereix alguna cosa que llegeixi el domini, és a dir, un component de capa d’aplicació. La resposta habitual és un proxy HTTP que viu a l’altre costat del túnel, amb el client triant quines peticions hi envia.

Un fitxer de configuració de proxy pot expressar aquesta tria. Les regles il·lustratives de sota envien un domini i els seus subdominis a un proxy i tot la resta directe:

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ó de nom exacte cobreix el domini mateix, i la comparació de sufix cobreix els seus fills sense coincidir amb un nom que només acaba en caràcters similars. Totes dues són necessàries, i ometre’n una produeix una regla que sembla correcta i es salta el vèrtex o un impostor.

Aquestes regles trien un proxy; no el creen i no canvien cap ruta del sistema operatiu. L’adreça del proxy encara necessita el seu propi camí pel túnel, i les peticions marcades com a directes segueixen la política d’encaminament que la màquina ja té.

Què no cobreix l’opció de proxy

Els programes que ignoren la configuració de proxy del navegador no es veuran afectats per res d’això. Les eines de línia d’ordres, els actualitzadors i les aplicacions amb la seva pròpia pila de xarxa prenen la taula d’encaminament, no el fitxer PAC, així que aquests casos necessiten un mecanisme per aplicació suportat o un disseny diferent. Inventarieu els clients que importen abans de prometre que la regla del navegador cobreix el flux de treball.

Tornar directe tampoc no és una escapatòria. Si la política d’encaminament de la màquina ja ho envia tot cap al túnel, una petició marcada com a directa es queda a dins, perquè la tria de proxy i la taula d’encaminament són decisions diferents preses en capes diferents.

La resolució de noms és una tercera qüestió separada. Triar quines peticions van a un proxy no diu res sobre quin resolutor les respon, i tractar les dues coses com un sol paràmetre produeix fuites que són invisibles fins que algú prova des de fora. Decidiu on es respon cada consulta i escriviu aquesta decisió al costat de la regla de proxy. Un resolutor que canvia perquè el túnel s’ha aixecat mourà la resposta en silenci.

Provar tots dos camins, no només el feliç

Proveu un nom d’amfitrió que hauria de coincidir, un nom d’amfitrió que no hauria, i el vèrtex del domini, ja que el vèrtex és el cas que més sovint s’escapa d’una regla només de sufix. Després confirmeu quin camí va prendre realment cada petició en lloc d’inferir-lo de si la pàgina es va carregar.

Finalment, proveu la branca de fallada. Un proxy que no és abastable hauria de fallar d’una manera que hàgiu decidit per endavant, en lloc de retrocedir en silenci a una connexió directa. La referència d’opcions de xarxa documenta els paràmetres de ruta amb precisió; la meitat de domini d’aquest disseny viu completament fora d’ella.