OpenVPN წყდება DHCP განახლების შემდეგ: შეინარჩუნეთ ბოლო წერტილის მარშრუტი

გვირაბი უკავშირდება, შემდეგ წვდომის რგოლზე იჯარის განახლება კლავს მას, და ჟურნალი მარშრუტის ნაცვლად დროის ამოწურვას ადანაშაულებს. VPN-ის კონფიგურაციაში არაფერი შეცვლილა და ეს არის მინიშნება: შეიცვალა რაღაც მის გარეთ. DHCP მოვლენამ გადაწერა მისამართი ან კარიბჭე, და ჰოსტის მარშრუტი, რომელიც გვირაბის ბოლო წერტილს ხელმისაწვდომად ინარჩუნებდა, ახლა მიუთითებს შემდეგ ნახტომზე, რომელიც აღარ არსებობს. ეს საკუთრების პრობლემაა, სანამ მარშრუტიზაციის პრობლემა გახდება.

შეადარეთ სიმპტომი ნახევრად ნაგულისხმევ მარშრუტებს

redirect-gateway def1-ით OpenVPN აყენებს 0.0.0.0/1-ს და 128.0.0.0/1-ს ნაგულისხმევი მარშრუტის შეცვლის ნაცვლად. ერთად ეს ორი მთელ მისამართთა სივრცეს ფარავს და 0.0.0.0/0-ს მხოლოდ პრეფიქსის სიგრძით სძლევს. ამიტომ ნებისმიერი დანიშნულება უფრო კონკრეტული დამთხვევის გარეშე გვირაბში შედის.

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

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

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

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

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

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

აიღეთ სამი სურათი და არა ერთი

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

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

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

გადაწყვიტეთ, რომელი კომპონენტი აახლებს გამონაკლისს

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

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

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

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

აიძულეთ განახლება dhcpcd -n eth0-ით ან იჯარის გაშვებით და ხელახლა აღებით, შემდეგ კვლავ შეამოწმეთ ip route get ბოლო წერტილისთვის. გააკეთეთ ეს ორჯერ, რადგან მეორე გავლა იჭერს კაუჭებს, რომლებიც დუბლირებულ მარშრუტებს ამატებენ. შემდეგ გადატვირთეთ, რადგან მდგრადობა სხვა თვისებაა, ვიდრე სისწორე.

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