როგორ გავარჩიოთ VPN-ის მიერ გაგზავნილი მარშრუტები სტატიკურისაგან Linux-ზე

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

ნაბიჯი 1: დაასახელეთ მექანიზმი, რომელიც პრეფიქსებს აყენებს

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

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

ნაბიჯი 2: შეადარეთ ცხრილი ერთი დაკავშირების განმავლობაში

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

ჩაიწერეთ ის ip route show table main > /tmp/route-down.txt-ით, დაუკავშირდით და ისევ ჩაიწერეთ. იგივე გააკეთეთ ip -6 route-ისთვის, თუ საიტი IPv6-ს იყენებს, რადგან იქ დაკარგული პრეფიქსი იწვევს ჩავარდნებს, რომლებიც მარშრუტიზაციასთან უკავშიროდ გამოიყურება.

ნაბიჯი 3: წაიკითხეთ მეტრიკა და არა მხოლოდ არსებობა

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

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

ნაბიჯი 4: იპოვეთ ჩანაწერები, რომლებიც გვირაბზე მეტხანს ცოცხლობს

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

შეამოწმეთ მუდმივი მხარე იმ ადგილას, რომელსაც თქვენი დისტრიბუცია იყენებს: იქნება ეს systemd-networkd ერთეული, NetworkManager პროფილი თუ სკრიპტი კლიენტის up საქაღალდეში. ცოცხალი ცხრილის ip route del-ით გასწორება მხოლოდ შემდეგ დაკავშირებამდე ძლებს. ეს წაშლა განიხილეთ როგორც ჰიპოთეზის გამოცდა და არა როგორც შეკეთება.

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

ნაბიჯი 5: დაადასტურეთ დაბრუნების გზა, სანამ კლიენტს დაადანაშაულებთ

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

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

ნაბიჯი 6: გამოსცადეთ რესურსი და არა ping

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

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