VPN с российским IP: что о вашем адресе видно на самом деле

от автора

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

Часть российских сервисов не пускает с зарубежных и серверных адресов. В комментариях на это отвечают одинаково: тебе нужен российский IP, сделай обратный впн. Так эту задачу и называют — обратный впн, или впн наоборот. Дальше идут разные рецепты, человек берёт первый попавшийся, и как повезёт.

Я собрал их у себя и посмотрел не на описания, а на то, что о вашем адресе реально видно снаружи. Выяснилось, что «российский IP» — это не одно свойство, а три разных, и рецепты закрывают их по-разному. Полностью закрывает только один, и он единственный, чей выход стоит не в сети хостера.

Где я мерил сам, а где опирался на чужую документацию, отмечено по тексту.


Начните с того, что видно о вас

Не с рецептов. Сначала посмотрите на собственный адрес — дальше вся статья читается как разбор того, что вы увидели.

Разбираться стоит по порядку, и порядок такой:

  1. какой адрес и какой версии протокола реально вышел наружу;

  2. чей это выход — хостер, провайдер, чья автономная система;

  3. как этот адрес классифицируют базы;

  4. и только потом — пускает ли вас конкретный сервис.

Первые три шага вы делаете сами и получаете данные. Четвёртый узнаётся только попыткой, и никакая команда его не предскажет.

Шаг 1: какой адрес вышел наружу

Подключитесь к своему VPN и спросите об этом обе версии протокола отдельно:

curl -4 -s ifconfig.me; echocurl -6 -s ifconfig.me; echo

Первая команда покажет ваш адрес IPv4. Вторая — IPv6, если он у вас есть. Пустой вывод второй команды и есть ответ: IPv6 наружу не ходит, и это упрощает вам жизнь. Почему это важно, объясню чуть ниже.

Шаги 2 и 3: чей это адрес и что о нём думают

curl -s "http://ip-api.com/json/?fields=query,country,isp,as,proxy,hosting"

Без адреса в запросе сервис отвечает про вас. Запрос идёт по http, а не https: на бесплатном тарифе шифрованный отдаёт пустой ответ, и если «поправить» схему, получите непонятный отказ. По открытому каналу ответ можно подменить по дороге, так что это индикатор, а не доказательство, — для первого взгляда достаточно, а перепроверить всегда можно из браузера.

Поля isp и as закрывают второй шаг — показывают, кому принадлежит выход. А дальше идут три, ради которых всё и затевается:

  • country — страна, к которой отнесён ваш адрес;

  • hosting — опознан ли адрес как принадлежащий дата-центру;

  • proxy — опознан ли как VPN, прокси или релей.

Чем эти поля не стоит считать. Это три удобные категории для первичной диагностики, а не модель того, как сайт принимает решение. Поля берутся из базы одного поставщика; они могут быть выведены из одного и того же номера автономной системы, а сайт может вместо трёх проверок считать единый балл риска. Чем пользуется конкретный сервис, снаружи не видно. Категории полезны тем, что описывают ваш адрес языком, на котором такие фильтры вообще разговаривают.

И сразу граница: дальше речь только про адрес. Антифрод смотрит ещё на устройство, поведение и историю операций, так что адрес — лишь один из факторов. Зато единственный, на который вы влияете настройкой.

Если хочется сразу ответ, а не разбор — таблица выбора в разделе «Какой выход выбрать под вашу задачу». Но она будет понятнее после замеров.

Всё описанное делит IPv4

Это надо сказать до таблиц, а не после. Ни одна из схем ниже не делит IPv6, и документация обеих это оговаривает прямо. Списков там два разных: каскад берёт снимок российских сетей (8626 записей, ни одной IPv6 — проверил у себя в репозитории), а схема с WARP получает свой по BGP от стороннего сервиса, около 11800 диапазонов. Совпадать они не обязаны, но IPv6 нет ни в том, ни в другом.

Практически: если у сайта есть AAAA-запись, а у вас включён IPv6, сайт увидит совсем другой адрес, чем тот, который вы только что продиагностировали. Один человек из обсуждений проекта на этом застрял надолго: адреса разрешались в IPv6, шли мимо туннеля напрямую, правки списков ни на что не влияли, а на телефоне проблема не воспроизводилась.

