Туннелирование IPv6-in-IPv4 при помощи протокола 6in4: почему это актуально для прокси и какие подводные камни ждут на пути

6in4: когда IPv6 приходится пробираться через IPv4-джунгли

IPv6 существует с 1996 года. Прошло почти тридцать лет, а значительная часть интернета всё ещё живёт на IPv4. Провайдеры не спешат менять оборудование, корпоративные сети держатся за старые адреса, а количество доступных IPv4-адресов давно исчерпано. Возникает парадокс: новая технология есть, а доступа к ней нет.

Туннелирование 6in4 решает эту проблему радикально — заворачивает IPv6-пакеты в IPv4-обёртку и отправляет через обычные маршрутизаторы. Протокол RFC 4213, минималистичный до безобразия: никакой инкапсуляции с шифрованием, никаких лишних заголовков. Просто IPv6-пакет целиком становится payload'ом IPv4-пакета.

Схема работы выглядит так: ваш сервер получает IPv6-адрес от туннельного брокера (например, Hurricane Electric), устанавливает соединение с его сервером и получает маршрут для всех IPv6-адресов через этот туннель. Весь трафик IPv6 упаковывается в IPv4 и летит через интернет как обычные UDP- или TCP-пакеты.

Почему это вообще нужно для прокси

Прокси-сервисы живут за счёт обхода ограничений и распределения нагрузки. IPv6-адреса дают почти бесконечное пространство — 2^128 адресов против жалких 2^32 у IPv4. Для прокси это означает возможность выдавать каждому клиенту уникальный IP-адрес, а не делить один IPv4 на сотни пользователей.

Кроме того, многие сайты и сервисы всё активнее блокируют IPv4-адреса дата-центров. Облачные провайдеры типа AWS или DigitalOcean давно в чёрных списках. А вот IPv6-адреса часто остаются вне зоны блокировок — их слишком много, и списки попросту не успевают пополняться.

Пример с lexic.ml показывает: прокси на IPv6-адресах работают стабильно уже много лет, потому что каждый клиент получает собственный адрес из огромного пула. Никакого шеринга IP, никаких следов соседей по прокси.

Технические детали протокола

Протокол 6in4 использует IP-протокол номер 41. Это важно помнить, потому что многие файрволы блокируют именно этот протокол — он не является ни TCP, ни UDP, и поэтому часто попадает под фильтры по умолчанию.

MTU для туннеля — классическая боль. Стандартный Ethernet MTU равен 1500 байт. IPv6-пакет внутри IPv4-обёртки добавляет дополнительные 20 байт заголовка. Если не уменьшить MTU на туннельном интерфейсе, пакеты будут фрагментироваться, что приводит к потере производительности и проблемам с некоторыми приложениями.

Рекомендуемое значение MTU для 6in4 — 1480 байт или даже 1472, если учитывать возможные дополнительные заголовки PPPoE. Многие забывают настроить это и потом удивляются, почему SSH-сессии зависают или сайты грузятся с ошибками.

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

Базовая настройка 6in4 на Linux занимает несколько минут. Для начала получаем адреса от туннельного брокера — обычно это IPv4-адрес сервера брокера, ваш IPv6-адрес и шлюз IPv6.

```

ip tunnel add sit1 mode sit remote 216.66.80.30 local 192.168.1.100 ttl 255

ip link set sit1 up

ip addr add 2001:470:1f0b:1234::2/64 dev sit1

ip route add ::/0 dev sit1

```

Первая команда создаёт туннель sit с удалённым адресом брокера. Вторая поднимает интерфейс. Третья назначает IPv6-адрес. Четвёртая добавляет маршрут по умолчанию через туннель.

Проблема в том, что после перезагрузки все настройки исчезнут. Для постоянной конфигурации лучше использовать systemd-networkd или /etc/network/interfaces. В systemd-networkd создаём файл /etc/systemd/network/6in4.netdev:

```

[NetDev]

Name=sit1

Type=sit

Remote=216.66.80.30

Local=192.168.1.100

TTL=255

```

И файл /etc/systemd/network/6in4.network:

```

[Match]

Name=sit1

[Network]

Address=2001:470:1f0b:1234::2/64

Gateway=2001:470:1f0b:1234::1

```

После этого `systemctl restart systemd-networkd` поднимет туннель автоматически.

Подводные камни с файрволами

Самый частый сценарий провала — файрвол блокирует протокол 41. На многих VPS-провайдерах по умолчанию разрешены только TCP и UDP, а всё остальное режется на уровне гипервизора.

Проверка простая — отправляем ping с IPv6-адреса на адрес брокера:

```

ping6 2001:470:1f0b:1234::1

```

Если ответа нет, а IPv4-ping работает, значит проблема с файрволом. На некоторых панелях управления (например, Vultr или Linode) нужно вручную добавить правило для протокола 41.

В iptables это выглядит так:

```

iptables -A INPUT -p ipv6 -j ACCEPT

iptables -A OUTPUT -p ipv6 -j ACCEPT

```

Но даже после этого может оказаться, что провайдер блокирует протокол 41 на уровне своей сети. Тогда 6in4 не заработает в принципе, и придётся использовать другие механизмы — например, туннели на основе UDP (Teredo, AYIYA) или вообще перейти на прокси-решения с поддержкой IPv4.

Кейс с MTU и Path MTU Discovery

