OpenVPN-ის კლიენტი ჩერდება, როცა მისი სერვერი იმავე ჰოსტზე მუშაობს
ერთ ჰოსტზე ორი OpenVPN ინსტანცია ერთსა და იმავე ლოკალურ პორტსა და მარშრუტიზაციის ცხრილს ეჯიბრება. დაამაგრეთ პორტი, გაყავით მოწყობილობები და შეამოწმეთ რომელი ცხრილი იმარჯვებს.
მქონდა ლაბორატორიული მანქანა, რომელიც შორეული საიტიდან გვირაბს იღებდა და ამავდროულად მომწოდებლის ქსელში რეკავდა. გამავალი პროფილი კვირების განმავლობაში მუშაობდა. შემავალი სერვერის დამატების შემდეგ, გამავალი დაუკავშირდა და შემდეგ რამდენიმე წამში შეწყვიტა ტრაფიკის გატარება, ან უარი თქვა გაშვებაზე „მისამართი უკვე გამოყენებულია“ შეცდომით. კონფიგურაციის ფაილები არ შეცვლილა; ჰოსტმა უბრალოდ შეიძინა მეორე OpenVPN პროცესი, პორტებსა და მარშრუტებზე საკუთარი აზრით.
მარცხი შემთხვევითი არ არის და ეს ავთენტიფიკაციის პრობლემა არ არის. ერთ მანქანაზე ორი დემონი ეჯიბრება ერთსა და იმავე ლოკალურ სოკეტსა და იმავე მარშრუტიზაციის ცხრილს, და რომელიც ბოლოს იწყებს ან ხელახლა უკავშირდება, ჩვეულებრივ იმარჯვებს. იმის ცოდნა, თუ ამ ორი შეჯახებიდან რომელი გაქვთ, განსაზღვრავს, სად უნდა შეხედოთ პირველად.
წაიკითხეთ სიმპტომი უკუღმა
დაიწყეთ იმით, როდის კვდება გვირაბი. bind შეცდომა გაშვებისას მიუთითებს მოსმენის მხარეს: რაღაც უკვე ფლობს ამ პორტს, და OpenVPN უარს ამბობს გაშვებაზე, ნაცვლად იმისა, რომ გაიზიაროს იგი. გვირაბი, რომელიც ადის და შემდეგ დუმს, მიუთითებს მარშრუტიზაციაზე, რადგან მეორე ინსტანციის მიერ დაყენებულმა მარშრუტმა შეიძლება გარე კავშირის პაკეტები მათი გზიდან გამოწიოს.
ორივე შემთხვევა ერთსა და იმავე მომხმარებლის საჩივარს წარმოშობს, ამიტომ განმეორებითი ცდების ციკლები და საგუშაგო სკრიპტები ვერაფერს არ ასწორებს. ისინი კლიენტს ისევ იმავე კონფლიქტში აკავშირებენ. პირველი სასარგებლო კითხვაა, გრძელდება თუ არა პროცესი, როცა ტრაფიკი ჩერდება.
ერთი სოკეტი და ერთი მოწყობილობა თითო ინსტანციაზე
მოსმენადი სერვერი ამაგრებს თავის პორტს; გამავალ კლიენტსაც სჭირდება ლოკალური პორტი მისი ინკაფსულირებული ტრაფიკისთვის. როცა ორივე ერთ ჰოსტზე ცხოვრობს, კლიენტის ნაგულისხმევი ქცევა შეიძლება დაეჯახოს სერვერის პორტს. კლიენტის ლოკალური პორტის დამაგრება შესაძლებელია, და დაკავშირება შეიძლება გამოტოვდეს იქ, სადაც პარტნიორს ფიქსირებული წყაროს პორტი არ სჭირდება:
lport 1195
nobind
dev tun1ეს რიცხვები მაგალითებია და არა მოთხოვნა. მთავარია, რომ კლიენტმა შეწყვიტოს სერვერის პორტისთვის ბრძოლა და თითოეულმა ინსტანციამ ცალკე გვირაბის მოწყობილობა მიიღოს. ორი დემონი, რომლებიც tun0-ს იზიარებენ, ერთმანეთის მოწყობილობის მდგომარეობას გადაწერს მაშინაც კი, როცა მათი პორტები განსხვავდება, ამიტომ თითო გვირაბზე ერთი მოწყობილობა სავალდებულოა.
nobind კლიენტის მხარეს ეკუთვნის. სერვერმა მაინც უნდა დაამაგროს და მოუსმინოს, ამიტომ ნუ დააკოპირებთ ხაზს სერვერის კონფიგურაციაში და ნუ გამორთავთ დამაგრებას კლიენტზე, რომლის პარტნიორიც ფიქსირებულ წყაროს პორტზე ფილტრავს.
აირჩიეთ ერთი მფლობელი ნაგულისხმევი მარშრუტისთვის
მხოლოდ ერთ კავშირს შეუძლია ნაგულისხმევი მარშრუტის დაყენება. თუ ორივე პროფილი მთელ ტრაფიკს გადამისამართებს, მეორე კავშირი ჩუმად ცვლის პირველს და პირველი გატეხილად გამოიყურება. ან შეინარჩუნეთ გამავალი გვირაბი გაყოფილი და გაუშვით მხოლოდ მომწოდებლის პრეფიქსები, ან მიეცით მას ცალკე მარშრუტიზაციის ცხრილი.
ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2ზემოთ მოცემული მისამართები და ცხრილის ნომერი დროებითი ადგილსამყოფელებია. წესის დამატებისთანავე დაადასტურეთ, რომ VPN სერვერის საკუთარი მისამართი კვლავ ჩვეულებრივი ცხრილის მეშვეობით წყდება; ცხრილი, რომელიც გარე ტრანსპორტს იჭერს, ამტვრევს იმ გვირაბს, რომლის დაცვაც უნდა ყოფილიყო, და შემდგომი ხელახალი კავშირის ციკლი არასანდო პროვაიდერის მსგავსი ჩანს.
კონფიგურაციისთვის, რომელმაც უნდა გაუძლოს ხელახალ კავშირებსა და გადატვირთვებს, ქსელური სახელთა სივრცე უფრო მტკიცე საზღვარია. მეორე კლიენტი მუშაობს საკუთარ სახელთა სივრცეში საკუთარი ინტერფეისებითა და მარშრუტებით, და ვლინდება მხოლოდ ის სერვისები, რომლებმაც საზღვარი უნდა გადაკვეთონ. ჰოსტი ინარჩუნებს ერთ ნაგულისხმევ მარშრუტს და სახელთა სივრცის ხელახალი კავშირი ვერ გადაწერს მას.
გადაამოწმეთ ცხრილით და არა სტატუსის ხაზით
კლიენტი, რომელიც აცხადებს, რომ დაკავშირებულია, მხოლოდ თავის საკონტროლო არხს ამტკიცებს. დააფიქსირეთ მარშრუტიზაციის მდგომარეობა ყოველ კავშირამდე და მის შემდეგ, შემდეგ ჰკითხეთ ბირთვს, რომელ მოწყობილობას გამოიყენებდა რეალური დანიშნულება:
ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194თუ მომწოდებლის მისამართისთვის არჩეული მოწყობილობა იცვლება მეორე გვირაბის გაშვებისას, გაქვთ მარშრუტების შეჯახება. თუ ორივე პროცესი ერთსა და იმავე ლოკალურ პორტზე ჩნდება, გაქვთ სოკეტების შეჯახება. პირველის გასწორება მეორის გარეშე მხოლოდ მარცხს გადაიტანს შემდეგ ხელახალ კავშირზე.
ჩაწერეთ პორტები, მოწყობილობები, ცხრილები და მარშრუტის მფლობელი ჰოსტის runbook-ში. წინააღმდეგ შემთხვევაში, მესამე გვირაბის დამამატებელი შემდეგი ადამიანი კვლავ აღმოაჩენს იმავე შეჯახებას და ერთადერთი ხილული მტკიცებულება იქნება კავშირი, რომელიც მუშაობს მანამ, სანამ ვინმე სხვისი დემონი ხელახლა არ გადაიტვირთება.