თქვენი CIFS-მაუნტი VPN-ზე nsswitch-ის რიგის გამო ვერ ფუნქციონირებს

გვირაბი აწეულია. ფაილური სერვერი 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-ის პრობლემაა მეორე მხარეს. ამოუხსნელი სახელი გამხსნელის პრობლემაა. ხოლო მაუნტი, რომელიც ავთენტიფიკაციას გადის, მაგრამ ნებართვის შეცდომებს აბრუნებს, არც ერთია და არც მეორე, ამიტომ ნუ გახსნით ხელახლა ქსელის კითხვას, როცა სესია უკვე დამყარებულია.

შეინახეთ დასკვნა ისე ვიწრო, როგორც მტკიცებულება. როცა მისამართი მუშაობს და სახელი არა, გვირაბი თავის საქმეს აკეთებს და გასწორება გამხსნელის რიგს, საძიებო დომენს ან თავად კონტეინერის კონფიგურაციას ეკუთვნის.