OpenVPN DNS lieka po SIGKILL: pirmiausia patikrinkite savininką

DNS nustoja spręsti po to, kai OpenVPN klientas nužudomas, ir pirmasis instinktas yra perrašyti /etc/resolv.conf. Šis pakeitimas gali sugadinti veikiantį sprendėją, nors tikroji pasenusi būsena yra kitur. Pirmiausia reikia išsiaiškinti, kam priklauso tunelio įdiegti DNS nustatymai, ir ar išėjimas, kuris praleido valymą, tikrai turėjo reikšmės.

Trys sąlygos nulemia taisymą: signalas, kuris užbaigė procesą, sprendėjo komponentas, kuris gavo nustatymus, ir ar tunelio jungtis dar egzistuoja. Atsakykite jais šia tvarka ir pataisymas paprastai ateina neliečiant globalaus failo.

Nuspręskite, kokia išėjimo rūšis įvyko

Community leidime OpenVPN ir SIGINT, ir SIGTERM yra tvarkingo išėjimo prašymai. SIGKILL negalima pagauti: jo negalima nei užblokuoti, nei apdoroti, todėl jokia išjungimo rutina negauna šanso paleisti. Įprastas Ctrl+C priekiniame terminale sukuria SIGINT, o laukimo atsisakantis prižiūrėtojas paprastai pakyla iki SIGKILL. Skirtumas svarbus, nes tik antrasis atvejis garantuoja, kad kabliai buvo praleisti.

Paleidimas screen arba tmux viduje nekeičia, kokį signalą siunčia Ctrl+C. Tikrinkite, ką procesas iš tikrųjų gavo, o ne ką terminalas paprastai daro.

Kai tunelį paleidžia tarnyba arba ryšių tvarkyklė, sustabdykite tą vieną ryšį per jo savininką, o ne žudydami pid. Tvarkyklė gali vėl pakelti procesą, palikdama jums naują tunelį ir painią sprendėjo būseną. Savarankiškam procesui tereikia įprasto sustabdymo prašymo, kad valymas įvyktų.

Nuspręskite, kam priklauso sprendėjas

systemd-resolved, resolvconf stiliaus scenarijus ir paprastas failo perrašymas yra trys skirtingi savininkai. Pirmasis laiko nustatymus pagal jungtį atmintyje ir atmeta juos, kai sąsaja išnyksta. Antrasis laiko įrašus, kurie išlieka, kol kas nors juos pašalina. Trečiasis rašo failą ir atkūrimą palieka tam, kas jį parašė.

Nustatykite savininką prieš pasirinkdami taisymo komandą. Tas pats simptomas turi tris skirtingus teisingus atsakymus, priklausomai nuo to, kuris naudojamas.

NetworkManager valdomas VPN jau gali turėti sprendėjo pakeitimus. Pridėjus antrą pagalbininką viršuje, atsiranda du savininkai, konkuruojantys dėl tos pačios jungties, o pralaimėjusiojo būsena vėl pasirodo kitą kartą prisijungus. Jei atsakinga tvarkyklė, taisykite nustatymą tvarkyklėje, o ne scenarijuje.

Ką down kabliukas gali ir ko negali

Scenarijus down paleidžiamas vieną kartą po to, kai TUN/TAP įrenginys uždaromas. Pridėjus down-pre ši tvarka apverčiama ir scenarijus paleidžiamas, kol įrenginys dar egzistuoja, ko reikalauja pagalbininkai, kuriems reikia gyvos jungties.

Nė viena direktyva nepriverčia kabliuko paleisti po SIGKILL. Teisės taip pat neatkuriamos down-pre: jei tarnyba nusileidžia iki user arba group arba patenka į chroot, kabliukas veikia su tuo pristatymu, kurį tai jam palieka. Iškvietus kabliuką, jam vis tiek gali nepavykti atnaujinti sprendėjo. OpenVPN žinynas apima signalus ir atgalinio iškvietimo gyvavimo ciklą.

Patikrinkite paties kabliuko klaidą šalia proceso išėjimo būsenos. Trūkstamas valymas ir nepavykęs valymas sprendėjuje atrodo vienodai, o žurnaluose skirtingai.

Patikrinkite būseną, kuri iš tikrųjų lieka

Sistemoje, kuri naudoja systemd-resolved, resolvectl status rodo, kuri jungtis vis dar perneša VPN DNS serverius arba maršrutizavimo domenus. Ta jungtis gali priklausyti dingusiam ryšiui arba kitam tuneliui, kuris dar pakeltas.

Išnykstanti sąsaja pasiima savo konfigūraciją pagal jungtį, todėl praleistas kabliukas gali egzistuoti kartu su švariu DNS. Jei jungtis dar registruota ir ją išimtinai valdo sustabdytas ryšys, ją valdanti tvarkyklė turėtų ją pašalinti. Jei senesnis scenarijus perrašė globalų sprendėjo failą, ieškokite to scenarijaus dokumentuoto atkūrimo veiksmo.

Atkurkite nepavogdami kitos jungties

Kai nustatymai pagal jungtį yra jūsų valdymo sritis, resolvectl revert paima jungties pavadinimą ir išvalo vykdymo laiko DNS konfigūraciją tai sąsajai. Tai vykdymo laiko veiksmas, o ne profilio redagavimas, todėl nuolatinė ryšio konfigūracija lieka nepaliesta. Pavadindami neteisingą jungtį, išvalysite veikiančio tunelio DNS, todėl pavadinimas imamas iš būsenos išvesties.

Prieš redaguodami patvirtinkite, kad /etc/resolv.conf yra tvarkoma simbolinė nuoroda, tada dar kartą įprastai sustabdykite klientą ir vėl pažiūrėkite į DNS. Jei antras sustabdymas išvalo, ankstesnė problema buvo priverstinis išėjimas, o ne konfigūracija.