თქვენი /64-ის გაყოფა IPv6-ს VPN კლიენტებამდე არ მარშრუტიზებს

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

მითი: თქვენი /64-ის ნაწილი უკვე ხელმისაწვდომია

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

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

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

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

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

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

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

რას მოითხოვს მარშრუტიზებული მიწოდება

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

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

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

ორი დამოუკიდებელი მარშრუტი, რომლებიც სწორად უნდა დალაგდეს

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

შეინარჩუნეთ IPv6-ზე დამოკიდებული კონტროლის ტრაფიკი მომუშავე ნებისმიერი პოლიტიკის ქვეშ, რომელსაც გამოიყენებთ. Packet Too Big შეტყობინებები მხოლოდ TCP და UDP-ის დამშვები firewall-ის კლასიკური მსხვერპლია და მათი ჩამოგდება ქმნის კავშირებს, რომლებიც დამყარდება და შემდეგ უფრო დიდ გადაცემებზე ჩერდება.

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

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

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

შემდეგ ცალსახად გამოსცადეთ უკანა მიმართულება, პაკეტით, რომელიც გარედან უნდა დაბრუნდეს. openvpn(8) სახელმძღვანელო ფარავს server-ipv6 და redirect ოპციებს, ხოლო თქვენი პროვაიდერის მარშრუტიზაციის დადასტურება ფარავს იმ ნახევარს, რომელსაც სახელმძღვანელო ვერ ფარავს.