IPv6 здесь не заменяет клиентский IPv4 и не участвует в пользовательской адресации. Он только несёт UDP-пакеты WireGuard между двумя маршрутизаторами. Это удобное разделение: внешний транспорт живёт своей жизнью, а внутреннюю IPv4-маршрутизацию можно менять независимо.

При underlay MTU 1500 мы оставили WireGuard MTU 1420. Расчёт скучный, но полезный: IPv6-заголовок занимает 40 байт, UDP ещё 8, служебная часть WireGuard data packet — 32. Итого 80 байт накладных расходов, поэтому 1500 − 80 = 1420.

Как должен был идти трафик

На центральном роутере появилась отдельная FIB-таблица с default route через туннельный адрес удалённого RouterOS. Трафик Linux-хоста портала маркировался и отправлялся в эту таблицу. На удалённой стороне были обратный маршрут к сети портала, разрешение forward из туннеля в ISP и обычный masquerade на внешнем интерфейсе.

Мы отдельно проверили транспорт:

• WireGuard handshake обновлялся с обеих сторон;

• внутренние адреса туннеля пинговались в обоих направлениях;

• OSPF поднялся поверх WireGuard и установил ожидаемые маршруты;

• удалённый RouterOS сам успешно ходил во внешний IPv4;

• центральный роутер выбирал нужную policy table.

То есть сам IPv6 underlay и межроутерный WireGuard работали. Но клиентский трафик всё равно не возвращался.

Почему первые подозрения оказались неверными

Сначала мы сравнили рабочий egress через другой роутер и новый egress. Отличались rp-filter, форма правила masquerade и набор forward-правил. Эти отличия выглядели подозрительно, но после приведения настроек к рабочему шаблону симптом остался.

Это был хороший сигнал перестать гадать по конфигам и посмотреть, где реально находится последний живой пакет.

Два tcpdump и один route get

На Linux-хосте портала одновременно запустили захват на интерфейсе WireGuard и на LAN-интерфейсе.

На выходе всё выглядело правильно: пакет клиента приходил из WG-пула, пересылался в LAN и получал SNAT в адрес самого хоста. На LAN-интерфейсе были видны и запросы к внешнему адресу, и ответы обратно. Значит, удалённый RouterOS, NAT и интернет-маршрут свою работу уже сделали.

Но на wg-интерфейсе были только исходящие запросы клиента. Ответы доходили до Linux-хоста и дальше в туннель не попадали. Счётчик forward в направлении LAN → WireGuard тоже не рос.

Решающим оказался обычный поиск маршрута для реального ответного пакета. Ядро выбирало основной default route хоста, а не wg-интерфейс. Причина была простой: policy rule существовало только для пакетов от клиентского пула. Ответ из интернета приходит к клиентскому пулу, поэтому правило по source на него не распространяется.

Точечное исправление

В отдельной таблице уже был link route клиентской сети через wg-интерфейс. Не хватало симметричного правила выбора этой таблицы по адресу назначения:

ip rule add to <WG_CLIENT_POOL> lookup <VPN_TABLE> ip rule add from <WG_CLIENT_POOL> lookup <VPN_TABLE>

Первое правило возвращает ответы в WireGuard, второе сохраняет прежний исходящий policy routing. После добавления destination rule тот же route lookup выбрал wg-интерфейс. В захвате появились echo reply к адресу клиента, обратный forward-счётчик начал расти, а реальный клиент получил интернет через удалённый egress.

Что из этого стоит запомнить

Свежий WireGuard handshake доказывает только работоспособность транспорта. OSPF Full доказывает соседство и обмен маршрутами между роутерами. Masquerade доказывает, что пакет можно выпустить наружу. Ни один из этих фактов не гарантирует, что Linux выберет правильную таблицу для ответного трафика после обратного NAT.

Для таких схем полезнее не перебирать настройки вслепую, а строить короткую цепочку доказательств: вход в wg, выход из LAN, возврат на LAN, решение route lookup, возврат в wg. Как только каждый переход подтверждён захватом или счётчиком, «мистическая проблема туннеля» обычно превращается в одно конкретное правило.

Больше технических разборов публикую на сайте.

Теперь облачной базе данных можно выдать бесплатный публичный IPv6-адрес.

Полезно, если:

1️⃣ Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы

2️⃣ Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов

3️⃣ Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.

Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.

При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации →

Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.

Привязать айпишник к базе →

1. Определение IPv6-адреса, подсети и имени сетевого интерфейса Yggdrasil Network.

