OpenVPN DNS paliek pēc SIGKILL: vispirms pārbaudiet īpašnieku

DNS pārstāj atrisināt pēc tam, kad OpenVPN klients tiek nogalināts, un pirmā instinktīvā reakcija ir pārrakstīt /etc/resolv.conf. Šī izmaiņa var salauzt strādājošu atrisinātāju, kamēr īstais novecojušais stāvoklis atrodas citur. Vispirms jāizlemj jautājums, kam pieder tunela uzstādītie DNS iestatījumi, un vai izeja, kas izlaida tīrīšanu, patiešām bija svarīga.

Trīs nosacījumi nosaka labošanu: signāls, kas beidza procesu, atrisinātāja komponente, kas saņēma iestatījumus, un tas, vai tuneļa saite joprojām pastāv. Atbildiet šādā secībā, un labojums parasti nāk, neaizskarot globālu failu.

Izlemiet, kāda veida izeja notika

Community izdevumā OpenVPN gan SIGINT, gan SIGTERM ir kārtīgas izejas lūgumi. SIGKILL nevar uztvert: to nevar ne bloķēt, ne apstrādāt, tāpēc neviena izslēgšanas rutīna neiegūst iespēju palaisties. Parasts Ctrl+C priekšplāna terminālī rada SIGINT, bet uzraugs, kas pārstāj gaidīt, parasti paaugstina līmeni līdz SIGKILL. Atšķirība ir svarīga, jo tikai otrais gadījums garantē, ka āķi tika izlaisti.

Palaide screen vai tmux iekšpusē nemaina to, kuru signālu sūta Ctrl+C. Pārbaudiet, ko process faktiski saņēma, nevis ko terminālis parasti dara.

Kad tuneli palaiž pakalpojums vai savienojumu pārvaldnieks, apturiet šo vienu savienojumu caur tā īpašnieku, nevis nogalinot pid. Pārvaldnieks var procesu atkal pacelt, atstājot jums jaunu tuneli un mulsinošu atrisinātāja stāvokli. Atsevišķam procesam tīrīšanas izpildei ir vajadzīgs tikai parasts apturēšanas lūgums.

Izlemiet, kam pieder atrisinātājs

systemd-resolved, resolvconf stila skripts un vienkārša faila pārrakstīšana ir trīs dažādi īpašnieki. Pirmais tur iestatījumus katram savienojumam atmiņā un izmet tos, kad saskarne pazūd. Otrais tur ierakstus, kas saglabājas, kamēr kaut kas tos neizdzēš. Trešais raksta failu un atjaunošanu atstāj tam, kas to rakstīja.

Nosakiet īpašnieku pirms labošanas komandas izvēles. Vienam un tam pašam simptomam ir trīs dažādas pareizas atbildes atkarībā no tā, kurš tiek izmantots.

NetworkManager pārvaldīts VPN jau var būt atrisinātāja izmaiņu īpašnieks. Otra palīga pievienošana virsū rada divus īpašniekus, kas sacenšas par vienu un to pašu saiti, un zaudētāja stāvoklis atkal parādās nākamajā atkārtotajā savienojumā. Ja atbildīgs ir pārvaldnieks, labojiet iestatījumu pārvaldniekā, nevis skriptā.

Ko down āķis var un ko nevar

Skripts down tiek palaists vienu reizi pēc tam, kad TUN/TAP ierīce ir aizvērta. Pievienojot down-pre šī secība tiek apgriezta un skripts tiek palaists, kamēr ierīce vēl pastāv, ko pieprasa palīgi, kuriem vajadzīga dzīvā saite.

Neviena direktīva nepanāk, ka āķis palaižas pēc SIGKILL. Arī privilēģijas netiek atjaunotas ar down-pre: ja dēmons nokrīt līdz user vai group vai iekļūst chroot vidē, āķis darbojas ar piekļuvi, ko tas tam atstāj. Izsaukts āķis tomēr var nespēt atjaunināt atrisinātāju. OpenVPN uzziņa aptver signālus un atzvanīšanas dzīves ciklu.

Pārbaudiet paša āķa kļūdu līdzās procesa izejas statusam. Trūkstoša tīrīšana un neizdevusies tīrīšana atrisinātājā izskatās vienādi, bet žurnālos atšķirīgi.

Pārbaudiet stāvokli, kas patiešām paliek

Sistēmā, kas izmanto systemd-resolved, resolvectl status parāda, kura saite joprojām pārnēsā VPN DNS serverus vai maršrutēšanas domēnus. Šī saite var piederēt savienojumam, kas jau pazuda, vai citam tunelim, kas vēl ir pacelts.

Pazūdoša saskarne paņem līdzi savu konfigurāciju katram savienojumam, tāpēc izlaists āķis var pastāvēt līdzās tīram DNS. Ja saite joprojām ir reģistrēta un to ekskluzīvi pārvalda apturētais savienojums, to pārvaldošajam pārvaldniekam tā jānoņem. Ja vecāks skripts pārrakstīja globālu atrisinātāja failu, meklējiet tā skripta dokumentēto atjaunošanas soli.

Atjaunojiet, nezogot citu saiti

Kad iestatījumi katram savienojumam ir jūsu pārvaldībā, resolvectl revert paņem saites nosaukumu un notīra izpildlaika DNS konfigurāciju šai saskarnei. Tā ir izpildlaika darbība, nevis profila rediģēšana, tāpēc pastāvīgā savienojuma konfigurācija paliek neskarta. Ja nosauksiet nepareizo saiti, notīrīsiet strādājoša tuneļa DNS, tāpēc nosaukums tiek ņemts no statusa izvades.

Pirms rediģēšanas pārliecinieties, ka /etc/resolv.conf ir pārvaldīta simboliskā saite, pēc tam vēlreiz parasti apturiet klientu un apskatiet DNS vēlreiz. Ja otrais apturējums notīra, iepriekšējā problēma bija piespiedu izeja, nevis konfigurācija.