Ձեր CIFS-մոնտաժը VPN-ի միջով ձախողվում է nsswitch-ի հերթականության պատճառով

Կիսվածքը պատասխանում է հասցեով և կախվում է անունով, ուստի որոնումը մահանում է նախքան SMB-ի սկսվելը։ Համեմատեք getent-ը host-ի հետ, ապա կարդացեք hosts տողը հերթականությամբ։

Թունելը բարձրացված է։ Ֆայլային սերվերը պատասխանում է ping-ին հասցեով։ Հետո mount.cifs հոսթի անվան հետ որոշ ժամանակ նստում է այնտեղ և հայտնում, որ հոսթը հասանելի չէ, և դուք սկսում եք վերակառուցել VPN պրոֆիլ, որը երբեք խնդիրը չի եղել։ Linux-ում glibc-ն լուծում է անունը նախքան որևէ SMB փաթեթի գոյությունը, և այդ լուծիչի հերթականությունը կարող է ավարտել որոնումը նախքան DNS-ից ընդհանրապես հարցնելը։ Ահա այն ուղին, որով ես անցնում եմ՝ սկսելով ձախողված հրամանից, ոչ թե հաճախորդից։

Կարդացեք ձախողումը ճիշտ տեղում

Երկու գործիք տարբեր ուղիներով գնում են նույն անվանը, և դրանց համեմատումը մեկ հրաման արժե։ getent անցնում է կազմաձևված անվանական ծառայությունների փաթեթով. host և dig հարցնում են DNS-ին ուղղակիորեն և անտեսում այդ փաթեթը։ Եթե ուղղակի հարցումը վերադարձնում է հասցե, իսկ getent ոչինչ չի վերադարձնում, ապա DNS սերվերը հասանելի է, և ձեր լուծիչի կազմաձևն է, որ ձախողվում է։

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Երրորդ հրամանը վճռիչն է. այն պարտադրում է DNS աղբյուրը և բաց թողնում փաթեթի մնացած մասը։ Երբ այն աշխատում է, իսկ սովորական getent-ը՝ ոչ, դուք ապացուցել եք, որ մեղավորը հերթականությունն է, ոչ թունելը և ոչ սերվերը։

hosts տողը հաջորդականություն է, որը վաղ է կանգ առնում

glibc-ի լուծիչը կարդում է /etc/nsswitch.conf-ը և անցնում hosts: գրառումը ձախից աջ։ Շատ դիստրիբուտիվներ տրամադրում են տող, որտեղ multicast որոնումը գալիս է առաջինը՝ վաղ վերադարձի գործողությամբ կցված։ Գործողությունը զարդարանք չէ. երբ mDNS-ը պատասխանում է “not found”, [NOTFOUND=return]-ը վերջացնում է ամբողջ որոնումը, ուստի կորպորատիվ անունը երբեք չի ուղարկվում այն լուծիչին, որը VPN-ն է պարտադրել։ Ոչինչ դա չի մատյանագրում, որովհետև ոչ մի հարցում չի ուղարկվել, որը լուծիչը կարող էր մերժել։ Այդ պատճառով մոնտաժը կարծես կախված է, ապա հայտնում է անհասանելի հոսթի մասին։

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

DNS-ը տեղափոխեք վաղ վերադարձի գործողությունից առաջ, փոխանակ mDNS-ը ջնջելու, և փոխեք այն կազմաձևի կառավարման միջոցով։ Ձեռքով ուղղումը ապրում է մինչև հաջորդ պատկերի կառուցումը, և հետո նույն տոմսը գալիս է այլ մեքենայից, որը չի հիշում ուղղումը։

Լուծիչը որոնման դոմեն չէ

Լուծմանը պետք է նաև, որ անունը փորձվի։ fileserver-ի նման չորակավորված անունը դառնում է fileserver.corp.example միայն այն ժամանակ, երբ հարցումը կրող ինտերֆեյսին կցված է որոնման դոմեն։ VPN-ն, որը պարտադրում է DNS սերվեր առանց որոնման ցանկի, ստեղծում է շատ որոշակի բաժանում. լրիվ որակավորված անունը լուծվում է, իսկ յուրաքանչյուր կարճ անուն ձախողվում է.

Փորձեք երկու ձևն էլ նախքան պրոֆիլը խմբագրելը, որովհետև երկու ձախողումները տարբեր ուղղություններ են ցույց տալիս։ systemd-resolved ունեցող հոսթում թունելի կապն ունի իր սերվերներն ու երթուղային դոմենները, ուստի կարդացեք կապը, ոչ թե գլոբալ ֆայլը։

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Եթե հարցումը վերագրվում է կապի, որը չի կրում թունելը, երթուղային դոմենը բացակայում է, թեև DNS հասցեն առկա է։ Դա քաղաքականության խնդիր է resolved-ի կազմաձևում, ոչ թե երթուղային խնդիր թունելում։

Կոնտեյներները կրում են պատասխանի իրենց պատճենը

Ընդհանուր պատկերից կառուցված կոնտեյները սովորաբար տրամադրում է ֆիքսված resolv.conf։ Հոսթի վրա արված լուծիչի փոփոխությունները չեն հասնում դրան, ոչ էլ որոնման դոմենը, ուստի թունելով կիսվածք մոնտավորող build աշխատանքը ձախողվում է, մինչդեռ նույն հրամանը կոնտեյներից դուրս աշխատում է։ Տվեք կոնտեյներին իր սեփական DNS և որոնման կարգավորումները compose ֆայլում կամ run արգումենտներում, ոչ միայն հոսթի պրոֆիլում։

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

Միայն այդ ժամանակ նայեք կիսվածքին և զտիչին

Երբ անունը լուծվում է, մնացած ձախողումները սովորական ցանցային են։ SMB-ին պետք է TCP 445 դեպի սերվեր, և աշխատանքային խմբի ցանկի զննումը կախված է անվանական ծառայություններից, որոնք թունելը հավանաբար չի փոխանցում։ Քարտեզագրեք ըստ հոսթի անվան՝ ցանկի լցվելուն սպասելու փոխարեն, և թող հաճախորդը ձեզ ասի, թե որ փուլին է հասել։ Մերժված կապակցումը և լուռ timeout-ը նույնպես արժե տարբերել, որովհետև առաջինը սովորաբար նշանակում է, որ ինչ-որ բան պատասխանել է, իսկ երկրորդը՝ որ ոչինչ։

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Լուծված հասցեն՝ 445 պորտով մերժված կամ ժամկետանց, հրդեհային պատի կամ listener-ի խնդիր է մյուս կողմում։ Չլուծված անունը լուծիչի խնդիրն է։ Իսկ մոնտաժը, որը նույնականացնում է, բայց թույլտվության սխալներ է վերադարձնում, ոչ մեկն է, ոչ մյուսը, ուստի չվերսկսեք ցանցի հարցը, երբ սեսիան արդեն հաստատված է։

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

Առնչվող հոդվածներ