Розподіл вашого /64 не маршрутизує IPv6 до VPN-клієнтів

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

Міф: частина вашого /64 уже доступна

Історія приваблива: сервер має публічний /64, розріжте його навпіл, віддайте другу половину пулу VPN, і ці клієнти вже в інтернеті. Розподіл префікса справді виділяє адреси без колізій. Але він не змінює того, як мережа upstream вирішує, куди має йти пакет для однієї з цих адрес.

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

Це вся відмова: прямий напрямок працює, бо його надсилає ваш сервер, а зворотний напрямок помирає за один перехід, бо upstream так і не дізнався, що клієнт існує.

Чого насправді потребує доставка на каналі

Коли upstream вважає весь /64 таким, що перебуває на фізичному каналі, він розв'язує кожну адресу призначення через виявлення сусідів. Він надсилає запит цим каналом і очікує, що власник адреси відповість. VPN-клієнт за тунелем не перебуває на цьому каналі й не може відповісти, тому запит залишається без відповіді, а пакет відкидається.

Вирізання /65 не змінює цього очікування. Upstream і далі розглядає діапазон як такий, що на каналі, бо єдине, що могло б змінити його думку, — це маршрут або проксі, що відповідає від імені клієнта. Жодне не з'являється, бо ви відредагували конфігурацію VPN. Саме ця прогалина пояснює, чому пул може бездоганно працювати між своїми клієнтами й усе одно бути недосяжним з будь-якого іншого місця.

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

Чого потребує маршрутизована доставка

Чистіша схема — це виділення, яке upstream справді маршрутизує на ваш шлюз. Це може бути делегований префікс або статичний маршрут для меншого блоку, і вимога в обох випадках одна: таблиця upstream має вказувати на ваш сервер для клієнтського діапазону. Тоді зворотний трафік надходить на шлюз, і шлюз передає його в тунель.

Маршрутизована доставка повністю знімає питання виявлення сусідів, тому варто попросити її у провайдера, перш ніж будувати щось хитре. Попросіть маршрут письмово й підтвердьте, що наступний перехід — це адреса, до якої upstream справді може дістатися.

Обидві схеми все ще потребують увімкненого пересилання IPv6 на шлюзі й правил брандмауера, що дозволяють пересланий потік в обох напрямках. Доставка — це передумова, а не заміна для решти шляху. Робочий маршрут із вимкненим пересиланням дає точно таку саму тишу, як відсутній маршрут, тому перевірте обидва варіанти, перш ніж щось переробляти.

Два незалежні маршрути, які треба налаштувати правильно

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Префікс вище — це простір документації, а перенаправлення стосується лише IPv6, що якраз і часто потрібно подвійному стеку, поки доставка IPv6 ще виправляється. Перенаправлення IPv4 не встановлює покриття IPv6, і жоден із параметрів не передбачає інший.

Підтримуйте керівний трафік, від якого залежить IPv6, робочим за будь-якої політики, яку застосовуєте. Повідомлення Packet Too Big — класична жертва брандмауера, що дозволяє лише TCP і UDP, і їх відкидання створює з'єднання, які встановлюються, а потім застрягають на більших передачах.

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

Запишіть схему, щоб перезбирання її відтворило

Запишіть три об'єкти окремо: виділення клієнта, маршрут призначення клієнта й метод доставки виділення з боку upstream. Читач, який має всі три, може перезібрати розгортання; читач, який має лише налаштування пулу, відтворить початкову помилку.

Потім явно перевірте зворотний напрямок пакетом, який має повернутися ззовні. Посібник openvpn(8) описує параметри server-ipv6 і redirect, а підтвердження маршрутизації від вашого провайдера покриває ту половину, яку посібник не може.