Делегирование префикса IPv6 в OpenWrt: проверка сети

Делегирование префикса IPv6 в OpenWrt распределяет полученный от провайдера блок адресов между нижестоящими сетями. Это не то же самое, что получение одного адреса WAN. Проверяйте блок, объявления LAN, маршруты клиентов и направление правил экрана отдельно, особенно после изменения префикса провайдером.

Ключевые выводы

• Адрес WAN не доказывает наличие делегированного префикса.
• RA сообщает маршрутизатор по умолчанию; DHCPv6 не заменяет это объявление.
• Правила input маршрутизатора и forwarding LAN защищают разные назначения.
• Сохраняйте необходимый ICMPv6 вместо его отключения для диагностики.
• Восстановление конфигурации не заставит провайдера вернуть прежний префикс.

Что требуется для делегирования префикса IPv6 в OpenWrt?

Процедура рассчитана на стабильную OpenWrt 25.12 с fw4/nftables, провайдера с DHCPv6 prefix delegation и одну контролируемую нижестоящую LAN. Она основана на официальной документации и стандартах; полное сквозное испытание маршрутизатора не проводилось. Таблицы описывают ожидаемое поведение и действия читателя при отказе, а не измерения автора.［1］

Перед изменением общего маршрутизатора используйте список ответственности и восстановления сети. Если OpenWrt является лишь дополнительным шлюзом в той же подсети, не запускайте там второй RA-сервер, имитируя отдельную маршрутизируемую сеть. Определите маршрутизатор, действительно получающий делегирование ISP.

Если воспринимаете IPv6-адрес как проброс порта IPv4, изучите различия адресации IPv4 и IPv6. Распределение публичных адресов и доступ к частной службе — отдельные задачи; выбрать поможет сравнение домашнего шлюза и интернет-выхода. Эта процедура не создаёт службу удалённого доступа.

Шаг 1: сохраните исходное состояние и определите WAN, PD и LAN

Используйте проводное управление с работающим IPv4, не зависящее от изменяемых настроек IPv6. Создайте новое подключение и подтвердите локальную процедуру восстановления. Сохраните конфигурации network, DHCP и экрана в закрытом месте вне маршрутизатора, включая записи служб и динамический DNS, содержащие адреса.

В Network → Interfaces найдите фактический логический интерфейс восходящего IPv6. Это может быть wan6; PPP способен автоматически создавать wan_6. До добавления ещё одного клиента DHCPv6 изучите существующие интерфейсы. Отдельно запишите делегированный префикс, длину и времена жизни, назначенный нижестоящий префикс и адреса клиентов.［2］

Объект	Что проверить	Чего это не доказывает
Адрес WAN	Адрес и маршрут вышестоящего интерфейса	Что провайдер делегировал пространство LAN
Делегированный префикс	Блок IPv6-PD и времена жизни	Что объявления LAN и правила экрана верны
Назначение LAN	Подсеть из полученного блока	Что каждый клиент имеет рабочий маршрут по умолчанию
Адрес клиента	Глобальные, локальные и link-local адреса	Что внешняя машина может обратиться к службе
Маршрут по умолчанию	Фактический следующий узел и интерфейс	Что DNS и обратный трафик работают

Если провайдер не выдаёт PD, остановите эту ветку и уточните поддерживаемую конфигурацию нижестоящей сети. Не копируйте посторонний статический префикс и не переходите молча к NDP proxy, ретрансляции или NAT66. Это другие схемы с отдельными предпосылками. Документационные адреса, например 2001:db8::/32, служат заполнителями и никогда не должны выдаваться за реальные назначения провайдера.

Шаг 2: запросите OpenWrt DHCPv6 PD и назначьте одну подсеть LAN

На существующем восходящем интерфейсе DHCPv6 проверьте Request IPv6-prefix of length. Обычно начните с auto, если провайдер не предписывает другой вариант. Параметр UCI называется reqprefix; это запрос, а не принуждение ISP выдать выбранный размер. Оставьте делегирование на восходящем интерфейсе включённым для последующего распределения.［2］

На контролируемой LAN задайте IPv6 assignment length равным 64 (ip6assign: 64) для этой обычной клиентской подсети. Делегированные /56 или /60 дают место нескольким LAN /64. Единственный делегированный /64 не создаёт независимый /64 для каждого VLAN. Не маскируйте нехватку пространства перекрывающимися назначениями.

Используйте ip6hint только для предпочтительного идентификатора подпрефикса в доступном пространстве, а ip6class — при намеренном выборе источника префикса. Эти параметры не создают отсутствующее делегирование. Изучайте реальное выделение, не предполагая, что запрошенный hint обязательно выполнен.［2］

Примените одно изменение через LuCI и перечитайте состояние интерфейса. Не перезапускайте WAN многократно в надежде вернуть желаемый префикс. Если нет PD сверху либо назначения LAN, остановитесь на этом уровне до изменения приложений или входящих правил экрана.

