OpenVPN se DNS agtergelaat ná SIGKILL: kyk eerste na die eienaar

DNS hou op met oplos nadat 'n OpenVPN-kliënt doodgemaak is, en die eerste instink is om /etc/resolv.conf. Daardie wysiging kan 'n werkende resolver breek terwyl die werklike verouderde toestand elders sit. Die vraag om eerste uit te klaar is wie die DNS-instellings besit wat die tonnel geïnstalleer het, en of die afsluiting wat die opruiming oorgeslaan het, werklik saak gemaak het.

Drie toestande bepaal die herstel: die sein wat die proses beëindig het, die resolver-komponent wat die instellings ontvang het, en of die tonnelskakel nog bestaan. Beantwoord hulle in daardie volgorde en die regstelling volg gewoonlik sonder om 'n globale lêer aan te raak.

Besluit watter soort afsluiting plaasgevind het

In Community OpenVPN, is SIGINT en SIGTERM albei grasieuse afsluitversoeke. SIGKILL kan nie gevang word nie: dit kan nie geblokkeer of hanteer word nie, so geen afsluitroetine kry 'n kans om te loop nie. 'n Normale Ctrl+C in 'n voorgrondterminale genereer SIGINT, terwyl 'n supervisor wat ophou wag gewoonlik na SIGKILL eskaleer. Die verskil maak saak omdat slegs die tweede geval waarborg dat die hake oorgeslaan is.

Om binne screen of tmux te loop verander nie watter sein Ctrl+C stuur nie. Kyk wat die proses werklik ontvang het eerder as wat die terminale gewoonlik doen.

Wanneer 'n diens of verbindingsbestuurder die tonnel laat loop, stop daardie een verbinding deur sy eienaar eerder as om die pid dood te maak. 'n Bestuurder kan die proses weer opbring, wat jou met 'n nuwe tonnel en verwarrende resolver-toestand laat. 'n Selfstandige proses benodig net 'n gewone beëindigingsversoek sodat die opruiming loop.

Besluit wie die resolver besit

systemd-resolved, 'n skrip in resolvconf-styl en 'n gewone lêer-herwysing is drie verskillende eienaars. Die eerste hou instellings per skakel in die geheue en laat dit val wanneer die koppelvlak verdwyn. Die tweede hou rekords wat bly staan tot iets hulle verwyder. Die derde skryf 'n lêer en laat die herstel aan wie dit ook al geskryf het.

Identifiseer die eienaar voordat jy 'n herstelopdrag kies. Dieselfde simptoom het drie verskillende korrekte antwoorde, afhangend van watter een in gebruik is.

'n NetworkManager-bestuurde VPN mag reeds resolver-veranderinge besit. Om 'n tweede helper bo-op te voeg skep twee eienaars wat om dieselfde skakel meeding, en die verloorder se toestand verskyn weer by die volgende herverbinding. As 'n bestuurder in beheer is, maak die instelling in die bestuurder reg eerder as in 'n skrip.

Wat die down-haak kan doen en nie kan doen nie

Die down script loop nadat die TUN/TAP-toestel gesluit het. Om down-pre by te voeg draai daardie volgorde om en laat die script loop terwyl die toestel nog bestaan, wat helpers nodig het wat die lewendige skakel vereis.

Nie een van die riglyne laat 'n haak ná SIGKILL loop nie. Voorregte word ook nie deur down-pre herstel nie: as die daemon na 'n user of group val of 'n chroot binnegaan, loop die haak met watter toegang dit ook al oorlaat. 'n Opgeroepe haak kan steeds faal om die resolver op te dateer. Die OpenVPN-verwysing dek die seine en die callback-lewensiklus.

Kyk na die haak se eie fout langs die proses se uitgangstatus. 'n Ontbrekende opruiming en 'n mislukte opruiming lyk dieselfde in die resolver en verskillend in die logs.

Kyk na die toestand wat werklik oorbly

Op 'n stelsel wat systemd-resolved gebruik, resolvectl status wys watter skakel nog die VPN se DNS-bediener of routeringsdomeine dra. Daardie skakel kan aan 'n verbinding behoort wat weg is, of aan 'n ander tonnel wat nog op is.

'n Koppelvlak wat verdwyn neem sy konfigurasie per skakel saam, so 'n oorgeslaande haak kan saam met skoon DNS bestaan. As die skakel nog geregistreer is en uitsluitlik deur die gestopte verbinding besit word, behoort die bestuurder wat dit besit dit te verwyder. As 'n ouer skrip 'n globale resolver-lêer herskryf het, soek eerder daardie skrip se gedokumenteerde herstelstap.

Herstel sonder om 'n ander skakel te steel

Wanneer instellings per skakel joune is om te bestuur, resolvectl revert neem die skakelnaam en wis die looptyd-DNS-konfigurasie vir daardie koppelvlak. Dit is 'n looptyd-aksie eerder as 'n profielwysiging, so die blywende verbindingskonfigurasie bly onaangeraak. Noem die verkeerde skakel en jy wis DNS vir 'n werkende tonnel, daarom kom die naam uit die status-uitset.

Bevestig dat /etc/resolv.conf 'n bestuurde simskakel is voordat jy dit wysig, stop dan die kliënt nog een keer normaal en kyk weer na DNS. As die tweede stop opruim, was die vroeëre probleem die gedwonge afsluiting eerder as die konfigurasie.