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

Архитектура IPv6-туннелирования: когда IPv4 не пускает

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

Архитектура строится на инкапсуляции. IPv6-пакет становится полезной нагрузкой для IPv4. Внешний заголовок — IPv4 с адресами туннельных узлов. Внутренний — оригинальный IPv6. Тип протокола в IPv4-заголовке — 41 (IPv6 encapsulation). Никакой магии, чистая обёртка.

Туннели бывают разные. Самые популярные: 6in4 (статический туннель), 6to4 (автоматический), Teredo (за NAT), ISATAP (внутри сети). У каждого свой зоопарк проблем. 6in4 требует выделенного IPv4-адреса с обеих сторон. 6to4 работает через anycast, но упирается в ограничения MTU. Teredo — вообще ад, использует UDP и пробивается через NAT, но скорость хромает.

Ограничения протокола: что болит

Первое и главное — MTU. IPv6 требует MTU 1280 байт минимум. IPv4-туннель добавляет 20-40 байт заголовка. Если MTU сети меньше 1500, начинаются фрагментации, потери пакетов, пересборки. Типичная проблема: SSH зависает, веб-страницы грузятся через раз.

Второе — NAT. IPv4 с NAT — зло для туннелей. 6in4 не работает за NAT, нужен публичный IP. Teredo решает проблему, но ценой производительности. UDP-инкапсуляция, дополнительные заголовки, пинг 200+ мс.

Третье — маршрутизация. IPv6-трафик идёт через туннельный endpoint. Если endpoint в другой стране, задержки растут. Нет прямой маршрутизации, как у нативного IPv6. Для критичных приложений — проблема.

Четвёртое — безопасность. Туннель — чёрный ящик. IPv4-сеть не видит внутреннего трафика. Firewall не может фильтровать IPv6-пакеты внутри. Дополнительная нагрузка на CPU — инкапсуляция/деинкапсуляция жрёт ресурсы.

Реальный кейс: настройка 6in4 на Linux

```bash

Поднимаем туннель

ip tunnel add sit1 mode sit remote 203.0.113.1 local 198.51.100.1 ttl 255

ip link set dev sit1 up

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

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

Проверяем

ping6 2001:4860:4860::8888

```

Чисто, прозрачно. Но если remote адрес за NAT — всё сломается. Выход — Teredo:

```bash

Установка Miredo

apt-get install miredo

Конфиг /etc/miredo/miredo.conf

InterfaceName = teredo

ServerAddress = teredo.iks-jena.de

Запуск

systemctl start miredo

```

Teredo даёт IPv6-адрес, но пинг до Google — 250 мс против 30 мс у нативного. Для веб-сёрфинга сойдёт, для игр — нет.

Провайдерские решения: DS-Lite и MAP-E

Провайдеры не хотят менять оборудование. Они внедряют DS-Lite (Dual-Stack Lite) и MAP-E (Mapping of Address and Port). DS-Lite — это CGNAT + IPv4-туннель к провайдерскому AFTR. Клиент получает нативное IPv6, а IPv4 уходит в туннель. Минус — IPv4-трафик идёт через провайдерский NAT, порты ограничены.

MAP-E — хитрее. Он маппит IPv4-адреса и порты на IPv6-префиксы. Клиент получает публичный IPv4 через IPv6-транспорт. Без NAT, без туннелей. Но требует поддержки на CPE и провайдерском оборудовании. В России MAP-E почти не используют, DS-Lite популярнее.

Когда туннелирование — зло

IPv6-туннели не для всего. P2P-трафик через Teredo — песня. BitTorrent падает, DHT не работает, UDP-трафик теряется. Для торрентов нужен нативный IPv6 или 6in4 с публичным IP.

VoIP и видеозвонки — тоже проблема. Jitter растёт, пакеты теряются. WebRTC на Teredo — грабли. Google Meet может работать, но с перебоями.

Для обычного веб-сёрфинга — норм. YouTube, GitHub, Cloudflare — все поддерживают IPv6. Но если сайт сидит на IPv4-only, туннель не поможет. Нужен NAT64/DNS64.

Альтернативы: NAT64 и прокси

NAT64 — мост между IPv6 и IPv4. Клиент отправляет IPv6-пакет, NAT64-шлюз конвертирует его в IPv4. DNS64 подменяет A-записи на AAAA. Работает прозрачно, но шлюз — единая точка отказа.

Прокси — другой путь. IPv6-клиент идёт на прокси-сервер, тот делает запрос к IPv4-ресурсу. Пример: lexic.ml — IPv6 прокси с 2015 года. Оборачивает IPv4-трафик в IPv6, даёт доступ к сайтам без нативного IPv6. Работает на уровне HTTP/HTTPS, не требует туннелей на клиенте.

Сравним:

| Метод | Скорость | NAT | MTU | Сложность |

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

| 6in4 | Высокая | Не работает | Проблемы | Средняя |

| Teredo | Низкая | Работает | Проблемы | Низкая |

| DS-Lite | Средняя | CGNAT | Нормально | Высокая |

| NAT64 | Средняя | Работает | Нормально | Высокая |

| Прокси | Зависит | Работает | Нормально | Низкая |

Практические грабли: что ломается чаще всего

1. **MTU mismatch**. Клиент шлёт пакет 1500 байт, туннель добавляет 40, сеть не пропускает. Решение — `ip link set dev sit1 mtu 1480`. Или настройка MSS clamping.

2. **Firewall блокирует протокол 41**. Некоторые провайдеры режут IPIP-туннели. Приходится использовать UDP-инкапсуляцию (Teredo, OpenVPN).

3. **IPv6-маршруты не обновляются**. Динамические IP — проблема. Нужен DDNS для туннеля.

4. **Симметричный NAT**. Teredo не пробивает. Только релейный сервер, который добавляет задержку.

Будущее: когда туннели станут не нужны

IPv6-пенетрация растёт. Google отчитывается о 40% трафика через IPv6. Провайдеры в Европе и США переходят на нативный Dual-Stack. В России — медленнее, но тенденция есть.

Туннели — временная мера. Для энтузиастов — 6in4 через Hurricane Electric. Для обычных пользователей — прокси или DS-Lite. Но пока IPv4 живёт, туннели остаются.

Главное — понимать ограничения. Не пихать туннель туда, где нужна стабильность. Для экспериментов — норм. Для продакшена — только если нет альтернатив.

И помните: IPv6-туннелирование не лечит IPv4-проблемы. Оно просто переносит их в другую плоскость.