IPv6 IPv4 VPN სერვერის გავლით მაინც IPv6 გასასვლელს მოითხოვს

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

სიმპტომი: მისამართია და გზა არა

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

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

თვალყური ადევნე პაკეტს დეკაფსულაციის შემდეგ

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

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

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

შეამოწმე თითოეული შრე ცალკე, რადგან მომუშავე გარე გვირაბი მალავს გატეხილ შიდა გვირაბს. შეამოწმე გარე გზა IPv4 ping-ით კლიენტიდან სერვერამდე და დაადასტურე პორტი, რომელსაც იყენებ. შემდეგ შეამოწმე შიდა გზა სერვერზე, სადაც ip -6 route უნდა აჩვენოს ნაგულისხმევი ან ნამდვილი upstream-იდან ნასწავლი კონკრეტული მარშრუტი, და ip -6 addr უნდა აჩვენოს წყაროს პრეფიქსი, რომელსაც upstream მიიღებს. ამაზე ნაკლები ინტერფეისზე მხოლოდ მორთულობაა.

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

იგივე ეხება კლიენტს: ip -6 route get 2001:4860:4860::8888 უნდა დაასახელოს გვირაბის მოწყობილობა, და თუ ფიზიკურს ასახელებს, კლიენტი IPv6-ისთვის VPN-ს საერთოდ არ იყენებს.

წყაროს პრეფიქსი, ზომა და ICMPv6

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

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

რა არის სულ სხვა პრობლემა

მხოლოდ IPv4 აპლიკაციამდე მისვლა მხოლოდ IPv6 კლიენტიდან თარგმანია, არა გვირაბიზაცია, და სჭირდება რაღაც განზრახ გაშვებული NAT64-ის მსგავსი. დანიშნულება ვერ გაიგებს დამატებით გვირაბის სათაურს მხოლოდ იმიტომ, რომ შენ დაამატე. ისტორიული გადასვლის სერვისები იმავე ყურადღებას იმსახურებენ: RFC 7526-მა გააუქმა 6to4 anycast რელეს მოდელი, ამიტომ მის გარშემო დაწერილი სახელმძღვანელო აღწერს რაღაცას, რასაც აღარ აქვს შენარჩუნებული საჯარო რელე.

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