რატომ ამტვრევს მეორე VPN გვირაბი პირველს?

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

სიმპტომი: მეორე კლიენტი ჩუმად იმარჯვებს

OpenVPN: redirect-gateway def1 პარამეტრი არ გადაფარავს 0.0.0.0/0-ს. ის ამატებს 0.0.0.0/1-ს და 128.0.0.0/1-ს: ერთად ისინი ფარავენ ყველა IPv4 მისამართს, და თითოეული პრეფიქსი სიგრძით სჯობს ჩვეულებრივ ნაგულისხმევს. საწყისი ნაგულისხმევი რჩება ცხრილში და წყვეტს ჩვეულებრივი ტრაფიკისთვის გამოყენებას, ხოლო ჰოსტ-მარშრუტი VPN სერვერამდე ხელს უშლის გვირაბს დაიჭიროს საკუთარი გარე პაკეტები. ორივე კლიენტი ასე აკეთებს, და მეორე უბრალოდ თავის წყვილს მოგვიანებით აყენებს.

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

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

წაიკითხეთ რომელი გვირაბი იმარჯვებს სინამდვილეში

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

Windows: აუკრძალეთ ერთ პროფილს ნაგულისხმევის ფლობა

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

Linux: დააშორეთ მეორე გვირაბი მთავარ ცხრილს

ერთ მანქანაზე openvpn --config-ის ორი ეგზემპლარის გაშვება ორივე კლიენტს ერთ ცხრილში აყენებს, და სამი პარამეტრი ზრდადი იზოლაციით ჰყოფს მათ. ყველაზე მსუბუქია მეორე კლიენტს საერთოდ აუკრძალოთ ცხრილის რედაქტირება: route-nopull-ით და ცხადი მარშრუტებით, ან route-up სკრიპტით, რომელიც მხოლოდ იმას აყენებს, რაც გინდათ. მაშინ მეორე გვირაბი ატარებს ზუსტად თქვენ მიერ დასახელებულ პრეფიქსებს და სხვას არაფერს. მაშინ თქვენ წყვეტთ რომელი პრეფიქსი სად წავიდეს, ნაცვლად იმისა რომ შემდეგ აღმოაჩინოთ.

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

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

თითო აპლიკაციაზე, და ჯაჭვური დაკავშირება ცალკე პრობლემად

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

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

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