OpenVPN-i DNS jääb pärast SIGKILL-i maha: kontrollige esmalt omanikku

DNS lakkab pärast OpenVPN-i kliendi tapmist lahendamast ja esimene tung on ümber kirjutada /etc/resolv.conf. See muudatus võib lõhkuda töötava resolveri, samal ajal kui tegelik aegunud olek asub mujal. Kõigepealt tuleb selgitada, kellele kuuluvad DNS-i seaded, mille tunnel paigaldas, ja kas väljumine, mis puhastuse vahele jättis, oli tegelikult oluline.

Paranduse otsustavad kolm tingimust: protsessi lõpetanud signaal, seaded saanud resolveri komponent ja see, kas tunneli link on veel olemas. Vastake neile selles järjekorras ja parandus järgneb tavaliselt ilma globaalse faili puudutamiseta.

Otsustage, milline väljumine toimus

Community väljaandes OpenVPN on nii SIGINT kui ka SIGTERM korrektse väljumise taotlused. SIGKILL-i ei saa tabada: seda ei saa blokeerida ega käsitleda, seega ei saa ükski sulgemisrutiin käivitumiseks võimalust. Tavaline Ctrl+C esiplaanil olevas terminalis tekitab SIGINT-i, samas kui ootamisest loobuv järelevalveprotsess eskaleerub tavaliselt SIGKILL-iks. Erinevus loeb, sest ainult teine juhtum tagab, et konksud jäeti vahele.

Jooksutamine screeni või tmuxi sees ei muuda, millise signaali Ctrl+C saadab. Kontrollige, mida protsess tegelikult sai, mitte mida terminal tavaliselt teeb.

Kui tunnelit jooksutab teenus või ühendusehaldur, peatage see üks ühendus selle omaniku kaudu, mitte tapske pidi. Haldur võib protsessi uuesti üles tõsta, jättes teile värske tunneli ja segase resolveri oleku. Eraldiseisev protsess vajab puhastuse käivitamiseks vaid tavalist lõpetamistaotlust.

Otsustage, kellele resolver kuulub

systemd-resolved, resolvconfi-stiilis skript ja lihtne faili ümberkirjutus on kolm erinevat omanikku. Esimene hoiab lingipõhiseid seadeid mälus ja viskab need maha, kui liides kaob. Teine hoiab kirjeid, mis püsivad, kuni miski need eemaldab. Kolmas kirjutab faili ja jätab taastamise sellele, kes selle kirjutas.

Tehke omanik kindlaks enne paranduskäsu valimist. Samal sümptomil on kolm erinevat õiget vastust sõltuvalt sellest, millist kasutatakse.

NetworkManageri hallatav VPN võib resolveri muudatused juba omada. Teise abilise lisamine selle peale loob kaks omanikku, kes võistlevad sama lingi pärast, ja kaotaja olek ilmub uuesti järgmisel taasühendamisel. Kui haldur vastutab, parandage seade halduris, mitte skriptis.

Mida down-konks suudab ja ei suuda

Skript down käivitub üks kord pärast seda, kui TUN/TAP-seade on suletud. Lisades down-pre pöörab selle järjekorra ümber ja käivitab skripti, kui seade veel eksisteerib, mida vajavad abilised, kes vajavad elusat linki.

Kumbki direktiiv ei pane konksu pärast SIGKILL-i käivituma. Õigusi ei taastata ka down-pre: kui deemon laskub user või group peale või siseneb chroot-i, käivitub konks selle juurdepääsuga, mille see talle jätab. Kutsutud konks võib ikkagi resolveri värskendamisel ebaõnnestuda. OpenVPN-i viide katab signaalid ja callbacki elutsükli.

Kontrollige konksu enda viga protsessi väljumisoleku kõrval. Puuduv puhastus ja ebaõnnestunud puhastus näevad resolveris ühesugused välja ja logides erinevad.

Kontrollige olekut, mis tegelikult järele jääb

Süsteemis, mis kasutab systemd-resolvedi, näitab resolvectl status, milline link kannab veel VPN-i DNS-serverid või marsruutimisdomeene. See link võib kuuluda ühendusele, mis on kadunud, või teisele tunnelile, mis on veel üleval.

Kaduv liides võtab oma lingipõhise konfiguratsiooni kaasa, seega võib vahele jäetud konks eksisteerida puhta DNS-i kõrval. Kui link on veel registreeritud ja kuulub ainult peatatud ühendusele, peaks seda omav haldur selle eemaldama. Kui vanem skript kirjutas ümber globaalse resolverifaili, otsige selle skripti dokumenteeritud taastamisammast.

Taastage teist linki varastamata

Kui lingipõhised seaded on teie hallata, resolvectl revert võtab lingi nime ja tühjendab selle liidese jooksva DNS-konfiguratsiooni. See on jooksev tegevus, mitte profiili muutmine, seega püsiv ühenduse konfiguratsioon jääb puutumata. Nimetage vale link ja te tühjendate töötava tunneli DNS-i, mistõttu pärineb nimi olekuväljundist.

Kinnitage, et /etc/resolv.conf on hallatav sümbollink enne selle muutmist, seejärel peatage klient veel korra tavaliselt ja vaadake DNS-i uuesti. Kui teine peatamine puhastab, oli varasem probleem sunnitud väljumine, mitte konfiguratsioon.