DNS de OpenVPN restas post SIGKILL: unue kontrolu la posedanton

DNS ĉesas solvi post kiam OpenVPN-kliento estas mortigita, kaj la unua instinkto estas reskribi /etc/resolv.conf. Tiu ŝanĝo povas rompi funkciantan solvilon dum la vera kaduka stato sidas aliloke. La demando unue solvenda estas, kiu posedas la DNS-agordojn, kiujn la tunelo instalis, kaj ĉu la eliro, kiu preterlasis la purigadon, vere gravis.

Tri kondiĉoj decidas la riparon: la signalo, kiu finis la procezon, la solvila komponento, kiu ricevis la agordojn, kaj ĉu la tunela ligilo ankoraŭ ekzistas. Respondu ilin laŭ tiu ordo kaj la korekto kutime sekvas sen tuŝi tutmondan dosieron.

Decidu, kia speco de eliro okazis

En la Community-eldono de OpenVPN, kaj SIGINT kaj SIGTERM estas petoj pri milda eliro. SIGKILL ne estas kaptebla: ĝi ne povas esti blokita nek traktita, do neniu elŝalta rutino ricevas ŝancon ruliĝi. Ordinara Ctrl+C en antaŭfona terminalo generas SIGINT, dum kontrolanto, kiu ĉesas atendi, kutime plialtiĝas al SIGKILL. La diferenco gravas ĉar nur la dua kazo garantias, ke la hokoj estis preterlasitaj.

Ruli ene de screen aŭ tmux ne ŝanĝas, kiun signalon Ctrl+C sendas. Kontrolu, kion la procezo efektive ricevis, anstataŭ kion la terminalo kutime faras.

Kiam servo aŭ konekta administranto rulas la tunelon, haltigu tiun unu konekton per ĝia posedanto anstataŭ mortigi la pid. Administranto povas relevi la procezon, lasante al vi freŝan tunelon kaj konfuzan solvilan staton. Memstara procezo bezonas nur ordinaran haltigan peton, por ke la purigado ruliĝu.

Decidu, kiu posedas la solvilon

systemd-resolved, skripto laŭ stilo resolvconf kaj simpla dosiera reskribo estas tri malsamaj posedantoj. La unua tenas agordojn po ligilo en la memoro kaj forĵetas ilin kiam la interfaco malaperas. La dua tenas rikordojn, kiuj restas ĝis io forigas ilin. La tria skribas dosieron kaj lasas la restarigon al tiu, kiu ĝin skribis.

Identigu la posedanton antaŭ ol elekti riparan komandon. La sama simptomo havas tri malsamajn ĝustajn respondojn laŭ tio, kiu estas uzata.

VPN administrata de NetworkManager eble jam posedas solvilajn ŝanĝojn. Aldoni duan helpanton supre kreas du posedantojn konkurencantajn pri la sama ligilo, kaj la stato de la malgajninto reaperas ĉe la sekva rekonekto. Se administranto respondecas, riparu la agordon en la administranto anstataŭ en skripto.

Kion la down-hoko povas kaj ne povas fari

La skripto down ruliĝas unufoje post kiam la TUN/TAP-aparato fermiĝis. Aldoni down-pre renversas tiun ordon kaj rulas la skripton dum la aparato ankoraŭ ekzistas, kion postulas helpantoj, kiuj bezonas la vivan ligilon.

Neniu el la du direktivoj igas hokon ruliĝi post SIGKILL. Privilegioj ankaŭ ne restariĝas per down-pre: se la demono falas al user aŭ group aŭ eniras chroot, la hoko ruliĝas kun kia ajn aliro tio lasas al ĝi. Alvokita hoko tamen povas malsukcesi ĝisdatigi la solvilon. La OpenVPN-referenco kovras la signalojn kaj la vivciklon de la retrovoĉo.

Kontrolu la propran eraron de la hoko apud la elira statuso de la procezo. Mankanta purigado kaj malsukcesinta purigado aspektas same en la solvilo kaj malsame en la protokoloj.

Kontrolu la staton, kiu efektive restas

Sur sistemo uzanta systemd-resolved, resolvectl status montras, kiu ligilo ankoraŭ portas la DNS-servilojn aŭ enkursigajn domajnojn de la VPN. Tiu ligilo povas aparteni al konekto, kiu foriris, aŭ al alia tunelo, kiu ankoraŭ staras.

Interfaco, kiu malaperas, kunportas sian agordon po ligilo, do preterlasita hoko povas kunekzisti kun pura DNS. Se la ligilo ankoraŭ estas registrita kaj posedata ekskluzive de la haltigita konekto, la posedanta administranto devus forigi ĝin. Se pli malnova skripto reskribis tutmondan solvilan dosieron, serĉu anstataŭe la dokumentitan restarigan paŝon de tiu skripto.

Restarigu sen ŝteli alian ligilon

Kiam agordoj po ligilo estas viaj por administri, resolvectl revert prenas la ligilan nomon kaj viŝas la rultempan DNS-agordon por tiu interfaco. Ĝi estas rultempa ago, ne profila redakto, do la daŭra konekta agordo restas netuŝita. Nomu la malĝustan ligilon kaj vi viŝos la DNS-on de funkcianta tunelo, tial la nomo venas el la statusa eligo.

Konfirmu, ke /etc/resolv.conf estas administrata simbola ligilo antaŭ ol redakti ĝin, poste haltigu la klienton normale ankoraŭfoje kaj rigardu la DNS-on denove. Se la dua halto purigas, la pli frua problemo estis la devigita eliro, ne la agordo.