Att redigera resolv.conf löser inte DNS efter att VPN:en kopplas från

Du kopplar från VPN:en, ping 1.1.1.1 svarar fortfarande, och varje namnförfrågan hänger innan sidan till slut ger upp. Då visar cat /etc/resolv.conf en namnserver som bara någonsin funnits inuti tunneln, oftast först i listan. Att radera den raden verkar fixa det i ungefär tio minuter, tills ett viloläge, en Wi-Fi-roaming eller en omstart sätter tillbaka den. Filen du redigerade är inte inställningen; den är en återgivning av länkstatus som en annan komponent äger.

Varför en enda inaktuell post kostar sekunder per uppslagning

glibc-resolvern går igenom namnserverlistan i ordning och väntar ut en timeout innan den provar nästa, och resolv.conf(5) begränsar listan till tre poster. Sätt en resolver på tunnelsidan som 10.8.0.1 högst upp efter att tunneln är borta, och varje uppslagning betalar timeouten innan den faller igenom till en server som svarar. Det är därför symtomet ser ut som en död anslutning och inte som ett DNS-fel: webbläsare blockerar, får tidsutfall och serverar ibland en cachad adress som senare blir inaktuell.

Det förklarar också varför klagomålet kommer som ”internet är trasigt”. En ping mot en IP-adress bevisar att länken är okej, vilket får felet att se ut som applikationens. Resolverlistan är det första man läser och det sista man redigerar.

Myten: resolv.conf är en inställningsfil

Fråga vad sökvägen faktiskt är innan du ändrar den:

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

På en systemd-resolved-värd är den en symbolisk länk till en stub-fil som pekar på 127.0.0.53, och de riktiga servrarna lever i tillståndet per länk som resolvectl skriver ut. På en NetworkManager-värd kan den vara en fil som NetworkManager skriver från den aktiva anslutningen. Hos vissa leverantörsklienter är den en vanlig fil som skrivs om på plats vid anslutning och, om du har otur, aldrig återställs vid frånkoppling. Det är tre olika ägare, och att redigera de två första för hand gör antingen ingenting eller håller till nästa nätverkshändelse.

resolvectl status är vyn som säger sanningen: DNS-servrar per länk, routingdomäner och om tunnellänken fortfarande finns. resolvectl query example.com går längre och visar vilket gränssnitt som svarade. Använd båda innan du rör en fil, och kom ihåg att en webbläsare med egen säker DNS ignorerar allt detta.

Hitta ägaren innan du redigerar något

Tre komponenter tävlar vanligtvis om samma inställning: systemd-resolved, NetworkManager och vad VPN-klienten har installerat. Identifiera den levande först:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Om resolved är aktiv och den symboliska länken pekar på dess stub är den globala filen genererad utdata och din redigering kosmetisk. Om NetworkManager äger anslutningen tillhör servrarna anslutningsprofilen, så åtgärden är en nmcli-egenskapsändring och inte en filredigering. Om en leverantörsdaemon körs överlever bara dess egen återställningsväg nästa anslutning.

Städa upp länkstatusen som klienten lämnade efter sig

En dödad klient kan inte köra sin städhook. SIGKILL går inte att fånga alls, medan SIGINT och SIGTERM går, så en tunnel som ”bara stannade” efter en påtvingad kill lämnar ofta både gränssnittsregistreringen och resolverposten på plats. Hitta den specifika PID:en och skicka signalen bara till den:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Grip inte efter pkill -f vpn eller killall vpn innan du har läst hela träfflistan. -f matchar hela kommandoraden, så den kan avsluta ett omslagsskript, en redigerarsession eller en orelaterad process vars sökväg innehåller strängen. Att avsluta fel process mitt i arbetet är hur ett resolverproblem blir en förlorad fil.

resolvectl revert återställer körtids-DNS-konfigurationen för den länken, vilket är snävare än att starta om resolvern och mycket snävare än att redigera den globala filen. Om tunnellänken är helt borta bygger systemctl restart NetworkManager upp anslutningstillståndet igen, och det är steget som källtrådarna ständigt återvänder till. Se upp för en tjänstehanterare med Restart=always, för den kan sätta tillbaka en dödad klient och dess DNS-inställningar direkt.

Den andra riktningen: pushad DNS som aldrig kom fram

Spegelbilden av den inaktuella posten är en tunnel helt utan användbar resolver. Ett DNS-alternativ i profilen är en begäran; komponenten som hanterar anslutningen måste lämna den till resolvern. Om loggen visar att servern togs emot men tunnellänken inte bär några DNS-inställningar, saknas integrationen, inte servern.

Testa överlämningen genom att göra den manuellt, vilket skiljer ”servern är fel” från ”ingen tillämpade den”:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Routingdomänen som fångar allt skickar varje namn till den länken, vilket en fulltunnelklient vill ha och vilket delad DNS inte får använda. Dessa inställningar försvinner vid nästa anslutning. För att göra dem beständiga i NetworkManager, stäng av automatisk DNS, sätt servern på anslutningen och lägg till domänen:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

För en företagstunnel som bara ska svara på interna namn, lista de zonerna med inledande tilde i stället för att fånga allt, så att publika namn fortsätter använda den lokala resolvern.

Tillfälliga lösningar som blir nästa avbrott

Att kopiera resolv.conf före anslutning och återställa den efteråt är en legitim rad i en runbook, och det är en tillfällig lösning och inte en reparation. Den misslyckas precis när det gäller, eftersom en krasch eller en påtvingad omstart hoppar över återställningen. Skriv ned det som en tillfällig lösning så att nästa person inte bygger vidare på den.

Att stänga av systemd-resolved och hårdkoda publika servrar är det andra populära draget. Det gör anslutning och frånkoppling förutsägbara och tar bort DNS per länk för alla andra nätverk, vilket förstör delad DNS för interna namn och omintetgör syftet med en tunnel som ska hålla frågorna innanför. Att installera resolvconf och fästa publika servrar kostar detsamma med ett extra lager. Behandla vilken som helst av dem som en diagnos: om den återställer surfandet har du lärt dig att resolverintegrationen är skyldig, inte att de publika servrarna är korrekta.

Den hållbara åtgärden är en ägare per lager: bestäm vilken komponent som äger tunnellänkens DNS och vilken som äger den globala standarden, skriv ned det och ta bort de andra från vägen. Verifiera sedan efter en frånkoppling med ett namn som bara VPN:en löser. Om ett privat namn fortfarande svarar togs registreringen inte bort; om inget löses pekar filen på en server som inte längre finns. Båda syns i resolvectl innan du öppnar en webbläsare.