რატომ ერთი ქვექსელი კვლავ გვერდს უვლის თქვენი VPN-ის ნაგულისხმევ მარშრუტს

VPN-ს სრულ გვირაბზე გადართავთ, ტრაფიკის უმეტესობა ემორჩილება, და შემდეგ ერთი მისამართი პირდაპირ პასუხობს — პრინტერი, NAS, ნახტომის ჰოსტი 10.x-ზე. აშკარა კითხვაა, რომ გვირაბი ჟონავს, ამიტომ ამცირებთ ნაგულისხმევი მარშრუტის მეტრიკას და არაფერი იცვლება. სწორედ ეს წარუმატებელი ცდაა მინიშნება: ნაგულისხმევი მარშრუტი სარეზერვოა და არა განაჩენი. მარშრუტის ძიება იღებს ყველაზე გრძელ დამთხვევ პრეფიქსს, სანამ საერთოდ შეადარებს მეტრიკებს, ამიტომ /24 აგრძელებს /0-ზე გამარჯვებას, რა რიცხვსაც არ უნდა მიაბათ რომელიმე მათგანს. როცა ეს რიგი ნათელია, გაჟონვა ჩვეულებრივ მარშრუტია, რომელიც ვიღაცამ განზრახ დააინსტალირა, ან პრეფიქსი, რომლის დაფარვასაც კლიენტი არასდროს აპირებდა.

რას ჰპირდება სინამდვილეში ნაგულისხმევი მარშრუტი

0.0.0.0/0 ემთხვევა ყველა IPv4 დანიშნულებას ნულოვანი ბიტი სპეციფიკით. ის არსებობს იმისთვის, რომ ჰოსტმა მიაღწიოს ყველაფერს, რასაც მისი ცხრილი უკეთ არ აღწერს. მარშრუტი 192.168.1.0/24-მდე ატარებს 24 დამთხვევ ბიტს, ამიტომ 192.168.1.40-ისთვის ის იმარჯვებს მანამ, სანამ ვინმე შეადარებს მეტრიკებს, ადმინისტრაციულ მანძილს ან რასაც კლიენტი პრიორიტეტის ველს უწოდებს. იგივე წესი მოქმედებს Linux FIB-ში, Windows-ის მარშრუტიზაციის ცხრილში და macOS-ის უკან მდგარ BSD სტეკში.

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

ნახევრად ნაგულისხმევი მარშრუტები, ან რატომ შეიძლება ნაგულისხმევი ჩანაწერი ხელუხლებლად გამოიყურებოდეს

ყველაზე სუფთა მაგალითია redirect-gateway def1 OpenVPN-ში. თქვენი ნაგულისხმევის წაშლისა და ჩანაცვლების ნაცვლად, ის ამატებს 0.0.0.0/1-ს და 128.0.0.0/1-ს. ერთად წყვილი ფარავს მთელ IPv4-ს, ყოველი პრეფიქსი /0-ზე გრძელია და ორივე ამარცხებს როუტერის ნაგულისხმევს, ტოვებს რა მას ადგილზე. შემდეგ გაუშვით მარშრუტების სია და თავდაპირველი ნაგულისხმევი ჯერ კიდევ იქ არის, ჯერ კიდევ თქვენს კარიბჭეზე მიუთითებს; უბრალოდ ის არასდროს ირჩევა ინტერნეტ დანიშნულებებისთვის.

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

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

მეტრიკები წყვეტს ყაიმს, პრეფიქსები წყვეტს გამარჯვებულს

მეტრიკების შედარება ხდება მხოლოდ იმ კანდიდატებს შორის, რომლებიც თანაბრად კარგად ემთხვევა დანიშნულებას. Linux-ზე ip route get 10.20.5.9 ბეჭდავს გამარჯვებულს მისი ცხრილითურთ, და ip route show table all ჩამოთვლის კანდიდატებს, მათ შორის ნებისმიერ ნახევრად ნაგულისხმევს და ნებისმიერ ცხრილს, რომელზეც წესი მიუთითებს. Windows-ზე Find-NetRoute -RemoteIPAddress 10.20.5.9 აბრუნებს არჩეულ მარშრუტს და წყაროს მისამართს, ხოლო Get-NetRoute აჩვენებს ნედლ ცხრილს — მაგრამ ეფექტური ღირებულება არის მარშრუტის მეტრიკა პლუს ინტერფეისის მეტრიკა, ამიტომ ნელი ადაპტერი შეიძლება დაკარგოს ყაიმი, რომელსაც თითქოს იგებს.

სამი შემთხვევა ფარავს იმის უმეტესობას, რასაც ნახავთ:

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

მესამე შემთხვევაა ის, სადაც ამ მოხსენებების უმეტესობა მთავრდება. Linux-ის ip rule ან Windows-ის VPN ტრაფიკის ფილტრს შეუძლია ტრაფიკი გაგზავნოს ცხრილში, რომელსაც არასდროს ჰქონია გვირაბის ნაგულისხმევი, და მთავარი ცხრილი მთელი დროის განმავლობაში სრულყოფილად გამოიყურება.

ვინ ფლობს ჩვეულებრივ ამ გვერდის ავლას

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

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

შემდეგ ცალკე შეამოწმეთ IPv6. ip -6 route და Get-NetRoute -AddressFamily IPv6 ინახავენ ცალკე მდგომარეობას, ცალკე ნაგულისხმევებს და ცალკე კლიენტის ქცევას. მხოლოდ IPv4-ის აუდიტი არაფერს ამბობს ორმაგი სტეკის ჰოსტზე, რომელიც ჩუმად უპირატესობას ანიჭებს მშობლიურ IPv6 გზას, და მხოლოდ ეს შეიძლება კლიენტი split-tunnel-ად აჩვენოს.

დაადასტურეთ თავად აპლიკაციის ნაკადით

ჩაწერეთ დანიშნულება, რომელსაც აპლიკაცია რეალურად იყენებს, შემდეგ ჰკითხეთ სისტემას გზა, რომელსაც გაივლიდა წყაროს მისამართიდან, რომელსაც ეს აპლიკაცია უკავშირდება. ip route get 10.20.5.9 from 192.168.1.40 ამას პასუხობს Linux-ზე; Find-NetRoute -RemoteIPAddress 10.20.5.9 პლუს ლოკალური მისამართი აკეთებს ამას Windows-ზე. შეადარეთ შედეგი იმას, რასაც პროფილი ამტკიცებს. ბრაუზერის საჯარო IP გვერდი ერთ დანიშნულებას ერთ პროტოკოლზე ამოწმებს და არაფერს ამბობს იმ კერძო მისამართზე, რომელმაც საჩივარი დაიწყო.

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

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

• დაასახელეთ დანიშნულება და წყაროს მისამართი, რომელსაც აპლიკაცია ნამდვილად იყენებს.
• დაბეჭდეთ გამარჯვებული მარშრუტი ip route get ან Find-NetRoute გამოყენებით.
• შეამოწმეთ, ფლობს თუ არა ინტერნეტ გზას /1 წყვილი თუ პოლიტიკის ცხრილი.
• ჩამოთვალეთ ყოველი /0-ზე გრძელი პრეფიქსი, რომელიც ემთხვევა დანიშნულებას.
• გაიმეორეთ IPv6 შემოწმება ცალკე.
• თვალი ადევნეთ გადარჩენილ მარშრუტს უკან, იმ ფაილამდე, პროფილამდე ან ფილტრამდე, რომელიც მას აყენებს.
• ხელახლა დაუკავშირდით და ხელახლა გაუშვით შეკითხვა, სანამ გამოსწორებულს უწოდებდეთ.

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