OpenVPN-DNS bliuwt efter SIGKILL: kontrolearje earst de eigner

DNS hâldt op mei oplossen neidat in OpenVPN-klant deade is, en it earste ynstinkt is om /etc/resolv.conf oer te skriuwen. Dy wiziging kin in wurkjende resolver brekke wylst de echte ferâldere tastân earne oars sit. De fraach dy't earst besljochte wurde moat, is wa't de DNS-ynstellingen besit dy't de tunnel ynstallearre, en oft de útgong dy't de opromming oersloech echt fan belang wie.

Trije betingsten bepale de reparaasje: it sinjaal dat it proses einige, it resolver-ûnderdiel dat de ynstellingen krige, en oft de tunnelkeppeling noch bestiet. Beäntwurdzje se yn dy folchoarder en de reparaasje folget meastentiids sûnder in globaal bestân oan te reitsjen.

Bepale hokker soarte útgong bard is

Yn 'e Community-edysje fan OpenVPN binne sawol SIGINT as SIGTERM fersiken om rêstich út te gean. SIGKILL is net te fangen: it kin net blokkearre of behannele wurde, dus gjin ôfsluitroutine krijt de kâns om te draaien. In normale Ctrl+C yn in terminal op 'e foargrûn generearret SIGINT, wylst in tafersjochhâlder dy't ophâldt mei wachtsjen meastentiids eskalearret nei SIGKILL. It ferskil makket út, om't allinnich it twadde gefal garandearret dat de heakken oerslein binne.

Draaie yn screen of tmux feroaret net hokker sinjaal Ctrl+C stjoert. Kontrolearje wat it proses echt ûntfongen hat, net wat de terminal normaal docht.

As in tsjinst of ferbiningsbehearder de tunnel draait, stopje dan dy iene ferbining fia har eigner ynstee fan de pid te deadzjen. In behearder kin it proses wer omheech bringe, wêrtroch't jo mei in nije tunnel en in betiizjende resolver-tastân sitte. In selsstannich proses hat allinnich in gewoan stopfersyk nedich om de opromming draaie te litten.

Bepale wa't de resolver besit

systemd-resolved, in skript yn resolvconf-styl en in gewoane bestânsoerskriuwing binne trije ferskillende eigners. De earste hâldt ynstellingen per keppeling yn it ûnthâld en smyt se weil as de ynterface ferdwynt. De twadde hâldt records dy't bliuwe oant eat se fuorthellet. De tredde skriuwt in bestân en lit it werombringen oan wa't it skreaun hat.

Identifisearje de eigner foardat jo in reparaasjekommando kieze. Deselde symptoom hat trije ferskillende goede antwurden ôfhinklik fan hokker brûkt wurdt.

In VPN beheard troch NetworkManager kin al eigner wêze fan resolver-wizigings. In twadde helper der boppeop tafoegje skept twa eigners dy't om deselde keppeling stride, en de tastân fan 'e ferliezer komt by de folgjende werferbining wer foar 't ljocht. As in behearder de baas is, reparearje de ynstelling dan yn 'e behearder yn stee fan yn in skript.

Wat de down-heak wol en net kin

It skript down draait ien kear neidat it TUN/TAP-apparaat sletten is. It tafoegjen fan down-pre draait dy folchoarder om en draait it skript wylst it apparaat noch bestiet, wat helpers nedich hawwe dy't de libbene keppeling brûke moatte.

Gjin fan beide rjochtlinen lit in heak nei SIGKILL draaie. Foarrjochten wurde ek net werombrocht troch down-pre: as de daemon sakket nei in user of group of in chroot yn giet, draait de heak mei de tagong dy't dat him lit. In oanroppen heak kin dochs misse om de resolver te fernijen. De OpenVPN-referinsje beslacht de sinjalen en de libbenssyklus fan 'e callback.

Kontrolearje de eigen flater fan 'e heak njonken de útgongstatus fan it proses. In ûntbrekkende opromming en in mislearre opromming lykje itselde yn 'e resolver en oars yn 'e logboeken.

Kontrolearje de tastân dy't echt oerbliuwt

Op in systeem dat systemd-resolved brûkt, lit resolvectl status sjen hokker keppeling noch de DNS-tsjinners of routingdomeinen fan 'e VPN draacht. Dy keppeling kin by in ferbining hearre dy't fuort is, of by in oare tunnel dy't noch oer ein is.

In ynterface dy't ferdwynt nimt syn konfiguraasje per keppeling mei, sadat in oersleine heak njonken skjinne DNS bestean kin. As de keppeling noch registrearre is en allinnich eigendom is fan 'e stoppe ferbining, soe de behearder dy't der eigner fan is it fuorthelje moatte. As in âlder skript in globaal resolverbestân oerskreaun hat, sykje dan ynstee it dokumintearre werombringsstap fan dat skript.

Werombringe sûnder in oare keppeling te stellen

As ynstellingen per keppeling fan jo binne om te behearen, resolvectl revert nimt de keppelingsnamme en wisket de runtime-DNS-konfiguraasje foar dy ynterface. It is in runtime-aksje en gjin profylbewurking, dus de bliuwende ferbiningskonfiguraasje bliuwt ûnoantaaste. Neam de ferkearde keppeling en jo wiskje de DNS fan in wurkjende tunnel, dêrom komt de namme út 'e statusútfier.

Befêstigje dat /etc/resolv.conf in beheard symboalyske keppeling is foardat jo it bewurkje, stopje dêrnei de klant noch ien kear normaal en sjoch wer nei DNS. As de twadde stop oprommet, wie it eardere probleem de twongen útgong en net de konfiguraasje.