Debian resolvconf: ordningen på posterna – sätt VPN-posten först

VPN:ets namnserver hamnar ständigt under LAN:ets, och att redigera /etc/resolv.conf rättar det i några minuter. Filen genereras, så rättelsen överlever aldrig. I Debians resolvconf är sorteringsindata /etc/resolvconf/interface-order, och den sorterar postnamn snarare än DNS-adresser. Bekräfta vilken resolver-stack som faktiskt bestämmer innan du rör någon av de två filerna.

Bekräfta att resolvconf äger utdata

Börja med att fråga vad som skrev den nuvarande filen och vad som kommer att skriva den igen. Paketet resolvconf beskriver sig som ett ramverk för dynamisk resolverkonfiguration, och en värd som kör systemd-resolved eller en NetworkManager-styrd resolver kan se likadan ut utifrån men ändå använda en helt annan policy.

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

Om den upplösta sökvägen inte leder in i resolvconfs runtime-katalog, stanna här: den här handboken hör till en annan stack.

Först efter den kontrollen är det värt att lista de poster som resolvconf håller just nu.

Läs posterna innan du skriver mönster

interface-order matchar namnen på leverantörsposter, inte adresser och inte kernens gränssnittsnamn. Lista vad som är registrerat så att dina mönster pekar på poster som finns.

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

Ett postnamn bär vanligen ett suffix som identifierar leverantören, så en tunnelpost och en DHCP-post kan dela ett gränssnittsprefix och ändå sorteras olika. Kopiera de exakta namnen från kataloglistningen. Härled inte ett namn från gränssnittsnamnet, eftersom klientintegrationen avgör vad som registreras. Ett påhittat namn matchar aldrig, och posten faller till mönstret som fångar allt utan något felmeddelande.

Skriv ordningen som förstamatchande mönster

Filen är en lista med shell-globmönster, ett per rad. En post tar platsen för det första mönstret den matchar, så ett brett mönster ovanför ett specifikt gör den specifika raden oåtkomlig.

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

Sätt det specifika tunnelmönstret ovanför mönstret som fångar allt och ovanför mönstret för det fysiska gränssnittet.

Behåll de andra raderna som filen redan hade. Att ersätta hela policyn med ett exempel är hur orelaterade leverantörer flyttar sig tyst; ändra en rad, generera om och jämför. Mönster får inte innehålla blanksteg, snedstreck eller en inledande punkt eller tilde, och tomma rader och hash-kommentarer ignoreras.

Generera om och verifiera resultatet

Ordningen gäller när uppdateringsskripten bygger om filen. Kör den stödda uppdateringsvägen i stället för att redigera den genererade utdatan, och läs sedan vad resolvern faktiskt fick.

resolvconf -u
cat /etc/resolv.conf

Verifiera två uppslag, inte ett: ett privat namn som ska lösas genom tunneln, och ett offentligt kontrollnamn. Om det privata namnet fortfarande misslyckas medan ordningen ser korrekt ut, är problemet namnområdesdirigering och inte postprioritet, och ingen omordning rättar det. Jämför varje svar med servern som returnerade det, inte bara med framgång. Ett privat namn som besvarats av fel resolver är fortfarande ett fel, och för användaren ser det ut som ett DNS-avbrott.

Avveckla den inaktuella posten i stället för att nedgradera den

En inaktuell VPN-post som fortsätter att dyka upp efter frånkoppling är ett livscykelfel i klientintegrationen. Att flytta den längst ner döljer symptomet och lämnar en död resolver i listan.

Avveckla den genom komponenten som registrerar den, och bekräfta sedan att postkatalogen inte längre listar den.

Anteckna leverantörens namn, mönstret du ändrade och de två uppslag du körde. Nästa person behöver de namnen mer än historien.