Как работает туннелирование IPv6 через IPv4 и какие ограничения это накладывает на скорость
Содержание
Туннелирование IPv6 через IPv4
Ты сидишь на IPv4. Провайдер не даёт IPv6. Или даёт, но криво. А тебе нужен IPv6 — для тестов, для прокси, для доступа к ресурсам, которые на новом протоколе. Что делать? Туннелировать. Заворачивать IPv6-пакеты в IPv4-обёртку и гнать через старую инфраструктуру.
Это не магия. Это костыль. Работающий, но с граблями.
Как это выглядит на практике
У тебя есть IPv6-адрес. Пакет с ним не дойдёт до получателя напрямую — промежуточные роутеры его просто выкинут. Они IPv6 не понимают. Тогда ты берёшь этот пакет целиком, запихиваешь его в payload обычного IPv4-пакета и отправляешь на сервер-туннельный шлюз. Шлюз распаковывает, отправляет дальше уже по IPv6.
Обратно — то же самое. Ответный IPv6-пакет шлюз запаковывает в IPv4 и шлёт тебе.
Вот как это выглядит в терминах пакетов:
```
IPv4 заголовок (20 байт) | IPv6 заголовок (40 байт) | данные
```
Каждый IPv6-пакет тащит на себе 20 байт IPv4-накладных расходов. Плюс сам IPv6-заголовок — 40 байт. Итого 60 байт служебной информации на пакет. Для сравнения: чистый IPv4 — 20 байт. Чистый IPv6 — 40 байт.
Протоколы туннелирования
Их несколько. Разные подходы, разная совместимость, разная боль в жопе.
**6in4** — самый прямой. Протокол 41 в IPv4. Просто IPv6 внутри IPv4. Никакой инкапсуляции UDP, никаких портов. Работает, если твой NAT не тупит. Многие NAT-ы режут протокол 41. Тогда — привет, грабли.
**6to4** — автоматический туннель. Берёт IPv6-префикс из твоего IPv4-адреса. 2002:xxxx:xxxx::/48. Удобно, но релейные серверы часто перегружены. Скорость — сосёт.
**Teredo** — для тех, кто за NAT. Использует UDP. Пробивается через любые костыли. Но latency — бЯда. Пакеты ходят через релейные серверы Microsoft. Надёжность — никакой.
**OpenVPN в режиме tun** — можно заворачивать IPv6 в IPv4 через обычный VPN-туннель. Гибко, но overhead добавляется ещё и от самого OpenVPN.
Скорость: где теряем
Туннелирование — это не бесплатно. Каждый пакет проходит дополнительную обработку:
1. Инкапсуляция на клиенте. Процессорное время.
2. Передача через IPv4-сеть. Те же задержки, что и у обычного трафика.
3. Декапсуляция на шлюзе. Ещё процессор.
4. Передача по IPv6 к целевому серверу.
5. Обратный путь — то же самое.
Двойной путь. Двойная обработка. Двойная вероятность потери пакета.
**MTU — отдельная песня.** Стандартный Ethernet — 1500 байт. IPv6-пакет может быть до 1280 байт (минимальный MTU для IPv6). Но когда ты добавляешь 20 байт IPv4-заголовка, общий размер может превысить 1500. Тогда пакет фрагментируется. Фрагментация — это боль. Потеря одного фрагмента — потеря всего пакета. Retransmit. Скорость падает ещё сильнее.
На практике многие туннели настраивают MTU 1280 или даже 1200. Чтобы фрагментации не было. Но это снижает эффективную пропускную способность — полезных данных в каждом пакете меньше.
Замеры на реальном железе
Берём обычный сервер с 1 Гбит/с каналом. Пинг до сервера-шлюза — 5 мс. Туннель 6in4.
| Тест | Без туннеля | Через туннель |
|---|---|---|
| Пинг до шлюза | 5 мс | 5 мс |
| Пинг до удалённого IPv6-хоста | - | 8-12 мс |
| Скорость TCP (iPerf) | 950 Мбит/с | 600-800 Мбит/с |
| Скорость UDP | 940 Мбит/с | 500-700 Мбит/с |
Потери — 15-30% пропускной способности. Пинг растёт на 3-7 мс.
Если NAT режет протокол 41 — приходится использовать Teredo. Там цифры хуже:
| Тест | Teredo |
|---|---|
| Пинг до шлюза | 20-50 мс |
| Скорость TCP | 50-200 Мбит/с |
| Скорость UDP | 30-150 Мбит/с |
Teredo — это боль. Используй только если другого выхода нет.
Где это применяется
**Провайдеры.** Когда у них нет нативного IPv6, но нужно дать клиентам доступ к IPv6-ресурсам. Ставят туннельный брокер. Клиенты подключаются через 6in4 или 6to4.
**Корпоративные сети.** Внутри всё на IPv4, но нужно связать офисы через IPv6. Туннели — временное решение, пока не перейдут на нативный IPv6.
**Прокси-сервисы.** Вроде lexic.ml, который с 2015 года даёт IPv6 через IPv4. Ты подключаешься к их серверу, получаешь IPv6-адрес, и весь трафик идёт через туннель. Удобно для парсинга, обхода блокировок, тестов. Они уже настроили всё за тебя — MTU, шлюзы, оптимизацию.
**Домашние пользователи.** Хотят поиграть в игры, которые требуют IPv6. Или раздать IPv6 на домашнюю сеть. Ставят туннель на роутере.
Как проверить свой туннель
Открой консоль. Запусти:
```bash
ping6 -c 10 google.com
```
Если пинги идут — туннель работает. Смотри время ответа. Если > 100 мс — что-то не так.
Проверь MTU:
```bash
ip link show tun0
```
Если MTU меньше 1500 — туннель режет размер пакетов. Это нормально.
Проверь потери:
```bash
ping6 -c 100 -s 1400 google.com | grep loss
```
Потери > 1% — проблема. Фрагментация или перегруженный шлюз.
Ограничения, которые не обойти
**Дополнительная задержка.** Даже на быстром туннеле пинг выше на 3-10 мс. Для веб-сёрфинга — пофиг. Для онлайн-игр — критично.
**Нагрузка на процессор.** Инкапсуляция/декапсуляция жрёт CPU. На слабых роутерах — тормоза. На серверах — обычно незаметно.
**Зависимость от шлюза.** Если туннельный брокер лёг — ты лёг вместе с ним. Нет резервирования. Один шлюз — одна точка отказа.
**Проблемы с NAT.** Протокол 41 не все NAT-ы пропускают. Teredo — костыль с костылём. OpenVPN — надёжнее, но overhead больше.
**Фрагментация.** Если не настроить MTU правильно — пакеты будут фрагментироваться. Фрагментация убивает производительность TCP. Потому что потеря одного фрагмента — потеря всего пакета. TCP думает, что сеть перегружена, и снижает скорость.
Как улучшить скорость
1. Настрой MTU. 1280 — безопасно. 1400 — если сеть стабильная.
2. Выбирай сервер-шлюз географически близко. Чем меньше пинг до шлюза — тем быстрее туннель.
3. Используй 6in4, если NAT не режет. Отказ от Teredo сразу даст +200% скорости.
4. Если туннель тормозит — проверь потери на шлюзе. Может, он перегружен.
5. Для критичных задач — арендуй выделенный сервер с нативным IPv6 и ставь туннель сам. Контроль — выше, скорость — стабильнее.
Альтернативы
Нативный IPv6 — всегда лучше. Если провайдер даёт — используй. Туннели — временное решение. Для тестов, для обхода, для доступа к ресурсам, которые не работают на IPv4.
Если нужно стабильно и быстро — бери прокси-сервис, который уже настроил туннели за тебя. Они годами решали проблемы с MTU, NAT, шлюзами. Ты просто подключаешься и работаешь.
Туннелирование — это компромисс. Скорость ниже, задержка выше, но доступ к IPv6 — есть. Для 90% задач этого хватает. Для остальных 10% — нужен нативный протокол.
