Планаванне IPv6 для хаба WireGuard на дзвюх пляцоўках: прэфікс, партнёры, маршруты
Прапрацуйце прыватны хаб IPv6 для дзвюх LAN: выберыце прэфікс, зарэзервуйце адрасы тунеля, а затым дайце AllowedIPs выказаць, які партнёр валодае якой падсеткай.
Дзве LAN, адзін хаб WireGuard і план адрасоў IPv6, які павінен адказаць на тры асобныя пытанні: які прэфікс, які адрас належыць кожнаму маршрутызатару і які партнёр валодае якой падсеткай. Калі адно з іх няправільна, атрымаецца тунель, які выконвае рукапоціск і нічога не маршрутызуе. План ніжэй разглядае прыватную схему з дзвюма пляцоўкамі ў гэтым парадку. Ён наўмысна не дае доступу да Інтэрнэту праз IPv6.
Вызначце, для чаго патрэбен прэфікс
Унікальны лакальны прэфікс з fd00::/8 — натуральны выбар, калі мэта — прыватная дасяжнасць паміж пляцоўкамі. Ён застаецца стабільным незалежна ад таго, які правайдар абслугоўвае кожнае месца, і не абвяшчаецца ў глабальнай табліцы маршрутызацыі, таму не можа выпусціць вашу ўнутраную нумарацыю ў Інтэрнэт.
Тая ж уласцівасць — і абмежаванне. 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 і LAN A, і гэтая пара — усё апісанне ўладання. Нішто іншае ў гэтым раздзеле партнёра не мусіць апісваць пляцоўку.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64
Запіс партнёра для пляцоўкі B валодае адпаведнай парай, і сіметрыя тут важнейшая за кароткасць. Чытайце два радкі разам — і размеркаванне ўладання відаць з першага погляду.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64
Гэта два асобныя раздзелы партнёраў, а не два спісы, што спаборнічаюць за аднаго партнёра. WireGuard выкарыстоўвае AllowedIPs у абодвух напрамках: ён выбірае партнёра для зыходнага прызначэння і адхіляе ўваходны пакет, крыніца якога не адпавядае дыяпазону, прызначанаму партнёру, які яго расшыфраваў. Калі аддаць увесь /48 абодвум партнёрам, гэтая другая праверка адключыцца і стане незразумела, якая пляцоўка валодае якім блокам. Менавіта гэтае размежаванне робіць няправільны адрас крыніцы бачным, а не моўчкі прынятым.
Кожнай пляцоўцы патрэбныя толькі прызначэнні, дасяжныя праз яе партнёра-хаб: пляцоўка A пералічвае адрас хаба, адрас тунеля пляцоўкі B і LAN B, а пляцоўка 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 дададуць пазней, перагледзьце выдзяленне ад правайдара, выбар адраса крыніцы і зваротную маршрутызацыю як новы крок праектавання; прыватны план вышэй застаецца сапраўдным для трафіку паміж пляцоўкамі.