როგორ გავატაროთ VPN-ით მხოლოდ ერთი კერძო ქვექსელი

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

სამი პირობა, რომლებიც განსაზღვრავს დიზაინს

პირველი, გჭირდებათ ზუსტი პრეფიქსი და ნიღაბი ქსელის მფლობელისგან. 10.x ქსელი პრეფიქსი არ არის; პრეფიქსია 10.20.0.0/16. დარწმუნდით, რომ ის არ ემთხვევა სახლის LAN-ს, Docker ხიდს ან თქვენს მიერ გაშვებულ სხვა VPN-ს, რადგან დაფარვა მარშრუტს ორაზროვანს ხდის და ბირთვი ირჩევს იმ ჩანაწერს, რომელიც არ გქონდათ მხედველობაში.

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

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

WireGuard: AllowedIPs მარშრუტების ცხრილია

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

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

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

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

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

თუ მარშრუტებს თავად მართავთ, დააყენეთ Table = off [Interface]-ის ქვეშ და დაამატეთ სასურველი მარშრუტი. მაშინ ავტომატურად არაფერი ემატება, ამიტომ მარშრუტი იმას ეკუთვნის, რაც ინტერფეისს ასწევს.

OpenVPN: გაგზავნეთ მარშრუტი, შემდეგ დარწმუნდით, რომ მიაღწევს

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

push "route 10.20.0.0 255.255.0.0"

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

კლიენტმა, რომელსაც სრული გვირაბის სერვერის მიმართ ვიწრო ქცევა სჭირდება, მხოლოდ ის ნაწილები უნდა უგულებელყოს, რომლებიც არ უნდა. OpenVPN 2.4-სა და უფრო ახალში pull-filter სწორედ ამისთვის არსებობს.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

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

როცა კერძო ქვექსელი VPN სერვერზე არ არის, არამედ სხვა კლიენტის უკანაა, სერვერს უნდა ეცნობოს. client-config-dir-ის მეშვეობით დაამატეთ ფაილი თითოეული კლიენტისთვის, რომელიც შეიცავს iroute 10.20.0.0 255.255.0.0-ს, პლუს შესაბამისი route, რათა სხვა კლიენტებმა გზა ისწავლონ. iroute-ის გარეშე სერვერს არ აქვს მიზეზი, რომ ის პრეფიქსი სწორედ იმ გვირაბით გაგზავნოს.

IPsec: ტრაფიკის სელექტორები უნდა შეთანხმდნენ

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

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

თუ კარიბჭე ორივე მხარეს 0.0.0.0/0-ითაა კონფიგურირებული, IKEv2-ის შევიწროება ჩვეულებრივ შვილეულ SA-ს ორი შემოთავაზების კვეთამდე ამცირებს, რაც სასურველი შედეგია. ზოგი კარიბჭე პირიქით, უარყოფს შემოთავაზებას, რომელიც მათ კონფიგურირებულ სელექტორებს არ ემთხვევა, და ჟურნალი მაშინ წარუმატებელ შვილეულ SA-ს აჩვენებს, არა მარშრუტიზაციის ჩივილს. როცა ეს ხდება, ცვლილება კარიბჭეს ეკუთვნის, რადგან კლიენტის მარშრუტი ვერ შექმნის გვირაბს იმ სელექტორისთვის, რომელსაც მეორე მხარე არ მიიღებს.

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

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

საბოლოო წერტილი და DNS გადაწყვეტილებას გარეთ დატოვეთ

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

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

შეამოწმეთ, შემდეგ გადატვირთეთ და კვლავ შეამოწმეთ

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

პირველი ხაზი ინტერფეისს ასახელებს. თუ ის თქვენს ფიზიკურ ინტერფეისს ასახელებს, მარშრუტი არასდროს დამდგარა. Windows-ზე Find-NetRoute -RemoteIPAddress 10.20.5.7 იმავე კითხვას პასუხობს, და ბოლო შემოწმებამ კვლავ თქვენი ჩვეული მისამართი უნდა აჩვენოს, არა VPN სერვერის.

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

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