В PowerShell от имени администратора:

yggdrasilctl getSelf

Пример вывода:

Build name: yggdrasil

Build version: #Ваша версия

IPv6 address: 200:aaaa:bbbb:cccc:XXXX:XXXX:XXXX:XXXX

IPv6 subnet: 300:aaaa:bbbb:cccc::/64

Public key: #Ваш публичный ключ

Разбираем:

Build name: yggdrasil

В конфигурационном файле Yggdrasil (yggdrasil.conf) есть параметр IfName. Именно он определяет имя сетевого интерфейса, который создаёт Yggdrasil в Windows. По умолчанию это просто «Yggdrasil», но вы можете изменить название на любое, например: «Ygg0», «Mesh6», «HyperLAN» или другое в рамках ANSI. Это важно, потому что все дальнейшие команды PowerShell опираются на факт того, как интерфейс называется реально. Если в вашем yggdrasil.conf имя изменено, то и в командах упоминающих действительные сетевые имена типа:

Set-NetIPInterface -InterfaceAlias "Yggdrasil" -Forwarding Enabled

нужно будет подставить своё значение, например:

Set-NetIPInterface -InterfaceAlias "Ваше название" -Forwarding Enabled

В данной статье используются стандартные имена «Yggdrasil» и «Ethernet» для LAN, чтобы избежать путаницы и сделать примеры универсальными.

Примечание: Сам Build name технически не является IfName, но в рамках статьи этот вопрос рассматриваться не будет поскольку не имеет определяющего значения на результат. Главное - использовать действительные имена сетевых интерфейсов Windows.

Продолжаем разбираться:

200:aaaa:bbbb:cccc:XXXX:XXXX:XXXX:XXXX — индивидуальный адрес вашей Yggdrasil-машины.

300:aaaa:bbbb:cccc::/64 — подсеть, которую мы и будем раздавать клиентам LAN. Это ваша «внутренняя Ygg-подсеть».

Скопируйте значение IPv6 subnet — оно потребуется позже.

2. Идентификация действительных сетевых имён интерфейсов Yggdrasil и LAN.

Через GUI: Панель управления → Сеть и Интернет → Центр управления сетями → Изменение параметров адаптера или в PowerShell:

netsh interface ipv6 show interfaces

Ищем строки примерно такого вида:

31 0 65535 connected Yggdrasil

12 20 1500 connected Ethernet

Yggdrasil — виртуальный интерфейс самого Yggdrasil, а Ethernet (или другое имя) - ваша LAN. MTU можно запомнить, но это не критично — главное знать имена интерфейсов. Эти два имени обязательно понадобятся далее при включении IPv6-форвардинга и назначении адреса подсети 300::/64.

Замечание: Так как имя сетевого интерфейса Yggdrasil Network привязано к параметру IfName из yggdrasil.conf, изменение его средствами Windows (через GUI или PowerShell) нецелесообразно: оно действует только в рамках текущего запуска yggdrasil.exe и после перезапуска будет автоматически заменено на значение из IfName. Это может привести к несоответствию реального имени интерфейса и настроек netsh после, например, аварийной перезагрузки или других подобных ситуаций. Используйте только имя, указанное в IfName.

3. Включение IPv6-маршрутизации в Windows.

По умолчанию Windows не маршрутизирует IPv6-пакеты, поэтому включаем эту функцию. Необходимо назначить два ключа в реестре из:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

DisabledComponents = 0 — включает полный IPv6-стек без ограничений.

EnableICSIPv6 = 1 — разрешает Windows действовать как IPv6-маршрутизатор при использовании Internet Connection Sharing.

Создаём параметры при необходимости в regedit или PowerShell-командами:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -PropertyType DWord -Value 0 -Force

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "EnableICSIPv6" -PropertyType DWord -Value 1 -Force

Примечание: На Windows Server 2012 R2 обычно требуется только DisabledComponents = 0.

4. Включение IPv6-Forwarding на интерфейсах Yggdrasil и LAN.

Выполняем:

Set-NetIPInterface -InterfaceAlias "Yggdrasil" -Forwarding Enabled

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Проверяем:

Get-NetIPInterface | Select InterfaceAlias, Forwarding

Вывод

Yggdrasil Enabled

Ethernet Enabled

говорит о верной настройке.

5. Проверка общих IPv6-настроек.

netsh interface ipv6 show global

Здесь особого действия не требуется — вывод носит справочный характер.

