Туннелирование IPv6-in-IPv4 с помощью 6rd и ISATAP: практические настройки и подводные камни

Туннелирование IPv6-in-IPv4 с помощью 6rd и ISATAP: практические настройки и подводные камни

Зачем это нужно

IPv4-адреса кончились. Провайдеры выдают серые адреса, а за NAT IPv6 не работает. Туннели 6in4 (например, от Hurricane Electric) требуют белого IP. Не у всех он есть.

6rd и ISATAP решают проблему иначе. Они работают поверх IPv4-инфраструктуры провайдера, не требуя белых адресов. Провайдер разворачивает шлюз — и все абоненты получают IPv6 без покупки дополнительных IP.

Разница между ними принципиальная. 6rd — это автоматический 6in4, где префикс вычисляется из IPv4-адреса. ISATAP — более старый механизм, который эмулирует IPv6-линк поверх IPv4. Первый живёт и сейчас, второй — мёртв, но его всё ещё можно встретить в корпоративных сетях.

Как работает 6rd

Провайдер выделяет IPv6-префикс (например, 2001:db8:100::/40) и IPv4-префикс (скажем, 10.0.0.0/8). Абонент получает IPv4-адрес 10.1.2.3. Из него вычисляется IPv6-адрес: 2001:db8:100:101:203::. Всё, никакого DHCPv6-PD не нужно.

Абонент настраивает туннель 6rd на свой шлюз (адрес которого прописан в конфигурации) и получает маршрут по умолчанию. Весь трафик уходит в туннель, шлюз его декапсулирует и отправляет в IPv6-интернет.

Главное преимущество — масштабирование. Провайдеру не нужно поднимать DHCPv6, не нужно хранить состояние туннелей. Всё считается на лету. Для абонента это тоже плюс: настройка сводится к трём параметрам.

Настройка 6rd на Linux

Берём Debian 12, ядро 6.1. Провайдер дал: IPv4-префикс 10.0.0.0/8, IPv6-префикс 2001:db8:100::/40, шлюз 10.0.0.1. Наш адрес — 10.1.2.3.

```bash

ip tunnel add 6rd mode sit local 10.1.2.3 ttl 64

ip tunnel 6rd dev 6rd 6rd-prefix 2001:db8:100::/40

ip tunnel 6rd dev 6rd 6rd-relay_prefix 10.0.0.0/8

ip addr add 2001:db8:100:101:203::/64 dev 6rd

ip link set 6rd up

ip route add ::/0 dev 6rd

```

Разбор по шагам. Создаём туннель SIT (Simple Internet Transition) с локальным адресом. Затем говорим ядру, как вычислять IPv6-адрес из IPv4: префикс 2001:db8:100::/40, а остальные биты — из IPv4. Параметр `6rd-relay_prefix` указывает, какие IPv4-адреса считаются внутренними (то есть "наши"). Всё, что не попадает в этот диапазон, — удалённые хосты, пакеты к ним идут через шлюз.

Проверяем:

```bash

ping6 -c 3 2001:db8:100::1

```

Если шлюз отвечает — туннель работает. Теперь можно добавить адрес в конфиг, чтобы настройка пережила перезагрузку. В `/etc/network/interfaces`:

```

auto 6rd

iface 6rd inet6 static

address 2001:db8:100:101:203::/64

gateway ::/0

pre-up ip tunnel add 6rd mode sit local 10.1.2.3 ttl 64

pre-up ip tunnel 6rd dev 6rd 6rd-prefix 2001:db8:100::/40

pre-up ip tunnel 6rd dev 6rd 6rd-relay_prefix 10.0.0.0/8

pre-down ip tunnel del 6rd

```

Подводные камни 6rd

MTU. Туннель SIT добавляет 20 байт заголовка. Если MTU на физическом интерфейсе 1500, то на туннеле — 1480. Многие приложения не любят фрагментацию. Решение — настроить MTU 1480 на туннеле и включить clamping MSS на файрволе:

```bash

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

```

Без этого YouTube будет тормозить, а крупные письма с вложениями — падать.

