Pag-alis ng hindi na ginagamit na VPN record mula sa database ng resolvconf

Ang isang panloob na pangalan ay nire-resolve pa rin sa VPN server isang araw matapos magsara ang tunnel, at ang resolver file ay paulit-ulit na bumabalik kasama ang entry na iyon. Kung saan pagmamay-ari ng Debian resolvconf ang estado, ang file na iyon ay binuo mula sa mga record ng supplier, at isa sa mga ito ang natira. Isang minuto lang ang pagbura ng record; ang patunayan na ligtas itong burahin ang tunay na gawain. Ang mga gate na ito ay tumatakbo nang sunod-sunod, at ang nabigong gate ay tinatapos ang pamamaraan sa halip na ipadala ka sa susunod na hakbang.

Kumpirmahin na pagmamay-ari ng resolvconf ang estado

Kilalanin muna ang may-ari, dahil ang parehong sintomas sa ilalim ng systemd-resolved ay nangangailangan ng ibang mga utos at ibang pagkukumpuni. Ang pakete ng resolvconf ay may hawak na database sa ilalim ng /run/resolvconf at itinuturo ang /etc/resolv.conf sa file na binubuo nito mula sa database na iyon. Dalawang pagbasa ang nagtatapos sa tanong: ang target ng symlink, at kung naka-install at aktibo ang pakete. Ang target sa ilalim ng /run/systemd/resolve ay nangangahulugan ng ibang disenyo, kung saan wala sa mga nasa ibaba ang naaangkop.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

Kung ang link ay tumuturo sa ibang lugar o wala ang pakete, huminto dito. Ang compatibility wrapper na humiram ng pangalan, at inihahatid ng ibang tagapamahala ng resolver, ay hindi nagmamay-ari ng database na ito.

Ang database ay may mga input, hindi ang sagot

Ang database ay may mga input at ang file ay output, kaya ang paglilista ng mga input ang tanging paraan upang makita kung aling programa ang nag-install ng entry na gusto mong alisin. Maikli ang mga record, at ang kanilang mga key ay ang mga hawakan na kakailanganin mo mamaya. Basahin ang mga ito bago magpasya kung alin ang luma, dahil ang pangalang mukhang interface ng VPN ay maaaring pagmamay-ari ng ibang client. Ilayo ang mga pribadong address at panloob na domain ng paghahanap sa ibinahaging diagnostics; ang key lamang ang kadalasang tumutukoy sa record.

sudo resolvconf --list
sudo resolvconf -i

Ang unang utos ay nagpi-print ng mga inihahatid na record nang hindi ito pinoproseso, at ang pangalawa ay naglilista ng mga interface na kasalukuyang nagbibigay ng configuration ng DNS. Ang mga key ay karaniwang binubuo mula sa pangalan ng interface at sa programang naghahatid. Ang manwal ng resolvconf ay naglalarawan ng database na tinutukoy ng mga key na iyon.

Kopyahin ang key mula sa output sa halip na buuin itong muli. Ang isang entry ay hindi tinatawag na tun0 dahil lamang ginamit ng lumang script ang pangalang iyon.

Patunayan na walang may-ari ang record

Ang isang record ay ligtas burahin kapag walang buhay na koneksyon ang nag-install nito. Iugnay ang key sa koneksyon na lumikha nito, pagkatapos kumpirmahin na wala na ang koneksyong iyon. Ang ugnayang iyon ang buong gate, at ito ang hakbang na pinakamadalas laktawan sa daan patungo sa utos ng pagbura. Kung malabo ang ebidensya, ituring na buhay ang record at huminto.

Ang mga pangalan ng proseso ay mahinang ebidensya. Tinatawag ng OpenConnect ang vpnc-script, kaya ang pagsuri sa prosesong vpnc ay walang sinasabi tungkol sa kung aling record ang kasalukuyan. Ang bagong koneksyon ay maaari ring gumamit muli ng pangalan ng interface na iniwan ng luma, na nagpapakita ng key na mas matanda kaysa sa tunay nitong edad. Ihambing ang address ng server sa loob ng record sa mga address ng tunnel na buhay pa, at huminto kung magkatugma ang mga ito.

Ang normal na pagdiskonekta sa pamamagitan ng tagapamahala na may-ari ay ang unang lunas. Binabawi nito ang in-install ng koneksyong iyon at hinahayaang hindi ginalaw ang ibang supplier.

Suriin ang pag-alis at ang muling pagsulat

Kapag kumpirmadong luma na ang record, burahin ito sa eksaktong key at pagkatapos basahin ang resulta sa halip na ipagpalagay ito. Binabago ng utos na ito ang estado ng resolver para sa bawat aplikasyon sa host, kaya patakbuhin ito sa isang window na kontrolado mo. Lagyan ng panipi ang key, dahil may mga karakter itong papalawakin ng shell kung wala. Ang placeholder sa block ay kumakatawan sa key na kinopya mo mula sa listahan, hindi sa literal na string.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

Ang pagbura ay nagpapatakbo ng mga update script kapag naka-enable ang pag-update; kapag naka-disable ang mga update, ipinagpapaliban nito ang pag-update, kaya ang tinanggal na record at ang muling naisulat na file ay dalawang magkaibang pangyayari. Basahin muli ang listahan at kumpirmahin na wala na ang key bago tingnan ang file. Pagkatapos tanungin ang isang pangalan na dapat pang ma-resolve sa pamamagitan ng natitirang mga supplier at isang pampublikong pangalan, at ihambing ang dalawa sa nakita mo bago ang pagbabago. Kung ang isang pribadong pangalan ay tuluyang huminto sa pag-resolve, dinadala pa rin ito ng record na iyon.

resolvconf -u ay nagpapatakbo lamang ng mga update script na iyon. Hindi nito kailanman natutukoy o nabubura ang isang lumang record, at ang muling pagbuo mula sa lumang input ay muling gumagawa ng parehong hindi kanais-nais na file.

Ang pinatay na disconnect hook ay nag-iiwan ng record

Ang isang beses na paglilinis ay nagbabalik ng estado ngayon, at ang susunod na naantala na shutdown ay ibinabalik ang record. Lakarin ang daan ng pagbuwag: ang disconnect hook ng client, ang helper na tinatawag ng hook na iyon, at ano ang nangyayari kapag pinatay ang alinman sa kanila. Ang naantala na shutdown ang karaniwang pinagmulan, dahil hindi talaga tumakbo ang hook. I-log nang isang beses ang exit status ng hook at malalaman mo kung tahimik itong nabigo.

Panatilihin ang setup at paglilinis sa ilalim ng isang may-ari. Ang pangalawang script na humuhula ng mga pangalan ng interface ay sa huli ay bubura ng record ng ibang koneksyon, na mas masahol pa kaysa sa lumang entry na sinimulan mo. Dapat ding magpasya ang may-ari kung kailan luma ang isang record, dahil alam nito kung aling koneksyon ang nag-install nito.

Pagkatapos sanayin ang lifecycle: kumonekta, magdiskonekta, ilista muli ang mga record. Ang pagkawala ng entry nang kusa ay ang tanging patunay na nananatili ang pagkukumpuni.