შემდეგი ნახტომი VPN მარშრუტზე: რატომ უნდა იყოს კარიბჭე ლოკალურად მისაწვდომი

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

ეს სახელმძღვანელო ჩვეულებრივ შემთხვევას მოიცავს: ლეპტოპი 192.168.20.0/24-ზე, VPN კარიბჭე LAN მისამართით 192.168.20.5 და დისტანციური ქსელი 10.70.0.0/24 ამ კარიბჭის უკან. ქვემოთ მოცემული ყველა ბრძანება ვარაუდობს, რომ ლეპტოპზე ხართ, თუ სხვაგვარად არ არის ნათქვამი.

ორი მისამართი, ერთი მარშრუტი

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

ამიტომ პირველი შემოწმება არ არის «კარიბჭე მუშაობს», არამედ «კარიბჭე ამ ბმულზეა». ლეპტოპის საკუთარი ქვექსელი, მისი ARP ან მეზობლის ჩანაწერი და მარშრუტში არსებული ინტერფეისი — ყველა უნდა თანხმდებოდეს. მისამართი, რომელიც მხოლოდ 10.70.0.0/24-ის შიგნით არსებობს, შეიძლება იყოს მეორე მარშრუტის დანიშნულება, მაგრამ არასოდეს — პირველის via.

რისკენ ავალდებულებს შემდეგი ნახტომი კარიბჭეს

მარშრუტის ლეპტოპზე დაყენება მხოლოდ პირველ გადაცემას წყვეტს. შემდეგ კარიბჭეს საკუთარი გზა სჭირდება: ჩართული გადამისამართება, გვირაბის მარშრუტი 10.70.0.0/24-ისთვის და ნებისმიერი წვდომის პოლიტიკა, რომელიც განსაზღვრავს, ვის შეუძლია მისი გამოყენება. Linux-ზე ეს არის net.ipv4.ip_forward=1 და გვირაბის მარშრუტი; მის წინ მდებარე ფაილს უნდა ჰქონდეს წესი, რომელიც გადამისამართებულ ნაკადს უშვებს.

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

გადაამოწმეთ ძიება იმ ჰოსტიდან, რომელიც აგზავნის

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

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

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

ნუ გამოიყენებთ onlink-ს მისაწვდომობის გასაყალბებლად

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

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

წერტილ-წერტილ გვირაბები Ethernet არ არის

გვირაბის მოწყობილობა ARP-ს არ აკეთებს და ხშირად არ აქვს მეზობლების შინაარსიანი ქვექსელი. მისი მარშრუტები ხშირად ასე გამოიყურება: 10.70.0.0/24 dev tun0, საერთოდ via-ის გარეშე, რადგან პარტნიორი ერთადერთი მეორე ბოლო წერტილია. LAN სტილის via-ის ამ ცხრილში კოპირება ქმნის მარშრუტს, რომელიც ბირთვმა შეიძლება უარყოს ან, უარესი, ისეთი, რომელიც მიუთითებს მისამართზე, რომელზეც პარტნიორი არასოდეს პასუხობს.

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

დაამატეთ, დაადასტურეთ, უკან დააბრუნეთ

მთელი ცვლილება სამი ბრძანება და ერთი შემოწმებაა, და ის ზუსტად ამ თანმიმდევრობით უნდა ჩაიწეროს:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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