Forigo de kaduka VPN-rikordo el la resolvconf-datumbazo

Interna nomo ankoraŭ solviĝas al la VPN-servilo unu tagon post la fermo de la tunelo, kaj la solvila dosiero daŭre revenas kun tiu enskribo. Kie la resolvconf de Debian posedas la staton, tiu dosiero estas kunmetata el rikordoj de provizantoj, kaj unu el ili estas la restaĵo. Forigi la rikordon daŭras minuton; pruvi, ke estas sekure forigi ĝin, estas la vera laboro. Ĉi tiuj pordegoj iras laŭ ordo, kaj malsukcesinta pordego finas la proceduron anstataŭ sendi vin al la sekva paŝo.

Konfirmu, ke resolvconf posedas la staton

Unue identigu la posedanton, ĉar la sama simptomo sub systemd-resolved bezonas aliajn komandojn kaj alian riparon. La pako resolvconf tenas datumbazon sub /run/resolvconf kaj direktas /etc/resolv.conf al la dosiero, kiun ĝi konstruas el tiu datumbazo. Du legaĵoj decidas la demandon: la celo de la simbola ligilo, kaj ĉu la pako estas instalita kaj aktiva. Celo sub /run/systemd/resolve signifas la alian dezajnon, kie nenio sube validas.

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

Se la ligilo montras aliloken aŭ la pako mankas, haltu ĉi tie. Kongrueca envolvaĵo, kiu prunteprenis la nomon kaj estas liverata de alia solvila administrilo, ne posedas ĉi tiun datumbazon.

La datumbazo tenas enigojn, ne la respondon

La datumbazo tenas enigojn kaj la dosiero estas eligo, do listigi la enigojn estas la sola maniero vidi, kiun programon instalas la enskribon, kiun vi volas forigi. La rikordoj estas mallongaj, kaj iliaj ŝlosiloj estas la teniloj, kiujn vi bezonos poste. Legu ilin antaŭ ol decidi, kiu estas kaduka, ĉar nomo, kiu aspektas kiel VPN-interfaco, povas aparteni al alia kliento. Tenu privatajn adresojn kaj internajn serĉajn domajnojn ekster kunhavata diagnostiko; kutime la ŝlosilo sola identigas la rikordon.

sudo resolvconf --list
sudo resolvconf -i

La unua komando presas liveritajn rikordojn sen prilabori ilin, kaj la dua listigas la interfacojn, kiuj nun provizas DNS-agordon. Ŝlosiloj kutime konstruiĝas el interfaca nomo plus la provizanta programo. La manlibro de resolvconf priskribas la datumbazon, kiun tiuj ŝlosiloj adresas.

Kopiu la ŝlosilon el la eligo anstataŭ rekonstrui ĝin. Enskribo ne nomiĝas tun0 nur ĉar malnova skripto uzis tiun nomon.

Pruvu, ke la rikordo havas neniun posedanton

Rikordo estas sekura forigi, kiam neniu viva konekto instalas ĝin. Rilatigu la ŝlosilon al la konekto, kiu kreis ĝin, poste konfirmu, ke tiu konekto foriris. Tiu rilatigo estas la tuta pordego, kaj ĝi estas la paŝo plej ofte preterlasata survoje al la foriga komando. Se la indicoj estas ambiguaj, traktu la rikordon kiel vivan kaj haltu.

Procesaj nomoj estas malfortaj indicoj. OpenConnect vokas vpnc-script, do kontrolo por proceso vpnc diras nenion pri tio, kiu rikordo estas aktuala. Nova konekto povas ankaŭ reuzi interfacan nomon, kiun malnova lasis, kio faras la ŝlosilon aspekti pli aĝa ol ĝi estas. Komparu la servilan adreson ene de la rikordo kun la adresoj de tuneloj, kiuj ankoraŭ staras, kaj haltu se ili kongruas.

Normala malkonekto tra la posedanta administrilo estas la unua rimedo. Ĝi retiras tion, kion tiu konekto instalas, kaj lasas aliajn provizantojn netuŝitaj.

Kontrolu la forigon kaj la rean skribon

Post kiam la rikordo estas konfirmita kaduka, forigu ĝin per la preciza ŝlosilo kaj poste legu la rezulton anstataŭ supozi ĝin. La komando ŝanĝas la solvilan staton por ĉiu aplikaĵo sur la gastigo, do rulu ĝin en fenestro, kiun vi kontrolas. Metu la ŝlosilon en citilojn, ĉar ĝi enhavas signojn, kiujn la ŝelo alie vastigus. La lokokupilo en la bloko signifas la ŝlosilon, kiun vi kopiis el la listo, ne laŭliteran ĉenon.

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

Forigo rulas la ĝisdatigajn skriptojn, kiam ĝisdatigo estas ebligita; kun malŝaltitaj ĝisdatigoj ĝi prokrastas la ĝisdatigon, do forigita rikordo kaj reskribita dosiero estas apartaj eventoj. Relu la liston kaj konfirmu, ke la ŝlosilo foriris antaŭ ol rigardi la dosieron. Poste demandu unu nomon, kiu ankoraŭ devus solviĝi tra la restantaj provizantoj, kaj unu publikan nomon, kaj komparu ambaŭ kun tio, kion vi vidis antaŭ la ŝanĝo. Se privata nomo tute ĉesas solviĝi, tiu rikordo ankoraŭ portis ĝin.

resolvconf -u rulas nur tiujn ĝisdatigajn skriptojn. Ĝi neniam identigas aŭ forigas kadukan rikordon, kaj rekonstruo el kadukaj enigoj reproduktas la saman nedeziratan dosieron.

Mortigita malkonekta hoko lasas la rikordon malantaŭe

Unufoja purigado restarigas la hodiaŭan staton, kaj la sekva interrompita malŝalto remetas la rikordon. Trapaŝu la malkonstrupadon: la malkonekta hoko de la kliento, la helpilo, kiun tiu hoko vokas, kaj kio okazas, kiam iu el ili estas mortigita. Interrompita malŝalto estas la kutima origino, ĉar la hoko tute ne funkciis. Protokolu la eliran staton de la hoko unufoje kaj vi scios, ĉu ĝi malsukcesas silente.

Tenu agordon kaj purigadon sub unu posedanto. Dua skripto, kiu divenas interfacajn nomojn, finfine forigos la rikordon de alia konekto, kio estas pli malbona ol la kaduka enskribo, kun kiu vi komencis. La posedanto ankaŭ devus decidi, kiam rikordo estas kaduka, ĉar ĝi scias, kiu konekto instalas ĝin.

Poste ekzercu la vivociklon: konektiĝu, malkonektiĝu, listigu la rikordojn denove. La memstara malapero de la enskribo estas la sola pruvo, ke la ripato tenas.