ip netns exec և DNS — ինչու են անունները ձախողվում անվանատարածքի ներսում

Հրամանը հասնում է 10.8.0.5 հասցեին VPN անվանատարածքի ներսում առանց որևէ բողոքի, և նույն հրամանը ձախողվում է այն պահին, երբ օգտագործում է հոսթի անուն։ Անվանատարածքն ունի իր ինտերֆեյսները, երթուղիները և սոկետները, բայց չունի իր լուծիչի ֆայլը։ Եթե ինչ-որ բան այնտեղ մեկը չդնի, ներսի պրոցեսը կարդում է հոսթի /etc/resolv.conf ֆայլը և հարցնում է սերվերից, որը գուցե հասանելի չէ այդ ցանցային փաթեթից։

Սա ֆայլի ընտրության խնդիր է, ոչ թե երթուղավորման խնդիր, և հենց դրա համար է, որ թվային նպատակակետը դեռ աշխատում է։

Ստուգեք լուծիչի այն տեսքը, որը պրոցեսն իրականում ստանում է

Մի՛ ենթադրեք, որ ձեր օգտագործած shell-ը համարժեք է այն պրոցեսին, որը դուք վրիպազերծում եք։ Գրաֆիկական հավելվածը, systemd միավորը և կոնտեյները կարող են յուրաքանչյուրը մտնել այլ mount կամ ցանցային համատեքստ։ Գործարկեք որոնումը նույն գործարկման ուղով, և տպեք լուծիչի ֆայլը ներսից։

ip netns add-ով ստեղծված անվանատարածքի համար միայն կարդալու ստուգումը կարճ է՝

ip netns exec vpn cat /etc/resolv.conf

Ուշադրություն դարձրեք՝ արդյոք արդյունքը նշում է հասանելի հասցե, loopback-ի stub, թե այլ հասանելիությամբ տեղ ցույց տվող խորհրդանշական հղում։

Ինչ է իրականում mount անում exec-ի օգնականը

ip-netns գործիքը փաստագրում է յուրաքանչյուր անվանատարածքի կարգավորումը /etc/netns/NAME/-ի ներքո։ Երբ այն պրոցես է գործարկում, օգնականը ստեղծում է mount անվանատարածք և այդ ֆայլերը mount է անում դրանց սովորական ուղիների վրա, այնպես որ պրոցեսը տեսնում է անվանատարածքին հատուկ պատճենը։ Սա այս կոնկրետ գործարկիչի հարմարավետությունն է։ Ցանցային անվանատարածք մեկ այլ ճանապարհով մտնելը, օրինակ unshare-ով կամ կոնտեյների runtime-ով, դա ինքնաշխատ չի վերարտադրում։

Այստեղ որոգայթը loopback լուծիչն է՝ 127.0.0.53 նշանակում է անվանատարածքի սեփական loopback-ը, ոչ թե հոսթի stub-ը։ Stub-ը, որը լսում է միայն հոսթի անվանատարածքում, նորում ծառայություն չի դառնում։

Ընտրեք լուծիչ, որին անվանատարածքը կարող է հասնել

Ինչ սերվեր էլ ֆայլը նշի, այն դեռ երթուղի է պահանջում այդ անվանատարածքից։ Հանրային լուծիչը կարող է պատասխանել հանրային անուններին և այնուամենայնիվ ձախողվել ներքին գոտու համար, որովհետև մասնավոր ծառայությունը հասանելի է միայն թունելով։ Ստուգեք երթուղին հասցեի հետ միաժամանակ, ոչ թե այն բանից հետո, երբ որոնումն արդեն ձախողվել է։

Սեփական լուծիչ ունեցող հավելվածները, օրինակ DNS over HTTPS օգտագործողը, կարող են ամբողջությամբ անտեսել ֆայլը։ Եթե գործիքն ունի իր DNS կարգավորումը, resolv.conf-ը փոխելը դրա վրա չի ազդի, և անվանատարածքը երբեք խնդիրը չի եղել։

Գրեք ֆայլը ճիշտ տեղում

Ստեղծեք անվանատարածքին հատուկ ֆայլը /etc/netns/NAME/resolv.conf-ի ներքո և թողեք գործարկիչը ներկայացնի այն։ Պահեք այն նվազագույն՝ մեկ կամ երկու հասանելի սերվեր և առաջադրանքի համար անհրաժեշտ որոնման դոմեններ։ Մի՛ խմբագրեք հոսթի գեներացված լուծիչի ֆայլը՝ պրոցեսների մի խմբի համար նախատեսված տեսքը շտկելու համար, որովհետև դա փոխում է մեքենայի յուրաքանչյուր հավելված։ Եթե հոսթն օգտագործում է լուծիչի կառավարիչ, անվանատարածքի ուղին կարգավորեք այդ կառավարչի միջոցով՝ դրա դեմ պայքարելու փոխարեն։

Գրանցեք ֆայլի բովանդակությունը runbook-ում։ Հակառակ դեպքում հաջորդ մարդը կստուգի հոսթի լուծիչը, կտեսնի աշխատող պատասխան և կեզրակացնի, որ անվանատարածքը կարգին է։

Կրկին ստուգեք ամբողջ ուղին

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

Հաստատեք, որ ֆայլը ստանում է պրոցեսը, ոչ թե shell-ը։ Այն որոնումը, որն աշխատում է ինտերակտիվ shell-ից և ձախողվում է ծառայությունից, mount-ի համատեքստի մասին հայտնագործություն է, և արժե այն գրի առնել հաջորդ միջադեպից առաջ՝ զրոյից նորից բացահայտելու փոխարեն։