Второй момент — вычисление адреса. Если у провайдера IPv4-префикс не кратен 8 битам, адрес получается кривой. Например, префикс 10.0.0.0/7 (это 10.0.0.0 и 11.0.0.0). Тогда IPv6-адрес абонента с IPv4 10.1.2.3 будет 2001:db8:100:101:203::? Нет. Бит из 7-го разряда IPv4 попадёт в 40-й бит IPv6-адреса, и получится 2001:db8:100:101:203::, но сдвиг будет на 1 бит. Всё сломается.

Провайдеры это знают и используют префиксы, кратные 8. Но если вы настраиваете 6rd сами — проверяйте маску.

ISATAP: старая школа

ISATAP появился раньше 6rd. Идея — создать IPv6-линк поверх IPv4. Каждый IPv4-адрес превращается в IPv6-адрес вида `2001:db8::5efe:10.1.2.3`. Формат фиксированный: 32 бита `5efe` (это 0x5EFE) и IPv4-адрес.

Работает это так: хост отправляет ICMPv6 Router Solicitation на адрес ISATAP-шлюза (обычно 10.0.0.1). Шлюз отвечает Router Advertisement, и хост настраивает маршрут. Всё как в обычной IPv6-сети, только линк виртуальный.

Настройка ISATAP на Windows

Windows поддерживает ISATAP из коробки. Включить:

```powershell

netsh interface ipv6 isatap set router 10.0.0.1

netsh interface ipv6 isatap set state enabled

```

Проверить:

```

netsh interface ipv6 show isatap

```

Если всё правильно — появится интерфейс ISATAP с адресом `2001:db8::5efe:10.1.2.3`. Но есть нюанс: Windows по умолчанию использует ISATAP только для внутрикорпоративного трафика. Для доступа в интернет нужно добавить маршрут:

```

netsh interface ipv6 add route ::/0 interface=ISATAP

```

Настройка ISATAP на Linux

На Linux всё сложнее. Модуль `ipv6` в ядре поддерживает ISATAP, но настройка не такая простая. Нужен демон `isatapd`:

```bash

apt install isatapd

```

Конфиг `/etc/default/isatapd`:

```

ISATAP_ROUTER=10.0.0.1

ISATAP_TUNNEL="sit0"

```

Запуск:

```bash

systemctl start isatapd

```

Но `isatapd` — древний софт, последний релиз — 2014 год. На современном ядре 6.x он может работать некорректно. Лучше настроить вручную:

```bash

ip tunnel add isatap mode sit local 10.1.2.3 ttl 64

ip link set isatap up

ip addr add 2001:db8::5efe:10.1.2.3/64 dev isatap

ip route add ::/0 dev isatap

```

Обратите внимание: адрес ISATAP всегда `/64`, а не `/128`. Это важно, иначе маршрутизация не заработает.

Почему ISATAP умирает

ISATAP имеет фундаментальный недостаток: он создаёт псевдо-линк, на котором нет реального соседства. Neighbor Discovery работает через IPv4-адреса, но это создаёт проблемы с безопасностью. Любой хост в IPv4-сети может подделать Router Advertisement и перенаправить трафик на себя.

Плюс — NAT. ISATAP не работает за NAT, потому что адрес `5efe:10.1.2.3` привязан к приватному IPv4. Шлюз не сможет достучаться до хоста за NAT. А 6rd решает эту проблему: шлюз не хранит состояние, пакеты идут в туннель и декапсулируются на лету.

Сравнение 6rd и ISATAP

| Параметр | 6rd | ISATAP |

|----------|-----|--------|

| Год появления | 2007 | 2002 |

| RFC | RFC 5969 | RFC 5214 |

| Работа за NAT | Да | Нет |

| Автоконфигурация | Из IPv4-адреса | Через ICMPv6 |

| Поддержка в ядрах | Linux, BSD, Windows | Linux (слабая), Windows |

| Безопасность | Выше | Ниже |

| MTU | 1480 | 1480 |

Практический пример: провайдер с 6rd

