როგორ გავუშვათ ერთი IPv4 დანიშნულება OpenVPN გვირაბის გარეთ

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

ხაზი უვნებლად გამოიყურება და ხშირად ასეცაა, მაგრამ ის მხოლოდ ერთ კითხვას წყვეტს: სად მიდიან პაკეტები სწორედ ამ IPv4 მისამართისთვის. ის არ ცვლის DNS-ს, IPv6-ს, firewall-ის პოლიტიკას ან იმას, თუ რომელმა პროცესმა გახსნა კავშირი, და ამათგან ყოველმა შეიძლება ჩუმად გააუქმოს გამონაკლისი.

რას ნიშნავს სინამდვილეში net_gateway

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

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

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

რატომ იმარჯვებს ჰოსტის მარშრუტი გვირაბის ნაგულისხმევზე

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

ერთი მისამართის მარშრუტი 255.255.255.255 ნიღბით არის /32, რაც IPv4-ის მაქსიმალური სიზუსტეა. როცა ამ მისამართისთვის პაკეტი ფასდება, /32 ემთხვევა და იმარჯვებს, მიუხედავად იმისა, რომელი მარშრუტი დაყენდა პირველი. ეს არის გამონაკლისის მიღმა არსებული მექანიზმი და ის ერთნაირად მუშაობს Linux-ზე, macOS-სა და Windows-ზე, სანამ მარშრუტი ნამდვილად არსებობს.

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

რას არ ფარავს გამონაკლისი

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

IPv6 მეორეა. მარშრუტის დირექტივა მხოლოდ IPv4-ს ეხება. ორმაგი დასტის დანიშნულებამ შეიძლება IPv6-ს უპირატესობა მისცეს, რომელიც პოლიტიკის მიხედვით გვირაბს ან ჰოსტის IPv6 ნაგულისხმევ მარშრუტს მიჰყვება, ამიტომ IPv4-ის გამონაკლისი არასოდეს ამოქმედდება. გჭირდებათ შესაბამისი IPv6 მარშრუტი, ან შეგნებული გადაწყვეტილება, გამორთოთ IPv6 ამ კლიენტისთვის.

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

გამონაკლისის შემოწმება საკუთარი თავის მოტყუების გარეშე

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

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

და ბოლოს, შეამოწმეთ ის კონტროლი, რომლებმაც შეიძლება მარშრუტს გადააჭარბონ. კლიენტის მხარეს kill switch ან Windows-ის block-outside-dns პარამეტრი შეიძლება პირდაპირ ტრაფიკს აკრძალოს, რაც ჩანს როგორც კავშირი, რომელიც მარშრუტის სისწორის მიუხედავად ვერ მუშაობს. ნუ გამორთავთ ამ კონტროლებს იმისთვის, რომ გამონაკლისი მომუშავედ გამოჩნდეს; თუ პოლიტიკა პირდაპირ გზას კრძალავს, გამონაკლისი დიზაინის პრობლემაა VPN სერვისის მფლობელისთვის.

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