Naiiwan ang DNS ng OpenVPN pagkatapos ng SIGKILL: suriin muna ang may-ari

Humihinto ang DNS sa paglutas pagkatapos patayin ang isang OpenVPN client, at ang unang instinct ay muling isulat ang /etc/resolv.conf. Maaaring masira ng pagbabagong iyon ang gumaganang resolver habang ang tunay na lumang estado ay nasa ibang lugar. Ang unang dapat linawin ay kung sino ang may-ari ng mga setting ng DNS na inilagay ng tunnel, at kung may tunay na halaga ang paglabas na lumaktaw sa paglilinis.

Tatlong kondisyon ang nagpapasya sa pag-aayos: ang senyas na nagtapos sa proseso, ang bahagi ng resolver na tumanggap ng mga setting, at kung umiiral pa ang link ng tunnel. Sagutin ang mga ito sa ganoong pagkakasunod-sunod at karaniwang dumarating ang pagwawasto nang hindi hinahawakan ang isang pandaigdigang file.

Magpasya kung anong uri ng paglabas ang nangyari

Sa edisyong Community ng OpenVPN, parehong SIGINT at SIGTERM ay mga hiling ng maayos na paglabas. Hindi mahuli ang SIGKILL: hindi ito maaaring harangan o pangasiwaan, kaya walang rutina ng pagsasara ang nakakakuha ng pagkakataong tumakbo. Ang normal na Ctrl+C sa terminal sa harapan ay gumagawa ng SIGINT, habang ang supervisor na tumitigil sa paghihintay ay karaniwang umaakyat sa SIGKILL. Mahalaga ang pagkakaiba dahil tanging ang ikalawang kaso ang nagsisiguro na nalaktawan ang mga hook.

Ang pagtakbo sa loob ng screen o tmux ay hindi nagbabago kung anong senyas ang ipinapadala ng Ctrl+C. Suriin kung ano talaga ang natanggap ng proseso, hindi kung ano ang karaniwang ginagawa ng terminal.

Kapag isang serbisyo o manager ng koneksyon ang nagpapatakbo ng tunnel, itigil ang isang koneksyong iyon sa pamamagitan ng may-ari nito sa halip na patayin ang pid. Maaaring muling itaas ng manager ang proseso, na nag-iiwan sa iyo ng bagong tunnel at nakalilitong estado ng resolver. Ang standalone na proseso ay kailangan lamang ng ordinaryong hiling ng pagtatapos para tumakbo ang paglilinis.

Magpasya kung sino ang may-ari ng resolver

systemd-resolved, isang script na istilong resolvconf at simpleng muling pagsulat ng file ay tatlong magkakaibang may-ari. Ang una ay nagtatago ng mga setting bawat link sa memorya at itinatapon ang mga ito kapag nawala ang interface. Ang ikalawa ay nagtatago ng mga rekord na nananatili hanggang may mag-alis sa mga ito. Ang ikatlo ay nagsusulat ng file at iniiwan ang pagpapanumbalik sa sinumang sumulat nito.

Tukuyin ang may-ari bago pumili ng utos sa pag-aayos. Ang parehong sintomas ay may tatlong magkakaibang tamang sagot depende sa kung alin ang ginagamit.

Ang VPN na pinamamahalaan ng NetworkManager ay maaaring may-ari na ng mga pagbabago sa resolver. Ang pagdaragdag ng ikalawang katulong sa ibabaw nito ay lumilikha ng dalawang may-ari na nag-aagawan sa parehong link, at ang estado ng natalo ay muling lumilitaw sa susunod na muling pagkonekta. Kung isang manager ang may pananagutan, ayusin ang setting sa manager at hindi sa isang script.

Ano ang kaya at hindi kaya ng down hook

Ang script na down ay tumatakbo isang beses pagkatapos maisara ang TUN/TAP device. Ang pagdaragdag ng down-pre ay binabaligtad ang pagkakasunod-sunod na iyon at pinapatakbo ang script habang umiiral pa ang device, na kinakailangan ng mga katulong na nangangailangan ng buhay na link.

Walang direktiba ang nagpapataas ng hook pagkatapos ng SIGKILL. Ang mga pribilehiyo ay hindi rin naipapanumbalik ng down-pre: kung bumaba ang daemon sa isang user o group o pumasok sa isang chroot, tatakbo ang hook sa anumang access na iniiwan nito. Ang tinawag na hook ay maaari pa ring mabigo sa pag-update ng resolver. Ang reperensya ng OpenVPN ay sumasaklaw sa mga senyas at siklo ng buhay ng callback.

Suriin ang sariling error ng hook sa tabi ng exit status ng proseso. Ang nawawalang paglilinis at nabigong paglilinis ay magkamukha sa resolver at magkaiba sa mga log.

Suriin ang estadong talagang natitira

Sa isang sistemang gumagamit ng systemd-resolved, resolvectl status ipinapakita kung aling link ang nagdadala pa rin ng mga DNS server ng VPN o mga routing domain. Ang link na iyon ay maaaring pagmamay-ari ng koneksyong wala na, o ng ibang tunnel na nakataas pa.

Ang interface na nawawala ay nagdadala ng konfigurasyon nito bawat link, kaya ang nalaktawang hook ay maaaring mabuhay kasama ng malinis na DNS. Kung ang link ay nakarehistro pa at eksklusibong pagmamay-ari ng itinigil na koneksyon, dapat itong alisin ng manager na may-ari. Kung may lumang script na muling sumulat ng pandaigdigang file ng resolver, hanapin sa halip ang dokumentadong hakbang sa pagpapanumbalik ng script na iyon.

Bumangon nang hindi nagnanakaw ng ibang link

Kapag ang mga setting bawat link ay responsibilidad mong pamahalaan, resolvectl revert kinukuha nito ang pangalan ng link at nililinis ang runtime DNS configuration para sa interface na iyon. Ito ay aksyon sa runtime at hindi pag-edit ng profile, kaya ang permanenteng konfigurasyon ng koneksyon ay nananatiling hindi nagalaw. Pangalanan ang maling link at nililinis mo ang DNS ng gumaganang tunnel, kaya galing sa output ng status ang pangalan.

Bago i-edit, kumpirmahin na ang /etc/resolv.conf ay isang pinamamahalaang symbolic link, pagkatapos ay itigil muli ang client nang normal at tingnan muli ang DNS. Kung nalilinis ng ikalawang paghinto, ang naunang problema ay ang sapilitang paglabas at hindi ang konfigurasyon.