SIGKILL-ийн дараа OpenVPN DNS үлддэг: эхлээд эзэмшигчийг шалга

OpenVPN клиент алагдсаны дараа DNS шийдэхээ болих ба эхний төлөв /etc/resolv.conf файлыг дахин бичих явдал юм. Энэ өөрчлөлт ажиллаж буй resolver-ийг эвдэж болох бол жинхэнэ хуучирсан төлөв өөр газар байна. Эхлээд шийдэх асуудал нь туннелийн суулгасан DNS тохиргоог хэн эзэмшдэг, мөн цэвэрлэлтийг алгассан гаралт үнэхээр чухал байсан эсэх юм.

Гурван нөхцөл засварыг тодорхойлно: процессыг дуусгасан сигнал, тохиргоог хүлээн авсан resolver бүрэлдэхүүн, туннелийн холбоос байсаар байгаа эсэх. Энэ дарааллаар хариулбал засвар ихэвчлэн глобал файлд хүрэхгүйгээр ирдэг.

Ямар төрлийн гаралт болсныг тодорхойл

Community хувилбарын OpenVPN-д SIGINT болон SIGTERM хоёулаа зөөлөн гарах хүсэлт юм. SIGKILL-ийг барьж болохгүй: түүнийг блоклох ч, боловсруулах ч болохгүй тул ямар ч унтраах горим ажиллах боломж олдохгүй. Урд төлөвийн терминал дахь энгийн Ctrl+C нь SIGINT үүсгэдэг бол хүлээхээ болих хянагч ихэвчлэн SIGKILL рүү өсдөг. Ялгаа нь чухал, учир нь зөвхөн хоёр дахь тохиолдол дэгээнүүд алгасагдсаныг батална.

screen эсвэл tmux дотор ажиллуулах нь Ctrl+C ямар сигнал илгээхийг өөрчлөхгүй. Терминал ихэвчлэн юу хийдэг биш, процесс бодитоор юу хүлээн авсныг шалга.

Туннелийг үйлчилгээ эсвэл холболтын менежер ажиллуулж байгаа бол pid-ийг алахын оронд тэр нэг холболтыг эзэмшигчээр нь зогсоо. Менежер процессыг дахин өргөж, шинэ туннель болон будлиантай resolver төлөвийг үлдээж болно. Бие даасан процесс цэвэрлэлт ажиллахад энгийн зогсоох хүсэлт л хэрэгтэй.

Resolver хэнд хамаарахыг тодорхойл

systemd-resolved, resolvconf хэв маягийн скрипт, энгийн файл дахин бичих нь гурван өөр эзэмшигч юм. Эхнийх нь холбоос бүрийн тохиргоог санах ойд хадгалж интерфэйс алга болоход хаядаг. Хоёр дахь нь ямар нэг зүйл устгах хүртэл үлддэг бичлэгүүдийг хадгалдаг. Гурав дахь нь файл бичиж сэргээхийг бичсэн хүнд нь үлдээдэг.

Засварын командыг сонгохын өмнө эзэмшигчийг тодорхойл. Ижил шинж тэмдэг нь аль нь ашиглагдаж байгаагаас хамаарч гурван өөр зөв хариулттай.

NetworkManager-ийн удирддаг VPN resolver-ийн өөрчлөлтийг аль хэдийн эзэмшиж болно. Дээр нь хоёр дахь туслахыг нэмбэл нэг холбоосын төлөө өрсөлдөх хоёр эзэмшигч үүсч, ялагдсан талын төлөв дараагийн дахин холбогдоход дахин илэрдэг. Хэрэв менежер хариуцлагатай бол тохиргоог скриптэд биш, менежерт зас.

down дэгээ юу хийж чадах ба чадахгүй

Скрипт down TUN/TAP төхөөрөмж хаагдсаны дараа нэг удаа ажиллана. down-pre нэмэхэд энэ дараалал эргэж, скрипт төхөөрөмж байх үед ажиллана, үүнийг амьд холбоос хэрэгтэй туслахууд шаарддаг.

Аль ч заавар дэгээг SIGKILL-ийн дараа ажиллуулдаггүй. Эрх мэдэл ч down-pre-ээр сэргэдэггүй: хэрэв демон user эсвэл group руу буух эсвэл chroot руу орвол дэгээ түүний үлдээсэн хандалтаар ажиллана. Дуудагдсан дэгээ resolver-ийг шинэчилж чадахгүй байж болно. OpenVPN-ийн лавлагаа сигналууд болон callback-ийн амьдралын мөчлөгийг хамарна.

Процессын гаралтын статусын хажууд дэгээний өөрийн алдааг шалга. Дутуу цэвэрлэлт болон бүтэлгүйтсэн цэвэрлэлт resolver-д ижил харагдаж, логт ялгаатай харагдана.

Бодитоор үлдсэн төлөвийг шалга

systemd-resolved ашигладаг системд resolvectl status аль холбоос VPN-ийн DNS сервер эсвэл чиглүүлэлтийн домэйныг зөөж байгааг харуулна. Тэр холбоос явсан холболтынх байж болно, эсвэл өргөгдсөн өөр туннелийнх байж болно.

Алга болох интерфэйс өөрийн холбоос бүрийн тохиргоог дагуулаад явдаг тул алгасагдсан дэгээ цэвэр DNS-тэй зэрэгцэн оршиж болно. Хэрэв холбоос бүртгэлтэй хэвээр, зөвхөн зогсоосон холболт эзэмшиж байвал эзэмшигч менежер түүнийг устгах ёстой. Хэрэв хуучин скрипт глобал resolver файлыг дахин бичсэн бол оронд нь тэр скриптийн баримтжуулсан сэргээх алхмыг хай.

Өөр холбоос хулгайлахгүйгээр сэргээ

Холбоос бүрийн тохиргоо таны удирдлагад байгаа үед resolvectl revert холбоосын нэрийг авч тэр интерфэйсийн ажиллах үеийн DNS тохиргоог арилгана. Энэ нь профайл засварлах биш ажиллах үеийн үйлдэл тул байнгын холболтын тохиргоо хөндөгдөхгүй үлдэнэ. Буруу холбоосыг нэрлэвэл ажиллаж буй туннелийн DNS-ийг арилгана, иймээс нэр нь статусын гаралтаас авдаг.

Засварын өмнө /etc/resolv.conf удирдлагатай симбол холбоос эсэхийг батал, дараа нь клиентийг дахин нэг удаа хэвийн зогсоож DNS-ийг дахин хар. Хоёр дахь зогсолт цэвэрлэж байвал өмнөх асуудал тохиргоо биш, албадлагын гаралт байсан.