OpenVPN-ის საათობრივი წყვეტა: განახლებული მოლაპარაკება თუ ნამდვილი ხელახალი დაკავშირება?

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

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

განასხვავეთ რბილი გადატვირთვა გადატვირთვისგან

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

წაიკითხეთ მოქმედი ტაიმერი და არა თქვენი ფაილი

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

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

შეცვალეთ იქ, სადაც ის რეალურად უბიძგება

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

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

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

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

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

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

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

კონფიგურაციაში ორი მეზობელი მსგავს სიმპტომებს და განსხვავებულ შესწორებებს იძლევა. ping-restart გადატვირთავს გვირაბს, როცა დაყენებული პერიოდის განმავლობაში არაფერი მოდის, ხოლო ping-exit კლიენტს სრულიად ხსნის. უმოქმედობის წყვეტა, ჟურნალში სადმე განახლებული მოლაპარაკების გარეშე, ამათ ეკუთვნის, ან NAT მოწყობილობას, რომელმაც UDP-ის რუკა საკუთარი გრაფიკით ამოწურა.

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

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