Префікс філії IPv6: iroute-ipv6 чи route-ipv6 на сервері?

Дві директиви з майже однаковою назвою трапляються в кожному робочому прикладі, і копіювання однієї без іншої дає тунель, який виглядає правильно й мовчки втрачає префікс філії. Вони роблять різну роботу з різних боків однієї межі: одна вчить ядро сервера, де живе префікс, а друга вчить OpenVPN, який перевірений клієнт його несе. Якщо обидві правильні, префікс тече; якщо одна, у пакетів є маршрут, але немає власника.

Дві директиви, дві різні задачі

route-ipv6 — це звичайне встановлення маршруту: сервер додає маршрут ядра, що вказує префікс на його тунельний інтерфейс. iroute-ipv6 належить до контексту конкретного клієнта й оголошує внутрішню належність, тож демон знає: трафік для цього префікса треба надсилати певному клієнту, а не тому peer, який випадково названо в маршруті ядра.

Одна стосується таблиці пересилання ядра, друга — внутрішньої моделі маршрутизації демона. Якщо тримати їх окремо, стає зрозуміло, чому конфігурація, що виглядає повною, все одно може втратити префікс. Це ж пояснює, чому та сама мережа з'являється двічі в кожному робочому прикладі. Жоден із двох рядків не зайвий.

У традиційній userspace-схемі потрібні обидві, і вони доповнюють одна одну. Сам маршрут ядра залишає демон без можливості вибрати peer. Сам iroute залишає ядро без шляху до тунелю. Звідси ж і більша частина плутанини з файлами для окремих клієнтів: файл — не запис таблиці маршрутів, а запис маршруту — не заява про належність.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Де місце кожній

Маршрут іде в керовану конфігурацію сервера, де він діє для цього процесу. iroute іде у файл, специфічний для клієнта, названий за перевіреною особистістю пристрою філії.

Ім'я файлу, що не збігається з фактичною особистістю, ніколи не читається, і симптом збігається з відсутнім iroute. Перевірте особистість, яку підтвердив сервер, а потім перевірте ім'я файлу символ за символом.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Тримайте пул і префікс філії окремо, бо їхнє перекриття створює загадку, яку не розв'яже жодна директива.

Що потрібно іншому клієнту

Другому клієнту, який має дістатися до цієї філії, потрібне оголошення, а не належність. Надішліть префікс тим клієнтам, яким треба, у клієнтському або груповому контексті, що пасує вашій конфігурації.

Не надсилайте його самій філії, бо в цього пристрою префікс уже є як під'єднана мережа.

Надсилання всім — вибір із наслідками: тоді кожен клієнт вважає, що філія доступна через тунель, зокрема клієнти, яким ви ніколи не збиралися давати цей доступ. Оголошення на практиці є рішенням про доступ, хоч директива виглядає як сантехніка. довідка з параметрів сервера описує iroute-ipv6 як належність конкретному клієнту, і саме цю відмінність варто зберегти.

Зворотний шлях на пристрої філії

Належність допомагає лише тоді, коли філія пересилає пакети і її LAN знає, як відповідати. Увімкніть пересилання IPv6 на пристрої філії й переконайтеся, що хости в її LAN надсилають трафік для пулу VPN назад до філії, а не до маршруту за замовчуванням, який цей пул не знає.

Цей зворотний шлях — відповідник для IPv6 тієї проблеми з відсутнім маршрутом, з якою люди стикаються в IPv4.

Перевірте це з хоста в LAN запитом адреси пулу VPN, а не з самої філії. Запит на маршрутизаторі відповідає на інше питання, ніж питання ваших користувачів, і ці відповіді досить часто розходяться, щоб зайва команда того варта.

Коли пари все ще бракує

Деякі розгортання взагалі не використовують цей шлях. Шлях даних ядра й сервери під керуванням продукту мають власну підтримувану обробку маршрутів, і приклад для userspace може не переноситися напряму.

Перевірте, який шлях даних використовує ваша збірка, перш ніж копіювати директиви з посібника, написаного для іншого.

І наостанок пам'ятайте про область адрес: унікальний локальний префікс на кшталт fd00:7a::/64 є приватним за задумом і нічого не каже про публічну доступність IPv6. Вважайте його внутрішнім доступом, а вихід в інтернет тримайте окремим питанням із власною політикою.