Debian resolvconf-ի գրառումների կարգը. VPN գրառումը՝ առաջին

VPN-ի անվանասերվերը մշտապես հայտնվում է LAN-ի անվանասերվերից ներքև, և /etc/resolv.conf-ի խմբագրումը դա ուղղում է մի քանի րոպեով։ Այդ ֆայլը գեներացվում է, ուստի ուղղումը երբեք չի մնում։ Debian-ի resolvconf-ում կարգի մուտքը /etc/resolvconf/interface-order-ն է, և այն դասավորում է գրառումների անունները, ոչ թե DNS հասցեները։ Նախքան երկու ֆայլերից որևէ մեկին դիպչելը հաստատեք, թե որ resolver-ի կույտն է իրականում պատասխանատու։

Հաստատեք, որ ելքը պատկանում է resolvconf-ին

Սկսեք հարցով, թե ինչ գրեց ընթացիկ ֆայլը և ինչ նորից կգրի այն։ resolvconf փաթեթն իրեն նկարագրում է որպես դինամիկ resolver-ի կարգավորման հիմք, և systemd-resolved կամ NetworkManager-ի կողմից կառավարվող resolver աշխատեցնող հոսթը կարող է դրսից նույնը թվալ, մինչդեռ բոլորովին այլ քաղաքականություն է կիրառում։

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Եթե լուծված ուղին չի տանում resolvconf-ի աշխատանքային պանակ, կանգ առեք այստեղ. այս ձեռնարկը պատկանում է մեկ այլ կույտի։

Միայն այդ ստուգումից հետո է արժե թվարկել այն գրառումները, որոնք resolvconf-ը հիմա պահում է։

Կարդացեք գրառումները նախքան ձևանմուշներ գրելը

interface-order-ը համընկնում է մատակարարի գրառումների անունների հետ, ոչ հասցեների և ոչ միջուկի ինտերֆեյսների անունների։ Թվարկեք, թե ինչ է գրանցված, որպեսզի ձեր ձևանմուշները հղվեն գոյություն ունեցող գրառումներին։

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Գրառման անունը սովորաբար կրում է վերջածանց, որը նույնականացնում է մատակարարին, ուստի թունելի գրառումը և DHCP գրառումը կարող են կիսել ինտերֆեյսի նախածանցը և այնուամենայնիվ տարբեր կերպ դասավորվել։ Պատճենեք ճշգրիտ անունները պանակի ցանկից։ Մի՛ ենթադրեք անուն ինտերֆեյսի անունից, քանի որ հենց հաճախորդի ինտեգրացիան է որոշում, թե ինչ գրանցել։ Ձեր հորինած անունը երբեք չի համընկնի, և գրառումը կընկնի ամեն ինչ բռնող ձևանմուշի մեջ՝ առանց որևէ սխալի հաղորդագրության։

Գրեք կարգը որպես առաջին համընկնման ձևանմուշներ

Ֆայլը shell glob ձևանմուշների ցանկ է՝ մեկը մեկ տողում։ Գրառումը զբաղեցնում է առաջին այն ձևանմուշի դիրքը, որին համընկնում է, ուստի կոնկրետ ձևանմուշից վեր դրված լայն ձևանմուշը կոնկրետ տողը դարձնում է անհասանելի։

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Կոնկրետ թունելի ձևանմուշը դրեք ամեն ինչ բռնող ձևանմուշից և ֆիզիկական ինտերֆեյսի ձևանմուշից վեր։

Պահպանեք ֆայլում արդեն եղած մյուս տողերը։ Ամբողջ քաղաքականությունը օրինակով փոխարինելը հենց այն եղանակն է, որով անկապ մատակարարները լուռ տեղաշարժվում են. փոխեք մեկ տող, վերաստեղծեք և համեմատեք։ Ձևանմուշները չեն կարող պարունակել բացատներ, շեղ գծեր կամ սկզբնական կետ կամ տիլդա, իսկ դատարկ տողերն ու հեշ մեկնաբանությունները անտեսվում են։

Վերաստեղծեք և ստուգեք արդյունքը

Կարգը կիրառվում է, երբ թարմացման սկրիպտները վերակառուցում են ֆայլը։ Գործարկեք աջակցվող թարմացման ուղին՝ գեներացված ելքը խմբագրելու փոխարեն, ապա կարդացեք, թե ինչ է իրականում ստացել resolver-ը։

resolvconf -u
cat /etc/resolv.conf

Ստուգեք երկու հարցում, ոչ մեկը. մասնավոր անուն, որը պետք է լուծվի թունելով, և հանրային հսկիչ անուն։ Եթե մասնավոր անունը դեռ ձախողվում է, մինչ կարգը ճիշտ է թվում, խնդիրը անվանատարածքի երթուղավորումն է, ոչ թե գրառումների առաջնահերթությունը, և ոչ մի վերադասավորում այն չի ուղղի։ Համեմատեք յուրաքանչյուր պատասխան այն սերվերի հետ, որը վերադարձրել է այն, ոչ միայն հաջողության հետ։ Սխալ resolver-ի պատասխանած մասնավոր անունը դեռ ձախողում է, և օգտատիրոջ համար դա DNS-ի ընդհատման տեսք ունի։

Հանեք հնացած գրառումը շահագործումից՝ փոխարենը չիջեցնելու այն

Հին VPN գրառումը, որը կապն անջատելուց հետո նորից է հայտնվում, կյանքի ցիկլի սխալ է հաճախորդի ինտեգրացիայում. Այն ցանկի վերջ տեղափոխելը թաքցնում է ախտանիշը և ցանկում թողնում մեռած resolver։

Հանեք այն այն բաղադրիչի միջոցով, որը գրանցում է այն, ապա հաստատեք, որ գրառումների պանակն այլևս չի ցուցադրում այն։

Գրանցեք մատակարարի անունը, փոփոխված ձևանմուշը և ձեր կատարած երկու հարցումները։ Հաջորդ մարդուն այդ անուններն ավելի են պետք, քան պատմությունը։