VPN კლიენტები სერვერს აღწევენ, LAN-ს კი არა: რომელი გამოსავალი?

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

ჯერ გაარკვიეთ, რომელი მიმართულებაა გატეხილი

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

პირველი კითხვა: შეგიძლიათ შორეული LAN-ის მარშრუტიზატორის რედაქტირება?

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

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

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

მეორე კითხვა: შეიძლება LAN-მა კლიენტების მისამართების ხედვა შეწყვიტოს?

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

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

მესამე კითხვა: არის თუ არა სერვერი თავად სხვა გვირაბის კლიენტი?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

შემდეგ შეამოწმეთ ორივე მიმართულება და ორივე ზომა

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

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

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