IPv6 в домашней сети на OpenWrt с делегированием префикса, анонсами маршрутизатора и сетевым экраном

Поддержка IPv6 у большинства провайдеров включена или включается по заявке, а домашние маршрутизаторы продолжают работать так, будто существует только IPv4. Настройка занимает около получаса и снимает несколько повседневных неудобств: проброс портов для доступа к домашним службам, нехватку адресов и проблемы протоколов, которые за трансляцией адресов работают хуже. Разбираем адресацию, настройку внешнего и внутреннего интерфейсов и обязательные правила сетевого экрана.

Какие задачи решает IPv6 и почему страхи преувеличены

Главное отличие от IPv4 не в длине адреса, а в модели работы. Трансляция сетевых адресов в IPv6 отсутствует как необходимость, и каждое устройство получает адрес из глобального диапазона.

Отсюда практическая польза. Доступ к домашнему серверу снаружи не требует проброса портов, достаточно имени в DNS и правила в сетевом экране. Устройства перестают конкурировать за адреса. Протоколы, чувствительные к трансляции, работают корректно, поскольку трансляции нет.

Второй страх касается безопасности. Утверждение, что IPv6 делает устройства открытыми интернету, неверно: сетевой экран никуда не исчезает, меняется логика правил. В IPv4 защиту обеспечивал сам факт трансляции, в IPv6 её обеспечивает явный фильтр, и доступ снаружи по умолчанию закрыт.

Третий страх связан со сложностью записи адресов. На практике вручную их почти не вводят: устройства получают адреса автоматически, а человек работает с именами.

Переход не означает отказа от IPv4. Обе версии работают одновременно, и такое состояние называется двойным стеком: часть ресурсов доступна только по четвёртой версии, часть по обеим.

Типы адресов и что такое делегирование префикса

Три категории адресов различают, поскольку в диагностике они ведут себя по-разному.

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

Уникальные локальные адреса начинаются с fd и предназначены для внутренней адресации. Снаружи они не видны и играют роль, похожую на частные адреса четвёртой версии.

Глобальные адреса получаются от провайдера и используются для выхода наружу. Провайдер выделяет не один адрес, а префикс, то есть диапазон, который маршрутизатор делит между своими сетями. Такой механизм называется делегированием префикса и выполняется через DHCPv6.

Размер префикса имеет значение. Провайдеры обычно делегируют префикс длиной 56 или 60 бит, что даёт 256 или 16 внутренних сетей по 64 бита. Каждая внутренняя сеть обязана иметь длину ровно 64 бита, поскольку автоконфигурация адресов рассчитана на такой размер, и при более длинном префиксе она работать не будет.

Посмотреть, что реально получено от провайдера:

ip -6 addr show scope global
ip -6 route show

Настройка внешнего интерфейса и получение префикса

Внешний интерфейс получает адрес и префикс через клиент DHCPv6. В OpenWrt за это отвечает отдельный логический интерфейс, который настраивается в файле network.

config interface 'wan6'
    option device '@wan'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix 'auto'

Ссылка @wan означает, что отдельного физического устройства не требуется. Параметр reqaddress со значением try запрашивает адрес для маршрутизатора, но его отсутствие ошибкой не считается. Параметр reqprefix управляет запросом префикса: auto запрашивает префикс той длины, которую готов выдать провайдер, число задаёт желаемую длину, а no оставляет только адрес для самого устройства.

Для соединений на основе PPP, включая PPPoE, параметр ipv6 задают в родительской секции внешнего интерфейса:

config interface 'wan'
    option proto 'pppoe'
    option ipv6 'auto'

Значение auto создаёт виртуальный интерфейс и запускает клиент, значение 1 включает только согласование и требует ручной настройки секции wan6, значение 0 отключает IPv6.

Если провайдер не поддерживает делегирование префикса, работает автоконфигурация без состояния: маршрутизатор получает собственный адрес из анонсов, но раздавать префиксы внутрь не может. Доступ наружу появляется у маршрутизатора, а не у внутренних устройств.

Проверить, что внешний интерфейс получил всё нужное:

logread | grep -i odhcp6c | tail -20
ifstatus wan6

Вторая команда отдаёт состояние интерфейса в формате JSON с полученным адресом, делегированным префиксом и сроками его действия.

Раздача адресов клиентам через анонсы маршрутизатора

Внутренняя сторона настраивается в секции локального интерфейса, где ключевой параметр задаёт размер выделяемого префикса:

config interface 'lan'
    option proto 'static'
    option ip6addr 'fd12:3456:789a::1/60'
    option ip6assign '60'
    option ip6hint '100'

Параметр ip6assign включает распределение делегированного префикса на интерфейс. Параметр ip6hint задаёт идентификатор подсети внутри префикса, и при получении того же префикса внутренняя сеть получит тот же адрес, а не новый.

За раздачу адресов и анонсов отвечает служба odhcpd, настраиваемая в файле dhcp:

config dhcp 'lan'
    option interface 'lan'
    option ra 'server'
    option dhcpv6 'server'
    option ra_management '1'
    option ra_default '1'
    list ra_flags 'managed-config'

Параметр ra включает анонсы маршрутизатора, dhcpv6 включает сервер, а ra_management определяет, получают ли клиенты адрес через автоконфигурацию или через сервер и как им передаются сведения о DNS.