Шаг 3: проверьте объявления, адреса и маршруты клиентов

Для этой маршрутизируемой нижестоящей LAN проверьте RA-Service и DHCPv6-Service в настройках IPv6 сервера DHCP. Используйте серверные роли, соответствующие существующим клиентам. Не включайте relay или NDP proxy только потому, что так сделано в примере форума. На восходящем интерфейсе эти объявления должны оставаться выключенными.［2］［3］

RA передаёт информацию о маршрутизаторе по умолчанию и может поддерживать SLAAC. DHCPv6 предоставляет другую конфигурацию и адреса совместимым клиентам; получение только информации DHCPv6 не доказывает наличие маршрутизатора IPv6 по умолчанию. У клиента законно могут одновременно быть несколько глобальных адресов, временные приватные адреса и link-local. Классифицируйте их, прежде чем определять источник запроса.［4］

На OpenWrt замените wan6 фактическим восходящим интерфейсом. Это команды осмотра, не образец вывода и не доказательство выдачи конкретного префикса. Не публикуйте домашние адреса и полный диагностический экспорт без проверки чувствительных данных.［3］

ifstatus wan6
ifstatus lan
ip -6 address show
ip -6 route show
ip -6 rule show

На тестовом клиенте Linux изучите ip -6 address show и ip -6 route show; другие системы имеют аналогичные представления адресов и маршрутов. Новый запрос должен использовать актуальный глобальный источник и нужный маршрутизатор. Отдельно проверьте доступ клиента к маршрутизатору, маршрутизатора к провайдеру и клиента к провайдеру. Успех самого маршрутизатора не доказывает пересылку LAN.

Как межсетевой экран IPv6 OpenWrt обрабатывает входящий трафик?

Защищайте маршрутизатор правилами input, а нижестоящие машины — forwarding. В fw4 указание зоны назначения относится к пересылке; без этой зоны правило обычно направлено на сам маршрутизатор. Изучайте реально сгенерированные правила и состав зон, а не предполагайте нужное направление по одному совпадению адреса.［5］

Сохраните запрет управления через WAN по умолчанию. Не добавляйте WAN input ACCEPT для LuCI или SSH и не разрешайте всю пересылку WAN–LAN ради доступности одной службы. Сохраните необходимый трафик клиента DHCPv6 и функции ICMPv6. ICMPv6 обеспечивает обнаружение соседей, сигналы ошибок и path MTU; безразборная блокировка способна нарушить корректные соединения.［2］［4］［6］

При намеренной публикации частной службы сначала используйте схему ограниченного доступа к NAS. Разрешённая публичная проверка должна назвать точное текущее назначение, протокол, порт, ограничение источника и экран конечной машины. Глобальный адрес клиента не разрешает открывать его управление. Отсутствие NAT типа IPv4 также не отменяет защиту экрана IPv6.

Шаг 4: перепроверьте смену префикса с разрешённой внешней точки

Наблюдайте естественное изменение либо обновляйте аренду или соединение только разрешённого тестового восходящего канала в согласованное окно. Запишите старый и новый PD, допустимые и предпочтительные времена жизни, а также назначения нижестоящей сети. Не обещайте смену префикса и не пытайтесь вызвать её постоянным обрывом подключения всего дома.

Проверьте точные адресные ссылки в правилах экрана, DNS, списках разрешений, привязках служб и мониторинге. Предпочитайте правила по интерфейсу или зоне, когда они точно выражают разрешение без фиксированного префикса ISP. Старый адрес может перестать совпадать, а слишком широкая замена — открыть другие устройства. Сохраняйте ограничения источника и обновляйте только принадлежащие этому упражнению ссылки.

Старые адреса могут оставаться допустимыми для существующих соединений, уже став устаревшими для новых. Проверяйте объявленные времена жизни, выбор источника и новые соединения вместо удаления всех IPv6-адресов клиентов. RFC 4861 и RFC 4862 описывают объявления и сроки адресов; конкретный переход определяют ISP и клиент.［4］

Метод проверки	Ожидаемое наблюдение	Действие при отказе
Перечитать PD и состояние LAN	Текущая LAN входит в реально делегированный блок	Проверить делегирование и распределение до клиента
Изучить RA, адрес и маршрут по умолчанию клиента	Доступны актуальный источник и нужный следующий узел	Проверить объявления и конфигурацию клиента
Создать новые разрешённые исходящие запросы IPv6	Маршрутизатор и клиент работают каждый на своём пути	Разделить ошибки источника, пересылки, DNS и обратного пути
Попытаться управлять маршрутизатором из разрешённой независимой IPv6-сети	Успешной сессии управления через WAN нет	Остановиться и убрать непредусмотренное input-разрешение
Проверить специально разрешённую службу и один неразрешённый порт	Подключается только документированная служба	Проверить forwarding, экран машины, привязку и фильтрацию ISP
Переподключить или перезагрузить только тестовый маршрутизатор и повторить	Сохранённый замысел действует, адресные ссылки актуальны	Восстановить свои изменения и перечитать текущий PD

