IPv6 и доступ к ИИ: почему VPN иногда не помогает

MAATRIX

Вы подключили VPN, IP в статус-баре сменился на нужную страну, но ChatGPT или Claude всё равно пишут «сервис недоступен в вашем регионе». Дело не всегда в блокировке или кривой настройке клиента — часто виновник прячется на уровень ниже: у устройства есть собственный IPv6-адрес, и сайт определяет ваше реальное местоположение по нему, полностью игнорируя VPN-туннель.

Почему так происходит: IPv6 живёт своей жизнью

Большинство VPN-протоколов — OpenVPN, WireGuard в типовой настройке — заворачивают в туннель только IPv4-трафик. Это исторически сложилось: IPv6 распространялся медленнее, и многие конфиги просто не учитывали его как отдельный маршрут.

Проблема в том, что операционная система при этом не «забывает» про IPv6. Если ваш провайдер (мобильный оператор или домашний интернет) выдаёт устройству нативный IPv6-адрес — а сегодня это делает всё больше операторов, — то он продолжает работать параллельно с VPN-туннелем. Получается ситуация с двумя одновременными маршрутами:

• IPv4-запросы уходят через VPN-туннель, и по ним виден IP сервера, к которому вы подключились;
• IPv6-запросы уходят напрямую через провайдера, минуя VPN, и по ним виден ваш реальный регион.

Браузер и приложения сами решают, какой протокол использовать для конкретного соединения — по правилу Happy Eyeballs (RFC 8305) современные ОС при прочих равных предпочитают IPv6, если он доступен и отвечает быстрее. То есть система не «ошибается» — она делает ровно то, для чего спроектирована: выбирает более быстрый путь. Просто в вашем случае этот путь обходит VPN стороной.

Раньше это было не так критично: у большинства сайтов и API просто не было IPv6-адресов, и весь трафик шёл через IPv4 внутри туннеля. Но к 2026 году значительная часть крупных ИИ-сервисов и CDN, через которые они раздаются, уже поддерживает IPv6 — Cloudflare, Google Cloud, AWS активно используют dual-stack инфраструктуру. Из-за этого IPv6 leak стал заметно более частой причиной, по которой «VPN подключён, но регион всё равно палится», чем несколько лет назад.

Похожая логика разобрана в статье «Приложение всё равно пишет регион: типичные ошибки туннеля к ИИ» — там IPv6 leak лишь одна из нескольких причин, здесь разберём её подробно.

Как проверить, есть ли у вас IPv6 leak

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

На компьютере (Linux/macOS):

ip -6 addr show scope global
# или на macOS
ifconfig | grep inet6

Если в выводе есть глобальный адрес (не начинается с fe80::, это link-local и не считается), IPv6 у вас работает и потенциально может «протекать» мимо VPN.

На Windows:

ipconfig | findstr /i "IPv6"

Дальше — сравнение адресов до и после включения VPN. Логика простая: узнаёте свой IPv6-адрес без VPN, включаете VPN, проверяете ещё раз. Если адрес не изменился (или вообще остался доступен, когда VPN должен был всё завернуть в туннель) — это и есть утечка.

Как тип проверки подойдёт любой сервис, который параллельно показывает IPv4- и IPv6-адрес клиента (в поиске находится по запросу «ipv6 leak test» или «what is my ipv6») — не буду называть конкретное название, поскольку такие сервисы часто меняют домены и надёжность, лучше проверить актуальный вариант самостоятельно. Смотрите на две вещи:

• показывает ли сервис IPv6-адрес вообще (если нет — вам повезло, IPv6 у провайдера отключён или не используется);
• совпадает ли гео по IPv6 с гео по IPv4 — если IPv4 показывает страну VPN-сервера, а IPv6 показывает страну вашего реального провайдера, вот она, утечка.

Дополнительно можно проверить руками через curl, если нужен именно IPv6-ответ:

curl -6 https://ifconfig.co
curl -4 https://ifconfig.co

Если оба запроса возвращают разные IP из разных стран во время включённого VPN — проблема подтверждена.

Быстрое временное решение: отключить IPv6 на устройстве

Пока вы не настроили полноценный IPv6-туннель на VPN-сервере, самый надёжный способ закрыть утечку — просто отключить IPv6 на клиенте. Это грубо, но работает мгновенно и не требует доступа к серверу.

Linux (временно, до перезагрузки):

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Linux (постоянно) — добавьте в /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

и примените:

sudo sysctl -p

macOS (для конкретного интерфейса, например Wi-Fi):

networksetup -setv6off Wi-Fi
# включить обратно:
networksetup -setv6automatic Wi-Fi

Windows — через панель управления: «Сетевые подключения» → свойства адаптера → снять галочку с «IP версии 6 (TCP/IPv6)». Либо через PowerShell (от администратора):

Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

На мобильных устройствах отключить IPv6 системными настройками обычно нельзя — это управляется профилем оператора. Здесь либо полагаетесь на VPN-клиент с корректной обработкой IPv6 (см. следующий раздел), либо переключаетесь на Wi-Fi с сетью без IPv6.

Важная оговорка: отключение IPv6 — это заплатка, а не решение. Она снижает скорость соединения к сайтам, которые предпочли бы IPv6 (для них произойдёт откат на IPv4, обычно с небольшой задержкой), и её нужно не забыть повторно применять после переустановки системы или смены сети. Для разового использования подходит, для постоянной работы — не очень.