Что с этим делать. Если вторая команда из шага 1 вернула адрес, у вас есть выход по IPv6, и он идёт мимо всего описанного ниже. Варианта два: отключить IPv6 на устройстве (тогда весь трафик пойдёт по IPv4 и схемы заработают предсказуемо) или держать в голове, что для сайтов с AAAA-записью диагностика выше не про тот адрес. Серверная сторона тут не поможет: прямой IPv6-трафик до вашего сервера просто не доходит.


Что базы говорят о каждом выходе

Дальше я прогнал ту же команду по адресам всех вариантов. Вывод сокращён до нужных полей. Все замеры ниже сделаны в начале августа 2026 — для таких данных это важно, они меняются.

Контроль первый — обычный VPS у зарубежного хостера, то есть ровно то, что у вас сейчас:

{"country":"United States","proxy":true,"hosting":true}

Плохо по всем трём: страна чужая, дата-центр опознан, анонимайзер опознан.

Контроль второй — домашняя линия российского провайдера:

{"country":"Russia","proxy":false,"hosting":false}

Чисто по всем трём. Дальше буду называть это эталоном — с оговоркой, что проверял я конкретные адреса конкретных провайдеров, а не «домашние адреса вообще»: домашние, мобильные и адреса за общим провайдерским NAT тоже получают свои метки, просто другие.

Выход через Cloudflare WARP. Чтобы проверить, насколько классификация вообще устойчива, дальше беру две независимые базы:

ip-api.com:   {"org":"Cloudflare WARP","proxy":true,"hosting":false}ipapi.is:     {"is_datacenter": true}

Один и тот же адрес: одна база говорит «не дата-центр», другая — «дата-центр». А метка анонимайзера у той базы, команду которой я дал выше, стоит — и это главное, что стоит запомнить про WARP.

Российский хостинг. Тут двумя адресами не отделаешься, потому что расхождение баз оказалось системным. Я взял 14 российских хостеров, у которых частное лицо реально арендует VPS, вытащил их анонсируемые диапазоны и прогнал 78 диапазонов через обе базы.

  • та база, команду которой я дал выше, помечает дата-центром 63% диапазонов;

  • вторая — 91%;

  • хотя бы одной помечены 77 из 78;

  • а согласны между собой они лишь в 56% случаев, причём расходятся в обе стороны.

Отсюда формулировка, которая точнее интуитивной: на моей выборке признак дата-центра у российского VPS есть почти всегда, но какая база его видит — лотерея. Если ваш сервер показывает hosting: false, это не значит «вы не дата-центр»: скорее всего база про ваш диапазон просто не знает, а возможно, у неё другая методика. Проверять стоит не одной базой.

Границы замера, чтобы числа не соврали: адрес брался из анонсируемого диапазона хостера, а не из пула, куда попадают конкретные клиентские машины. То есть мерилась классификация диапазона — она в таких фильтрах и используется, но это не то же самое, что арендовать сервер и посмотреть. Ещё два диапазона пришлось отбросить: они анонсировались под вывеской российского хостера, а по обеим базам оказались американским и белорусским. Тот же тезис в миниатюре: принадлежность хостера не равна стране адреса.

Сводка по выходам

Точка выхода

country

hosting

proxy

Зарубежный VPS (как сейчас)

чужая

да

да

Домашняя линия в России

Russia

нет

нет

Сеть Cloudflare через WARP

страна вашего сервера

у баз по-разному

да

Российский хостинг

Russia

почти всегда да

обычно нет

Каскад, российское плечо

Russia

почти всегда да

обычно нет

Каскад, зарубежное плечо

чужая

да

да

Каскад в таблице занимает две строки не для красоты: у него два выхода, и российские сайты видят одно, а зарубежные — другое. Дальше это ещё пригодится.

Чистая по всем трём полям строка ровно одна — домашняя линия. Серверный выход почти всегда оставляет след: в моей выборке из 78 российских диапазонов не помечен вообще никем ровно один, и рассчитывать, что вам достанется именно он, не стоит. Это не повод не пользоваться серверами, это повод заранее знать, что именно останется видно.

