Как работает IPv6-туннелирование через IPv4: архитектура и ограничения

Что за зверь и зачем он нужен

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

Проблема в том, что в 2024 году до сих пор ~30% мирового трафика идет по IPv4. Провайдеры не спешат менять оборудование, а адресов уже нет. Туннели — временный костыль, но без него никуда. Особенно когда нужно соединить два IPv6-островка посреди IPv4-океана.

Архитектура: как это работает под капотом

Берем IPv6-пакет. Заворачиваем его в IPv4-заголовок. В поле Protocol ставим 41 (это magic number для IPv6-инкапсуляции). Отправляем через IPv4-сеть. На выходе распаковываем.

```

[IPv4 заголовок | Protocol=41 | IPv6 пакет | Данные]

```

Два узла туннеля — точки входа и выхода. Они знают друг друга по IPv4-адресам. Внутри туннеля — своя IPv6-подсеть, обычно /64 или /127.

Ключевой момент: MTU. IPv6 требует минимум 1280 байт. Добавляем 20 байт IPv4-заголовка — получаем 1300. Если промежуточный роутер режет пакеты — всё ломается. Path MTU discovery работает хреново, особенно с NAT.

Типы туннелей: зоопарк решений

6in4 (протокол 41)

Старый-добрый. Требует публичного IPv4 с обеих сторон. Провайдеры часто блокируют протокол 41 — считают угрозой. У нас на lexic.ml именно такой вариант для dedicated-серверов.

Плюсы: минимальные накладные расходы, полный контроль.

Минусы: нужен белый IP, проблемы с NAT.

Teredo

Корявый, но живучий. Работает через UDP, пробивает NAT. Используется в Windows по умолчанию. Скорость — никакая, задержки — адские.

6rd (IPv6 Rapid Deployment)

Провайдерский вариант. Автоматически нарезает IPv6-адреса из своего блока. Работает на CPE-роутерах. Никакой гибкости, зато без ручной настройки.

GRE (Generic Routing Encapsulation)

Туннель общего назначения. Можно гонять не только IPv6, но и любой L3-протокол. Cisco-админы его обожают. Накладные расходы — 24 байта на пакет.

Сравнение методов туннелирования

Метод	Накладные расходы	NAT Traversal	Скорость	Сложность
6in4	20 байт	Нет	Высокая	Средняя
Teredo	~40 байт	Да	Низкая	Низкая
6rd	20 байт	Нет	Высокая	Низкая
GRE	24 байта	Нет	Высокая	Высокая

Практический пример: поднимаем 6in4 на Linux

```

На стороне клиента

ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 192.0.2.1

ip link set tun6in4 up

ip addr add 2001:db8:1::2/64 dev tun6in4

ip route add ::/0 via 2001:db8:1::1

На стороне сервера (туннель-брокера)

ip tunnel add tun6in4 mode sit remote 192.0.2.1 local 203.0.113.1

ip link set tun6in4 up

ip addr add 2001:db8:1::1/64 dev tun6in4

ip route add 2001:db8:2::/48 via 2001:db8:1::2

```

Проверка через curl:

```

curl -6 --interface tun6in4 https://ipv6.google.com

```

Если не работает — смотри tcpdump. 90% проблем — MTU или блокировка протокола 41 провайдером.

Ограничения: грабли, на которые наступают все

MTU — проклятие туннелей

IPv4-фрагментация убивает производительность. IPv6 не фрагментируется на промежуточных узлах — только на конечных. Когда пакет с MTU 1500 пролезает в туннель с накладными расходами 20 байт — он не влезает. Роутер шлет ICMPv6 Packet Too Big. Не все хосты это понимают.

Решение: принудительно ставить MTU на туннельном интерфейсе 1280-1400 байт. Или использовать MSS clamping.

NAT — вечная боль

Протокол 41 не дружит с NAT. Teredo — да, но ценой производительности. Если у клиента CGNAT — 6in4 не взлетит. Только Teredo или прокси-решения.

Блокировки провайдерами

Многие операторы считают туннели угрозой. Протокол 41 режут на уровне AS. Пример: в 2022 году Роскомнадзор блокировал 6in4-трафик вместе с VPN. Выход — использовать UDP-инкапсуляцию (Teredo, OpenVPN в туннеле).

Реальный кейс: игровой сервер через туннель

Была задача: подключить Minecraft-сервер к IPv6-сети. Провайдер давал только IPv4 за NAT. Подняли 6in4 до туннель-брокера. Получили /48. Раздали /64 каждому игроку.

Проблемы:

- Пинг вырос на 5-10 мс (дополнительная маршрутизация).

- Иногда пакеты терялись на перегруженных брокерах.

- Пришлось править firewall — IPv6-трафик шел через туннель, а не напрямую.

Результат: игроки с IPv6 заходили без лагов. Количество одновременных подключений выросло на 40%.

Альтернативы: когда туннели не нужны

NAT64/DNS64

Позволяет IPv6-клиентам ходить на IPv4-серверы. Не требует туннелей. Ставится на пограничном роутере. Минус — не все приложения дружат с NAT64.

Прокси-серверы с двойным стеком

Nginx или HAProxy слушают на обоих протоколах. Клиент приходит по IPv6, сервер отвечает по IPv4. Прозрачно для пользователя.

BGP и транзит IPv6

Если есть свой AS — просто покупаешь IPv6-транзит у апстрима. Никаких туннелей. Но это дорого и сложно.

Итоги

IPv6-туннелирование — вынужденная мера. Без него не обойтись, пока провайдеры не перейдут на IPv6. 6in4 — золотой стандарт для dedicated-серверов. Teredo — для домашних сетей за NAT. GRE — для корпоративных сетей с Cisco.

Запомните: туннели не решают проблему исчерпания адресов. Они только откладывают неизбежное. Рано или поздно придется переходить на нативный IPv6. Но пока этот день не настал — туннели будут жить.

И да, если хотите стабильный 6in4 — смотрите в сторону dedicated-провайдеров с поддержкой протокола 41. Дешевые VPS часто режут этот трафик.