OpenVPN-ის მიერ DNS-ის გადაცემის შემდეგ ლოკალური Samba გაზიარება გაქრა

Samba კარგავს ლოკალურ გაზიარებებს იმ მომენტში, როცა OpenVPN უკავშირდება, და გვირაბი თითქმის არასოდეს არის მიზეზი. მიმაგრება რიგზეა, NAS მუშაობს, და გვირაბის მიერ დაყენებული რეზოლვერი პასუხობს კითხვებს სახელზე, რომელიც არასოდეს უნახავს. Samba ამ რეზოლვერს ეკითხება თავისი ძებნის რიგის დასაწყისში, სჯერა პასუხის და უკავშირდება მისამართს, სადაც არაფერი უსმენს. გაზიარების შეკეთება ნიშნავს პასუხის შეკეთებას და არა მიმაგრების.

ხუთი შემოწმება, იმ რიგით, რომელიც ყოველ ნაბიჯზე ყველაზე მეტ შესაძლებლობას გამორიცხავს.

ვინ პასუხობს მოკლე სახელს

ჰკითხეთ ოპერაციულ სისტემას და არა ფაილების მენეჯერს. resolvectl status ბეჭდავს თითოეულ კავშირზე მიმაგრებულ DNS სერვერებს და აღნიშნავს, რომელი კავშირია ნაგულისხმევი მარშრუტი, ხოლო მოკლე სახელზე მოთხოვნა აცნობებს პასუხის გამცემ სერვერს. გაუშვით ის ერთხელ NAS-ის სახელისთვის და ერთხელ იმ სახელისთვის, რომელიც იცით, რომ ოფისის დომენში არსებობს. თუ ორი პასუხი სხვადასხვა სერვერიდან მოდის, თქვენ იპოვეთ გაყოფა.

შეამოწმეთ, პასუხი უარყოფითი პასუხი იყო თუ მისამართი. უარყოფითი პასუხი ნიშნავს, რომ Samba სხვა მექანიზმზე უნდა გადასულიყო, და ხარვეზი სხვაგანაა. მისამართი ნიშნავს, რომ Samba რეალურ ადგილს დაუკავშირდა და ვერაფერი მიიღო.

რატომ სჯერა Samba არასწორ პასუხს

Samba სახელებს ხსნის name resolve order-ით განსაზღვრული ფიქსირებული თანმიმდევრობით. დისტრიბუტივების უმეტესობაში ნაგულისხმევი მოიცავს host-ს, რაც ნიშნავს DNS-ს, და ის მუშაობს NetBIOS მაუწყებლობის მსგავს მხოლოდ ლოკალური ქსელის მექანიზმებამდე. ამიტომ რეზოლვერის გადამცემი გვირაბი იღებს პირველი უარის უფლებას ყოველ გაზიარების სახელზე, მათ შორის ერთი ეტიკეტის სახელებზე, რომლებსაც შენობის დატოვება არასოდეს უნდა დასჭირვებოდა.

ჩვეულებრივ უცნობი სახელი აბრუნებს უარყოფით პასუხს და შემდეგი მექანიზმი იღებს რიგს. ზოგიერთი რეზოლვერი, განსაკუთრებით სამომხმარებლო ISP-ების და საჯარო რეზოლვერები, უცნობ სახელებს პასუხობს საძიებო გვერდით ან სარეკლამო მისამართით. ეს პასუხი რეზოლვერის ბიბლიოთეკას წარმატებად ეჩვენება, ამიტომ Samba წყვეტს ძებნას და აკრეფს მისამართს, რომელსაც თქვენს ქსელთან არაფერი აქვს საერთო.

შედეგი არის გაზიარება, რომელიც ქრება შეცდომის დიალოგის გარეშე. ამ თანმიმდევრობაში არაფერი არ არის VPN მარშრუტიზაციის ხარვეზი, ამიტომ NAS-ზე ping კვლავ მუშაობს, მაშინ როცა მასზე დათვალიერება არ მუშაობს.

განსხვავებული მოცულობის ორი შეკეთება

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

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

თუ ამ სიაში host არ არის, DNS გადის გაზიარების ძებნის გზიდან, და ერთი ეტიკეტის სახელები რჩება ლოკალურ სეგმენტზე. ოფისის სახელები კვლავ ჩვეულებრივად იხსნება ყველა სხვა პროგრამისთვის, რადგან ეს მხოლოდ Samba-ს ცვლის. ფასი ის არის, რომ Samba საერთოდ ვეღარ იყენებს DNS-ს, ამიტომ სრულად კვალიფიციური ოფისის სახელით მისამართებული გაზიარება პრობლემად იქცევა.

ფართო შეკეთება აშორებს მიზეზს: შეწყვიტეთ იმ რეზოლვერის გადაცემა, რომელიც პასუხობს სახელებს, რომლებიც მისი არ არის, ან გადასცით გაყოფილი DNS პოლიტიკა, რომ ოფისის რეზოლვერამდე მხოლოდ ოფისის სუფიქსები მივიდეს. ეს უკეთესი გრძელვადიანი პასუხია მართულ ქსელში, რადგან იცავს ბრაუზერსაც და პაკეტების მენეჯერსაც, მაგრამ მოითხოვს ადმინისტრაციულ წვდომას სერვერის მხარეს და კლიენტს, რომელიც ემორჩილება გადაცემულ პარამეტრებს.

აირჩიეთ ერთი განზრახ. რეზოლვერის ცვლილება ერთდროულად ცვლის სახელების გარჩევას ყველა აპლიკაციისთვის, რაც ცვლილების ჩანაწერია და არა მხარდაჭერის ზარისთვის განკუთვნილი რედაქტირება.

სუფიქსმა შეიძლება ყველაფერი ახსნას

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

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

დაამტკიცეთ ხელახალი დაკავშირების შემდეგ

სცადეთ სამი სახელი ერთ სესიაში: ლოკალური გაზიარება მოკლე სახელით, ოფისის ჰოსტი სახელით და ჩვეულებრივი ვებსაიტი. თუ პირველი მუშაობს და მეორე ტყდება, შეკეთებამ ხარვეზი გადაადგილა და არა აღმოფხვრა. თუ მესამე ტყდება, რეზოლვერის ცვლილებამ ჩაფიქრებულზე შორს წავიდა და ყოველი ძებნა ახლა საეჭვოა.

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

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