Здесь и видно, почему «дай мне российский IP» — запрос неточный. Российских адресов в таблице три, и для фильтра они выглядят по-разному.


Почему это случилось именно с вами

Две вещи, которые стоит понимать про исходную ситуацию.

Первое: скорее всего вы ничего не настраивали неправильно. У типовой установки российский трафик идёт в туннель по умолчанию. Список, который выдаётся клиенту, — это весь публичный IPv4 за вычетом приватных диапазонов; российские сети из него не исключены. То есть с этим может столкнуться любой, кто поднял сервер за границей и оставил настройки как есть, а не только любители экзотики.

Второе: от вашего физического местоположения зависит, что вам вообще доступно.

Если вы в России, эталонный адрес у вас уже есть — домашний. Задача сводится к тому, чтобы нужный трафик до него доходил, а не уезжал в туннель.

Если вы за границей, своей российской домашней линии у вас нет. Но взять её не «неоткуда»: если есть кому поставить небольшую коробку на домашнюю линию в России, эталонный выход становится доступен и вам. Цена у этого своя, разберу ниже.


Четыре выхода и что каждый меняет

Дальше речь не про рецепты, а про точки выхода: рецепт лишь способ на нужную точку попасть.

Выход 1. Домашняя линия

Единственный, дающий чистые все три поля. Попасть на него можно двумя путями.

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

Насколько весь, посчитал: взял агрегированный список российских сетей из своего репозитория (8626 сетей) и вычел его из 0.0.0.0/0. Получилось 21615 записей, строка AllowedIPs весит около 348 килобайт. Технически работает; практически конфиг перестаёт быть конфигом — в QR-код не превращается, глазами не проверяется, на телефон переносится только файлом, а список стареет с первого дня.

И цена, о которой обычно молчат: трафик, выведенный из туннеля, идёт мимо VPN целиком. Провайдер видит, куда вы обращаетесь, работает его DNS. Для российских сайтов это ровно то, чего вы и хотели, но выбор должен быть осознанным.

Так что обратный список — это измеренная цена подхода «делим по сетям», а не единственный вариант. Практически работают два других, и оба проще.

Перевернуть список. Он огромен только потому, что перечисляет то, что НЕ идёт в туннель. Перечислите то, что идти должно, — получится несколько строк вместо 21615. В установщике это отдельный режим (--route-custom), и он подходит, когда в туннеле нужна горстка адресов, а не «весь интернет кроме России».

Готча, без которой рецепт ломается: в кастомный список надо руками добавить подсеть самого туннеля. Без неё перестаёт маршрутизироваться трафик к собственному серверу, а выглядит это как отказ фаервола: ufw status показывает всё правильно, а ping не идёт.

Отдать деление клиенту. Ответ тут обратный интуитивному. Приложение AmneziaVPN умеет делить трафик по сайтам само, но включает эту функцию, только если конфиг гонит в туннель весь трафик: частичный список подсетей оно считает уже разделённым на уровне маршрутов и переключатель прячет. То есть AllowedIPs надо не сужать, а наоборот поставить полный туннель — и дальше задавать исключения по именам сайтов в самом приложении, без списка на 348 килобайт. Если вы видели надпись «сервер не поддерживает раздельное туннелирование», причина именно в этом, и сервер тут ни при чём.

Оговорки две. Это функция конкретного приложения, а не свойство протокола. И список сайтов вы ведёте руками: для типовой задачи «сломались маркетплейс, банк и доска объявлений» это три-четыре домена, но заменой списку на 8626 сетей оно не станет.

Если вы за границей — нужен узел на домашней линии в России: небольшой мини-ПК, старый ноутбук или подходящий роутер у кого-то, кто согласится его включить. Тогда ваш выход к российским сервисам получает свойства домашней линии, а не хостинга.

Честная цена: нужен человек и линия там; аплинк домашний и узкий; надёжность тоже домашняя — свет, роутер, переезд; белый адрес выдают не все провайдеры; и не всякий провайдер такое приветствует. Зато по трём полям это единственный из проверенных мной выходов, который в базах не отличается от обычного домашнего подключения.

