Планування 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, перегляньте виділення від провайдера, вибір адреси джерела й зворотну маршрутизацію як новий крок проєктування; приватний план вище лишається чинним для трафіку між майданчиками.