OpenVPN-ի DNS-ը մնում է SIGKILL-ից հետո. նախ ստուգեք սեփականատիրոջը

DNS-ը դադարում է լուծվել այն բանից հետո, երբ OpenVPN-ի հաճախորդը սպանվում է, եւ առաջին բնազդը /etc/resolv.conf ֆայլը վերագրելն է։ Այդ փոփոխությունը կարող է կոտրել աշխատող լուծիչը, մինչդեռ իրական հնացած վիճակը այլ տեղ է։ Առաջին հերթին պարզելու հարցն այն է, թե ով է տիրապետում թունելի տեղադրած DNS կարգավորումներին, եւ արդյոք մաքրումը բաց թողած ելքը իրականում նշանակություն ուներ։

Երեք պայման է որոշում վերանորոգումը՝ գործընթացն ավարտած ազդանշանը, կարգավորումներն ստացած լուծիչի բաղադրիչը, եւ արդյոք թունելի կապը դեռ գոյություն ունի։ Պատասխանեք այդ հերթականությամբ, եւ ուղղումը սովորաբար գալիս է առանց գլոբալ ֆայլին դիպչելու։

Որոշեք, թե ելքի որ տեսակն է տեղի ունեցել

Community տարբերակում OpenVPN-ի համար ինչպես SIGINT-ը, այնպես էլ SIGTERM-ը սահուն ելքի հարցումներ են։ SIGKILL-ը հնարավոր չէ որսալ՝ այն չի կարող արգելափակվել կամ մշակվել, ուստի անջատման ոչ մի ընթացակարգ հնարավորություն չի ստանում աշխատելու։ Սովորական Ctrl+C-ն առաջին պլանի տերմինալում առաջացնում է SIGINT, մինչդեռ սպասելը դադարեցնող վերահսկիչը սովորաբար բարձրանում է մինչեւ SIGKILL։ Տարբերությունը կարեւոր է, որովհետեւ միայն երկրորդ դեպքն է երաշխավորում, որ կեռիկները բաց են թողնվել։

screen-ի կամ tmux-ի ներսում աշխատելը չի փոխում, թե Ctrl+C-ն որ ազդանշանն է ուղարկում։ Ստուգեք, թե գործընթացն ինչ է իրականում ստացել, ոչ թե ինչ է սովորաբար անում տերմինալը։

Երբ թունելը գործարկում է ծառայությունը կամ կապերի կառավարիչը, դադարեցրեք այդ մեկ կապը դրա սեփականատիրոջ միջոցով՝ pid-ը սպանելու փոխարեն։ Կառավարիչը կարող է նորից բարձրացնել գործընթացը՝ ձեզ թողնելով նոր թունել եւ շփոթեցնող լուծիչի վիճակ։ Առանձին գործընթացին մաքրումը գործարկելու համար բավական է սովորական դադարեցման հարցում։

Որոշեք, թե ով է տիրապետում լուծիչին

systemd-resolved-ը, resolvconf ոճի սկրիպտը եւ ֆայլի պարզ վերագրումը երեք տարբեր սեփականատերեր են։ Առաջինը կապի համար կարգավորումները պահում է հիշողության մեջ եւ գցում դրանք, երբ ինտերֆեյսը անհետանում է։ Երկրորդը պահում է գրառումներ, որոնք մնում են այնքան, մինչեւ ինչ-որ բան հեռացնի դրանք։ Երրորդը գրում է ֆայլ եւ վերականգնումը թողնում է նրան, ով գրել է այն։

Նույնականացրեք սեփականատիրոջը նախքան վերանորոգման հրաման ընտրելը։ Նույն ախտանիշն ունի երեք տարբեր ճիշտ պատասխան՝ կախված նրանից, թե որն է օգտագործվում։

