IPv6 через туннель OpenVPN: проход по домашнему маршрутизатору

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

Начните с клиента

Посмотрите на клиента, прежде чем трогать сервер. ip -6 addr должен показывать адрес туннеля из пула, а ip -6 route — протолкнутый префикс, указывающий на туннельное устройство. Когда адрес есть, а маршрута нет, проталкивание отсутствует или клиент его проигнорировал. Когда нет ни того, ни другого, сервер вообще ничего не назначил.

Затем проверьте, что клиент думает о внешнем мире. Маршрут по умолчанию через туннель требует всего трафика IPv6, тогда как маршрут для 2000::/3 требует только глобальный unicast. Оба могут быть верными, и они отвечают на разные вопросы об утечке.

Клиент без маршрута по умолчанию IPv6 проваливает каждый публичный тест, хотя сам туннель полностью здоров. Это пробел в политике, а не сломанный туннель.

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

Сервер может выделять адреса только из префикса, который он действительно контролирует. Если провайдер делегирует /56, оставьте один /64 для туннеля, а остальное — для LAN. Там, где провайдер отдаёт на WAN только один /64 и больше ничего не маршрутизирует, оставьте префикс LAN в покое и дайте туннелю уникальный локальный диапазон, приняв, что у клиентов не будет глобального выхода.

Пул и проталкивание идут вместе. server-ipv6 2001:db8:80:10::/64 назначает адреса, а push "route-ipv6 2000::/3" говорит клиентам, что отправлять в туннель. Проталкивание 2000::/3 покрывает глобальный unicast и оставляет диапазоны link-local и multicast за пределами туннеля.

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

Включите пересылку для второго семейства

Пересылка IPv4 не означает пересылку IPv6. Задайте net.ipv6.conf.all.forwarding=1 и повторите всё, что уже разрешает политика FORWARD для IPv4. На маршрутизаторе, чья цепочка FORWARD по умолчанию отбрасывает пакеты, отсутствующий набор правил выглядит точно как мёртвый туннель.

Рукопожатие проходит, клиент получает адрес, а обратно ничего не приходит. Добавьте правила для обоих направлений и для плеча WAN, потому что туннель, который доходит до LAN, но не до интернета, проваливает третий тест. После неудачной попытки посмотрите на счётчики цепочки, потому что правило, которое ни разу не совпало, — это другая проблема, чем то, которое совпало и отбросило.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Один побочный эффект ловит тех, кто в итоге винит туннель. Включение пересылки заставляет ядро пропускать настройку адреса через Router Advertisement, если не сказать иначе, и выученный так маршрут по умолчанию исчезает вместе с ней. Либо закрепите явный маршрут по умолчанию на интерфейсе WAN, либо намеренно задайте там accept_ra равным 2. После любого изменения убедитесь, что у маршрутизатора по-прежнему есть рабочий путь IPv6 наружу, прежде чем снова тестировать клиентов.

Отвечайте на обнаружение соседей, когда верхняя сторона не маршрутизирует

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

OpenVPN предоставляет назначенный адрес обработчику client-connect, поэтому записи могут следовать за настоящим пулом, а не за списком, который ведут вручную. Обработчик добавляет ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, а соответствующий обработчик client-disconnect удаляет его. Без удаления таблица прокси устаревает, и более поздний клиент может унаследовать запись для адреса, который он никогда не получал. Подтвердите состояние с помощью ip -6 neigh show proxy.

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

Пройдите путь наружу, прыжок за прыжком

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

Следите за MTU туннеля, потому что маршрутизаторы IPv6 на пути не будут фрагментировать за вас. Слишком большой MTU проявляется как ошибка packet-too-big и зависший TLS, а не как чистый сбой. Задайте его явно и проверьте с нагрузкой, близкой к пределу.