რატომ წყვეტს სრული გვირაბის მარშრუტი სერვერს, რომელიც მას ატარებს

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

მარშრუტი, რომელიც საკუთარ ტრანსპორტს ჭამს

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

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

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

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

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

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

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

სარკული გამოსახულება სერვერზე

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

გამონაკლისები, რომლებსაც გვირაბი გამუდმებით იპარავს

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

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

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

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

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

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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