Выход 2. Сеть Cloudflare через WARP

Сервер сам знает, какие адреса российские, и отправляет трафик к ним другим выходом. Список приезжает по BGP от стороннего сервиса и обновляется без участия человека — на моём стенде в июле это было около 11800 диапазонов. Вторым выходом служит Cloudflare WARP, поднятый на сервере обычным WireGuard-интерфейсом.

По замерам выше признак дата-центра снимает лишь одна база из двух, а метка анонимайзера сохраняется — у зарубежного VPS она и так стояла. Со страной хуже: Cloudflare подбирает её под страну того, кто подключается, а подключается ваш сервер, поэтому метка будет его страны. Своего замера с заграничного стенда у меня нет, механизм взят из документации Cloudflare, — но по ней российского адреса эта схема дать не может.

Если вы встречали отзывы «включил WARP, и все российские сервисы открылись», посмотрите, откуда человек его включал. В тех, что попадались мне, WARP поднимался с устройства внутри России, у которого и метка страны российская. На схему с заграничным сервером такой опыт не переносится.

Отдельно про режим отказа, он неочевидный. Если пир WARP перестал отвечать, а интерфейс на сервере остался поднятым, маршруты продолжат вести в никуда: российские сайты не открываются вообще, зарубежные работают как ни в чём не бывало, а мониторинг BGP-сессии показывает, что всё хорошо. Поэтому проверять надо не сессию, а проходимость:

curl --interface warp https://api.ipify.org

Нет ответа — второй выход мёртв. Быстрое лечение: остановить интерфейс, маршруты уйдут вместе с ним и трафик вернётся на прямой выход.

Выход 3. Российский хостинг

Если вы за границей и вам нужен только доступ к российским сервисам, а зарубежный выход не нужен, никакого каскада не требуется. Хватит одного VPS в России: подключаетесь к нему, и весь трафик выходит с российского адреса.

По полям это country: Russia, метка анонимайзера обычно снята, а признак дата-центра остаётся — см. замер выше. Дёшево и просто, но зарубежный выход вы теряете.

Выход 4. Два выхода сразу, каскад

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

Из описанных это единственная схема, дающая российский адрес без потери зарубежного выхода. Признак дата-центра остаётся: вход каскада — тот же российский хостинг, и каскад его «серверность» не снимает.

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

Почему российский сайт может оказаться вне российского списка

Когда при каскаде российский сайт всё равно не открывается, первая версия обычно звучит так: его адреса нет в списке. Проверил 36 популярных сервисов, 50 адресов — от Госуслуг, банков и маркетплейсов до новостных сайтов и операторов связи. В списке 48 из 50, и оба недостающих адреса принадлежат одному домену.

Этот единственный промах интереснее самой проверки. gismeteo.ru в списке нет, хотя база считает его адреса российскими.

Дело в устройстве списка, и это проверяется одной командой. Страновые зоны собираются не из геобаз и не из whois, а из статистики распределения адресов, которую публикуют региональные регистраторы: там записана только верхнеуровневая выдача диапазона участнику, без внутренних назначений внутри неё. Смотрим, кому выдан диапазон, в который попадают адреса gismeteo:

curl -s https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest | grep '|31.172.64.0|'
ripencc|ES|ipv4|31.172.64.0|4096|20110401|allocated|...

ES. Выдача испанская, поэтому весь диапазон в российскую зону и не попадает — при том что внутреннее назначение на /24 помечено как российское и геобаза честно отвечает country: Russia. Соседние выдачи в том же файле идут под RU и в моём списке лежат уже слитыми в один агрегат: виден весь путь от регистратора до строчки в файле.

Практический вывод для диагностики: если сайт российский, а через каскад уходит не туда, смотрите не на геолокацию его адреса, а на то, кому выдан диапазон.

Границу назову честно: я проверил, что в статистике распределения этот диапазон числится за испанской организацией и что в зоне его нет. Чем именно питается конкретный список, этим файлом или его производной, я не проверял.


Какой выход выбрать под вашу задачу

Сводка по тому, зачем вам российский IP и что за него придётся отдать.

