Linux VPN-ის პასუხები ქრება? შეამოწმეთ rp_filter და მარშრუტი

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

რას წყვეტს წყაროს ვალიდაცია

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

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

წაიკითხეთ ფაქტობრივი რეჟიმი, და არა ერთი ველი

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

იპოვეთ შეუსაბამობა სანამ შემოწმებას შეცვლით

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

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

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

შერჩევითი კორექტირება, რომლის დაცვაც შეგიძლიათ

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

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

გაყავით IPv4 და IPv6 ცალ-ცალკე

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

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