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

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

გაუშვით ნაგულისხმევი მარშრუტი და დაადასტურეთ, რა დააყენა კლიენტმა

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

push "redirect-gateway def1"

ხელახლა დაკავშირების შემდეგ წაიკითხეთ კლიენტის მარშრუტიზაციის ცხრილი და ნუ დაეყრდნობით პროფილს. Linux-ზე ორი /1 ჩანაწერი ორიგინალური ნაგულისხმევის გვერდით ჩნდება, ხოლო Windows იმავე წყვილს 0.0.0.0/1 და 128.0.0.0/1 სახით აჩვენებს. კლიენტი, რომელიც გაშვებულ ოფციებს უგულებელყოფს, ან რომელიც მათ უარყოფაზეა გამართული, თავის ძველ ნაგულისხმევს ინარჩუნებს და ინტერნეტ ტრაფიკს გვირაბში არასდროს აგზავნის. ეს საკითხი სერვერზე რაიმეს შეცვლამდე გადაწყვიტეთ, რადგან სერვერის მხარეს არცერთი წესი ვერ ანაზღაურებს.

გადამისამართება სერვერის პარამეტრია და არა VPN-ის

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

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

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

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

მიეცით პასუხებს ადგილი, სადაც წავლენ

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

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

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

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

დაამტკიცეთ კლიენტიდან და არა სერვერის გარსიდან

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

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

ცვლილებები და გაუქმების ნაბიჯი მსვლელობისას ჩაწერეთ, რათა გასასვლელი პოლიტიკა ერთი მოქმედებით დაბრუნდეს, როცა გამოცდა ჩავარდება. ეს რეცეპტი მხოლოდ IPv4-ს მოიცავს; სანამ იტყვით, რომ განლაგება მთელ ტრაფიკს ატარებს, IPv6 ცალკე აღრიცხეთ.