Què impedeix realment route-nopull d’OpenVPN que enviï el servidor

Vas posar route-nopull en un perfil de client perquè el túnel no s’empassés la ruta per defecte, i ara la subxarxa de l’oficina és inaccessible mentre el client encara diu que està connectat. Les dues observacions són certes i no ha fallat res. L’indicador diu al client que ometi les rutes i les entrades DHCP que el servidor envia, una instrucció més estreta del que la majoria espera quan l’afegeix. El que queda és un túnel funcional sense opinió sobre quins destins l’han d’utilitzar.

Aquest buit és tota la decisió de què tracta aquest article. O el servidor descriu la xarxa, o la descriu el client, i l’indicador lliura aquesta feina al client sense fer-ne res per tu.

Què desactiva l’indicador en connectar

Un client OpenVPN que estira normalment rep del servidor, després de l’autenticació, un paquet: rutes, una redirecció de la passarel·la per defecte, servidors DNS i unes quantes directrius d’ajust. Amb route-nopull en vigor, el client encara accepta la sessió, encara verifica certificats, encara negocia xifratges i keepalives, i encara aixeca la interfície. El que descarta és l’aplicació de les línies route enviades i de les línies dhcp-option enviades, DNS inclòs.

La confusió ve d’un indicador verd al costat d’una aplicació morta. El túnel existeix; la correspondència dels destins amb aquest túnel no. Res al tauler d’estat del client distingeix «connectat i encaminant» de «connectat i inert», perquè des del punt de vista del túnel tots dos són el mateix estat.

Per què un túnel viu pot no encaminar res

La interfície apareix amb la seva pròpia adreça i, en un enllaç punt a punt, sovint no res més específic que una ruta d’amfitrió cap al parell. Una subxarxa privada només es fa abastable quan alguna ruta apunta a aquesta interfície amb el prefix correcte, i amb l’enviament desactivat aquesta ruta no arriba mai. El perfil baixat tampoc sol ajudar, perquè es va escriure assumint que el servidor proporcionaria exactament aquesta informació. Per això la interfície pot semblar sana mentre la subxarxa continua fosca.

Llegir el perfil, doncs, demostra molt poc. Llegeix l’estat en execució, a la màquina connectada:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Una adreça sense ruta de subxarxa a la segona ordre és la signatura d’aquest problema. La tercera ordre respon llavors la pregunta que realment importa als usuaris, perquè informa de la interfície que el nucli triaria per a un destí concret en lloc de la llista que esperaves que utilitzés. Si respon per l’enllaç físic, el túnel no és en absolut al camí.

La resolució de noms falla per un motiu relacionat, no per un de separat. Les entrades dhcp-option DNS enviades se salten amb el mateix indicador, així que les consultes per a hosts interns van al resolutor que hagi proporcionat la xarxa local. Aquest resolutor no té cap zona per a l’oficina, així que la consulta falla o retorna una resposta pública, i la fallada sembla un problema del servidor quan és un problema de configuració del client. Provar una adreça abans d’un nom és el que separa les dues coses.

Triar entre l’indicador i un filtre de prefix

Les dues opcions resolen formes diferents de la mateixa queixa, i triar malament és el que produeix l’estat de connectat però inútil. Una substitueix la política enviada del tot, mentre que l’altra l’edita per prefix. La taula en dóna la versió curta, i el paràgraf següent cobreix la part que atrapa la gent.

pull-filter és un comparador de prefixos amb tres verbs, així que pot acceptar una família de línies, ignorar-les silenciosament o rebutjar la connexió directament quan apareix un prefix. Aquest darrer comportament és el que val la pena conèixer: una regla de rebuig converteix un desacord de política en un establiment fallit en lloc d’una omissió silenciosa. El manual d’OpenVPN 2.6 llista els prefixos acceptats i la semàntica exacta de cada verb.

Un camí mitjà habitual és rebutjar només redirect-gateway i deixar que les rutes de l’oficina i el DNS arribin com estava previst. Això manté l’enviament funcionant per a les parts que el servidor entén millor que tu, alhora que evita la única línia que s’apoderaria de la teva ruta per defecte.

Afegir rutes i un resolutor a mà

Si mantens l’indicador, el perfil ha de dir el que hauria dit el servidor. Les directrius route del costat del client s’apliquen després d’establir la connexió, així que funcionen al costat de l’indicador en lloc de quedar bloquejades per ell. Posa-les al perfil, no en una línia d’ordres interactiva, o la propera reconnexió no reproduirà l’estat funcional.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

La línia DNS queda en una posició incòmoda: és una directriu del costat del client, però alguns clients només l’apliquen a través de la integració DNS de la plataforma, que pot sobreescriure-la quan canvia l’enllaç. En un amfitrió systemd, configurar el resolutor directament a la interfície del túnel és més previsible que esperar que el client guanyi el concurs de prioritats:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

El domini d’encaminament importa tant com l’adreça. Sense ell, les consultes de noms públics també es poden enviar al resolutor intern, i qualsevol resolutor intern que rebutgi la recursió trencarà la navegació mentre deixa la zona privada funcionant. Amb ell, només els noms sota aquest sufix s’encaminen al resolutor del túnel i tota la resta segueix l’enllaç físic.

Comprovar el resultat: adreça, nom i el camí exterior

Tres proves separen les fallades possibles. Obtén l’adreça privada per IP, després el mateix amfitrió pel nom, després un lloc públic corrent. Una IP que funciona amb un nom que falla apunta al resolutor; una IP que falla amb un nom que funciona apunta a l’encaminament; que fallin totes dues sol significar que el túnel no és al camí.

Després mira cap enfora en lloc de cap endins. La ruta pròpia del punt final del túnel ha de sobreviure al canvi, i qualsevol bloqueig de fallada ha d’estar limitat al túnel sense capturar el punt final. Un client que continua navegant després que caigui el túnel és un problema de política, no d’encaminament, i no apareixerà en cap de les tres proves anteriors.

Escriu la llista final a la documentació del perfil: les rutes, el resolutor, els dominis i el motiu pel qual existeix cadascun. Una reconnexió que reprodueixi la mateixa taula és l’única evidència que la política local és completa. Si les aplicacions encara fallen amb el túnel aixecat i les tres proves superades, el següent lloc on mirar és la classe de problemes de connectat però fora de línia, no certificats que ja s’han verificat.