Режимов два. Без состояния клиент сам формирует адрес из префикса, а сервер выдаёт только дополнительные сведения вроде адресов DNS. С состоянием клиент получает адрес от сервера, что позволяет вести учёт, но добавляет точку отказа.

Для домашней сети режим без состояния предпочтительнее: он проще и не требует журнала выданных адресов. Режим с состоянием оправдан там, где нужен фиксированный адрес устройства и централизованный учёт.

Проверить раздачу с клиента:

ip -6 addr show scope global
ip -6 route show default

Правила сетевого экрана и обязательный трафик ICMPv6

Самая частая ошибка связана с сетевым экраном. Протокол ICMPv6 в шестой версии выполняет работу, которую в четвёртой делал отдельный протокол разрешения адресов, и его блокировка полностью ломает сеть.

Разрешить нужно сообщения об обнаружении маршрутизаторов и поиске соседей, а также эхо-обмен, нужный для диагностики, и сообщения об ошибках доставки.

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    option list icmp_type 'echo-request'
    option list icmp_type 'echo-reply'
    option list icmp_type 'destination-unreachable'
    option list icmp_type 'packet-too-big'
    option list icmp_type 'time-exceeded'
    option list icmp_type 'parameter-problem'
    option list icmp_type 'router-solicitation'
    option list icmp_type 'router-advertisement'
    option list icmp_type 'neighbour-solicitation'
    option list icmp_type 'neighbour-advertisement'
    option family 'ipv6'
    option target 'ACCEPT'

В стандартной поставке OpenWrt такое правило уже есть, и трогать его не нужно. Важно другое: не добавлять сплошной запрет на ICMPv6, который иногда советуют в руководствах по защите.

Правило для входящих соединений к конкретной внутренней службе выглядит привычно, но без трансляции адреса:

config rule
    option name 'Allow-Webserver'
    option src 'wan'
    option dest 'lan'
    option proto 'tcp'
    option dest_port '443'
    option family 'ipv6'
    option target 'ACCEPT'

Обратить внимание стоит на отсутствие параметра dest_ip: без него правило действует для всех устройств внутренней сети, что почти никогда не требуется. Лучше указать конкретный адрес.

Правило для клиента DHCPv6 также должно присутствовать, поскольку ответы сервера приходят на порт 546 по UDP:

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

Перечислим типовые ошибки настройки защиты:

1. Блокировка ICMPv6 целиком, из-за чего перестают работать обнаружение маршрутизатора и поиск соседей, а сеть выглядит полностью неработоспособной;
2. Правило доступа к внутренней службе без указания конкретного адреса, открывающее порт для всех устройств сразу;
3. Отсутствие параметра family в правиле, из-за чего оно применяется не к той версии протокола или не применяется вовсе;
4. Ожидание трансляции адресов там, где её нет, поскольку в IPv6 внутреннее устройство доступно по своему глобальному адресу напрямую;
5. Включённая раздача префикса при отсутствии правила запрета входящих соединений по умолчанию, что открывает все внутренние устройства.

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

Поведение сети при смене префикса и доступность служб по имени

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

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

Полезно проверить, что внутренний сервер не оказался доступен снаружи там, где это не планировалось. Тест выполняют извне домашней сети:

nmap -6 -p 443,22,80 2a00:1450:xxxx::1

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

Диагностика, проверка доступности снаружи и жизнь с двойным стеком

Диагностика IPv6 строится на тех же принципах

Диагностика строится на тех же принципах, что и в четвёртой версии, но с другими инструментами.

Состояние адресов и маршрутов:

ip -6 addr show
ip -6 route show
ip -6 neigh show

Последняя команда показывает таблицу соседей, аналогичную таблице ARP. Состояние failed означает, что устройство не отвечает, и это первый признак проблем в сегменте.

Проверка связности до внешнего узла:

ping -6 -c 4 2001:4860:4860::8888

Проверка разрешения имён отдельно по шестой версии:

resolvectl query example.com
dig AAAA example.com

Отсутствие записи AAAA означает, что ресурс недоступен по IPv6 и обращение пойдёт по четвёртой версии. Это нормальное поведение двойного стека.

Отдельная тонкость касается приватности. Механизм временных адресов периодически меняет последний сегмент, чтобы усложнить отслеживание устройства. Клиентам это полезно, серверу неудобно, и отключается механизм на уровне ядра:

sysctl net.ipv6.conf.all.use_tempaddr

Значение 0 отключает временные адреса, 1 включает их как предпочитаемые, 2 делает основными. Для сервера выбирают 0 или 1, для рабочей станции оставляют 2.

Механизмы инкапсуляции вроде 6in4, 6rd и 6to4 позволяют получить IPv6 там, где провайдер его не даёт, но за трансляцией адресов они обычно не работают, поскольку требуют прямого прохождения протокола 41. Реалистичный путь здесь запросить поддержку IPv6 у провайдера.

Отдельно проверяют, что при смене префикса служба продолжает отвечать. Для этого на маршрутизаторе принудительно разрывают внешнее соединение и ждут нового, после чего повторяют обращение по имени из внешней сети. Если запись обновилась и ответ получен, значит механизм динамического обновления работает. Доступ к внутренней службе по глобальному адресу с мобильного телефона через сотовую сеть самый честный тест: он проверяет делегирование префикса, анонсы и правила сетевого экрана одновременно.