dnsmasq 53 პორტს ვერ აბამს: იპოვეთ სოკეტი, რომელიც მას ფლობს

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

ხუთი ნაბიჯი ამ თანმიმდევრობით: გაამეორეთ შეცდომა, ჩამოთვალეთ მსმენელები, გაიგეთ wildcard, დაავალეთ სამუშაო და შემდეგ გადაამოწმეთ.

ნაბიჯი 1: შეცდომის გამეორება და წაკითხვა

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

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

ნაბიჯი 2: მფლობელების ჩამოთვლა

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

ss -lntup 'sport = :53'

წაიკითხეთ გამომავალი სვეტებად: ტრანსპორტი, ლოკალური მისამართი, პორტი, პროცესი. TCP მსმენელი და UDP მსმენელი ცალკე სოკეტებია, ამიტომ ერთის შეჩერება მეორეს არ ათავისუფლებს. wildcard მისამართი ფარავს ყველა ინტერფეისს, რაც ნიშნავს, რომ VPN-ის მისამართი უკვე დაკავებულია, თუმცა არც ერთი ხაზი არ ახსენებს მას სახელით. ხოლო პროცესის სახელი გეუბნებათ, ეს დისტრიბუტივის მიერ მართული resolver-ია, კონტეინერი თუ ის, რაც წინა ექსპერიმენტმა მუშა მდგომარეობაში დატოვა.

ნაბიჯი 3: wildcard-ის ხაფანგი

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

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

ნაბიჯი 4: სამუშაოს დავალება

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

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

ნაბიჯი 5: სოკეტის შემოწმება, შემდეგ გზის

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

სამი ცალკე შედეგი, რომლებიც ერთმანეთისგან უნდა გაიმიჯნოს: სოკეტი არსებობს, კლიენტი აღწევს მას, პასუხი სწორია.

რა არ უნდა გააკეთოთ

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

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