SIGKILL ondoren OpenVPN-en DNSa geratzen da: egiaztatu jabea lehenengo

DNSa ebazteari uzten dio OpenVPN bezero bat hil ondoren, eta lehen bulkada /etc/resolv.conf berridaztea da. Aldaketa horrek funtzionatzen duen resolver bat hautsi dezake, benetako egoera zaharra beste leku batean dagoen bitartean. Lehenengo argitu beharreko galdera da nor den tuneleak instalatutako DNS ezarpenen jabea, eta garbiketa saltatu zuen irteerak benetan garrantzirik izan ote zuen.

Hiru baldintzek erabakitzen dute konponketa: prozesua amaitu zuen seinalea, ezarpenak jaso zituen resolver osagaia, eta tunelaren lotura oraindik badagoen. Erantzun horiei ordena horretan eta konponketa normalean fitxategi global bat ukitu gabe etortzen da.

Erabaki zer irteera mota gertatu zen

Community edizioaren OpenVPN bertsioan, SIGINT eta SIGTERM biak irteera leunaren eskaerak dira. SIGKILL ezin da harrapatu: ezin da blokeatu ezta kudeatu ere, beraz itzaltze errutina batek ez du exekutatzeko aukerarik. Lehen planoko terminal batean Ctrl+C arruntak SIGINT sortzen du, eta itxaroteari uzten dion gainbegiraleak, berriz, normalean SIGKILLera igotzen du. Aldeak garrantzia du, bigarren kasuak soilik bermatzen duelako kakoak saltatu zirela.

screen edo tmux barruan exekutatzeak ez du aldatzen Ctrl+Ck zein seinale bidaltzen duen. Egiaztatu prozesuak benetan zer jaso zuen, terminalak normalean zer egiten duen beharrean.

Zerbitzu edo konexio kudeatzaile batek tunela exekutatzen duenean, gelditu konexio hori bere jabearen bidez, pida hil beharrean. Kudeatzaileak prozesua berriro altxa dezake, tunel berria eta resolver egoera nahasia utziz. Prozesu autonomo batek amaiera eskaera arrunta besterik ez du behar garbiketa exekuta dadin.

Erabaki norena den resolverra

systemd-resolved, resolvconf estiloan egindako script bat eta fitxategi baten berridazketa hutsa hiru jabe desberdin dira. Lehenengoak lotura bakoitzeko ezarpenak memorian gordetzen ditu eta interfazea desagertzen denean botatzen ditu. Bigarrenak zerbait ezabatu arte irauten duten erregistroak gordetzen ditu. Hirugarrenak fitxategi bat idazten du eta berreskuratzea idatzi zuenari uzten dio.

Identifikatu jabea konponketa komando bat aukeratu aurretik. Sintoma berak hiru erantzun zuzen desberdin ditu, erabiltzen ari denaren arabera.

NetworkManager-ek kudeatutako VPN bat resolver aldaketen jabea izan daiteke jada. Horren gainean bigarren laguntzaile bat gehitzeak lotura beraren bila lehiatzen duten bi jabe sortzen ditu, eta galtzailearen egoera hurrengo berrikonexioan agertzen da berriro. Kudeatzaile bat arduratzen bada, zuzendu ezarpena kudeatzailean, ez script batean.

Zer egin dezakeen down kakoak eta zer ez

Scriptak down TUN/TAP gailua itxi ondoren behin exekutatzen da. Gehitzeak down-pre ordena hori iraultzen du eta scripta gailua oraindik badagoela exekutatzen du, lotura bizia behar duten laguntzaileek eskatzen dutena.

Bi direktibek ez dute kako bat SIGKILL ondoren exekutarazten. Pribilegioak ere ez dira berreskuratzen down-pre bidez: daemona user edo group mailara jaisten bada edo chroot sartzen bada, kakoak horrek uzten dion sarbidearekin egiten du lan. Deitutako kako batek hala ere huts egin dezake resolverra eguneratzean. OpenVPN erreferentziak seinaleak eta callback bizi-zikloa hartzen ditu.

Egiaztatu kakoaren errorea prozesuaren irteera-egoeraren ondoan. Falta den garbiketa eta hutsegindako garbiketa berdin ikusten dira resolverrean eta desberdin erregistroetan.

Egiaztatu benetan geratzen den egoera

systemd-resolved erabiltzen duen sistema batean, resolvectl status ikusten da zein loturak daraman oraindik VPNaren DNS zerbitzariak edo bideratze domeinuak. Lotura hori desagertutako konexio batena izan daiteke, edo oraindik altxatuta dagoen beste tunel batena.

Desagertzen den interfaze batek bere lotura bakoitzeko konfigurazioa eramaten du, beraz saltatutako kako bat DNS garbiarekin batera egon daiteke. Lotura oraindik erregistratuta badago eta gelditutako konexioak soilik badu jabe, hura kudeatzen duen kudeatzaileak kendu beharko luke. Script zaharrago batek resolver fitxategi global bat berridatzi bazuen, bilatu horren ordez script horren berreskuratze urrats dokumentatua.

Berreskuratu beste lotura bat lapurtu gabe

Lotura bakoitzeko ezarpenak zuk kudeatzekoak direnean, resolvectl revert loturaren izena hartzen du eta interfaze horren DNS konfigurazioa garbitzen du exekuzio denboran. Exekuzio denborako ekintza da, ez profilaren edizioa, beraz konexioaren konfigurazio iraunkorra ukitu gabe geratzen da. Lotura okerra izendatuz gero, funtzionatzen duen tunel baten DNSa garbituko duzu, horregatik dator izena egoera-irteeratik.

Egiaztatu /etc/resolv.conf kudeatutako esteka sinbolikoa dela editatu aurretik, gero gelditu bezeroa normaltasunez beste behin eta begiratu berriro DNSari. Bigarren geldialdiak garbitzen badu, aurreko arazoa irteera behartua zen, ez konfigurazioa.