6. Включение IPv6-Forwarding для Yggdrasil и LAN на уровне интерфейса netsh.

netsh interface ipv6 set interface "Yggdrasil" forwarding=enabled

netsh interface ipv6 set interface "Ethernet" forwarding=enabled

OK.

7. Назначение LAN-интерфейсу адреса из вашей подсети 300::.

Используем записанное ранее значение подсети: 300:aaaa:bbbb:cccc::/64 и назначаем LAN-интерфейсу адрес, например, ::a из GUI, либо в PowerSell:

netsh interface ipv6 add address "Ethernet" "300:aaaa:bbbb:cccc::a"

Длинна префикса подсети: 64

Важно: нельзя использовать адрес, который выводится в строке из yggdrasilctl getSelf: «IPv6 address: 200:aaaa:bbbb:cccc:XXXX:XXXX:XXXX:XXXX» - он уже занят самим Ygg-нодом и находится в диапазоне 200:.

Замечание: Интернет (WAN) и LAN на Windows-мосте обязательно должны быть разными интерфейсами. Интерфейс с подсетью 300::/64 — это чисто внутренняя сеть. Интернет, через который Yggdrasil подключается к пирам, должен приходить через другой сетевой адаптер. Если интернет приходит в эту же LAN-сеть, Windows может перепутать маршрутизацию и попытаться отправлять Ygg-трафик обратно в LAN, что приводит к полной неработоспособности моста. Сам факт корректной маршрутизации возможен даже и при таких условиях, однако потребует дополнительных сведений о конфигурации вашей сети, знаний и опыта в маршрутизации.

Команды:

netsh interface ipv6 show addresses "Ethernet"

netsh interface ipv6 show addresses "Yggdrasil"

расскажут вам дополнительные подробности. Если все действия совершены верно, Windows готов выполнять роль моста Yggdrasil ↔ LAN.

8. Настройка клиентов LAN.

На каждом клиентском устройстве указываются:

IPv6-адрес (индивидуально): 300:aaaa:bbbb:cccc::b (или любой другой в этой подсети)

Длинна префикса подсети: 64

Основной шлюз: 300:aaaa:bbbb:cccc::a (адрес вашего Windows-моста)

9. Проверка.

С любого устройства LAN:

ping любой:узел:Yggdrasil

или откройте в браузере Ygg-сайт по адресу видa:

http://[300:....]

http://[200:....]

например http://[222:a8e4:50cd:55c:788e:b0a5:4e2f:a92c]

Если всё работает — мост настроен.

Стоит отметить, что разворачивая мост, вы по сути выводите всю вашу LAN в глобальную IPv6-среду Yggdrasil. И даже если у вас дома всё под контролем помните, что теперь локальные машины и сам сетевой мост - часть общей yggdrasil-сети без сквозного шифрования. Если сомневаетесь в добросовестности абсолютно всех пользователей Yggdrasil Network или имеете индивидуальные требования к сетевой безопасности - есть смысл настроить фильтрацию в брандмауэре Windows или на внешнем маршрутизаторе согласно вашим нуждам.

Заключение

Описанный метод успешно работает у меня в домашней сети, где шлюзом выступает Windows Server 2012 R2. Аналогичный подход применим ко всем версиям Windows, поддерживающим PowerShell и запуск Yggdrasil, а также полезен как общее введение в IPv6-маршрутизацию.

Выражаю благодарность авторам TCP/IP-протокола, Microsoft, OpenAI, HowToYgg wiki, разработчикам и сообществу Yggdrasil Network.

Успехов в настройках, господа сетевые администраторы!

Умные мысли в комментариях приветствуются.

UPD. Ложная тревога (конкретно этот случай). Дочка клиента вспомнила, что пару месяцев назад вызывала мастера по объявлению на остановке т.к. знакомый был недоступен. Провайдер - Дом.ру, когда постучались в роутер (Asus) пароль не подошел, роутер был сброшен (после инцидента и поста).

Спасибо всем откликнувшимся.

А раз так, то вот вам суть:

ТСПУ по каким-то неведомым мне причинам игнорирует существование ipv6.

Операторы (в большинстве своем) представляют доступ к данному протоколу.

В настройках точки доступа APN достаточно поставить "ipv4/ipv6" ну и на всякий случай аутентификацию "PAP или CHAP"

В моем случае даже опцию открытый ipv6 не пришлось подключать в личном кабинете, и так все работало.

Ну а дальше копайте, от забора и до обеда.