Реальный пример: сервер с nginx 1.24, раздающий статические файлы. Пользователи жалуются, что крупные файлы скачиваются с ошибками, а мелкие страницы открываются нормально.

Причина — MTU туннеля не настроен. IPv6-пакеты размером 1500 байт инкапсулируются в IPv4, итоговый размер превышает MTU канала, и начинается фрагментация. Path MTU Discovery не работает корректно через туннель, потому что ICMP-сообщения о превышении размера теряются.

Решение — принудительно установить MTU на туннельном интерфейсе:

```

ip link set sit1 mtu 1480

```

После этого проблема исчезла. Крупные файлы стали скачиваться без ошибок, скорость выросла на 15-20% из-за отсутствия фрагментации.

Проблема с IPv4-адресами назначения

Ещё один нюанс: 6in4 работает только для IPv6-трафика. Если ваш прокси-сервер должен обрабатывать и IPv4-запросы, придётся настраивать два стека или использовать трансляцию NAT64.

Некоторые сайты до сих пор не имеют IPv6-версий. Ваш IPv6-трафик через туннель дойдёт до сервера брокера, но дальше упрётся в отсутствие маршрута. Брокеры обычно предоставляют NAT64 для таких случаев, но это добавляет задержку и может вызвать проблемы с геолокацией.

Стабильность и задержки

Туннель 6in4 добавляет дополнительный хоп в маршрутизации. Если ваш сервер находится в Европе, а брокер — в США, каждый пакет будет делать лишний круг через океан. Задержка вырастет на 50-150 мс, что критично для прокси.

Выбирайте брокера, географически близкого к вашему серверу. Hurricane Electric имеет точки присутствия по всему миру, но не все они одинаково хорошо связаны. Проверяйте пинг до сервера брокера перед настройкой — если он больше 30 мс, ищите другого.

Для прокси-сервисов, где важна скорость, лучше использовать туннели с меньшей задержкой. Например, 6rd или 6to4, но у них свои ограничения.

Кейс с блокировкой по геолокации

Пример: прокси-сервер для доступа к американскому стриминговому сервису. Настроили 6in4 через брокера в США, всё работает, но сервис показывает контент для Европы.

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

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

Кейс с чёрными списками

Другой случай: сайт блокирует все IPv6-адреса, потому что через них идёт много спама. Ваш 6in4-туннель попадает в чёрный список, и все запросы отклоняются.

Тут помогает смена IPv6-префикса. У брокеров обычно есть возможность запросить новый префикс. Но если сайт блокирует всю подсеть брокера, это не спасёт.

Альтернатива — использовать несколько туннелей от разных брокеров и балансировать трафик между ними. Это усложняет конфигурацию, но даёт устойчивость к блокировкам.

Безопасность туннеля

6in4 не шифрует трафик. Любой, кто имеет доступ к каналу, может прочитать содержимое пакетов. Для прокси это означает, что данные клиентов передаются в открытом виде.

Если нужно шифрование, используйте IPsec поверх 6in4 или сразу переходите на OpenVPN/WireGuard. Но учтите — шифрование добавляет задержку и снижает пропускную способность.

Ещё один аспект безопасности — подделка пакетов. Злоумышленник может отправить IPv6-пакеты от вашего имени, если знает адреса туннеля. Рекомендуется настроить фильтрацию на туннельном интерфейсе, разрешив только трафик от брокера.

Нестандартные применения

6in4 можно использовать не только для прокси. Например, для объединения нескольких офисов в единую IPv6-сеть или для доступа к IPv6-only сервисам из сети с IPv4.

Ещё вариант — раздача IPv6-адресов клиентам через DHCPv6-PD. Это позволяет каждому клиенту получить собственную подсеть /64, которую он может использовать для своих устройств.

Но для прокси-бизнеса самый интересный вариант — это использование 6in4 в сочетании с IPv6-адресами от lexic.ml для создания пула уникальных IP-адресов. Каждый клиент получает собственный IPv6-адрес, который нельзя заблокировать, не задев остальных.

Диагностика проблем

Когда туннель не работает, проверяйте по шагам:

```

ping -c 4 216.66.80.30

ping6 -c 4 2001:470:1f0b:1234::1

ip -6 route show

tcpdump -i sit1 -n

```

Первый ping проверяет доступность IPv4-адреса брокера. Второй — работу туннеля. Третий показывает маршруты. Четвёртый — реальный трафик через туннель.

Если tcpdump показывает пакеты, но ответа нет, проблема в маршрутизации или файрволе на стороне брокера. Если пакетов нет вообще — туннель не поднялся или неправильные адреса.

Когда 6in4 не нужен

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

6in4 оправдан только в трёх случаях: провайдер не даёт IPv6, нужен IPv6 в конкретной локации, или требуется быстро развернуть туннель без ожидания апгрейда сети.

В остальных ситуациях лучше потратить время на поиск хостинга с поддержкой IPv6 или настройку более современных туннельных протоколов (WireGuard, VXLAN), которые дают больше возможностей и лучше работают с NAT.

Выводы

6in4 — рабочий протокол, но с кучей ограничений. MTU, файрволы, задержки, отсутствие шифрования — всё это приходится учитывать. Для прокси-сервисов он подходит, если правильно настроен и используется с умом.

Главное — не забывать про MTU, проверять доступность протокола 41 и выбирать брокера поближе к серверу. Тогда туннель будет работать стабильно и не доставит хлопот.