Версия 6 протокола IP изначально разрабатывалась с расчётом на множественные подключения к Интернету и множественные IP-адреса у одного хоста. Что может быть полезным в месте, где отсутствует «хороший» доступ к Интернету по IPv6. Увы, всё ещё возможно вести бизнес предоставления доступа, не предоставляя в меню IPv6. Это вынуждает админов на местах пользоваться различными суррогатами. Представьте, например, что первый суррогат надёжен, но является медленным, а второй быстр, но особого доверия к нему нет. Разумно «на всякий случай» держать включенными оба. Но если два диапазона IPv6 маршрутизованы через одну и ту же машину-шлюз, то как не дать ей запутаться, каким пакетам куда идти? Обычные правила маршрутизации, основанные на IP-адресах получателя, тут не годятся.

Что решается

Данная статья описывает решение проблемы маршрутизации IPv6 в случае, когда локальная сеть наделяется двумя источниками IPv6, работающими через один маршрутизатор. Конкретно, чтобы пакет IPv6 из локальной сети уходил в Интернет через тот интерфейс, к которому приписан его исходящий адрес.

Что не решается

В данной статье не рассматривается, как прикладные программы выбирают, каким подключением к Интернету им пользоваться. В частности, как выбирать между двумя глобальными «своими» адресами IPv6 (или слать по IPv4).

Статья не делает акцент на вопросы подключения IPv6, полагая их решение доступным самостоятельным усилиям администратора.

Описание условий

В приводимом ниже примере в распоряжении администратора локальной сети имеются два блока (глобального) IPv6-пространства, и оба реализованы через 6in4 (инкапсуляция v6 в пакетах IPv4). Первый — 6to4, отображающий диапазон IPv6-адресов 2002::/16 на Интернет v4. Если провайдер выделяет вам белый IP-адрес, имеет маршрут на anycast-адрес 192.88.99.1 и в целом не слишком крив, то FreeBSD сама поднимет его (под именем stf0) при указании в /etc/rc.conf:

ipv6_enable="YES"
stf_interface_ipv4addr="▀▀.▄▄.◥◥.◣◣"  # Здесь должен быть записан белый IP
ipv6_defaultrouter="2002:c058:6301::"

Этот способ с 2015 года считается устаревшим, однако его преимуществом является привязка диапазона IPv6 к публичному адресу IPv4 (который, в моём случае, постоянен). Даже если в сетевой инфраструктуре, обеспечивающей 6to4, что-то поменяется, то на адресах, назначенных устройствам в локальной сети, это не отразится. Важнейшим недостатком 6to4 в современных условиях является низкая пропускная способность. Также, мой 6to4 гоняет IPv6 из локалки в европейской России через шлюз в Амстердаме, что добавляет около 40 мс задержки.

Второй источник моего IPv6 в диапазоне 2001:470::/32 расположен поближе и пропускная способность у него побольше, поскольку делает его компания Hurricane Electric (под брэндом tunnelbroker.net). Это — туннель, интерфейс которого ядро называет gif0 и поднимаю я его особым системным скриптом, изготовление и установка которого выходит за рамки статьи; потребные для включения tunnelbroker команды перечислены здесь. Его недостатком являются блок IPv6 без особого запаса по размеру (/64), а также зависимость от коммерческой фирмы, с которой не имеешь договора.

Описание pf(4)

Файл /etc/pf.conf содержит текст программы для пакетного фильтра pf(4), входящего в поставку BSD-систем. Текст состоит из определений (макросов) и последовательности правил вида «для такого-то пакета оттуда-то и туда-то делай то-то». При указании pf_enable="YES" в /etc/rc.conf подача правил на выполнение включается автоматически во время инициализации FreeBSD. Вручную можно включить (новый) свод правил командой

pfctl -e -f /etc/pf.conf

Если pf уже включен, то указывать ключ «-e» не обязательно.

Решение

Предполагаем, что наш /etc/pf.conf содержит следующие определения:

myv6_6to4 = "2002:▀▀▄▄:◥◥◣◣::/48"
myv6_he   = "2001:470:◆◆:●●●::/64"
v6_noglobal = "fc00::/6"

Это позволяет решить поставленную задачу двумя правилами:

# routing related to tunnels
pass quick from $myv6_he to {$myv6_6to4, $myv6_he, $v6_noglobal}
pass out route-to gif0 from $myv6_he to any

Основная работа делается правилом «pass out route-to ⋯», предписывающим исходящим (out) пакетам идти (pass) в интерфейс gif0 невзирая на таблицу маршрутов (где, как мы вспоминаем, присутствует default на stf0).

Правило «pass quick ⋯» досрочно (quick) прекращает проверку фильтром пакетов, идущих из диапазона на адреса в том же диапазоне ($myv6_he), либо в другом принадлежащем сети диапазоне ($myv6_6to4), а также на разные адреса ($v6_noglobal), не являющиеся глобальными. Этот трафик не надо принудительно направлять в gif0.

Важно: в pf.conf правила pass должны идти после определений и правил переназначения адреса (rdr, nat).

Замечания

Если вместо «pass out route-to ⋯» поставить «pass in route-to ⋯», то правило будет обслуживать трафик, проходящий через шлюз, но не сработает для пакетов, создаваемых на машине FreeBSD локально.

Поскольку канала для IPv6 только два, маршрутизацию 6to4 мы смогли сделать «исключением альтернатив», на основании стандартной таблицы маршрутов ядра. Что, если канала станет три и понадобится маршрутизировать 6to4 явно? В принципе, можно было бы добавить аналогичные правила для stf0:

pass quick from $myv6_6to4 to {$myv6_6to4, $myv6_he, $v6_noglobal}
pass out route-to stf0 from $myv6_6to4 to any

Препятствие заключается в том, что протокол 6to4 устроен сложнее, чем «просто» туннель gif0 (в котором не имеется выбора, через которую точку послать пакет). А мы предположили, что маршрут по умолчанию ведёт не в stf0. Хотя pf(4) понимает непосредственного получателя пакета с опцией «route-to (interface, gateway)», в 6to4 этот gateway надо включать лишь если адрес назначения не лежит в диапазоне 2002::/16. Можно попытаться заменить один «pass out route-to ⋯» двухходовкой

pass out quick route-to stf0 from $myv6_6to4 to 2002::/16
pass out route-to (stf0, 2002:c058:6301::) from $myv6_6to4 to any

но лично мне как-то пробовать уже не интересно…