El servidor de noms de la VPN cau sempre per sota del de la LAN, i editar /etc/resolv.conf ho arregla durant uns minuts. Aquest fitxer es genera, així que la solució no perdura mai. Al resolvconf de Debian l’entrada d’ordenació és /etc/resolvconf/interface-order, i ordena noms de registre en lloc d’adreces DNS. Confirmeu quina pila de resolució és realment la que mana abans de tocar cap dels dos fitxers.

Confirmeu que resolvconf és el propietari de la sortida

Comenceu preguntant què va escriure el fitxer actual i què el tornarà a escriure. El paquet resolvconf es descriu com un marc per a la configuració dinàmica del resolutor, i un amfitrió que executi systemd-resolved o un resolutor gestionat per NetworkManager pot semblar igual des de fora mentre fa servir una política completament diferent.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Si el camí resolt no porta al directori d’execució de resolvconf, atureu-vos aquí: aquest manual pertany a una altra pila.

Només després d’aquesta comprovació val la pena llistar els registres que resolvconf té actualment.

Llegiu els registres abans d’escriure patrons

interface-order coincideix amb els noms dels registres del proveïdor, no amb adreces ni amb noms d’interfície del nucli. Llisteu què hi ha registrat perquè els vostres patrons es refereixin a entrades que existeixen.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Un nom de registre sol portar un sufix que identifica el seu proveïdor, de manera que un registre de túnel i un registre DHCP poden compartir un prefix d’interfície i tot i així ordenar-se diferent. Copieu els noms exactes del llistat del directori. No deduïu un nom a partir del nom de la interfície, perquè la integració del client decideix què registra. Un nom que inventeu no coincidirà mai, i el registre caurà al patró que ho atrapa tot sense cap missatge d’error.

Escriviu l’ordre com a patrons de primera coincidència

El fitxer és una llista de patrons glob d’intèrpret d’ordres, un per línia. Un registre pren la posició del primer patró amb què coincideix, així que un patró ampli per sobre d’un de concret fa que la línia concreta sigui inaccessible.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Poseu el patró específic del túnel per sobre del patró que ho atrapa tot i per sobre del patró de la interfície física.

Manteniu les altres línies que el fitxer ja tenia. Substituir tota la política per un exemple és com els proveïdors no relacionats es mouen en silenci; canvieu una línia, regenereu i compareu. Els patrons no poden contenir espais, barres inclinades ni un punt o una titlla inicials, i les línies buides i els comentaris amb coixinet s’ignoren.

Regenereu i verifiqueu el resultat

L’ordre s’aplica quan els scripts d’actualització reconstrueixen el fitxer. Activeu el camí d’actualització compatible en lloc d’editar la sortida generada, i després llegiu què ha rebut realment el resolutor.

resolvconf -u
cat /etc/resolv.conf

Verifiqueu dues consultes, no una: un nom privat que s’hauria de resoldre pel túnel, i un nom de control públic. Si el nom privat encara falla mentre l’ordre sembla correcte, el problema és l’encaminament de l’espai de noms i no la prioritat dels registres, i cap reordenació no ho arreglarà. Compareu cada resposta amb el servidor que l’ha retornada, no només amb l’èxit. Un nom privat respost pel resolutor equivocat continua sent un fracàs, i per a l’usuari sembla una caiguda del DNS.

Retireu el registre obsolet en lloc de degradar-lo

Un registre VPN obsolet que torna a aparèixer després de desconnectar és un error de cicle de vida a la integració del client. Moure’l al final amaga el símptoma i deixa un resolutor mort a la llista.

Retireu-lo a través del component que el registra, i després confirmeu que el directori de registres ja no el llista.

Anoteu el nom del proveïdor, el patró que heu canviat i les dues consultes que heu executat. La propera persona necessita més aquests noms que la història.

Articles relacionats