С клиента проверьте видимый публичный выход IPv6, не смешивая его с входящей доступностью. Если используется туннель, изучите непредусмотренный обход через IPv6. Ответ исходящего веб-запроса не доказывает блокировку управления через WAN.

Без разрешённой внешней точки IPv6 отметьте входящую проверку как не выполненную, не заявляя приёмку публичного доступа. Один неудачный внешний запрос также не определяет место блокировки. Сопоставьте его со счётчиками маршрутизатора, экраном машины и состоянием службы. Ограничьте наблюдение согласованными машинами и портами; не сканируйте чужие сети.

Шаг 5: восстановите настройки, а не обещание прежнего префикса ISP

Отмените только изменения reqprefix, назначения LAN и объявлений этой процедуры, её временные разрешения служб и адресные ссылки. Верните записанные прежние значения в соответствующих разделах конфигурации, сохраняя последующие посторонние правки. Перед рискованным применением снова подключитесь по независимому проводному пути управления.

После восстановления заново изучите текущий делегированный префикс и назначения LAN. Провайдер может сохранить новый префикс: архив настроек не резервирует и не возвращает старый. Согласуйте DNS и точные адресные правила с текущими разрешёнными адресами. Удаляйте устаревшие ссылки только после выяснения использующих их служб.

Закройте временные внешние разрешения, остановите созданную вами тестовую службу и подтвердите её недоступность с разрешённой внешней точки. Повторите обычный DNS LAN, новые запросы IPv4/IPv6 и локальное управление в новой сессии. Если восстановление нельзя подтвердить, прекратите изменения и восстанавливайте локально, не ослабляя экран ради результата.

Итоги

• Проверяйте WAN-адрес, делегирование и распределение LAN как отдельные этапы.
• Согласуйте объявления и маршруты с настоящей нижестоящей топологией.
• Раздельно изучайте input, forwarding и необходимый ICMPv6.
• Восстанавливайте конфигурацию и сверяйте её с текущим префиксом ISP.

Часто задаваемые вопросы (FAQ)

Глобальный адрес WAN означает делегированный префикс LAN?

Нет. Адрес WAN и делегирование — разные результаты. Проверьте блок IPv6-PD и нижестоящее назначение, прежде чем ожидать глобально маршрутизируемые адреса клиентов.

Запрос /56 заставляет провайдера выдать его?

Нет. Запрос ограничен услугой и политикой ISP. Используйте поддерживаемое значение и остановитесь, если топологии нужно больше пространства, чем делегируется.

Почему адрес клиента есть, а интернет IPv6 не работает?

Может отсутствовать объявление маршрутизатора по умолчанию, допустимый выбор источника, разрешение пересылки или обратный путь. Проверяйте адреса и маршруты клиента и маршрутизатора отдельно.

Нужно блокировать весь ICMPv6, чтобы скрыть сеть?

Нет. Необходимые сообщения обеспечивают обнаружение соседей, ошибки и path MTU. Сохраняйте документированную защиту и нужные типы сообщений вместо полного запрета или полного разрешения.

Публичный IPv6 отменяет необходимость экрана?

Нет. Глобально маршрутизируемый адрес указывает возможный путь; экран маршрутизатора и конечной машины определяет разрешение новых входящих соединений. Явно проверяйте границу службы.

Правило со старым префиксом обновится автоматически?

Не предполагается, что буквальный адрес следует перенумерации. Проверьте адресные правила и DNS, сохраните ограничения и изменяйте лишь ссылки с известными назначением и владельцем.

Восстановление копии вернёт старый префикс провайдера?

Оно возвращает локальные настройки, а не распределение ISP. После восстановления прочтите фактическое делегирование и приведите законные адресные ссылки к текущему префиксу.

Источники:

1. OpenWrt — 25.12.0 release notes — https://openwrt.org/releases/25.12/notes-25.12.0
2. OpenWrt — IPv6 configuration — https://openwrt.org/docs/guide-user/network/ipv6/configuration
3. OpenWrt — IPv6 troubleshooting — https://openwrt.org/docs/guide-user/network/ipv6/troubleshooting
4. IETF — RFC 4861 and RFC 4862, Neighbor Discovery and Stateless Address Autoconfiguration — https://www.rfc-editor.org/rfc/rfc4861 ; https://www.rfc-editor.org/rfc/rfc4862
5. OpenWrt — Firewall configuration — https://openwrt.org/docs/guide-user/firewall/firewall_configuration
6. IETF — RFC 4890, Recommendations for Filtering ICMPv6 Messages — https://www.rfc-editor.org/rfc/rfc4890

Sources checked 11 октября 2026 г.

---

Рекомендуемые статьи:

• Ограничения шлюза в общей подсети
• Сравнение двух семейств адресов
• IPv6 в обход запланированного туннеля
• Частный доступ или публичный выход
• Ограниченный доступ к домашнему NAS