Как VPN-серверы определяют и блокируют IPv6-туннели: методы детекции 6in4

6in4 — старый добрый протокол из 1996 года. RFC 4213. Инкапсулирует IPv6-пакеты прямо в IPv4-дейтаграммы, протокол 41. Никакой шифровки, никаких портов — просто IP-пакеты внутри IP-пакетов. Провайдеры его ненавидят. VPN-серверы — тоже. Потому что это идеальный способ обойти фильтрацию, если у тебя нет нативного IPv6.

Разберём, как серверы вычисляют такие туннели.

Протокол 41 как открытая книга

Самый простой способ — смотреть на заголовок IP. Номер протокола 41 в IPv4-заголовке. Поле Protocol, байт номер 9. Если там стоит 41 — это 6in4.

```bash

tcpdump -i eth0 'ip proto 41'

```

Всё. Одна команда — и ты видишь весь трафик. Никакого TCP или UDP, никаких портов. Просто поток протокола 41.

Проблема в том, что легитимного протокола 41 в интернете почти не осталось. Туннельные брокеры вроде Hurricane Electric — да, но массово — нет. Поэтому любой всплеск proto 41 сразу привлекает внимание.

Глубокий анализ: версии IP и несоответствия

Дальше — интереснее. VPN-сервер смотрит на пары пакетов. Внешний заголовок — IPv4. Внутренний — IPv6. Проверяем:

- Версия внешнего пакета: 4

- Версия внутреннего: 6

- Длина внешнего пакета vs длина внутреннего + 20 байт заголовка

Если сервер видит IPv4-пакет, внутри которого IPv6 — это 6in4. Если внутри IPv4 — это уже 6over4, и это другая история.

```python

from scapy.all import *

def detect_6in4(pkt):

if IP in pkt and pkt[IP].proto == 41:

inner = pkt[IP].payload

if inner.version == 6:

return True

return False

```

Но есть нюанс. Некоторые реализации используют IPv6-заголовки с расширениями. И тогда просто проверка версии не работает. Нужно парсить всю цепочку заголовков.

MTU как палец на спусковом крючке

6in4 добавляет 20 байт к каждому пакету. Это ломает MTU. Стандартный Ethernet — 1500 байт. После инкапсуляции — 1520. Фрагментация или снижение MTU до 1480.

VPN-серверы отслеживают ICMPv6 Packet Too Big. Если клиент шлёт IPv6-пакеты размером 1480 байт внутри IPv4-пакетов размером 1500 — это 6in4.

```bash

iptables -A INPUT -p 41 -m length --length 1481:1520 -j LOG --log-prefix "6in4-detect: "

```

Реальные цифры: типичный TCP MSS для IPv6 — 1440 байт. Для 6in4 — 1420. Разница в 20 байт — это сигнатура.

TTL и временные метки

Ещё один метод — анализ TTL. В 6in4 внешний TTL устанавливается маршрутизатором клиента. Внутренний TTL — хостом. Разница обычно 1, иногда больше.

Если сервер видит пакет с внешним TTL=64 и внутренним TTL=63 — это почти наверняка туннель. При нормальной маршрутизации TTL не меняется внутри пакета.

Но это ненадёжно. Многие ОС устанавливают одинаковые значения. Поэтому этот метод используют как вспомогательный.

Проверка на стороне VPN-сервера

Когда клиент подключается к VPN, сервер может проверить, есть ли у него IPv6-адрес. Если клиент шлёт IPv6-трафик через VPN, но при этом его IPv4-адрес принадлежит сети без IPv6 — это подозрительно.

Пример: клиент из России, у провайдера нет IPv6, но клиент шлёт IPv6-пакеты. Откуда? Только через туннель.

VPN-сервер может сделать обратный DNS-запрос, проверить маршруты, посмотреть на BGP-анонсы. Если IPv6-адрес клиента не анонсируется его провайдером — значит, туннель.

Активная детекция: ICMP-эхо

Некоторые серверы шлют ICMPv6 echo request на IPv6-адрес клиента. Если ответ приходит — проверяют путь. Если TTL в ответе отличается от ожидаемого для прямого соединения — туннель.

Другой вариант — шлют пакет с маленьким TTL, чтобы он умер на промежуточном маршрутизаторе. Смотрят, откуда пришёл ICMP Time Exceeded. Если адрес источника не совпадает с ожидаемым — туннель.

Пассивный мониторинг и поведенческий анализ

Самый современный метод — машинное обучение. Собирают статистику:

- Размеры пакетов

- Интервалы между пакетами

- Количество соединений

- Используемые протоколы

6in4 имеет характерные паттерны. Резкие всплески трафика, однотипные размеры пакетов, отсутствие TCP-рукопожатий на IPv4-уровне.

VPN-серверы с DPI-движками (Deep Packet Inspection) типа nDPI или OpenDPI могут классифицировать 6in4 по сигнатурам.

Блокировка: технические методы

Когда туннель обнаружен, его блокируют. Просто отбрасывают пакеты с proto 41:

```bash

iptables -A INPUT -p 41 -j DROP

```

Или на уровне маршрутизации:

```bash

ip route add blackhole 2001:db8::/32

```

Но это не всё. Умные серверы делают сложнее. Например, отправляют ICMP Protocol Unreachable обратно клиенту. Это убивает туннель на клиентской стороне быстрее, чем просто дроп.

Что делает клиент

Клиент может маскировать 6in4. Например, оборачивать его в UDP. Это называется 6in4-over-UDP. Или использовать более сложные схемы — GRE, IPIP, даже SSH-туннели.

Но это уже не чистый 6in4, а гибрид. И каждый такой гибрид — новая сигнатура для детекции.

Хороший вариант — использовать IPv6-прокси от lexic.ml. Там не нужно изобретать велосипеды с туннелями. Просто настраиваешь прокси и работаешь.

Реальный пример: блокировка на VPS

Пример: VPS от Hetzner, Ubuntu 22.04, nginx 1.24. Клиент подключается через 6in4 от Hurricane Electric. Через час сервер перестал отвечать на IPv6.

Логи показали:

```

kernel: [12345.678] IN=eth0 OUT= MAC=... SRC=192.0.2.1 DST=198.51.100.1 LEN=1500 TOS=0x00 PREC=0x00 TTL=57 ID=54321 PROTO=41

```

Всё. Один пакет с proto 41 — и автоматическое правило в firewall. Hetzner мониторит такие вещи. Их система безопасности сама добавляет правила блокировки.

Итоги

6in4 легко обнаружить. Протокол 41 в заголовке, MTU-аномалии, TTL-разницы, поведенческие паттерны. VPN-серверы используют комбинацию методов.

Для обхода нужны более сложные схемы. UDP-инкапсуляция, маскировка под обычный трафик, использование прокси. Но и это не гарантия. Детекция становится умнее с каждым годом.

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