ორი VPN კლიენტი, ერთი მარშრუტიზაციის ცხრილი: ვინ იღებს ნაგულისხმევ მარშრუტს

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

კონფლიქტი მარშრუტიზაციის ცხრილში ცხოვრობს

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

კლიენტები ერთი საერთო ცხრილის რედაქტორები არიან. იმის ცოდნა, რომელი ცვლილება იყო ბოლო, თითქმის ყველა სიმპტომს ხსნის.

წაიკითხეთ, რომელი გვირაბი ფლობს მიმდინარე გზას

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

ip route get 10.20.0.5
route print -4

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

შეაჩერეთ მეორე კლიენტი ყველაფრის მოთხოვნაში

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

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull უგულებელყოფს ყოველ უბიძგებულ მარშრუტს, მაშინ როცა pull-filter ignore "redirect-gateway" მხოლოდ ნაგულისხმევი მარშრუტის დირექტივას უშვებს და უბიძგებულ DNS-სა და სხვა პარამეტრებს ინარჩუნებს. აირჩიეთ მათ შორის იმის მიხედვით, სერვერის კონფიგურაციის რამდენი ნაწილი გსურთ ჯერ კიდევ, შემდეგ დაამატეთ კონკრეტული პრეფიქსები, რაც მეორე ქსელს სჭირდება. გაითვალისწინეთ DNS, რადგან გამხსნელი, რომელსაც უბიძგებს გვირაბი, რომელიც მოთხოვნებს არ ატარებს, არაფერს აბრუნებს. გამოსცადეთ ერთი ცნობილი ჰოსტი თითოეულ ქსელში და დაადასტურეთ წყაროს მისამართი, რომელსაც შორეული მხარე ხედავს.

გადამფარავი ქვექსელების გვერდის ავლა შეუძლებელია

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

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