Пример: российский провайдер "Дом.ру" использует 6rd для раздачи IPv6. Параметры: IPv6-префикс `2a02:6b8::/32`, IPv4-префикс `91.122.0.0/16`, шлюз `91.122.0.1`. Абонент получает IPv4 `91.122.10.20`.

Вычисляем IPv6-адрес:

```python

import ipaddress

ipv4 = ipaddress.IPv4Address('91.122.10.20')

ipv6_prefix = ipaddress.IPv6Address('2a02:6b8::')

ipv4_bytes = ipv4.packed

Префикс /32, IPv4-префикс /16, значит IPv4-адрес занимает 32 бита

ipv6_addr = int(ipv6_prefix) | (int(ipv4) << 32)

print(ipaddress.IPv6Address(ipv6_addr))

2a02:6b8:5b7a:a14::

```

Настройка на роутере OpenWrt:

```

config interface 'wan6'

option proto '6rd'

option peeraddr '91.122.0.1'

option ip6prefix '2a02:6b8::/32'

option ip4prefix '91.122.0.0/16'

```

Всё. OpenWrt сам вычислит адрес и настроит туннель.

Кейс: корпоративная сеть с ISATAP

Фирма с 500 сотрудниками, офисы в трёх зданиях. IPv4-сеть 10.0.0.0/8, шлюз ISATAP на 10.0.0.1. Внедрили ISATAP для доступа к IPv6-ресурсам.

Проблема: через неделю половина сотрудников потеряла доступ к внутренним ресурсам. Оказалось, DHCP-сервер выдавал адреса из разных подсетей, и ISATAP-шлюз не знал, как маршрутизировать между ними. Хост с адресом 10.0.1.5 не мог достучаться до хоста 10.0.2.5, потому что оба считали, что находятся в одном IPv6-линке.

Решение: на шлюзе настроили маршруты для каждой подсети:

```bash

ip route add 2001:db8::5efe:10.0.0.0/120 dev isatap

ip route add 2001:db8::5efe:10.0.1.0/120 dev isatap

ip route add 2001:db8::5efe:10.0.2.0/120 dev isatap

```

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

Кейс: 6rd и фрагментация

Провайдер раздал 6rd, но сайты открываются через раз. Смотрим на tcpdump:

```bash

tcpdump -i 6rd -n icmp6

```

Видим: `ICMP6, echo request, length 1480`. Ответа нет. Проблема — MTU. На физическом интерфейсе 1500, на туннеле 1480. Пакет с MTU 1480 фрагментируется, но ICMPv6 не поддерживает фрагментацию в туннелях. Решение — уменьшить MTU до 1472:

```bash

ip link set 6rd mtu 1472

```

И проверить:

```bash

ping6 -c 3 -s 1400 2001:db8::1

```

Кейс: 6rd и Windows

Windows 10 поддерживает 6rd, но настройка через GUI отсутствует. Нужен PowerShell:

```powershell

netsh interface ipv6 add v6v4tunnel 6rd 91.122.10.20 91.122.0.1

netsh interface ipv6 add prefix 2a02:6b8::/32 91.122.0.0/16

```

После этого нужно перезагрузить сеть:

```powershell

netsh interface ipv6 reset

```

Если не работает — проверьте, не блокирует ли файрвол протокол 41 (IPv6-in-IPv4). Windows Defender по умолчанию блокирует входящие туннели. Добавьте правило:

```powershell

New-NetFirewallRule -DisplayName "6rd" -Direction Inbound -Protocol 41 -Action Allow

```

Когда использовать 6rd, а когда ISATAP

6rd — для провайдеров и крупных сетей. Он масштабируется, работает за NAT, не требует состояния на шлюзе. ISATAP — для маленьких корпоративных сетей, где нет возможности настроить 6rd, но нужно дать доступ к IPv6. Но помните: ISATAP не работает за NAT и менее безопасен.

Если у вас выбор — берите 6rd. ISATAP оставьте для исторических экскурсов. На практике 6rd работает стабильнее и проще в обслуживании.