SIGKILL-dan sonra OpenVPN DNS-i qalır: əvvəlcə sahibini yoxlayın

OpenVPN klienti öldürüldükdən sonra DNS həll etməyi dayandırır və ilk instinkt /etc/resolv.conf faylını yenidən yazmaq olur. Bu düzəliş işləyən bir resolver-i poza bilər, halbuki əsl köhnəlmiş vəziyyət başqa yerdədir. Əvvəlcə həll edilməli sual budur: tunelin quraşdırdığı DNS parametrləri kimə aiddir və təmizləməni atlayan çıxış həqiqətən vacib idimi.

Təmiri üç şərt müəyyən edir: prosesi bitirən siqnal, parametrləri qəbul edən resolver komponenti və tunel linkinin hələ də mövcud olub-olmaması. Onlara bu ardıcıllıqla cavab verin və düzəliş adətən qlobal fayla toxunmadan gəlir.

Hansı növ çıxışın baş verdiyini müəyyənləşdirin

Community OpenVPN-də həm SIGINT, həm də SIGTERM zərif çıxış istəkləridir. SIGKILL tutula bilməz: onu nə bloklamaq, nə də emal etmək mümkündür, ona görə də heç bir bağlanma rutini işləmək şansı almır. Ön plandaki terminalda adi Ctrl+C SIGINT yaradır, gözləməkdən əl çəkən nəzarətçi isə adətən SIGKILL-ə keçir. Fərq vacibdir, çünki yalnız ikinci hal qarmaqların atlandığına zəmanət verir.

screen və ya tmux içində işləmək Ctrl+C-nin hansı siqnal göndərdiyini dəyişmir. Terminalın adətən nə etdiyinə deyil, prosesin həqiqətən nə aldığına baxın.

Tuneli bir xidmət və ya bağlantı meneceri işlədirsə, pid-i öldürmək əvəzinə həmin bağlantını öz sahibi vasitəsilə dayandırın. Menecer prosesi yenidən qaldıra bilər və sizdə təzə tunel ilə qarışıq resolver vəziyyəti qalar. Müstəqil prosesə isə təmizləmənin işləməsi üçün yalnız adi dayandırma istəyi kifayətdir.

Resolver-in kimə aid olduğunu müəyyənləşdirin

systemd-resolved, resolvconf üslubunda skript və sadə fayl yenidən yazma üç fərqli sahibdir. Birincisi hər link üzrə parametrləri yaddaşda saxlayır və interfeys yox olduqda onları silir. İkincisi nə isə silənə qədər qalan qeydlər saxlayır. Üçüncüsü fayl yazır və bərpanı onu yazanın öhdəsinə buraxır.

Təmir əmrini seçməzdən əvvəl sahibini müəyyən edin. Eyni simptomun istifadə olunan sahibdən asılı olaraq üç fərqli düzgün cavabı var.

NetworkManager ilə idarə olunan VPN artıq resolver dəyişikliklərinə sahib ola bilər. Üstünə ikinci bir köməkçi əlavə etmək eyni link üzərində rəqabət edən iki sahib yaradır və uduzanın vəziyyəti növbəti yenidən qoşulmada yenə görünür. Əgər menecer cavabdehdirsə, parametri skriptdə deyil, menecerdə düzəldin.

down qarmağının nə edə biləcəyi və bilmədiyi

down skripti TUN/TAP cihazı bağlandıqdan sonra bir dəfə işləyir. down-pre bu sıranı dəyişir və skripti cihaz hələ mövcud ikən işlədir; canlı linkə ehtiyac duyan köməkçilər bunu tələb edir.

Heç bir direktiv qarmağın SIGKILL-dan sonra işləməsini təmin etmir. Səlahiyyətlər də down-pre ilə bərpa olunmur: daemon user və ya group istifadəçisinə keçirsə və ya chroot daxil olursa, qarmaq onun buraxdığı girişlə işləyir. Çağırılan qarmaq yenə də resolver-i yeniləyə bilməz. OpenVPN sənədləri siqnalları və callback həyat dövrünü əhatə edir.

Qarmağın öz xətasını prosesin çıxış statusu ilə yanaşı yoxlayın. Çatışmayan təmizləmə və uğursuz təmizləmə resolver-də eyni, jurnallarda isə fərqli görünür.

Həqiqətən qalan vəziyyəti yoxlayın

systemd-resolved istifadə edən bir sistemdə resolvectl status hansı linkin hələ də VPN DNS serverlərini və ya marşrut domenlərini daşıdığını göstərir. O link getmiş bir bağlantıya, ya da hələ açıq olan başqa bir tunelə aid ola bilər.

Yox olan interfeys hər link üzrə konfiqurasiyasını özü ilə aparır, ona görə atlanmış qarmaq təmiz DNS ilə birgə mövcud ola bilər. Link hələ qeydiyyatdadırsa və yalnız dayandırılmış bağlantıya aiddirsə, sahib menecer onu silməlidir. Əgər köhnə skript qlobal resolver faylını yenidən yazmışdısa, onun sənədləşdirilmiş bərpa addımını axtarın.

Başqa linki oğurlamadan bərpa edin

Hər link üzrə parametrlər sizin idarənizdədirsə, resolvectl revert link adını götürür və həmin interfeys üçün işləmə vaxtı DNS konfiqurasiyasını təmizləyir. Bu, profil redaktəsi deyil, işləmə vaxtı əməliyyatıdır, ona görə davamlı bağlantı konfiqurasiyası toxunulmaz qalır. Səhv linki adlandırsanız, işləyən tunelin DNS-ini təmizləyirsiniz; ad məhz buna görə status çıxışından götürülür.

Redaktə etməzdən əvvəl /etc/resolv.conf faylının idarə olunan simvolik keçid olduğunu təsdiqləyin, sonra klienti bir dəfə də normal dayandırın və DNS-ə yenidən baxın. İkinci dayandırma təmizləsə, əvvəlki problem konfiqurasiya deyil, məcburi çıxış idi.