რამდენ ხანს უნდა აგრძელებდეს OpenConnect გაწყვეტილი VPN-ის ხელახლა ცდას?

--reconnect-timeout პასუხობს ერთ ვიწრო კითხვას: გვირაბის ჩავარდნის შემდეგ რამდენ ხანს აგრძელებს ეს კლიენტის პროცესი ცდას, სანამ დანებდება და გავა. OpenConnect-ის სახელმძღვანელოს გვერდი ამ პარამეტრს აღრიცხავს დოკუმენტირებული ნაგულისხმევი 300 წამით იმ განმეორებითი ცდებისთვის, რომლებიც მოჰყვება დაკარგულ ბმულს ან პარტნიორს, რომელმაც პასუხი შეწყვიტა, და რიცხვი ერთი მოქმედი კლიენტისთვის ვადაა და არა მტკიცება, რომ VPN ხელმისაწვდომი რჩება. ის ასევე არ არის პროცესის ცოცხლად შენარჩუნების პოლიტიკა, და სწორედ აქ იწყება არეულობის დიდი ნაწილი.

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

რას ზღუდავს სინამდვილეში ხელახალი დაკავშირების ფანჯარა

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

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

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

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

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

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

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

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

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

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

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

რა უნდა შემოწმდეს შეფერხების დროს და შემდეგ

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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