OpenVPN-DNS blijft achter na SIGKILL: controleer eerst de eigenaar

DNS stopt met resolven nadat een OpenVPN-client is gedood, en de eerste reflex is om /etc/resolv.conf te herschrijven. Die wijziging kan een werkende resolver breken terwijl de echte verouderde toestand ergens anders zit. De vraag die eerst moet worden beslecht is wie de DNS-instellingen bezit die de tunnel heeft geïnstalleerd, en of de afsluiting die de opruiming oversloeg echt uitmaakte.

Drie voorwaarden bepalen de reparatie: het signaal dat het proces beëindigde, het resolveronderdeel dat de instellingen ontving, en of de tunnelkoppeling nog bestaat. Beantwoord ze in die volgorde en de correctie volgt meestal zonder een globaal bestand aan te raken.

Bepaal wat voor afsluiting er is gebeurd

In de Community-editie van OpenVPN zijn zowel SIGINT als SIGTERM verzoeken om netjes af te sluiten. SIGKILL is niet te vangen: het kan niet worden geblokkeerd of afgehandeld, dus geen enkele afsluitroutine krijgt de kans om te draaien. Een normale Ctrl+C in een terminal op de voorgrond genereert SIGINT, terwijl een supervisor die opgeeft met wachten meestal escaleert naar SIGKILL. Het verschil is belangrijk omdat alleen het tweede geval garandeert dat de hooks werden overgeslagen.

Draaien in screen of tmux verandert niet welk signaal Ctrl+C stuurt. Controleer wat het proces werkelijk heeft ontvangen, niet wat de terminal normaal doet.

Wanneer een service of verbindingsbeheerder de tunnel draait, stop dan die ene verbinding via de eigenaar in plaats van de pid te doden. Een beheerder kan het proces weer opstarten, waardoor je een nieuwe tunnel en een verwarrende resolverstatus overhoudt. Een losstaand proces heeft alleen een gewoon beëindigingsverzoek nodig om de opruiming te laten draaien.

Bepaal wie de resolver bezit

systemd-resolved, een script in resolvconf-stijl en een simpele bestandsherschrijving zijn drie verschillende eigenaren. De eerste houdt instellingen per koppeling in het geheugen en laat ze vallen wanneer de interface verdwijnt. De tweede houdt records die blijven tot iets ze verwijdert. De derde schrijft een bestand en laat het herstel aan wie het heeft geschreven.

Identificeer de eigenaar voordat je een reparatiecommando kiest. Hetzelfde symptoom heeft drie verschillende juiste antwoorden, afhankelijk van welke in gebruik is.

Een door NetworkManager beheerde VPN bezit mogelijk al de resolverbewijzigingen. Een tweede helper erbovenop maakt twee eigenaren die om dezelfde koppeling concurreren, en de toestand van de verliezer duikt bij de volgende herverbinding weer op. Als een beheerder de baas is, herstel de instelling dan in de beheerder en niet in een script.

Wat de down-hook wel en niet kan

Het script down draait één keer nadat het TUN/TAP-apparaat is gesloten. Toevoegen van down-pre keert die volgorde om en draait het script terwijl het apparaat nog bestaat, wat helpers vereisen die de levende koppeling nodig hebben.

Geen van beide richtlijnen zorgt ervoor dat een hook na SIGKILL draait. Privileges worden ook niet hersteld door down-pre: als de daemon naar een user of group zakt of een chroot binnengaat, draait de hook met de toegang die dat hem laat. Een aangeroepen hook kan nog steeds mislukken om de resolver bij te werken. De OpenVPN-referentie behandelt de signalen en de callback-levenscyclus.

Controleer de eigen fout van de hook naast de exitstatus van het proces. Ontbrekende opruiming en mislukte opruiming zien er in de resolver hetzelfde uit en in de logs anders.

Controleer de toestand die werkelijk overblijft

Op een systeem met systemd-resolved laat resolvectl status zien welke koppeling nog de DNS-servers of routeringsdomeinen van de VPN draagt. Die koppeling kan bij een verbinding horen die weg is, of bij een andere tunnel die nog actief is.

Een interface die verdwijnt neemt zijn configuratie per koppeling mee, dus een overgeslagen hook kan naast schone DNS bestaan. Als de koppeling nog geregistreerd is en uitsluitend eigendom is van de gestopte verbinding, zou de beherende beheerder hem moeten verwijderen. Als een ouder script een globaal resolverbestand heeft herschreven, zoek dan in plaats daarvan de gedocumenteerde herstelstap van dat script.

Herstel zonder een andere koppeling te stelen

Wanneer instellingen per koppeling jouw verantwoordelijkheid zijn, resolvectl revert neemt de koppelingsnaam en wist de runtime-DNS-configuratie voor die interface. Het is een runtime-actie en geen profielwijziging, dus de blijvende verbindingsconfiguratie blijft onaangeroerd. Noem je de verkeerde koppeling, dan wist je DNS voor een werkende tunnel, daarom komt de naam uit de statusuitvoer.

Bevestig dat /etc/resolv.conf een beheerde symbolische koppeling is voordat je die bewerkt, stop de client daarna nog één keer normaal en kijk opnieuw naar DNS. Als de tweede stop opruimt, was het eerdere probleem de geforceerde afsluiting en niet de configuratie.