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

Дръж pool-а и префикса на клона отделни, защото припокриването им създава главоблъсканица, която никоя директива не може да реши.

Какво е нужно на друг клиент

Вторият клиент, който трябва да достигне този клон, се нуждае от обявление, а не от собственост. Изпрати префикса до клиентите, които искаш, в контекста на клиент или група, който отговаря на твоята конфигурация.

Не го изпращай до самия клон, защото това устройство вече има префикса като свързана мрежа.

Изпращането до всички е избор с последствия: всеки клиент тогава вярва, че клонът е достъпен през тунела, включително клиенти, на които никога не си искал да дадеш този достъп. Обявлението е на практика решение за достъп, макар директивата да изглежда като водопроводна работа. справката за опциите на сървъра документира iroute-ipv6 като собственост, специфична за клиента, и това е разликата, която си струва да се задържи.

Обратният път на устройството на клона

Собствеността помага само ако клонът препраща пакети и неговата LAN знае как да отговори. Включи препращането на IPv6 на устройството на клона и потвърди, че хостовете в неговата LAN изпращат трафика за pool-а на VPN обратно към клона, а не към маршрут по подразбиране, който не познава pool-а.

Този обратен път е IPv6 еквивалентът на проблема с липсващия маршрут, на който хората се натъкват с IPv4.

Провери го от хост в LAN с търсене на адреса на pool-а на VPN, а не от самия клон. Търсене на рутера отговаря на друг въпрос от този на твоите потребители и двете достатъчно често се разминават, за да си струва допълнителната команда.

Когато двойката все още не е достатъчна

Някои внедрявания изобщо не използват този път. Пътят на данни на ядрото и сървърите, управлявани от продукта, имат собствена поддържана обработка на маршрути, а примерът за userspace може да не се пренася директно.

Потвърди кой път на данни използва твоята сборка, преди да копираш директиви от ръководство, написано за другата.

Накрая, помни обхвата на адресите: уникален локален префикс като fd00:7a::/64 е частен по дизайн и не казва нищо за публичната достъпност на IPv6. Третирай го като вътрешен достъп, а изхода към интернет дръж като отделен въпрос със собствена политика.