NetworkManager-ով կառավարվող VPN-ը կարող է արդեն տիրապետել լուծիչի փոփոխություններին։ Վերեւում երկրորդ օգնական ավելացնելը ստեղծում է երկու սեփականատեր, որոնք մրցում են նույն կապի համար, եւ պարտվողի վիճակը նորից երեւում է հաջորդ վերամիացման ժամանակ։ Եթե կառավարիչն է պատասխանատու, կարգավորումը ուղղեք կառավարչում, ոչ թե սկրիպտում։

Ինչ կարող է եւ ինչ չի կարող անել down կեռիկը

Սկրիպտը down գործարկվում է մեկ անգամ այն բանից հետո, երբ TUN/TAP սարքը փակվել է։ down-pre ավելացնելը շրջում է այդ կարգը եւ սկրիպտը գործարկում է, քանի դեռ սարքը գոյություն ունի, ինչը պահանջում են կենդանի կապի կարիք ունեցող օգնականները։

Ոչ մի հրահանգ չի ստիպում կեռիկին աշխատել SIGKILL-ից հետո։ Արտոնությունները նույնպես չեն վերականգնվում down-pre-ի միջոցով. եթե դեմոնը իջնում է user կամ group մակարդակի կամ մտնում է chroot միջավայր, կեռիկը աշխատում է այն հասանելիությամբ, ինչ դա նրան թողնում է։ Կանչված կեռիկը դեռ կարող է չկարողանալ թարմացնել լուծիչը։ OpenVPN-ի տեղեկագիրքը ընդգրկում է ազդանշանները եւ հետկանչի կյանքի ցիկլը։

Ստուգեք կեռիկի սեփական սխալը գործընթացի ելքի կարգավիճակի կողքին։ Բացակայող մաքրումը եւ ձախողված մաքրումը լուծիչում նույն տեսքն ունեն, իսկ մատյաններում՝ տարբեր։

Ստուգեք այն վիճակը, որն իսկապես մնում է

systemd-resolved օգտագործող համակարգում resolvectl status ցույց է տալիս, թե որ կապը դեռ կրում է VPN-ի DNS սերվերները կամ երթուղման տիրույթները։ Այդ կապը կարող է պատկանել գնացած միացմանը կամ դեռ բարձրացված մեկ այլ թունելի։

Անհետացող ինտերֆեյսը իր հետ տանում է կապի համար իր կարգավորումը, ուստի բաց թողնված կեռիկը կարող է գոյակցել մաքուր DNS-ի հետ։ Եթե կապը դեռ գրանցված է եւ բացառապես պատկանում է դադարեցված միացմանը, տիրապետող կառավարիչը պետք է հեռացնի այն։ Եթե ավելի հին սկրիպտը վերագրել է գլոբալ լուծիչի ֆայլ, փնտրեք դրա փոխարեն այդ սկրիպտի փաստաթղթավորված վերականգնման քայլը։

Վերականգնեք առանց մեկ այլ կապ գողանալու

Երբ կապի համար կարգավորումները ձեր կառավարման ներքո են, resolvectl revert վերցնում է կապի անունը եւ մաքրում է այդ ինտերֆեյսի գործարկման ժամանակի DNS կարգավորումը։ Սա գործարկման ժամանակի գործողություն է, ոչ պրոֆիլի խմբագրում, ուստի մշտական կապի կարգավորումը մնում է անձեռնմխելի։ Սխալ կապ նշեք՝ եւ կմաքրեք աշխատող թունելի DNS-ը, դրա համար էլ անունը գալիս է կարգավիճակի ելքից։

Համոզվեք, որ /etc/resolv.conf-ը կառավարվող սիմվոլիկ հղում է, նախքան այն խմբագրելը, ապա եւս մեկ անգամ սովորական դադարեցրեք հաճախորդին եւ նորից նայեք DNS-ին։ Եթե երկրորդ դադարեցումը մաքրում է, նախորդ խնդիրը հարկադիր ելքն էր, ոչ թե կարգավորումը։