OpenVPN-DNS blir liggjande etter SIGKILL: sjekk eigaren først

DNS sluttar å slå opp etter at ein OpenVPN-klient er drepen, og den første innskota er å skrive om /etc/resolv.conf. Den endringa kan øydeleggje ein fungerande resolver medan den eigentlege utdaterte tilstanden ligg ein annan stad. Spørsmålet som må avgjerast først, er kven som eig DNS-innstillingane tunnelen installerte, og om avsluttinga som hoppa over oppryddinga faktisk betydde noko.

Tre vilkår avgjer reparasjonen: signalet som avslutta prosessen, resolverkomponenten som tok imot innstillingane, og om tunnellenka framleis finst. Svar på dei i den rekkjefølgja, og rettinga følgjer vanlegvis utan å røre ei global fil.

Avgjer kva slag avslutting som skjedde

I Community-utgåva av OpenVPN er både SIGINT og SIGTERM førespurnader om ei ryddig avslutting. SIGKILL kan ikkje fangast: det kan korkje blokkerast eller handterast, så ingen nedstengingsrutine får sjanse til å køyre. Ein vanleg Ctrl+C i ein terminal i framgrunnen genererer SIGINT, medan ein overvakar som gjev opp å vente, vanlegvis eskalerer til SIGKILL. Skilnaden betyr noko fordi berre det andre tilfellet garanterer at krokane vart hoppa over.

Det endrar ikkje kva signal Ctrl+C sender, å køyre inne i screen eller tmux. Sjekk kva prosessen faktisk tok imot, ikkje kva terminalen vanlegvis gjer.

Når ein teneste eller tilkoplingshandsamar køyrer tunnelen, stopp den eine tilkoplinga gjennom eigaren i staden for å drepe pid-en. Ein handsamar kan starte prosessen att og late deg sitje att med ein ny tunnel og ein forvirrande resolvertilstand. Ein frittståande prosess treng berre ei vanleg avsluttingsførespurnad for at oppryddinga skal køyre.

Avgjer kven som eig resolveren

systemd-resolved, eit skript i resolvconf-stil og ei enkel filskriving er tre ulike eigarar. Den første held innstillingar per lenke i minnet og slepp dei når grensesnittet forsvinn. Den andre held postar som varer til noko fjernar dei. Den tredje skriv ei fil og overlèt gjenopprettinga til den som skreiv ho.

Identifiser eigaren før du vel ein reparasjonskommando. Det same symptomet har tre ulike riktige svar avhengig av kva som er i bruk.

Ein VPN som NetworkManager styrer, kan alt eige resolverendringane. Legg du til ein andre hjelpar på toppen, får du to eigarar som konkurrerer om same lenke, og tilstanden til taparen dukkar opp att ved neste gjenoppkopling. Viss ein handsamar har ansvaret, rett innstillinga i handsamaren i staden for i eit skript.

Kva down-kroken kan og ikkje kan

Skriptet down køyrer éin gong etter at TUN/TAP-eininga er lukka. Å leggje til down-pre snur den rekkjefølgja og køyrer skriptet medan eininga framleis finst, noko hjelparar som treng den levande lenka krev.

Ingen av direktiva får ein krok til å køyre etter SIGKILL. Privilegium vert heller ikkje gjenoppretta av down-pre: viss daemonen går ned til ein user eller group eller går inn i ein chroot, køyrer kroken med den tilgangen det lèt etter. Ein kalla krok kan framleis mislykkast med å oppdatere resolveren. OpenVPN-referansen dekkjer signala og livssyklusen til tilbakekallet.

Sjekk eigen feil i kroken ved sida av avslutningsstatusen til prosessen. Manglande opprydding og mislykka opprydding ser like ut i resolveren og ulike ut i loggane.

Sjekk tilstanden som faktisk er att

På eit system som brukar systemd-resolved, viser resolvectl status kva lenke som framleis ber DNS-tenarane eller rutingsdomena til VPN-en. Den lenka kan høyre til ei tilkopling som er borte, eller til ein annan tunnel som framleis er oppe.

Eit grensesnitt som forsvinn tek med seg konfigurasjonen per lenke, så ein overhoppa krok kan samstundes finnast med rein DNS. Viss lenka framleis er registrert og berre vert eigd av den stoppa tilkoplinga, bør handsamaren som eig ho, fjerne ho. Viss eit eldre skript skreiv om ei global resolverfil, leit i staden etter det dokumenterte gjenopprettingsteget til det skriptet.

Gjenopprett utan å stele ei anna lenke

Når innstillingar per lenke er ditt ansvar å styre, resolvectl revert tek lenkenamnet og tømmer køyretids-DNS-konfigurasjonen for grensesnittet. Det er ei køyretidshandling og ikkje ei profilendring, så den varige tilkoplingskonfigurasjonen held seg urørt. Nemner du feil lenke, tømmer du DNS for ein fungerande tunnel, og difor kjem namnet frå statusutskrifta.

Stadfest at /etc/resolv.conf er ei administrert symbolsk lenke før du redigerer ho, og stopp deretter klienten normalt éin gong til og sjå på DNS att. Viss den andre stoppen ryddar opp, var det tidlegare problemet den tvinga avsluttinga og ikkje konfigurasjonen.