SSH VPN-ზე ყოველ წუთს წყდება? მიზეზი keepalive არ არის

განმეორებადი ინტერვალით მომაკვდავი სესია ჩვეულებრივ firewall-ის მდგომარეობას კარგავს და არა keepalive-ებს. ორივე მიმართულება გამოიკვლიეთ, სანამ MTU-ს ან ტაიმერებს შეეხებით.

SSH უკავშირდება, დაახლოებით ერთი წუთი მუშაობს და შემდეგ ყოველ ჯერზე დაახლოებით იმავე ინტერვალზე იყინება. გავრცელებული ახსნა idle timeout-ია, ამიტომ ადამიანები MTU-ს ამცირებენ და კლიენტის keepalive-ებს აყენებენ. WireGuard-ის ის კავშირი, რომელზეც ვმუშაობდი, უკვე ამ ყველაფერს გავლილი ჰქონდა: უფრო პატარა გვირაბის MTU, client-alive პარამეტრები, კონფიგურირებული გვირაბის keepalive. წყვეტები უცვლელად გრძელდებოდა. მიზეზი ასიმეტრიული LAN მარშრუტი აღმოჩნდა, და ეს ნიმუში ცნობადია, რადგან ის ტაიმერებზე დაფუძნებულ ყველა გასწორებას ამარცხებს.

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

მითი: keepalive-ები ჩუმ წყვეტას ასწორებს

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

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

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

რას აკეთებს სინამდვილეში დამატებითი gateway

მოათავსეთ ლეპტოპი და VPN gateway იმავე LAN-ში, ცალკე LAN firewall-ით ნაგულისხმევ gateway-ად. ლეპტოპი VPN-ისკენ მიმავალ ტრაფიკს firewall-ს უგზავნის, firewall გადასცემს მას gateway-ს, და gateway-ის პასუხები პირდაპირ ბრუნდება LAN-ზე ლეპტოპთან. ის მეორე ფეხი არასოდეს გადის firewall-ში, ამიტომ მისი მდგომარეობის ცხრილი ნახევარ კავშირს ინახავს.

ქვემოთ მოცემული მისამართები ასახავს ამ განლაგებას:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

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

აირჩიეთ ერთი განზრახ გზა

ზემოთ მოცემული განლაგებისთვის, დისტანციური ქვექსელის პირდაპირ VPN gateway-ზე მარშრუტიზაცია აშორებს ნახევარ კავშირს:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

ეს სანიმუშო მისამართებია. შემდეგი hop უნდა იყოს მისაწვდომი თქვენს LAN-ში, prefix უნდა იყოს განზრახული დისტანციური ქსელი, და მეორე ბრძანება გიჩვენებთ შედეგს, სანამ მას დაეყრდნობით. თუ gateway თქვენს ქვექსელში არ არის, ეს მარშრუტი არ არის ის გასწორება, რომელიც გსურთ.

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

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

გამოსცადეთ ორივე ბოლოდან

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

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

როდის არის ასიმეტრია ნორმალური

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

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

დაკავშირებული სტატიები