Ordinea înregistrărilor în resolvconf pe Debian: puneți înregistrarea VPN prima

Serverul de nume al VPN ajunge mereu sub cel al LAN, iar editarea /etc/resolv.conf repară asta pentru câteva minute. Fișierul respectiv este generat, așa că remedierea nu rezistă niciodată. În resolvconf din Debian intrarea de ordonare este /etc/resolvconf/interface-order, iar aceasta sortează nume de înregistrare, nu adrese DNS. Confirmați ce stivă de resolver este cu adevărat responsabilă înainte de a atinge oricare dintre cele două fișiere.

Confirmați că resolvconf deține ieșirea

Începeți prin a întreba ce a scris fișierul actual și ce îl va scrie din nou. Pachetul resolvconf se descrie ca un cadru pentru configurarea dinamică a resolverului, iar un gazdă care rulează systemd-resolved sau un resolver administrat de NetworkManager poate arăta la fel din exterior folosind totuși o politică complet diferită.

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

Dacă calea rezolvată nu duce în directorul de rulare al resolvconf, opriți-vă aici: acest ghid aparține altei stive.

Abia după acea verificare merită să listați înregistrările pe care resolvconf le deține acum.

Citiți înregistrările înainte de a scrie modele

interface-order se potrivește cu numele înregistrărilor furnizorului, nu cu adrese și nu cu nume de interfață ale nucleului. Enumerați ce este înregistrat, astfel încât modelele dvs. să se refere la intrări care există.

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

Un nume de înregistrare poartă de obicei un sufix care identifică furnizorul, așa că o înregistrare de tunel și una DHCP pot împărți un prefix de interfață și totuși să se sorteze diferit. Copiați numele exacte din listarea directorului. Nu deduceți un nume din numele interfeței, pentru că integrarea clientului decide ce se înregistrează. Un nume inventat nu se va potrivi niciodată, iar înregistrarea va cădea în modelul care prinde tot, fără niciun mesaj de eroare.

Scrieți ordinea ca modele de prima potrivire

Fișierul este o listă de modele glob de shell, unul pe linie. O înregistrare ia poziția primului model cu care se potrivește, așa că un model larg deasupra unuia specific face linia specifică inaccesibilă.

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

Puneți modelul specific al tunelului deasupra modelului care prinde tot și deasupra modelului interfeței fizice.

Păstrați celelalte linii pe care fișierul le avea deja. Înlocuirea întregii politici cu un exemplu este felul în care furnizorii fără legătură se mută în tăcere; schimbați o linie, regenerați și comparați. Modelele nu pot conține spații, bare oblice sau un punct ori tilde inițial, iar liniile goale și comentariile cu diez sunt ignorate.

Regenerați și verificați rezultatul

Ordinea se aplică atunci când scripturile de actualizare reconstruiesc fișierul. Declanșați calea de actualizare acceptată în loc să editați ieșirea generată, apoi citiți ce a primit de fapt resolverul.

resolvconf -u
cat /etc/resolv.conf

Verificați două interogări, nu una: un nume privat care ar trebui rezolvat prin tunel și un nume de control public. Dacă numele privat eșuează în continuare în timp ce ordinea pare corectă, problema este rutarea spațiului de nume, nu prioritatea înregistrărilor, și nicio reordonare nu o va repara. Comparați fiecare răspuns cu serverul care l-a returnat, nu doar cu succesul. Un nume privat răspuns de resolverul greșit rămâne o eroare, iar pentru utilizator arată ca o cădere DNS.

Scoateți din uz înregistrarea învechită în loc să o retrogradați

O înregistrare VPN învechită care reapare după deconectare este o eroare de ciclu de viață în integrarea clientului. Mutarea ei la subsol ascunde simptomul și lasă un resolver mort în listă.

Scoateți-o din uz prin componenta care o înregistrează, apoi confirmați că directorul de înregistrări nu o mai listează.

Notați numele furnizorului, modelul pe care l-ați schimbat și cele două interogări pe care le-ați rulat. Următoarei persoane îi trebuie mai mult acele nume decât povestea.