Atureu dos serveis de Linux que competeixen per /etc/resolv.conf

El DNS torna una i una altra vegada a l'estat anterior, la reconnexió de la VPN desfà la vostra correcció i algú de l'equip acaba proposant bloquejar el fitxer. Aquesta seqüència és un símptoma, no una solució: dos components creuen tots dos que posseeixen /etc/resolv.conf, i guanya el que escriu l'últim. Bloquejar el fitxer no resol el conflicte de propietat, només l'amaga mentre trenca el component que realment volíeu. Feu les quatre comprovacions següents en ordre i corregiu la disposició al nivell que en és propietari, no al fitxer.

Comprovació 1: és un enllaç simbòlic i cap a què

Comenceu pel fitxer mateix, perquè el camí que editeu potser no és el fitxer en absolut. Un enllaç simbòlic al directori d'execució d'un resolutor es comporta d'una manera completament diferent d'un fitxer normal que reescriu un script de client:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Un enllaç a un camí stub de systemd-resolved vol dir que el contingut del fitxer es genera, i l'edició manual se sobreescriurà al proper esdeveniment. Un fitxer normal amb línies nameserver normalment l'escriu el client o el ganxo DHCP que s'executa en connectar-se. Tots dos són legítims; el que importa és saber quin teniu abans de canviar res.

Comprovació 2: quin dimoni s'està executant

Esbrineu què és realment actiu i no què està instal·lat. En una distribució moderna hi pot haver diversos resolutors, i el que té el port 53 a la interfície loopback és el que respon:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

La sortida de l'estat anomena els servidors DNS per enllaç i els dominis d'encaminament, que és el mapa que necessiteu per al DNS dividit. Si els noms interns han d'anar a un servidor intern i la resta a un de públic, aquesta política viu als dominis per enllaç, i aplanar-la en una llista estàtica de nameserver dins del fitxer perd aquesta distinció en silenci.

La configuració pròpia de NetworkManager decideix quin d'aquests rerefons utilitza. La seva opció dns= al fitxer de configuració principal tria entre el seu resolutor intern, dnsmasq, systemd-resolved i none, i potser la distribució ha triat per vosaltres. Llegiu aquesta opció abans de decidir què vol dir “arreglar el DNS” en aquest amfitrió.

Comprovació 3: què pot escriure el client de VPN

Aquí és on sol viure el conflicte. Un client de VPN que reescriu directament el fitxer del resolutor lluitarà contra qualsevol servei que també el mantingui, i el perdedor és el que s'executa primer. Les versions recents d'OpenVPN poden lliurar la configuració DNS a systemd-resolved en lloc de reescriure el fitxer, que és el comportament cooperatiu que voleu; els scripts més antics i els ganxos escrits a mà sovint criden un auxiliar antic o simplement sobreescriuen el fitxer.

La situació de WireGuard és similar en la forma: la configuració de la interfície no gestiona el DNS, ho fan les eines del voltant, mitjançant un auxiliar de resolutor o la integració amb resolved. Si hi ha dos auxiliars d'aquest tipus instal·lats, tots dos intentaran aplicar la seva visió del món en connectar.

Llegiu els ganxos d'activació i desactivació del client en lloc d'endevinar. Unes quantes línies de shell a /etc/openvpn/up.sh o en un directori equivalent expliquen un comportament que d'altra manera sembla aleatori, i també són el lloc on podeu fer que el client cooperi en lloc de competir.

Comprovació 4: corregiu-ho al propietari, no al fitxer

Quan sapigueu el propietari, configureu el DNS a través de la interfície que admet aquell propietari. Per a systemd-resolved això vol dir opcions per enllaç i dominis d'encaminament en lloc d'un fitxer estàtic; per a NetworkManager vol dir les opcions DNS del perfil de connexió i el rerefons triat; per a una distribució amb integració de resolvconf vol dir escriure a través d'aquest auxiliar.

No feu el fitxer immutable. L'atribut immutable atura les renovacions legítimes de DHCP i les actualitzacions de la VPN juntament amb les que combatíeu, i deixa el sistema en un estat en què la propera actualització de paquets o reconnexió produeix una fallada que ningú no pot explicar a partir de la configuració. Amaga el conflicte de propietat, que és precisament el que intentàveu resoldre.

Quan dos components realment han de coexistir, doneu-los feines diferents. Deixeu que el gestor de xarxa posseeixi la configuració a nivell d'interfície, deixeu que el client de VPN aporti DNS i dominis per enllaç mitjançant la mateixa integració, i traieu el tercer script que escriu el fitxer directament. La documentació de systemd-resolved exposa els modes que admet i què exposa cadascun a /etc/resolv.conf. Trieu el mode que encaixi amb la quantitat de política que cal conservar. Si el DNS dividit és important, la disposició stub amb dominis per enllaç el conserva, mentre que el mode que copia els servidors upstream al fitxer l'aplana en silenci.

Verifiqueu-ho després d'una reconnexió, no després de l'edició

Un fitxer que sembla correcte just després del vostre canvi no demostra res, perquè el proper esdeveniment encara no ha passat. Activeu la seqüència que abans el trencava: baixeu i torneu a pujar el túnel, renoveu la concessió DHCP o canvieu la interfície, i torneu a llegir els mateixos valors.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Aleshores confirmeu la distinció que importa: el nom intern es resol pel servidor intern mentre el nom públic encara funciona. Una configuració que ho envia tot al servidor intern sembla bé fins que algú intenta arribar a internet pel túnel, i una configuració que ho envia tot al públic filtra noms interns.

Anoteu el propietari, el rerefons i el mode d'enllaç simbòlic a les notes de desplegament. Aquest sol paràgraf converteix una futura actualització de paquets d'incident en element de revisió, i evita que la propera persona redescoberixi el mateix conflicte amb una ordre chattr.