დაამატეთ კერძო IPv6 OpenVPN-ის ლაბორატორიას, თითო საკონტროლო წერტილი ერთდროულად

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

პირველი საკონტროლო წერტილი: კავშირი, რომელიც უკვე მუშაობს

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

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

მეორე საკონტროლო წერტილი: შეარჩიეთ შიდა პრეფიქსები

აირჩიეთ ULA /48 საიტისთვის და მოაჭერით ორი /64: ერთი გვირაბის კლიენტებისთვის, ერთი IPv6 დატვირთვის მქონე LAN სეგმენტისთვის. დააგენერირეთ 40-ბიტიანი გლობალური ID ნიმუშის პრეფიქსის კოპირების ნაცვლად, და შეამოწმეთ ორივე ქვექსელი ყველა იმ ქსელთან, რომელსაც საიტი უკვე მარშრუტიზაციას უკეთებს:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

მესამე საკონტროლო წერტილი: დაამატეთ დამხმარე და მარშრუტის ბიძგი

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

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

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

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

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

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

შემდეგ მიეცით LAN-ს დაბრუნების მარშრუტი გვირაბის პულისკენ. დატვირთვის IPv6 კარიბჭე LAN-ის როუტერია და არა VPN სერვერი, ამიტომ მარშრუტი ამ როუტერზეა და მიუთითებს სერვერის LAN მისამართზე:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

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

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

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

მარშრუტი, რომელიც გვირაბს ირჩევს, ამტკიცებს, რომ კლიენტმა იცის სად გაუშვას პაკეტი. ის არ ამტკიცებს, რომ სერვერი გადასცემს მას, რომ LAN-ის როუტერს აქვს დაბრუნების მარშრუტი, ან რომ აპლიკაციას პასუხის უფლება აქვს.

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

გამოაქვეყნეთ AAAA ჩანაწერი მხოლოდ მაშინ, როცა IPv6 ბილიკი ბოლოდან ბოლომდე პასუხობს. IPv4-ით მოთხოვნილი DNS მაინც შეიძლება დააბრუნოს IPv6 მისამართი, ამიტომ გადაწყვეტადი სახელი არ არის მტკიცებულება, რომ რაღაც ისმენს. RFC 4193 ULA გზამკვლევი მოიცავს გლობალური ID-ის გენერაციას, რომელიც ამ პრეფიქსებს თქვენსას ხდის და არა ასლს.