ping-მეთვალყურე ვერ არჩევს გატეხილ გვირაბს ჯანმრთელისგან
ინტერნეტში ping ნაკლებს ამტკიცებს, ვიდრე ჩანს. შეამოწმეთ გვირაბი შიგნიდან, დათვალეთ წარუმატებლობები მოქმედებამდე და სერვერის შეცვლა ცალკე გადაწყვეტილებად მიიჩნიეთ.
სამი პირობა განსაზღვრავს, ეხმარება თუ ზიანს აყენებს მეთვალყურე: რისი გარჩევა შეუძლია შემოწმებას, რამდენი ზედიზედ წარუმატებლობა ამართლებს მოქმედებას და მოქმედება ხელახალი დაკავშირებაა თუ შეცვლა. cron-ის სტრიქონი, რომელიც საჯარო მისამართს ping-ს უგზავნის, არც ერთ მათგანს არ პასუხობს კარგად. ის ხელახლა აკავშირებს სუფთა გვირაბებს და ტოვებს გატეხილებს, და ორივეს აკეთებს ჩანაწერის გარეშე. შენარჩუნებად ღირსეული დიზაინი ამ სამ არჩევანს ცხადს ხდის.
შემოწმება ის ნაწილია, რომელიც ყველაფერ დანარჩენს განსაზღვრავს.
რას ამტკიცებს სინამდვილეში ინტერნეტში ping
საჯარო resolver-ზე ping აჩვენებს, რომ ლოკალური ინტერნეტ გზა ცოცხალია. ის არ ამტკიცებს, რომ გვირაბი ტრაფიკს ატარებს, და სრული გვირაბის პროფილში თვით ping გვირაბში გადის, ასე რომ ჯანმრთელი პასუხი და გატეხილი გვირაბი შეიძლება ერთდროულად არსებობდეს, სანამ კლიენტი კვლავ გადასცემს პაკეტებს. თუ პროფილი სახელების ძიებას გვირაბით აგზავნის, DNS-ის წარუმატებლობა მკვდარ ბმად იკითხება და იწყებს ხელახალ დაკავშირებას, რომელსაც ვერაფერი გამოასწორებს.
შეცდომის ორივე მიმართულებიდან არც ერთი არ ჩანს გასვლის კოდში. ამ სიგნალზე აგებული მეთვალყურე cron-ის განრიგით მონეტის გადაგდებაა.
შეამოწმეთ ის, რაც გვირაბის უკან ცხოვრობს
ip -brief addr show tun0 ip route get 10.100.20.10 nc -z -w3 10.100.20.10 443
შეამოწმეთ შიგნიდან, ყველაზე იაფი შემოწმება პირველი. ინტერფეისის არსებობა ამბობს, რომ გვირაბი აწეულია; ცნობილ შიდა მისამართზე მარშრუტის ძიება ამბობს, რომ ტრაფიკი შევიდოდა; მეორე მხარეს ჰოსტზე TCP შემოწმება ამბობს, რომ რაღაც ნამდვილად პასუხობს. მხოლოდ echo მოთხოვნები ატყუებს: ბევრი შიდა ჰოსტი სიამოვნებით პასუხობს TCP-ს, მაგრამ ICMP-ს აგდებს, ამიტომ ping-ზე აგებული მეთვალყურე განუწყვეტლივ ხელახლა აკავშირებს გვირაბს, რომელსაც მუშაობა არასდროს შეუწყვეტია.
შეინარჩუნეთ შემოწმება დროში შეზღუდული და მიეცით ცალკე გასვლის სტატუსი. ოცდაათი წამით ჩამოკიდებული შემოწმება მეთვალყურეს ჩაშენებული დაყოვნების მქონე გათიშვის ამომცნობად აქცევს.
აირჩიეთ ერთ სტრიქონსა და ციკლს შორის
* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect
cron-ის ჩანაწერი ერთი სტრიქონია მეხსიერების გარეშე, რაც ერგება ლეპტოპს, სადაც ზედმეტი ხელახალი დაკავშირება არაფერი ღირს. ზედამხედველობის ქვეშ მყოფი ციკლი ინახავს მთვლელს და მოქმედებს მხოლოდ რამდენიმე გამოტოვების შემდეგ, რაც ხელს უშლის არასტაბილურ ბმას ხელახალი დაკავშირებების ქარიშხალი გამოიწვიოს. ნებისმიერ შემთხვევაში, გაუშვით ის ზედამხედველის ქვეშ, რომ გადაიტანოს კრაში და ჟურნალში ჩაწეროს. აირჩიეთ იმის მიხედვით, მნიშვნელოვანია თუ არა ზედმეტი ხელახალი დაკავშირება, და არა იმის მიხედვით, რომელი ვერსიაა მოკლე.
failures=0 while sleep 30; do if nc -z -w5 10.100.20.10 443; then failures=0 else failures=$((failures+1)); fi if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi done
ის ციკლი ითვლის ზედიზედ წარუმატებლობებს და არა წილს ფანჯარაზე. ფანჯარას სჭირდება საათი და ნიმუშების მეხსიერება, და ხელით დაწერილი მეთვალყურეების შეცდომების უმეტესობა სწორედ ამ არითმეტიკაში ცხოვრობს.
სერვერის შეცვლა სხვა გადაწყვეტილებაა
სერვერების შეცვლა განსხვავდება ხელახალი დაკავშირებისგან. ჯერ ძველი ბმა გააწყვიტეთ, რადგან მეორე კლიენტი, რომელიც დაიწყებს, სანამ პირველი ჯერ კიდევ ფლობს მისამართს, დაეჯახება. დათვალეთ ზედიზედ წარუმატებლობები შეცვლამდე, შეზღუდეთ მცდელობები და ახალი ბმის აწევის შემდეგ კვლავ შეამოწმეთ, ნაცვლად connect ბრძანების გასვლის სტატუსის ნდობისა. არასწორი კონფიგურაცია არ უნდა ტრიალებდეს ციკლში ყველა სერვერზე.
არ შეამოწმოთ VPN სერვერის საკუთარი საჯარო მისამართი სრული გვირაბის შიგნიდან. ეს შემოწმება დამოკიდებულია იმაზე, რასაც ამოწმებს, და წარმატებას აცნობს მაშინ, როცა გზა, რომლის დადასტურებაც უნდა მოეხდინა, უკვე გაქრა.
ჩაწერეთ, რომელი შემოწმება გაიშვა, რა დააბრუნა და რა მოქმედება მოჰყვა. ეს ჩანაწერი იდუმალ ხელახალ დაკავშირებას დიაგნოსტიკად ხდის.