Правильное решение: VPN с полноценным туннелированием IPv6

Надёжный путь — не прятать IPv6, а завернуть его в туннель вместе с IPv4. Тогда весь трафик, независимо от протокола, идёт через сервер, и утечки не возникает в принципе.

WireGuard

WireGuard изначально спроектирован как dual-stack протокол — добавить IPv6 в конфиг несложно. На сервере в wg0.conf:

[Interface]
Address = 10.8.0.1/24, fd42:42:42::1/64
PrivateKey = <ключ_сервера>
ListenPort = 51820
PostUp = sysctl -w net.ipv6.conf.all.forwarding=1
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <ключ_клиента>
AllowedIPs = 10.8.0.2/32, fd42:42:42::2/128

На клиенте в AllowedIPs укажите 0.0.0.0/0, ::/0 — это заставит клиент заворачивать в туннель весь трафик обоих протоколов, а не только IPv4:

[Interface]
Address = 10.8.0.2/32, fd42:42:42::2/128
PrivateKey = <ключ_клиента>
DNS = 10.8.0.1

[Peer]
PublicKey = <ключ_сервера>
Endpoint = ваш.сервер.io:51820
AllowedIPs = 0.0.0.0/0, ::/0

Здесь используется ULA-адрес (fd42:42:42::/64) — это внутренняя IPv6-сеть только для туннеля, она не даёт клиенту «настоящий» глобальный IPv6 наружу, но полностью решает проблему прямой утечки через провайдерский IPv6. Если серверу нужен полноценный исходящий IPv6 (например, для NAT66 на глобальный адрес), потребуется, чтобы хостинг-провайдер выделил серверу IPv6-подсеть — это стоит уточнить при заказе VPS.

Подробное сравнение протоколов — в статье «WireGuard или OpenVPN: что выбрать для сервера».

OpenVPN

OpenVPN тоже поддерживает IPv6, но конфигурировать нужно явно — по умолчанию тянет только IPv4. В серверном конфиге добавьте:

server-ipv6 fd42:42:42:1::/64
push "route-ipv6 2000::/3"
tun-ipv6

И на клиенте — не забудьте redirect-gateway, чтобы весь IPv6-трафик тоже шёл через туннель:

redirect-gateway def1 ipv6

Без этой строки OpenVPN поднимет IPv6-интерфейс, но не заставит систему направлять через него весь трафик — и утечка сохранится, просто через сам VPN-интерфейс с неверным адресом, что ещё запутаннее для диагностики. Если у вас уже есть развёрнутый OpenVPN и он не завёрнут под IPv6, дешевле пересобрать конфиг заново, чем патчить существующий, — велика вероятность разъехавшихся маршрутов.

Если сервер не имеет собственного IPv6

Не все хостинги по умолчанию выдают VPS блок IPv6-адресов. Если у сервера нет IPv6 вовсе, самый простой вариант — не пытаться туннелировать несуществующий IPv6 наружу, а просто заблокировать IPv6 на клиенте (раздел выше) либо арендовать VPS у провайдера, который сразу даёт IPv6-подсеть в комплекте — это снимает вопрос на уровне инфраструктуры, а не костыля на клиенте.

Отдельный случай: мобильный интернет и IPv6-only сети

Часть операторов, особенно в мобильных сетях, уже работает по схеме IPv6-only с механизмом трансляции (NAT64/DNS64) для доступа к IPv4-ресурсам. Здесь ситуация зеркальная: у устройства нет собственного «настоящего» IPv4, весь трафик изначально IPv6, и если VPN-клиент на телефоне не умеет корректно туннелировать IPv6, вы рискуете вообще потерять доступ в интернет через VPN, а не просто «протечь» регионом.

Признак: VPN подключается, статус показывает «Connected», но сайты не грузятся вовсе, либо грузятся с задержкой в несколько секунд (после отката на IPv4 через NAT64). Если сталкивались с полным отсутствием интернета через WireGuard, у нас есть отдельный разбор в статье «WireGuard: нет интернета через VPN — причины и решение».

Проверка после настройки: убедитесь, что течь закрыта

После того как вы либо отключили IPv6, либо настроили его туннелирование, обязательно проверьте результат заново — не полагайтесь на то, что конфиг «выглядит правильно».

Порядок проверки:

1. Отключите VPN, зафиксируйте текущий публичный IPv6 (если он есть) через curl -6 https://ifconfig.co.
2. Включите VPN.
3. Повторите curl -6 https://ifconfig.co — если IPv6 отключён, команда должна вернуть ошибку соединения (это нормально и означает, что leak закрыт). Если IPv6 туннелируется — адрес должен смениться на адрес VPN-сервера или пропасть, но точно не совпадать с исходным.
4. Дополнительно откройте сервис ИИ, к которому раньше был ограничен доступ, и убедитесь, что он не показывает сообщение о регионе.

Таблица для быстрой сверки состояний:

Если после настройки IPv6 в VPN сайты определяют регион всё равно, проверьте, не подключено ли одновременно два VPN-профиля или конфликтующих туннеля — это отдельная частая причина, разобранная в статье «Второй туннель на телефоне: конфликт VPN, как решить».

Частые вопросы