Как работает обход блокировок через IPv6: почему сайты не видят ваш реальный IP

Архитектура IPv6-туннелирования

IPv6-прокси — это не просто смена IP. Это полная замена транспортного уровня. Ваш IPv4-трафик упаковывается в IPv6-пакеты, идёт через прокси-сервер, а наружу выходит уже с чужим адресом. Сайт видит только IP прокси. Ваш реальный адрес остаётся внутри туннеля.

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

Почему это работает? Потому что протокол IPv4 и IPv6 — разные сетевые уровни. Блокировки обычно завязаны на IPv4-адреса. Переход на IPv6 автоматически выводит трафик из-под фильтров. Но только если прокси настроен правильно.

Почему IPv4-адрес остаётся скрыт

Главная причина — отсутствие маршрутов. IPv4-пакет, идущий через IPv6-туннель, не виден внешним роутерам. Они видят только внешнюю IPv6-обёртку. Ваш настоящий IP не передаётся в заголовках HTTP — прокси его просто не вставляет.

Но есть нюанс. Некоторые прокси оставляют X-Forwarded-For. Это заголовок, который указывает исходный IP. Если прокси его добавляет — сайт увидит ваш адрес. Хорошие IPv6-прокси этот заголовок не ставят. Или ставят, но с IP самого прокси.

Пример: curl через IPv6-прокси без лишних заголовков:

```bash

curl -x http://[2001:db8::1]:3128 http://httpbin.org/ip

```

Ответ покажет IP прокси. Ваш IPv4 не появится. Ни в заголовках, ни в теле запроса.

Разница между IPv4 и IPv6 прокси

IPv4-прокси — это просто relay. Вы подключаетесь к серверу, он шлёт запросы от своего имени. Но многие сайты научились детектить такие прокси по времени отклика, по заголовкам, по поведению TCP/IP.

IPv6-прокси сложнее. Трафик идёт через другой протокол. Сайт видит IPv6-соединение. Если у сайта нет IPv6 — прокси сам делает NAT64. То есть преобразует IPv6-запрос в IPv4. Но для сайта это выглядит как обычный IPv4-запрос с адреса прокси.

Таблица сравнения:

| Параметр | IPv4 прокси | IPv6 прокси |

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

| Видимость IP | Прокси-сервер | Прокси-сервер |

| Детект блокировок | Высокий | Низкий |

| Доп. заголовки | Часто X-Forwarded-For | Обычно нет |

| Скорость | ~50-100 мс | ~80-150 мс |

| MTU | Стандартный 1500 | Туннель может фрагментировать |

Цифры примерные, но тенденция ясна. IPv6-прокси чуть медленнее из-за туннелирования, но надёжнее прячет клиента.

Как сайты пытаются определить ваш реальный IP

Сайты не глупые. Они могут использовать WebRTC. Это протокол для P2P-соединений в браузере. Он может «утечь» ваш IPv6-адрес напрямую, минуя прокси. Даже если вы используете IPv6-прокси, браузер может отправить запрос напрямую.

Решение — отключать WebRTC в настройках браузера. Или использовать расширения типа uBlock Origin с дополнительными фильтрами. В Firefox это делается через `about:config` — параметр `media.peerconnection.enabled` ставится в false.

Ещё один метод — анализ времени задержки. Если задержка до прокси мала, а до сайта велика — это подозрительно. Но IPv6-туннель добавляет свою задержку, что сбивает такие алгоритмы. Пример: ping до прокси 10 мс, до сайта 150 мс. Прокси с IPv6 даёт ту же задержку 150 мс — разница не видна.

Настройка клиента для работы через IPv6

Самый простой способ — использовать HTTP-прокси с IPv6-адресом. Настраивается в системных настройках или через переменные окружения. Пример для Linux:

```bash

export http_proxy="http://[2001:db8::1]:3128"

export https_proxy="http://[2001:db8::1]:3128"

```

Для Python-скриптов:

```python

import requests

proxies = {

'http': 'http://[2001:db8::1]:3128',

'https': 'http://[2001:db8::1]:3128'

}

response = requests.get('http://httpbin.org/ip', proxies=proxies)

print(response.text)

```

Важно: в квадратных скобках IPv6-адрес. Без них curl или requests не поймут, где адрес, где порт. Это стандарт RFC 3986.

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

Пример: сервер в России, nginx 1.24, модуль GeoIP. Конфиг блокирует все запросы не из РФ:

```nginx

geoip_country /etc/nginx/geoip/GeoIP.dat;

if (\ != "RU") {

return 403;

}

```

Если клиент использует IPv6-прокси с адресом из Нидерландов — nginx видит страну NL. Блокировка срабатывает. Реальный IP клиента (российский) не виден. GeoIP видит только прокси.

Решение — подобрать прокси с IPv6-адресом в нужной стране. Например, если нужно показать, что вы из РФ — используйте прокси с российским IPv6. Такие есть, но реже.

Кейс: обход DPI с IPv6

Глубокая проверка пакетов (DPI) часто завязана на IPv4. Провайдеры анализируют заголовки, ищут признаки VPN или прокси. IPv6-трафик для них — тёмный лес. Пример: провайдер блокирует OpenVPN по порту 1194. Если трафик идёт через IPv6-туннель — порт 1194 виден только внутри туннеля. Снаружи — обычный IPv6-трафик на 443 порт.

Проблема: некоторые DPI-системы умеют анализировать и IPv6. Но это редкость. Обычно IPv6-трафик пропускают без проверки. Исключение — Китай, где DPI работает на обоих протоколах.

Кейс: утечка DNS через IPv6

Даже если HTTP-трафик идёт через прокси, DNS-запросы могут утекать. Браузер делает DNS-запрос для IPv6-адреса прокси — это нормально. Но если сайт имеет IPv6-запись AAAA, браузер может попытаться подключиться напрямую, минуя прокси.

Решение — использовать DNS-over-HTTPS или DNS-over-TLS. Настраивается в браузере или системно. Пример для systemd-resolved:

```bash

sudo resolvectl dns eth0 1.1.1.1

sudo resolvectl domain eth0 ~.

```

Или в Firefox: `network.trr.mode` = 2 (DoH с резервированием). Тогда DNS-запросы идут через HTTPS, не утекают.

Почему не все IPv6-прокси одинаковы

Качество прокси сильно различается. Некоторые прокси добавляют заголовки `Via` или `X-Forwarded-For`. Другие не поддерживают HTTPS — только HTTP. Третьи имеют высокий пинг из-за плохой маршрутизации.

Пример плохого прокси: добавляет `X-Forwarded-For: 192.168.1.1`. Сайт видит ваш внутренний IP. Это провал. Хороший прокси не добавляет ничего лишнего. Проверить можно так:

```bash

curl -x http://[прокси]:3128 -v http://httpbin.org/headers

```

В ответе должны быть только стандартные заголовки: `Host`, `User-Agent`, `Accept`. Никаких `X-Forwarded-For`.

Итог: когда IPv6-прокси не спасает

IPv6-прокси не панацея. Если сайт использует fingerprinting браузера — ваш IP не важен, вас определят по кукам, шрифтам, canvas. Если у вас включён WebRTC — IP утечёт. Если DNS утекает — вас найдут.

Но для обхода блокировок по IP, GeoIP, DPI — IPv6-прокси работает отлично. Главное — правильно настроить клиент и проверить, что нет утечек.