LAN როუტერი და VPN კლიენტი: ორი მოწყობილობა, ორი მარშრუტის ცხრილი

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

დახაზეთ ორი ჰოპი სანამ მარშრუტს შეეხებით

აიღეთ საილუსტრაციო განლაგება: LAN ჰოსტები 192.168.50.0/24-ზე, ჩვეულებრივი როუტერი 192.168.50.1-ზე, გამოყოფილი კლიენტი 192.168.50.15-ზე და შორეული LAN 10.60.0.0/24-ზე, რომელიც ხელმისაწვდომია მხოლოდ იმ გვირაბით, რომელიც ამ კლიენტს აქვს. არც ერთი კერძო დიაპაზონი არ ემთხვევა მეორეს, და გვირაბს აქვს საკუთარი მისამართების გეგმა.

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

ნაბიჯი 1: მიმართეთ როუტერი კლიენტისკენ, არა გვირაბისკენ

LAN როუტერზე დაამატეთ დანიშნულების მარშრუტი, რომლის შემდეგი ჰოპი კლიენტის LAN მისამართია:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

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

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

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

შეხედეთ სანამ რამეს დაამატებთ:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

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

ნაბიჯი 3: დაუშვით გადაგზავნა და აირჩიეთ დაბრუნების გზა

მიღება და გადაგზავნა სხვადასხვა ნებართვაა. net.ipv4.ip_forward=1 კლიენტზე ნებას რთავს ტრანზიტს ბირთვის დონეზე, და firewall-ის წესმა მაინც უნდა დაუშვას ის LAN ინტერფეისსა და გვირაბს შორის. წესი, რომელიც კლიენტის საკუთარი მართვის გვერდზე წვდომას უშვებს, არ დაუშვებს ტრანზიტს შორეულ LAN-ზე, და ეს განსხვავება ადვილი გამოსატარებელია, როცა იგივე ჰოსტი ლოკალურად პასუხობს ping-ებს.

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

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

ნაბიჯი 4: ორივე გადაწყვეტილება მუდმივი გახადეთ, შემდეგ შეამოწმეთ რეალური გზა

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

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

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