Ваша ситуация

Выход

Серверов

Что останется видно

Вы в России, российские сайты сломались

домашняя линия, исключение из туннеля

0 дополнительных

ничего, поля чистые

Вы за границей, нужен вид обычного пользователя

узел на домашней линии в России

коробка там

ничего, но нужен человек и линия

Вы за границей, нужен только российский доступ

российский хостинг

1 вместо прежнего

признак дата-центра

Нужны оба выхода сразу

каскад

2

к российским сайтам — признак дата-центра; к зарубежным всё как было: чужая страна, дата-центр, анонимайзер

Второго сервера не хочется, а попробовать надо

WARP по фиду

1, тот же

страна остаётся чужой; метка анонимайзера остаётся; признак дата-центра — как повезёт с базой

Последняя строка нуждается в оговорке, потому что интуитивно от WARP ждут большего. Он не делает вас похожим на домашнего пользователя и российского адреса не даёт вовсе. Поэтому это вариант «дёшево попробовать, вдруг именно ваш сервис смотрит на принадлежность диапазона хостеру», а не решение задачи.

Проверить результат можно теми же командами из первого раздела: они покажут, какие метки у вас появились после переделки. Что с этими метками сделает конкретный сервис, заранее не скажет никто — это выясняется попыткой.


Где я ошибся, пока это собирал

Считал, что каскад решает всё. Российский адрес получен — задача закрыта. Пока не прогнал команду по адресам российских хостеров и не увидел, что признак дата-центра никуда не делся. Каскад чинит страну, а не «серверность», и я объяснял людям схему, ни разу не проверив это измерением.

Форма подписки на BGP-фид подставила мой же выходной адрес. Чтобы сервис начал отдавать список, на его странице надо зарегистрировать адрес сервера. Поле IP страница заполняет сама — адресом того, кто её открыл. Я смотрел её через собственный VPN, и туда подставился адрес совсем другой машины. Заметил случайно. Вывод скучный: любое поле, заполненное за вас, надо перечитывать перед отправкой.

Неправильно измерил поведение при аварии. Схема должна деградировать безопасно: демон маршрутизации умер, маршруты сняты, трафик вернулся на прямой выход. Убил процесс сигналом, увидел ровно то, что ожидал, — и ошибся. Systemd поднял демон обратно за несколько секунд, так что я смотрел на окно перезапуска, а не на отказ. Чистая проверка дала обратное: при аварийном завершении маршруты остаются, ядро не связывает их с жизнью процесса, и список просто застывает.

Вывод: если результат замера совпал с ожиданием, это повод перепроверить, а не повод радоваться.


Что с AmneziaWG 3.0

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

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

Про саму третью версию и что учесть при переходе написано отдельно в документации проекта — ссылка в конце.


Кому спасибо и куда смотреть дальше

Серверные схемы придумал не я. Каскад из двух серверов принёс glfenix. Идею взять Cloudflare WARP вторым выходом первым назвал kantnm, а выборочной по BGP-фиду её сделал alexfiu4-cyber. Все трое — из обсуждений проекта на GitHub. Я обе схемы собрал у себя, нашёл в них по паре мест, где инструкция расходится с реальностью, и оформил в документацию, чтобы не терялись в переписке.

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

Если у вас получилось иначе, напишите в обсуждениях.

Каскад из двух серверов, со скриптом и разбором граблей: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md

Пошаговая сборка того же каскада, если хочется по шагам: https://habr.com/ru/articles/1056220/

Второй выход через WARP и BGP-фид, целиком: https://github.com/bivlked/amneziawg-installer/blob/main/WARP-RU.md

Режимы маршрутизации, AllowedIPs и раздельное туннелирование в клиенте: https://github.com/bivlked/amneziawg-installer/blob/main/ADVANCED.md#allowedips-adv

Что нового в третьей версии AmneziaWG и что учесть при переходе: https://github.com/bivlked/amneziawg-installer/blob/main/ADVANCED.md#awg3-adv

Сам проект, установщик и управление клиентами: https://github.com/bivlked/amneziawg-installer

ссылка на оригинал статьи https://habr.com/ru/articles/1067230/