Debian resolvconf: rekkefølgen på oppføringene – sett VPN-oppføringen først

Navneserveren til VPN havner stadig under LAN-ens, og å redigere /etc/resolv.conf fikser det i noen minutter. Den filen genereres, så rettelsen overlever aldri. I Debians resolvconf er sorteringsinngangen /etc/resolvconf/interface-order, og den sorterer oppføringsnavn framfor DNS-adresser. Bekreft hvilken resolver-stack som faktisk styrer før du rører noen av de to filene.

Bekreft at resolvconf eier utdataene

Start med å spørre hva som skrev den gjeldende filen og hva som vil skrive den igjen. Pakken resolvconf beskriver seg selv som et rammeverk for dynamisk resolver-konfigurasjon, og en vert som kjører systemd-resolved eller en NetworkManager-styrt resolver kan se lik ut utenfra og likevel bruke en helt annen policy.

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

Hvis den oppløste stien ikke fører inn i kjøretidskatalogen til resolvconf, stopp her: denne kjøreboken tilhører en annen stack.

Først etter den kontrollen er det verdt å liste oppføringene resolvconf holder nå.

Les oppføringene før du skriver mønstre

interface-order matcher navnene på leverandøroppføringer, ikke adresser og ikke kjernens grensesnittnavn. List opp det som er registrert, slik at mønstrene dine viser til oppføringer som finnes.

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

Et oppføringsnavn har vanligvis et suffiks som identifiserer leverandøren, så en tunelloppføring og en DHCP-oppføring kan dele et grensesnittprefiks og likevel sortere ulikt. Kopier de nøyaktige navnene fra kataloglisten. Ikke utled et navn fra grensesnittnavnet, for klientintegrasjonen bestemmer hva som registreres. Et navn du finner på, vil aldri matche, og oppføringen faller til mønsteret som fanger alt, uten noen feilmelding.

Skriv rekkefølgen som førstetreff-mønstre

Filen er en liste med shell-glob-mønstre, ett per linje. En oppføring tar plassen til det første mønsteret den matcher, så et bredt mønster over et spesifikt gjør den spesifikke linjen utilgjengelig.

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

Sett det spesifikke tunnelmønsteret over mønsteret som fanger alt og over mønsteret for det fysiske grensesnittet.

Behold de andre linjene filen allerede hadde. Å erstatte hele policyen med et eksempel er måten urelaterte leverandører stille flytter seg; endre én linje, generer på nytt og sammenlign. Mønstre kan ikke inneholde mellomrom, skråstreker eller et innledende punktum eller en tilde, og tomme linjer og hash-kommentarer ignoreres.

Generer på nytt og verifiser resultatet

Rekkefølgen gjelder når oppdateringsskriptene bygger filen på nytt. Bruk den støttede oppdateringsveien i stedet for å redigere de genererte utdataene, og les deretter hva resolveren faktisk mottok.

resolvconf -u
cat /etc/resolv.conf

Verifiser to oppslag, ikke ett: et privat navn som skal løses gjennom tunnelen, og et offentlig kontrollnavn. Hvis det private navnet fortsatt feiler mens rekkefølgen ser riktig ut, er problemet navneromsruting og ikke oppføringsprioritet, og ingen omrokkering vil rette det. Sammenlign hvert svar med serveren som returnerte det, ikke bare med suksess. Et privat navn besvart av feil resolver er fortsatt en feil, og for brukeren ser det ut som et DNS-utfall.

Utfas den utdaterte oppføringen i stedet for å nedgradere den

En utdatert VPN-oppføring som stadig dukker opp etter frakobling, er en livssyklusfeil i klientintegrasjonen. Å flytte den nederst skjuler symptomet og etterlater en død resolver på listen.

Utfas den gjennom komponenten som registrerer den, og bekreft deretter at oppføringskatalogen ikke lenger viser den.

Noter leverandørnavnet, mønsteret du endret og de to oppslagene du kjørte. Den neste personen trenger de navnene mer enn historien.