IPv6 через VPN: делегированный префикс — это не пул адресов
Одному клиенту нужен адрес, маршрутизатору за ним нужна сеть. Сначала задайте вопрос о роли, затем шаг адресации, затем проверку обратного маршрута.
В один и тот же день приходят две заявки: ноутбуку нужен IPv6 через туннель, а небольшая площадка хочет IPv6 для устройств за своим маршрутизатором. Обоим отвечают адресом, и второй затем неделю тратит на неудачи. Роли различаются, как и механизмы, конфигурация и проверка, доказывающая, что это работает. Это руководство держит их порознь.
Шаг первый: решите, какую роль вы обслуживаете
Одиночному хосту нужен один адрес на его туннельном интерфейсе, маршрут на дальнюю сторону и ничего ниже, что пришлось бы нумеровать. Маршрутизатору за туннелем нужна целая сеть, которую он может раздавать, плюс маршрут на дальней стороне, возвращающий эти адреса к нему. То, что стоит за туннелем, определяет каждое следующее решение.
Ответьте на этот вопрос, прежде чем открывать любую конфигурацию. Всё после этого шага зависит от того, какой ответ вы дали.
Шаг второй: назначение адресов для одиночного хоста
Назначьте адрес туннеля, подтвердите длину префикса, которую ожидает продукт, и проверьте, устанавливает ли клиент маршрут для удалённого диапазона, а не отправляет его на локальный шлюз по умолчанию. /128 на туннельном интерфейсе нормален для соединения точка-точка, тогда как /64 там претендует на сеть, которую никто не делегировал. Два вывода решают вопрос: таблица адресов и таблица маршрутов, прочитанные на обоих концах. Читайте их вместе, потому что маршрут, указывающий на неправильный интерфейс, — самая частая ошибка на этом шаге.
Проверьте по таблицам адресов и маршрутов на обоих концах, затем отправьте один запрос. Если запрос уходит правильно и ничего не возвращается, неисправность в маршруте дальней стороны, а не в адресе клиента.
Шаг третий: делегирование для маршрутизатора за туннелем
Делегирование префикса — отдельный механизм от назначения адресов, со своим запросом и своей арендой. Делегирующая сторона должна быть настроена выдавать префикс, достаточно большой для нижестоящей сети, а запрашивающий маршрутизатор должен нумеровать свой внутренний интерфейс из этого префикса.
Не предполагайте, что пул, обслуживающий мобильных клиентов, умеет делегировать. Многие продукты VPN назначают отдельные адреса и вовсе не имеют роли делегирования, а префикс провайдера, приходящий на ваш край, не передаётся автоматически партнёру. Запишите, какую роль обслуживает каждый пул, потому что оба настраиваются в разных местах.
Шаг четвёртый: сделайте обратный маршрут явным
Обе стороны должны договориться, какой партнёр несёт какой префикс. На дальней стороне добавьте маршрут для делегированной сети, указывающий на туннель, и подтвердите, что никакой пересекающийся диапазон уже не претендует на него.
Действительный префикс без обратного маршрута даёт аккуратный план адресации и никакой связности. Маршрут без правила доступа раскрывает больше площадки, чем задумано, поэтому объедините оба изменения в одном окне и держите наполовину применённое состояние подальше от пользователей.
Шаг пятый: проверьте из-за маршрутизатора
Выполняйте проверки по порядку: адрес туннельного интерфейса на клиенте, делегированный префикс на внутреннем интерфейсе, маршрут дальней стороны к этому префиксу и наконец запрос с устройства за маршрутизатором. Используйте пункт назначения, который вы контролируете, чтобы тихая блокировка отличалась от отсутствующего маршрута. Какой бы шаг вас ни удивил, исправлять нужно именно его, прежде чем двигаться дальше.
Выполните последнюю проверку дважды: один раз с самого маршрутизатора и один раз с устройства за ним. Маршрутизатор, который достигает пункта назначения, тогда как его клиенты не могут, — это проблема делегирования или пересылки, а не проблема выше по потоку.
Откат
Сохраните предыдущую конфигурацию адресации до изменения и отметьте, какой из двух механизмов вы изменили. Удаление делегированного префикса без удаления маршрута оставляет чёрную дыру, а удаление маршрута без префикса оставляет адреса, до которых ничто не дотянется. Отметьте оба изменения отдельно, потому что отмена одного при сохранении другого делает площадку недоступной только в одном направлении.
Если продукт, как выяснилось, не поддерживает нужную вам роль, остановитесь и измените проект, а не растягивайте поле клиента, чтобы уместить диапазон, для которого оно никогда не предназначалось. Обращение в поддержку, отвеченное не тем механизмом, стоит дороже, чем обошлось бы изменение проекта.