რატომ ვერ უპასუხებს თქვენი GCP VM OpenVPN-ის IPv6 პულს

თქვენი IPv6 VPN კლიენტი აღწევს დატვირთვას, დატვირთვა პასუხობს გვირაბში და პასუხი არასოდეს მოდის. პირველი ინსტინქტი ფაირვოლის ან გვირაბის დადანაშაულებაა და ჩვეულებრივ არც ერთი მათგანი არ არის დამნაშავე. მისამართი, რომელსაც გასცემს OpenVPN, არის შიდა ქსელი, რომელიც მხოლოდ გვირაბის შიგნით არსებობს; Google Cloud-მა არ იცის, რომ fd42:90::/64 კონკრეტული VM-ის უკან უნდა იყოს, სანამ თქვენ არ ეტყვით.

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

პული შიდა ქსელია, არა ქვექსელი

OpenVPN-ს შეუძლია IPv6 მისამართების გაცემა თქვენ მიერ არჩეული დიაპაზონიდან და ეს დიაპაზონი ფიქციაა, რომელზეც გვირაბის ორი ბოლო თანხმდება. ეს არ არის Google Cloud-ის ქვექსელი, არ ჩანს VPC-ის ქვექსელების სიაში და VM-ის ქსელური ინტერფეისი ამ მისამართებს არ იღებს. ამიტომ კლიენტზე პასუხისმგებელი დატვირთვა პაკეტს უგზავნის მისამართზე, რომელსაც ქსელი არამარშრუტიზებად მიიჩნევს.

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

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

მიეცით VPC-ს დანიშნულება და შემდეგი ნაბიჯი

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

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

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

გადაგზავნა ორჯერ უნდა ჩაირთოს

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

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

უთხარით OpenVPN-ს, ვის რა ეკუთვნის

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

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

ინტერნეტის გამავალი არხი ამ დიზაინს მიღმა დატოვეთ

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

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