უფრო მარტივია სრული გვირაბი, ვიდრე გაყოფილი გვირაბის გრძელი სია?

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

დაიწყეთ იმ წესების დათვლით, რომლებსაც ინარჩუნებთ

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

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

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

შეამოწმეთ, შეუძლია თუ არა კარიბჭეს ნაგულისხმევის ტარება

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

ip -s link show dev tun0
conntrack -C
ss -s

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

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

დაადასტურეთ, რომ ლოკალური სერვისები და კერძო DNS ჯერ კიდევ მუშაობს

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

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

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

გადაიტანეთ ერთი პროფილი და შეამოწმეთ საზღვრები

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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