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

მიეცით თითოეულ პროფილს საკუთარი ლოკალური პორტი

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

Local Port 0

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

პროფილის ფაილები ინახავს საიდენტიფიკაციო მონაცემებს, ამიტომ უფლებები დიზაინის ნაწილია და არა დალაგების. /etc/vpnc-ის ქვეშ ყველასთვის წაკითხვადი ფაილი ჯგუფის საიდუმლოს ყველა ლოკალურ მომხმარებელს აძლევს. შეინახეთ რეჟიმი 0600-ზე root-ით მფლობელად და მიეცით სკრიპტებს ფაილის root-ად წაკითხვის საშუალება საიდუმლოების არგუმენტებში კოპირების ნაცვლად. სწორედ ამიტომ შემოწმების სკრიპტმა არასდროს არ უნდა დაბეჭდოს ფაილის შიგთავსი ჟურნალში.

შეამოწმეთ ერთი სერვისი თითოეული პროფილისთვის და არა გვირაბის მისამართი

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

შეამოწმეთ ერთი სერვისი თითოეული პროფილისთვის მოკლე TCP ვადით და ხელახლა დაუკავშირეთ მხოლოდ ის პროფილი, რომლის შემოწმებაც ვერ შესრულდა. ორი წამი ყოფს მკვდარ გზას ნელი გზისგან, და TCP შემოწმება არ არის დამოკიდებული იმაზე, დაშვებულია თუ არა ICMP სადმე გზაზე. შეცვალეთ მხოლოდ სამიზნე და კონფიგურაციის სახელი პროფილებს შორის:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

შეინახეთ ეს როგორც /usr/local/bin/ensure-vpn-ops.sh, გახადეთ ის გასაშვები და გაიმეორეთ თითოეული პროფილისთვის მხოლოდ შემოწმების სამიზნისა და კონფიგურაციის სახელის შეცვლით. შემოწმება, რომელიც პროტოკოლურ კითხვას პასუხობს, გადაურჩება გეითვეებს, რომლებიც ექოს ყრიან, მაგრამ მაინც გადასცემენ მომხმარებლებისთვის მნიშვნელოვან სერვისებს.

დააკავშირეთ შემოწმებები ჯაჭვად, რათა ისინი არასდროს დაეჯიბრონ

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

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

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

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

თვალი ადევნეთ ჟურნალს, შემდეგ განზრახ გატეხეთ ერთი

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

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

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

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

რა არ უნდა გააკეთოს მეთვალყურემ

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

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

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