resolv.conf-ի խմբագրումը չի շտկում DNS-ը VPN-ի անջատվելուց հետո

Անջատում եք VPN-ը, ping 1.1.1.1-ը դեռ պատասխանում է, և յուրաքանչյուր անվան հարցում կախվում է, մինչև էջը վերջապես հանձնվի։ Այնուհետև cat /etc/resolv.conf-ը ցույց է տալիս անվան սերվեր, որը երբևէ գոյություն է ունեցել միայն թունելի ներսում, սովորաբար ցանկի առաջինը։ Այդ տողը ջնջելը կարծես թե ուղղում է այն մոտ տասը րոպեով, մինչև կասեցումը, Wi-Fi-ի թափառումը կամ վերագործարկումը վերադարձնեն այն։ Ձեր խմբագրած ֆայլը կարգավորումը չէ․ այն կապի վիճակի պատկերում է, որը պատկանում է մեկ այլ բաղադրիչի։

Ինչու մեկ հնացած գրառումը վայրկյաններ արժե յուրաքանչյուր հարցման համար

glibc-ի լուծիչը հերթով անցնում է անվան սերվերների ցանկը և սպասում է ժամկետի լրանալուն՝ նախքան հաջորդը փորձելը, և resolv.conf(5) այդ ցանկը սահմանափակում է երեք գրառմամբ։ Թունելի կողմի լուծիչ, օրինակ 10.8.0.1, դրեք ցանկի գլխին այն բանից հետո, երբ թունելը վերացել է, և յուրաքանչյուր հարցում վճարում է ժամկետը՝ նախքան պատասխանող սերվերին անցնելը։ Այդ պատճառով ախտանիշը մեռած կապի տեսք ունի, այլ ոչ DNS սխալի․ բրաուզերները արգելափակվում են, սպառում ժամանակը և երբեմն մատուցում են քեշավորված հասցե, որը հետագայում հնանում է։

Սա նաև բացատրում է, թե ինչու բողոքը գալիս է «ինտերնետը կոտրվել է» ձևով։ IP հասցեին ping-ը ապացուցում է, որ կապը լավ է, ինչի պատճառով խափանումը թվում է հավելվածի։ Լուծիչների ցանկն առաջին բանն է, որ պետք է կարդալ, և վերջինը, որ պետք է խմբագրել։

Առասպելը․ resolv.conf-ը կարգավորումների ֆայլ է

Հարցրեք, թե իրականում ինչ է ուղին, նախքան այն փոխելը․

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved ունեցող հոսթում դա սիմվոլիկ հղում է դեպի 127.0.0.53-ը ցույց տվող stub ֆայլ, և իրական սերվերներն ապրում են այն կապ-առանձին վիճակում, որը տպում է resolvectl-ը։ NetworkManager ունեցող հոսթում այն կարող է ֆայլ լինել, որը NetworkManager-ը գրում է ակտիվ կապից։ Որոշ արտադրողի հաճախորդներում այն սովորական ֆայլ է, որը միանալիս վերագրվում է տեղում և, եթե բախտ չունեք, անջատվելիս երբեք չի վերականգնվում։ Դրանք երեք տարբեր սեփականատերեր են, և առաջին երկուսը ձեռքով խմբագրելը կամ ոչինչ չի անում, կամ տևում է մինչև հաջորդ ցանցային իրադարձությունը։

resolvectl status-ը այն տեսքն է, որ ճշմարտությունն է ասում․ DNS սերվերներ ըստ կապի, երթուղային տիրույթներ և արդյոք թունելի կապը դեռ գոյություն ունի։ resolvectl query example.com-ը ավելի հեռու է գնում և ցույց է տալիս, թե որ ինտերֆեյսը պատասխանեց։ Օգտագործեք երկուսն էլ նախքան ֆայլին դիպչելը, և հիշեք, որ սեփական անվտանգ DNS ունեցող բրաուզերը անտեսում է այս ամենը։

Գտեք սեփականատիրոջը նախքան ինչ-որ բան խմբագրելը

Սովորաբար երեք բաղադրիչ մրցում են նույն կարգավորման համար․ systemd-resolved, NetworkManager և այն, ինչ տեղադրել է VPN հաճախորդը։ Նախ բացահայտեք կենդանին․

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Եթե resolved-ը ակտիվ է և սիմվոլիկ հղումը ցույց է տալիս նրա stub-ին, գլոբալ ֆայլը գեներացված ելք է, և ձեր խմբագրումը ձևական է։ Եթե NetworkManager-ն է տիրապետում կապին, սերվերները պատկանում են կապի պրոֆիլին, ուստի ուղղումը nmcli հատկության փոփոխություն է, ոչ թե ֆայլի խմբագրում։ Եթե արտադրողի դեմոն է աշխատում, միայն նրա սեփական վերականգնման ուղին է դիմանում հաջորդ միացմանը։

