საჯარო პრეფიქსი OpenVPN-ის გავლით: დაბრუნების გზის შესწორება

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

პრეფიქსი ჯერ თქვენკენ უნდა იყოს მარშრუტიზებული

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

თუ პროვაიდერი 198.51.100.64/28-ს თქვენს შესვლის სერვერზე მარშრუტიზებს, ამ დიაპაზონის პაკეტები სერვერზე მიდიან და იქ ჩერდებიან, თუ მათ არ გადაამისამართებთ. თუ პროვაიდერი ამის ნაცვლად დიაპაზონს თქვენს uplink-ზე ხიდავს, სერვერმა მასზე ARP-ით უნდა უპასუხოს, რაც სხვა პრობლემაა.

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

მარშრუტიზაციის ორი დონე: ბირთვის მარშრუტი და iroute

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

სერვერის მხარეს მარშრუტი ასე გამოიყურება, და პრეფიქსი და ნიღაბი გამოყოფას უნდა შეესაბამებოდეს:

ip route add 198.51.100.64/28 dev tun0

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

iroute 198.51.100.64 255.255.255.240

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

სად ცხოვრობს სერვისის მისამართი

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

Linux კლიენტზე, რომელიც სერვისს ლოკალურად ამთავრებს, საკმარისია ერთი ჰოსტის მისამართი:

ip address add 198.51.100.70/32 dev lo

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

შეინარჩუნეთ საჯარო წყარო დაბრუნების გზაზე

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

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

iptables -t nat -S POSTROUTING

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

შეამოწმეთ ორივე მიმართულება, სანამ დაეყრდნობით

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

ჰკითხეთ ბირთვს, რომელ გზას იღებს გადანაწილებული მისამართი, და დააკვირდით გვირაბს, სანამ მოთხოვნა მიმდინარეობს:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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