IPv6-туннелирование через IPv4: архитектура, ограничения и когда это оправдано

Архитектура: как IPv4 тащит на себе IPv6

IPv6-туннель — это когда пакет IPv6 целиком заворачивается в IPv4-пакет. Без изменений, без адаптации. Просто берётся датаграмма с адресами 2001:db8::1 → 2001:db8::2, на неё навешивается IPv4-заголовок с адресами 192.0.2.1 → 192.0.2.2. И пошла.

На физическом уровне всё выглядит так:

```

[IPv4-заголовок | IPv6-заголовок | TCP/UDP | данные]

```

Протокол в IPv4-заголовке выставляется в 41 (IPv6 encapsulation). Маршрутизаторы, которые не понимают IPv6, видят обычный IPv4-трафик. Они его транзитом гоняют, как привыкли. Только на выходе кто-то должен распаковать туннель и отдать чистый IPv6 получателю.

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

**6in4** — статический туннель «точка-точка». Провайдер даёт тебе IPv4-адрес своего сервера, ты настраиваешь интерфейс sit0 (на Linux) или аналогичный. Протокол прописан в RFC 4213. Работает десятилетиями, но требует ручного конфига и публичного IPv4-адреса с обеих сторон.

**6to4** — автоматический туннель с префиксом 2002::/16. Твой IPv4-адрес превращается в часть IPv6-префикса. Берёшь 192.0.2.1, конвертируешь в hex — получается c000:0201. Префикс: 2002:c000:0201::/48. Красиво, но на практике — хреново. Релейные серверы перегружены, маршрутизация непредсказуема, NAT ломает всё.

**Teredo** — туннель через NAT. Использует UDP, потому что UDP легче пробивается через домашние роутеры. Microsoft придумала в 2006-м. Работает через серверы teredo.ipv6.microsoft.com и другие. Скорость — никакая. Задержка — +50-100 мс. Сегодня почти мёртв.

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

Первое и самое жирное — MTU. Когда ты заворачиваешь IPv6-пакет в IPv4, размер вырастает на 20 байт (без опций). Если исходный IPv6-пакет был 1280 байт (минимальный MTU для IPv6), то после инкапсуляции он становится 1300. А стандартный Ethernet MTU — 1500. Казалось бы, запас есть. Но начинается фрагментация на промежуточных маршрутизаторах, и всё летит в тартарары.

На практике: многие туннели ставят MTU на 1280 или даже 1200. Это снижает скорость, потому что каждый пакет меньше, но зато не фрагментируется. Для TCP это особенно больно — сегменты мельче, оверхед по заголовкам растёт.

Второе — NAT. Если у тебя за NAT, то 6in4 не заведётся. Протокол 41 не пробрасывается стандартными роутерами. Teredo решает эту проблему, но ценой производительности. Альтернатива — пробросить порты для протокола 41 или поднять VPN поверх UDP (OpenVPN, WireGuard), а уже внутри гонять IPv6. Костыль, но рабочий.

Третье — задержка. Каждый туннель добавляет 5-15 мс RTT. Если туннель идёт через полмира (например, через Hurricane Electric), задержка может вырасти до 100-150 мс. Для веб-сёрфинга терпимо. Для онлайн-игр — смертельно.

Четвёртое — надёжность. Туннельный провайдер может лечь. В отличие от нативного IPv6, где маршрутизация перестраивается автоматически, у тебя один туннель — одна точка отказа. Упал сервер — ты без IPv6.

Когда это оправдано: три железобетонных кейса

**Кейс 1: Провайдер не даёт IPv6, но тебе нужно тестировать приложения.**

Ситуация: ты разрабатываешь софт, который должен работать с IPv6. Заказчик требует. А у тебя дома — старый ADSL-роутер, который IPv6 не поддерживает. Решение — туннель. Берёшь аккаунт на tunnelbroker.net (Hurricane Electric), настраиваешь sit0 на Linux-сервере, и ты в сети.

Проверено: настройка занимает 15 минут. Скорость — до 50 Мбит/с на дешёвом VPS. Для тестов и отладки — идеально.

**Кейс 2: Нужен статический IPv6-адрес для сервера.**

Допустим, у тебя есть VPS с IPv4, но тебе нужно, чтобы к нему обращались через IPv6. Провайдер VPS не даёт нативный IPv6? Поднимаешь туннель. На выходе — стабильный /64 или даже /48 префикс.

Пример: VPS на Hetzner за 3 евро. IPv6 у них есть, но только для новых серверов. Старые — без. Туннель через Hurricane Electric решает проблему. Или можно взять прокси-сервис вроде lexic.ml, который уже умеет работать с IPv6-туннелями и не требует ручной настройки.

**Кейс 3: Обход блокировок и цензуры.**

IPv6-адреса пока что блокируют реже, чем IPv4. Если твой провайдер режет трафик к определённым ресурсам, туннель может обойти ограничение. Работает не всегда — если блокировка на уровне DNS, то IPv6 поможет. Если на уровне IP — тоже поможет, если твой туннельный сервер не заблокирован.

Но есть нюанс: если твой провайдер блокирует протокол 41, придётся использовать Teredo или VPN. Teredo — дёшево и сердито, но медленно. VPN — надёжно, но дороже.

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

| Метод | MTU | NAT | Задержка | Скорость | Настройка |

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

| 6in4 | 1280 | Не работает | +5-10 мс | Высокая | Ручная |

| 6to4 | 1280 | Проблемы | +10-20 мс | Средняя | Авто |

| Teredo | 1280 | Работает | +50-100 мс | Низкая | Авто |

| VPN+IPv6 | 1400 | Работает | +10-30 мс | Высокая | Средняя |

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

```bash

Устанавливаем необходимые пакеты

apt install iproute2

Создаём туннельный интерфейс

ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local 192.0.2.1 ttl 255

Включаем интерфейс

ip link set he-ipv6 up

Назначаем IPv6-адрес (полученный от провайдера туннеля)

ip addr add 2001:470:1f0b:1::2/64 dev he-ipv6

Добавляем маршрут по умолчанию

ip route add ::/0 dev he-ipv6

Настраиваем DNS

echo "nameserver 2001:4860:4860::8888" > /etc/resolv.conf

```

Проверяем:

```bash

ping6 google.com

```

Если идёт — ты в деле. Если нет — проверь, не блокирует ли провайдер протокол 41.

Когда туннель — зло

Туннель не нужен, если:

- У тебя есть нативный IPv6. Зачем тебе костыль, если есть нормальная дорога?

- Ты играешь в онлайн-игры. Лишняя задержка — это лишние смерти.

- Ты стримишь видео в реальном времени. Фрагментация и потеря пакетов убьют качество.

- Твой трафик чувствителен к джиттеру. Туннель добавляет нестабильность.

В этих случаях лучше либо дождаться нативного IPv6 от провайдера, либо использовать VPN с поддержкой IPv6.

Итог: стоит ли овчинка выделки

IPv6-туннелирование — это временное решение. Оно не заменит нативный IPv6, но даёт возможность работать с протоколом нового поколения уже сегодня. Если тебе нужно тестировать, разрабатывать или обходить блокировки — туннель оправдан.

Но помни: туннель добавляет сложность, задержку и точку отказа. Чем меньше зависимость от него, тем лучше. Рано или поздно провайдеры перейдут на нативный IPv6. Вопрос времени. А пока — туннелируй, но с умом.