პორტი 1194 უკვე გამოყენებულია: ვის ეკუთვნის ეს OpenVPN სოკეტი?

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

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

წაიკითხეთ ზუსტი დაკავშირების შეცდომა

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

შეადგინეთ სოკეტების აღრიცხვა, არა პორტის

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

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

გაარკვიეთ რომელი პროცესი ფლობს მას

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

ერთი მფლობელი, თუ ორი დაპროექტებული ინსტანცია

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

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

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

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

ყველაფერზე ადრე გადაამოწმეთ დაკავშირება

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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