VPN პარტნიორი სხვა ინტერფეისებს პინგავს, რადგან ისინი ლოკალურია
ლოკალური მარშრუტიზაციის ცხრილი პაკეტებს უგზავნის ყველა მისამართს, რომელიც ჰოსტს ეკუთვნის, რომელ ინტერფეისზეც არ უნდა იყოს ის. გადაგზავნის პარამეტრები ამ გზაზე არასოდეს შედის.
WireGuard კლიენტი უკავშირდება და პინგავს მისამართს სრულიად სხვა ინტერფეისზე, და პასუხი მოდის. ჩანაწერები აჩვენებს, რომ მოთხოვნა მხოლოდ გვირაბზეა. არაფერი გატეხილი არ არის, და ყურადღებით გამორთულ გადაგზავნის პარამეტრს ამასთან კავშირი არ აქვს. ეს არის ორი გზის შედარება, რომლებიც დიაგრამაზე მსგავსად გამოიყურება და ბირთვში სრულიად განსხვავებულია.
ერთი გზა პაკეტებს სხვისთვის გადასცემს; მეორე მათ თავად ჰოსტს აწვდის.
ჰოსტისთვის მიმართული პაკეტი ჰოსტში რჩება
დისტანციური კლიენტი აგზავნის IP პაკეტს მისამართზე, რომელიც ჰოსტს ეკუთვნის. მარშრუტიზაცია ამ პაკეტზე ერთ კითხვას სვამს: ეს დანიშნულება ლოკალურია? ჰოსტის ყველა მისამართი ჩნდება ლოკალური მარშრუტიზაციის ცხრილში, და ეს ცხრილი მთავარ ცხრილამდე განიხილება, ამიტომ პაკეტი ჰოსტის საკუთარ დასტაში მიდის და არა სხვა ინტერფეისიდან გადის. პასუხი ლოკალურად იქმნება და გვირაბში ბრუნდება, რადგან კითხვა იქიდან მოვიდა.
ეს არის მთელი მექანიზმი. გადაგზავნა არ ხდება, ინტერფეისის მდგომარეობის ცვლილება არ მონაწილეობს, და არც ამ მისამართს სჭირდება სხვა ადგილიდან ხელმისაწვდომობა.
რატომ არ გამოიყენება ip_forward
გადაგზავნა მართავს იმ პაკეტებს, რომლებიც უნდა გავიდნენ სხვა ინტერფეისიდან, ვიდრე ის, რომელზეც მოვიდნენ. თავად ჰოსტზე პინგი ამ გზას არასოდეს ირჩევს: პაკეტი ლოკალურად მოიხმარება და პასუხი ლოკალურად იქმნება. ამიტომ net.ipv4.ip_forward=0-ის დაყენება აქ არაფერს ცვლის, და გადაგზავნის ჯაჭვის წესი ამ ტრაფიკს არასოდეს ხედავს. სწორი კონტროლი შემავალ გზაზეა, შემომავალი ინტერფეისით ან წყაროთი შეზღუდული.
ამიტომ გადაგზავნის გამორთვა და იმის დაშვება, რომ ჰოსტი იზოლირებულია, უსაფრთხოების ცრუ განცდას ქმნის.
წაიკითხეთ ლოკალური ცხრილი, რომელმაც გადაწყვიტა
ip rule show ჩვეულებრივ იუწყება ნულოვანი პრიორიტეტის წესზე, რომელიც ყველა ძიებას ჯერ ლოკალურ ცხრილში აგზავნის, ხოლო ip route show table local ჩამოთვლის ჰოსტის საკუთარ მისამართებს ლოკალური არეალით. ეს ცხრილი მოიცავს ადმინისტრაციულად გამორთული, მაგრამ ჯერ კიდევ კონფიგურირებული ინტერფეისების მისამართებს. სტატიკურად მინიჭებული IPv4 მისამართები ჩვეულებრივ გადურჩება კავშირის წყვეტას, და სწორედ ამიტომ გამორთულ ხიდზე პინგი მაინც შეიძლება წარმატებული იყოს და ოპერატორს გაუკვირდეს.
IPv6 სწორედ ამ პუნქტში განსხვავდება. მისი მისამართები ჩვეულებრივ უკან იწევა, როცა კავშირი წყდება, თუ keep_addr_on_down არ არის დაყენებული. შეადარეთ ოჯახები, ნაცვლად იმისა, რომ ჩათვალოთ, ერთი წესი ორივეს ფარავს.
რას აღწევს პარტნიორი სინამდვილეში
სეგმენტზე მარშრუტიზატორის საკუთარი მისამართიდან მიღებული პასუხი არაფერს ამბობს ამ სეგმენტის უკან მყოფ მანქანებზე. პარტნიორი ამ გზით ვერ მიაღწევს მეორე ინტერფეისის უკან მყოფ ჰოსტს; ის მხოლოდ იმ მისამართებს აღწევს, რომლებიც თავად მარშრუტიზატორს ეკუთვნის. ცალკე LAN ჰოსტზე სერვისის ტესტირება, მარშრუტიზატორის მისამართზე პინგის ნაცვლად, არის ის, რაც ადგენს, საერთოდ დაიშვება თუ არა გადაგზავნა.
პარტნიორის შეზღუდვა გვირაბის მისამართზე მიბმულ სერვისებზე შემავალი პოლიტიკის საკითხია. დაუშვით სასურველი სერვისი გვირაბის ინტერფეისზე და შეზღუდეთ წყაროები, რომლებსაც შეუძლიათ მისი გამოყენება, რადგან პაკეტი ნამდვილად აღწევს იქ.
შეამოწმეთ ის მისამართებიც, რომელთა გაუქმებასაც აპირებდით. მისამართის ინტერფეისიდან მოცილება უფრო საიმედოა, ვიდრე ძველ მისამართზე firewall-ის წესების დაწყობა.