Debian resolvconf-postrækkefølge: sæt VPN-posten først

VPN'ens navneserver havner hele tiden under LAN'ens, og en rettelse af /etc/resolv.conf holder kun få minutter. Den fil genereres, så rettelsen overlever aldrig. I Debians resolvconf er sorteringsindgangen /etc/resolvconf/interface-order, og den sorterer postnavne frem for DNS-adresser. Bekræft, hvilken resolver-stak der reelt styrer, før du rører nogen af de to filer.

Bekræft, at resolvconf ejer outputtet

Start med at spørge, hvad der skrev den nuværende fil, og hvad der vil skrive den igen. Pakken resolvconf beskriver sig selv som en ramme for dynamisk resolver-konfiguration, og en vært, der kører systemd-resolved eller en resolver styret af NetworkManager, kan se ens ud udefra og alligevel bruge en helt anden politik.

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

Hvis den opløste sti ikke fører ind i resolvconfs runtime-mappe, så stop her: denne kørebog hører til en anden stak.

Først efter den kontrol er det værd at liste de poster, resolvconf har i øjeblikket.

Læs posterne, før du skriver mønstre

interface-order matcher navnene på leverandørposter, ikke adresser og ikke kernens interface-navne. List, hvad der er registreret, så dine mønstre henviser til poster, der findes.

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

Et postnavn bærer som regel et suffiks, der angiver leverandøren, så en tunnelpost og en DHCP-post kan dele et interface-præfiks og alligevel sortere forskelligt. Kopiér de præcise navne fra mappelisten. Udled ikke et navn af interface-navnet, for klientintegrationen bestemmer, hvad der registreres. Et navn, du opfinder, matcher aldrig, og posten falder ned i opfangningsmønsteret uden nogen fejlmeddelelse.

Skriv rækkefølgen som først-match-mønstre

Filen er en liste af shell-glob-mønstre, ét pr. linje. En post tager pladsen for det første mønster, den matcher, så et bredt mønster over et specifikt gør den specifikke linje utilgængelig.

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

Sæt det specifikke tunnelmønster over opfangningsmønsteret og over det fysiske interface-mønster.

Behold de andre linjer, filen allerede havde. At erstatte hele politikken med et eksempel er måden, hvorpå ubeslægtede leverandører stille flytter sig; ret én linje, generér igen, og sammenlign. Mønstre må ikke indeholde mellemrum, skråstreger eller et indledende punktum eller en tilde, og tomme linjer og hash-kommentarer ignoreres.

Generér igen, og verificér resultatet

Rækkefølgen gælder, når opdateringsscripts genopbygger filen. Brug den understøttede opdateringsvej i stedet for at redigere det genererede output, og læs derefter, hvad resolveren faktisk modtog.

resolvconf -u
cat /etc/resolv.conf

Verificér to opslag, ikke ét: et privat navn, der bør opløses gennem tunnelen, og et offentligt kontronavn. Hvis det private navn stadig fejler, mens rækkefølgen ser rigtig ud, er problemet navnerumsrouting og ikke postprioritet, og ingen omrokering vil rette det. Sammenlign hvert svar med den server, der returnerede det, ikke kun med succes. Et privat navn besvaret af den forkerte resolver er stadig en fejl, og for brugeren ligner det et DNS-nedbrud.

Udfas den forældede post i stedet for at nedgradere den

En forældet VPN-post, der bliver ved med at dukke op efter afbrydelse, er en livscyklusfejl i klientintegrationen. At flytte den nederst skjuler symptomet og efterlader en død resolver på listen.

Udfas den gennem den komponent, der registrerer den, og bekræft derefter, at postmappen ikke længere viser den.

Notér leverandørnavnet, det mønster du ændrede, og de to opslag, du kørte. Den næste person har mere brug for de navne end for historien.