IPv6-ის დაგეგმვა ორი უბნის WireGuard ჰაბისთვის: პრეფიქსი, პირები, მარშრუტები
იმუშავეთ ორი LAN-ისთვის კერძო IPv6 ჰაბზე: აირჩიეთ პრეფიქსი, დაიტოვეთ გვირაბის მისამართები, შემდეგ მიეცით AllowedIPs-ს გამოხატოს, რომელი პირი ფლობს რომელ ქვექსელს.
ორი LAN, ერთი WireGuard ჰაბი და IPv6 მისამართების გეგმა, რომელმაც სამ ცალკე კითხვას უნდა უპასუხოს: რომელი პრეფიქსი, რომელი მისამართი ეკუთვნის თითოეულ მარშრუტიზატორს და რომელი პირი ფლობს რომელ ქვექსელს. ერთ-ერთის შეცდომა ქმნის გვირაბს, რომელიც ხელის ჩამორთმევას აკეთებს და არაფერს მარშრუტიზებს. ქვემოთ მოცემული გეგმა იმავე თანმიმდევრობით გადის კერძო ორუბნიან დიზაინს. ის განზრახ არ უზრუნველყოფს IPv6 ინტერნეტ წვდომას.
გადაწყვიტეთ, რისთვისაა პრეფიქსი
fd00::/8-დან უნიკალური ლოკალური პრეფიქსი ბუნებრივი არჩევანია, როცა მიზანი უბნებს შორის კერძო წვდომაა. ის სტაბილური რჩება მიუხედავად იმისა, რომელი ISP ემსახურება თითოეულ ადგილს, და არ ცხადდება გლობალურ მარშრუტიზაციის ცხრილში, ამიტომ ვერ გაიტანს თქვენს შიდა ნუმერაციას ინტერნეტში.
იგივე თვისება შეზღუდვაა. ULA არ იძლევა საჯარო დაბრუნების გზას, რადგან არცერთ ზედა დინებამ არ იცის მისი თქვენს კარიბჭემდე მარშრუტიზაცია. თუ მოთხოვნა მოიცავს IPv6 ინტერნეტ გასასვლელს, გჭირდებათ გამოყოფა პროვაიდერისგან, რომელიც მას თქვენკენ მარშრუტიზებს, და ეს ცალკე დიზაინის გადაწყვეტილებაა საკუთარი პრეფიქსის ზომით.
ნუ ივარაუდებთ, რომ ყველა განლაგებას /48 სჭირდება. RFC 6177 გადაუხვია საბოლოო უბნის ერთი სავალდებულო ზომისგან, და სწორი ზომა დამოკიდებულია იმ ქსელების რაოდენობაზე, რომლებსაც მართავთ. შექმენით ULA RFC 4193 პროცედურით და არ გამოიგონოთ პრეფიქსი, რომელსაც სხვა ორგანიზაციაც შეიძლება იყენებდეს. ჩაწერეთ შედეგი მისამართების გეგმაში სანამ რომელიმე მოწყობილობა დაკონფიგურირდება, რადგან პრეფიქსი, რომელიც არავინ ჩაწერა, არის პრეფიქსი, რომელსაც ვინმე ხელახლა გამოიყენებს.
დაყავით პრეფიქსი როლებად
ქვემოთ მოცემული მაგალითი იყენებს fd7c:2e91:4a00::/48-ს, და ცხრილი დალაგებულია იმის მიხედვით, თუ სად იწერება თითოეული ბლოკი და არა უბნის მიხედვით. მოექეცით მნიშვნელობებს როგორც ნიმუშს და შექმენით თქვენი საკუთარი სანამ რამეს განათავსებთ.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN ბლოკები /64-ია, რადგან ჩვეულებრივი SLAAC მოელის 64-ბიტიან ინტერფეისის იდენტიფიკატორს. LAN-ის უფრო პატარა ბლოკად დაყოფა არღვევს ამ დაშვებას ჰოსტების უმეტესობაზე, და ოპერაციული ხარჯი არ ღირს მისამართების დაზოგვას კერძო გეგმაში. ორივე LAN ბლოკი /48-ის შუიდან მოდის, დაბალი დიაპაზონი კი თავისუფალი რჩება შემდგომი უბნებისთვის.
გვირაბის მისამართები ადმინისტრაციული მარაგია და არა ბმულზე არსებული ქსელი. თითოეული ინტერფეისი მისგან იღებს ერთ /128-ს, ამიტომ არცერთი ჰოსტი არ ვარაუდობს საერთო ქვექსელს გვირაბზე და მეზობლების აღმოჩენა არ მუშაობს იქ, სადაც არ არის საჭირო. შეინახეთ როლები განცალკევებული და ჩაწერეთ ისინი ორგანიზაციის მისამართების გეგმაში, რათა შემდგომმა უბანმა ბლოკი ხელახლა არ გამოიყენოს.
მიეცით თითოეულ მარშრუტიზატორს ერთი გვირაბის მისამართი
გამოყავით ერთი /128 მარშრუტიზატორზე და შეინარჩუნეთ მოქმედი ჰაბის არსებული გასაღებები და ბოლო წერტილები. ქვემოთ მოცემული სამი მნიშვნელობა მხოლოდ ჰოსტის ნაწილში განსხვავდება.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128ეს /128 აღწერს ამ ინტერფეისზე მინიჭებულ ერთადერთ მისამართს. ის არაფერს ამბობს იმაზე, რამდენი დანიშნულების მარშრუტიზაცია შეუძლია პირს, რადგან წვდომადობა AllowedIPs-ში გამოიხატება და არა ინტერფეისის პრეფიქსში.
უბნის თითოეულ მარშრუტიზატორს ასევე სჭირდება მისამართი თავის LAN ბლოკში და მისი გავრცელების გზა, ჩვეულებრივ მარშრუტიზატორის განცხადებები SLAAC-ისთვის. WireGuard არ აგზავნის ამ განცხადებებს თქვენ ნაცვლად და არ აკავშირებს ორ LAN-ს. უბნის მარშრუტიზატორი ორივე მიმართულებით მარშრუტიზატორია.
მოათავსეთ ქვექსელის საკუთრება AllowedIPs-ში
ჰაბის პირის ჩანაწერი A უბნისთვის ფლობს A-ის გვირაბის მისამართს და A-ის LAN-ს, და ეს წყვილი მთელი საკუთრების განაცხადია. ამ პირის სექციაში სხვა არაფერია საჭირო უბნის აღსაწერად.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64B უბნის პირის ჩანაწერი ფლობს შესაბამის წყვილს, და აქ სიმეტრია უფრო მნიშვნელოვანია, ვიდრე სიმოკლე. წაიკითხეთ ორი ხაზი ერთად და საკუთრების გაყოფა ერთი შეხედვით ჩანს.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64ეს ორი ცალკე პირის სექციაა და არა ორი სია, რომლებიც ერთ პირზე იბრძვიან. WireGuard AllowedIPs-ს ორივე მიმართულებით იყენებს: ის ირჩევს პირს გამავალი დანიშნულებისთვის და უარყოფს შემომავალ პაკეტს, რომლის წყარო არ ემთხვევა იმ პირისთვის მინიჭებულ დიაპაზონს, რომელმაც ის გაშიფრა. მთელი /48-ის ორივე პირისთვის მიცემა გამორთავდა ამ მეორე შემოწმებას და დააბინდავდა, რომელი უბანი ფლობს რომელ ბლოკს. სწორედ ეს განსხვავება ხდის არასწორი წყაროს მისამართს ხილულს ჩუმად მიღების ნაცვლად.
თითოეულ უბანს სჭირდება მხოლოდ ის დანიშნულებები, რომლებიც ხელმისაწვდომია მისი ჰაბის პირის მეშვეობით: A უბანი ჩამოთვლის ჰაბის მისამართს, B უბნის გვირაბის მისამართს და B-ის LAN-ს, ხოლო B უბანი ჩამოთვლის საპირისპირო სიმრავლეს. სიები განზრახ ასიმეტრიულია, რადგან თითოეული მარშრუტიზატორი ტოპოლოგიის სხვადასხვა მხარეს ხედავს. ორივე დაწერეთ მისამართების გეგმიდან და არა მეორე უბნის კონფიგურაციიდან, რადგან სწორედ ასე გადაურჩება ძველი დიაპაზონი გადანომვრას.
wg-quick-თან ეს დიაპაზონები მარშრუტებსაც ქმნის. systemd-networkd-ის ან ხელით გამართვის შემთხვევაში თავად დაამატეთ ეკვივალენტური მარშრუტები; წინააღმდეგ შემთხვევაში გვირაბი ატარებს პაკეტებს, რომლებსაც ბირთვი მასში არასოდეს აგზავნის.
დაასრულეთ გადაცემა და გამოსცადეთ ორივე მიმართულება
ჩართეთ IPv6 გადაცემა ჰაბზე და ორივე უბნის მარშრუტიზატორზე, და გადაცემის პოლიტიკაში დაუშვით საჭირო უბნებსშორისო სერვისები. შეინახეთ ICMPv6 Packet Too Big შეტყობინებები გამოსაყენებლად, რადგან მათი გადაყრა ამტვრევს ბილიკის MTU აღმოჩენას და ქმნის დიდი გადაცემების შეფერხებებს, რომლებიც აპლიკაციის ხარვეზებს ჰგავს. ჰაბი, რომელიც გადასცემს ხანძარსაწინააღმდეგო კედლის ნებართვის გარეშე, პაკეტს მარშრუტიზაციასა და გვირაბს შორის ყრის. ეს მარცხის რეჟიმი ღირს ცოდნად, რადგან გვირაბი რჩება ჩართული და მხოლოდ ზოგიერთი ნაკადი იღუპება.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1გამოსცადეთ A უბნის ჰოსტიდან B უბნის ჰოსტამდე და შემდეგ საპირისპირო მიმართულებით. ჰაბის გვირაბის მისამართზე ping ამოწმებს მხოლოდ პირველ ნახტომს და გაივლის მაშინაც, როცა LAN-ის მარშრუტები არასწორია. სწორედ ჰოსტიდან ჰოსტამდე ნაკადი ამტკიცებს გეგმას.
გარე WireGuard კავშირი შეიძლება IPv4-ზე მუშაობდეს, სანამ შიდა ტრაფიკი IPv6-ია, და ეს დამოუკიდებლობა სასარგებლოა მიგრაციის დროს. თუ მოგვიანებით დაემატება გლობალური IPv6 გასასვლელი, გადახედეთ პროვაიდერის გამოყოფას, წყაროს მისამართის შერჩევას და დაბრუნების მარშრუტიზაციას როგორც ახალ დიზაინის ნაბიჯს; ზემოთ მოცემული კერძო გეგმა ძალაში რჩება უბნებსშორისო ტრაფიკისთვის.