OpenVPN კლიენტი აღწევს სერვერს, მაგრამ არა LAN ჰოსტებს: შემოწმების სია

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

პირველი ნაბიჯი: დააკვირდით კლიენტის მარშრუტიზაციის გადაწყვეტილებას

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

ip route get 192.168.50.10

თუ პასუხი ასახელებს თქვენს ფიზიკურ ადაპტერს და ოფისის კარიბჭეს, სერვერის მხარეს არც ერთი ცვლილება არ დაეხმარება. OpenVPN მარშრუტებს მხოლოდ მაშინ ანაწილებს, როცა სერვერი მათ უბიძგებს, ამიტომ მოძებნეთ push "route 192.168.50.0 255.255.255.0" სერვერის კონფიგურაციაში და შემდეგ ხელახლა დააკავშირეთ კლიენტი. კლიენტების უმეტესობა უბიძგებულ მარშრუტებს კავშირის დროს იყენებს, არა პროფილის განახლებისას.

Windows-ზე იმავე კითხვას სხვა ბრძანება აქვს. Find-NetRoute -RemoteIPAddress 192.168.50.10 ბეჭდავს ინტერფეისს და შემდეგ ნახტომს, რომელსაც სტეკი აირჩევდა, ხოლო route print -4 აჩვენებს, საერთოდ არსებობს თუ არა უბიძგებული პრეფიქსი.

მეორე ნაბიჯი: დაადასტურეთ, რომ სერვერი პაკეტს გადასცემს

თუ კლიენტის მარშრუტი სწორია, პაკეტი აღწევს სერვერს და სერვერი უნდა დათანხმდეს მის გადაცემას. ბირთვის გადამრთველი პირველი ჭიშკარია და sysctl net.ipv4.ip_forward-მა უნდა დააბრუნოს 1. მისი დაყენება echo 1 > /proc/sys/net/ipv4/ip_forward-ით მუშაობს შემდეგ გადატვირთვამდე, და სწორედ ამიტომ ბრუნდება იგივე საჩივარი კვირების შემდეგ.

ჩაწერეთ ის ადგილას, რომელიც გადატვირთვას გადაურჩება:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

მეორე ჭიშკარი ფილტრის ცხრილია. Docker-ის მქონე ჰოსტს ხშირად FORWARD პოლიტიკა DROP აქვს, და გვირაბი ამ გადაწყვეტილებას მემკვიდრეობით იღებს. iptables -L FORWARD -v -n აჩვენებს როგორც პოლიტიკას, ისე პაკეტების მთვლელებს; თუ პოლიტიკა DROP-ია, გადაცემას სჭირდება ცალსახა ნებართვა გვირაბიდან LAN-ის მიმართულებით და კიდევ ერთი პასუხისთვის.

მესამე ნაბიჯი: მიჰყევით პაკეტს LAN-ამდე და მოძებნეთ პასუხი

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

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

მეოთხე ნაბიჯი: აირჩიეთ თარგმანსა და დაბრუნების მარშრუტს შორის

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

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

შეზღუდეთ წესი აუზით და LAN ინტერფეისით, შემდეგ გახადეთ ის მუდმივი, თორემ შემდეგი firewall-ის გადატვირთვა ჩუმად წაშლის თქვენს შესწორებას. ფასი იდენტობაა: ყოველი კლიენტი LAN-ის ჟურნალებში და წვდომის წესებში VPN სერვერს ჰგავს, და per-client policy becomes guesswork.

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

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

დახურეთ ციკლი კლიენტიდან და არა სერვერიდან. დაუკავშირდით რეალურ სერვისს LAN ჰოსტზე, შემდეგ დაადასტურეთ, რომ თარგმანის მთვლელები iptables -t nat -L POSTROUTING -v -n-ით გადაადგილდა, რადგან ნულოვანი პაკეტებით წესი ის წესია, რომელიც არასოდეს დამთხვევია. conntrack -L -s 10.8.0.5 აჩვენებს ნაკადს და მის მდგომარეობას, როცა გჭირდებათ დადასტურება, რომ დაბრუნების მიმართულება კონტროლდება.

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