Поднял себе сервер за границей, настроил, всё летает. Зарубежные сайты открываются, скорость нормальная, можно жить. А потом маркетплейс начинает показывать капчу на каждое движение, банк отказывает в операции, сайт объявлений выдаёт пустую страницу.
Часть российских сервисов не пускает с зарубежных и серверных адресов. В комментариях на это отвечают одинаково: тебе нужен российский IP, сделай обратный впн. Так эту задачу и называют — обратный впн, или впн наоборот. Дальше идут разные рецепты, человек берёт первый попавшийся, и как повезёт.
Я собрал их у себя и посмотрел не на описания, а на то, что о вашем адресе реально видно снаружи. Выяснилось, что «российский IP» — это не одно свойство, а три разных, и рецепты закрывают их по-разному. Полностью закрывает только один, и он единственный, чей выход стоит не в сети хостера.
Где я мерил сам, а где опирался на чужую документацию, отмечено по тексту.
Начните с того, что видно о вас
Не с рецептов. Сначала посмотрите на собственный адрес — дальше вся статья читается как разбор того, что вы увидели.
Разбираться стоит по порядку, и порядок такой:
-
какой адрес и какой версии протокола реально вышел наружу;
-
чей это выход — хостер, провайдер, чья автономная система;
-
как этот адрес классифицируют базы;
-
и только потом — пускает ли вас конкретный сервис.
Первые три шага вы делаете сами и получаете данные. Четвёртый узнаётся только попыткой, и никакая команда его не предскажет.
Шаг 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, это не значит «вы не дата-центр»: скорее всего база про ваш диапазон просто не знает, а возможно, у неё другая методика. Проверять стоит не одной базой.
Границы замера, чтобы числа не соврали: адрес брался из анонсируемого диапазона хостера, а не из пула, куда попадают конкретные клиентские машины. То есть мерилась классификация диапазона — она в таких фильтрах и используется, но это не то же самое, что арендовать сервер и посмотреть. Ещё два диапазона пришлось отбросить: они анонсировались под вывеской российского хостера, а по обеим базам оказались американским и белорусским. Тот же тезис в миниатюре: принадлежность хостера не равна стране адреса.
Сводка по выходам
|
Точка выхода |
|
|
|
|---|---|---|---|
|
Зарубежный 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/