OpenVPN-DNS ligger kvar efter SIGKILL: kontrollera ägaren först

DNS slutar lösa upp namn efter att en OpenVPN-klient dödats, och den första instinkten är att skriva om /etc/resolv.conf. Den ändringen kan förstöra en fungerande resolver medan det egentliga inaktuella tillståndet finns någon annanstans. Frågan som måste avgöras först är vem som äger de DNS-inställningar tunneln installerade, och om avslutningen som hoppade över städningen faktiskt spelade roll.

Tre villkor avgör reparationen: signalen som avslutade processen, resolverkomponenten som tog emot inställningarna, och om tunnellänken fortfarande finns. Svara i den ordningen och rättelsen följer vanligtvis utan att röra en global fil.

Avgör vilken typ av avslutning som skedde

I Community-utgåvan av OpenVPN är både SIGINT och SIGTERM begäranden om en kontrollerad avslutning. SIGKILL går inte att fånga: det kan varken blockeras eller hanteras, så ingen avstängningsrutin får chansen att köras. Ett vanligt Ctrl+C i en terminal i förgrunden genererar SIGINT, medan en övervakare som ger upp väntandet vanligtvis eskalerar till SIGKILL. Skillnaden spelar roll eftersom bara det andra fallet garanterar att krokarna hoppades över.

Det ändrar inte vilken signal Ctrl+C skickar att köra inne i screen eller tmux. Kontrollera vad processen faktiskt tog emot, inte vad terminalen brukar göra.

När en tjänst eller anslutningshanterare kör tunneln, stoppa den anslutningen via dess ägare istället för att döda pid. En hanterare kan starta processen igen och lämna dig med en ny tunnel och ett förvirrande resolvertillstånd. En fristående process behöver bara en vanlig avslutningsbegäran för att städningen ska köras.

Avgör vem som äger resolvern

systemd-resolved, ett skript i resolvconf-stil och en enkel filöverskrivning är tre olika ägare. Den första håller inställningar per länk i minnet och släpper dem när gränssnittet försvinner. Den andra håller poster som består tills något tar bort dem. Den tredje skriver en fil och lämnar återställningen till den som skrev den.

Identifiera ägaren innan du väljer ett reparationskommando. Samma symptom har tre olika korrekta svar beroende på vilken som används.

En VPN som hanteras av NetworkManager kan redan äga resolverändringarna. Lägger du till ytterligare en hjälpare ovanpå skapas två ägare som konkurrerar om samma länk, och förlorarens tillstånd dyker upp igen vid nästa återanslutning. Om en hanterare ansvarar, rätta inställningen i hanteraren och inte i ett skript.

Vad down-kroken kan och inte kan göra

Skriptet down körs en gång efter att TUN/TAP-enheten har stängts. Att lägga till down-pre vänder på den ordningen och kör skriptet medan enheten fortfarande finns, vilket hjälpare som behöver den levande länken kräver.

Ingen av direktiven får en krok att köras efter SIGKILL. Behörigheter återställs inte heller av down-pre: om daemonen sjunker till en user eller group eller går in i en chroot, körs kroken med den åtkomst det lämnar. En anropad krok kan fortfarande misslyckas med att uppdatera resolvern. OpenVPN-referensen täcker signalerna och livscykeln för återanropet.

Kontrollera krokens eget fel bredvid processens slutstatus. Saknad städning och misslyckad städning ser likadana ut i resolvern och olika ut i loggarna.

Kontrollera tillståndet som verkligen finns kvar

På ett system som använder systemd-resolved visar resolvectl status vilken länk som fortfarande bär VPN:ens DNS-servrar eller routingdomäner. Den länken kan tillhöra en anslutning som är borta, eller en annan tunnel som fortfarande är uppe.

Ett gränssnitt som försvinner tar med sig sin konfiguration per länk, så en överhoppad krok kan samexistera med ren DNS. Om länken fortfarande är registrerad och uteslutande ägs av den stoppade anslutningen, bör hanteraren som äger den ta bort den. Om ett äldre skript skrev om en global resolverfil, leta i stället efter det skriptets dokumenterade återställningssteg.

Återställ utan att stjäla en annan länk

När inställningar per länk är ditt ansvar att hantera, resolvectl revert tar länknamnet och rensar körtids-DNS-konfigurationen för det gränssnittet. Det är en körtidshandling och inte en profiländring, så den bestående anslutningskonfigurationen förblir orörd. Namnger du fel länk rensar du DNS för en fungerande tunnel, därför kommer namnet från statusutskriften.

Bekräfta att /etc/resolv.conf är en hanterad symbolisk länk innan du redigerar den, stoppa sedan klienten normalt en gång till och titta på DNS igen. Om det andra stoppet städar upp var det tidigare problemet det påtvingade avslutet och inte konfigurationen.