Մաքրեք հաճախորդի թողած կապի վիճակը

Սպանված հաճախորդը չի կարող գործարկել իր մաքրման կեռիկը։ SIGKILL-ը բացարձակապես հնարավոր չէ որսալ, մինչդեռ SIGINT-ը և SIGTERM-ը հնարավոր է, ուստի հարկադիր սպանությունից հետո «ուղղակի կանգնած» թունելը հաճախ տեղում է թողնում և՛ ինտերֆեյսի գրանցումը, և՛ լուծիչի գրառումը։ Գտեք կոնկրետ PID-ը և ազդանշանը ուղարկեք միայն նրան․

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Մի՛ ձեռք մեկնեք pkill -f vpn կամ killall vpn-ին, նախքան կարդալը ամբողջ համընկնումների ցանկը։ -f-ը համընկնում է ամբողջ հրամանի տողի հետ, ուստի կարող է վերջացնել փաթաթող սկրիպտ, խմբագրի նստաշրջան կամ անկապ պրոցես, որի ուղին պարունակում է այդ տողը։ Սխալ պրոցեսը աշխատանքի կեսին վերջացնելը հենց այն ձևն է, որով լուծիչի խնդիրը դառնում է կորցրած ֆայլ։

resolvectl revert-ը վերակայում է այդ կապի գործարման ժամանակի DNS կարգավորումը, ինչը ավելի նեղ է, քան լուծիչի վերագործարկումը և շատ ավելի նեղ, քան գլոբալ ֆայլի խմբագրումը։ Եթե թունելի կապն ամբողջովին վերացել է, systemctl restart NetworkManager-ը նորից կառուցում է կապի վիճակը, և դա այն քայլն է, որին աղբյուրի թելերը անընդհատ վերադառնում են։ Ուշադիր եղեք Restart=always ունեցող ծառայությունների կառավարչի նկատմամբ, քանի որ այն կարող է սպանված հաճախորդին և նրա DNS կարգավորումները ուղիղ վերադարձնել։

Մյուս ուղղությունը․ հրող DNS, որը երբեք չհասավ

Հնացած գրառման հայելային պատկերը թունել է առանց որևէ օգտակար լուծիչի։ Պրոֆիլում DNS ընտրանքը հարցում է․ կապը կառավարող բաղադրիչը պետք է այն հանձնի լուծիչին։ Եթե մատյանը ցույց է տալիս, որ սերվերը ստացվել է, բայց թունելի կապը ոչ մի DNS կարգավորում չի կրում, բացակայում է ինտեգրումը, ոչ թե սերվերը։

Փորձարկեք հանձնումը՝ կատարելով այն ձեռքով, ինչը բաժանում է «սերվերը սխալ է»-ը «ոչ ոք չկիրառեց»-ից․

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Ամեն ինչ որսացող երթուղային տիրույթը յուրաքանչյուր անուն ուղարկում է այդ կապին, ինչն ուզում է լրիվ թունելի հաճախորդը և ինչը չպետք է օգտագործի բաժանված DNS-ը։ Այս կարգավորումները անհետանում են հաջորդ միացման ժամանակ։ NetworkManager-ում դրանք մշտական դարձնելու համար անջատեք ավտոմատ DNS-ը, սերվերը դրեք կապի վրա և ավելացրեք տիրույթը․

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

Լուծումներ, որոնք դառնում են հաջորդ վթարը

resolv.conf-ը միանալուց առաջ պատճենելը և հետո վերականգնելը runbook-ում օրինական տող է, և դա լուծում է, ոչ թե վերանորոգում։ Այն ձախողվում է հենց այն պահին, երբ կարևոր է, որովհետև վթարը կամ հարկադիր վերագործարկումը բաց է թողնում վերականգնումը։ Գրառեք այն որպես լուծում, որպեսզի հաջորդ մարդը դրա վրա չկառուցի։

systemd-resolved-ի անջատումը և հանրային սերվերների կոշտ կոդավորումը մյուս սիրված քայլն է։ Այն կանխատեսելի է դարձնում միանալն ու անջատվելը և հեռացնում է կապ-առանձին DNS-ը բոլոր մյուս ցանցերի համար, ինչը կոտրում է ներքին անունների բաժանված DNS-ը և զրոյացնում է թունելի նպատակը, որը նախատեսված է հարցումները ներսում պահելու համար։ resolvconf-ի տեղադրումը և հանրային սերվերների ամրագրումը նույն արժեքն ունի լրացուցիչ շերտով։ Վերաբերվեք դրանցից ցանկացածին որպես ախտորոշում․ եթե այն վերականգնում է դիտարկումը, դուք իմացաք, որ լուծիչի ինտեգրումն է մեղավոր, ոչ թե այն, որ հանրային սերվերները ճիշտ են։

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