SSH ServerAliveInterval VPN-ის გავლით: რომელი მხარე აგზავნის პრობას?

SSH სესიის ცოცხლად შენარჩუნების რჩევების უმეტესობა ჩერდება ფრაზაზე «დაამატე ServerAliveInterval 30» და სასარგებლო ნაწილებს გარეთ ტოვებს. საკვანძო სიტყვა არის კლიენტის მხარის ტაიმერი, რომელიც ირთვება მხოლოდ მაშინ, როცა არხი დუმდა, ის ითვლის უპასუხო პრობებს და არა წამებს, და ცხოვრობს ფაილში, სადაც იმარჯვებს პირველი დამთხვევა მნიშვნელობა. შეცდით ამ სამ თვისებაში და ჯანსაღი VPN სესია მაინც ჩავარდება, მაშინ როცა მკვდარი ჩამოკიდებული დარჩება.

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

ServerAliveInterval-ს კითხულობს თქვენი ssh კლიენტი. ClientAliveInterval-ს კითხულობს შორეული მხარის sshd და ამოწმებს საპირისპირო მიმართულებით, სერვერიდან კლიენტისკენ. ისინი არ არიან სინონიმები და არ თანამშრომლობენ, ამიტომ ერთის დაყენებას არანაირი გავლენა არ აქვს მეორე მხარის ქცევაზე. მათი ერთმანეთში არევა ჩვეულებრივი მიზეზია იმისა, რომ შესწორება თითქოს ერთ ჰოსტზე მუშაობს და მომდევნოზე არა.

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

რას ამტკიცებს პრობა და რას არა

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

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

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

თანმიმდევრობა წყვეტს, რომელი მნიშვნელობა გადარჩება

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

ბრძანების ხაზის ოფციები ჯაბნიან ფაილს, რაც დროებით ექსპერიმენტს იაფს ხდის:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

რას აკეთებენ keepalive-ები გვირაბის გავლით

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

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

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

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

სერვერზე გამოიტანეთ დემონის ეფექტური კონფიგურაცია, ნაცვლად იმისა, რომ ფაილი წაიკითხოთ და გამოიცნოთ, რომელმა include-მა მოიგო:

sshd -T | grep -i clientalive

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

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