Обновить

Прозрачный VPN на роутере: VLESS + Reality + TPROXY на OpenWrt от А до Я

Уровень сложностиСложный
Время на прочтение27 мин
Охват и читатели31K
Всего голосов 48: ↑46 и ↓2+51
Комментарии72

Комментарии 72

Пробовал похожую тему с tproxy..правда не vless а другой протокол..в итоге были две проблемы ..перехват трафика в raw и зависающие сессии .. Потом перешёл с tproxy на tun..и стало лучше )

У меня схема отличается - я не использую raw вообще, у меня TPROXY через nftables в mangle/prerouting + policy routing.

Сессии не висят: Xray стабильно принимает соединения и маршрутизирует (и direct, и proxy), это видно по логам.

Так что, скорее всего, у тебя проблема была в конкретной реализации (raw/маршрутизация/loop), а не в TPROXY как таковом :)

Вполне возможно) реализация была адовая просто)

Да боже мой...
Статья очередной нейрослоп.
Сравнения, противопоставления, выводы, разрыв повествования, отсутствие структуры, ни одного скриншота.
А куда ставиться пакеты? А по какому пути лежат конфиги? Где команды для редактирования их?
А "Проверка что всё работает" вообще гениален. Никто и никогда в виде "кода" выкладывать набор команд, да еще с комментариями не будет.

ps пишу под первым комментовм чтобы мой комментарий увидели побольше читающих.

Если бы вы дочитали статью, то увидели бы и пути, и команды: /etc/xray/config.json, /etc/init.d/xray-tproxy, /etc/hotplug.d/iface/99-xray-fix, /usr/bin/adguardhome, nft list table ip xray, ip rule show - это всё там есть.

Скриншоты для SSH/nftables-конфига тут не обязательны: важнее рабочие команды и понятная схема. Если нужен формат «одна кнопка и всё само», то это просто не тот жанр статьи.

Ага части конфига /etc/xray/config.json размазаны рандомно по всей статьи, а путь конфига указан только в файле Init скрипта
А по ответу мне кажется что и ИИ бот отвечает :)
ps А как на вашем роуторе пожарить яичницу? :)

Путь к конфигу есть в статье, просто он не вынесен в отдельный “список путей”, а показан там, где это нужно по смыслу.

Статья - не справочник по OpenWrt, а разбор рабочей схемы. Поэтому конфиг, init-скрипт, nft и диагностика разбросаны по соответствующим разделам, а не сведены в один блок ради галочки.

Про “ИИ-бота” удобно писать, когда не хочется читать внимательнее.

А яичницу на этом роутере, к сожалению, не жарю :)

Я воспользовался поиском и путь где находлится config.json указан ровно в одном месте, в инит скрипте.
А настройки которорые в нем содержатся начинаются с самого начала статьи, с заголовка "Конфиг Xray: разбор по частям", сразу как установили пакеты, но узнаем где же этот конфиг находится мы из скрипта запуска, все очень логично

Боже мой, какие нафиг скриншоты (ещё бы в ворд их предложили вставить)??? Текст и только текст, который легко скопировать, сохранить, переписать, а не голимый скриншот непонятно чего непонятного качества, который завтра на хостинге протухнет и ищи-свищи, чего там было «выставляем галочки как на скриншоте».

Вы настраивали на роуторе что-нибудь похожее как в статье?
Вот возьмите статью и читая ее и пользуюсь информацией из нее попробуйте настроить.
Не прочитать и положить на полочку, а прочитать и по статье настроить.
Сразу поймете что с статьей чтото не так, информации нахватает, огромная часть информации о настройки, о действияфх с роутерами, с конфигами, почему это так просто отсутствует.
Я думаю на этапе прошивки возникнут вопросы (на точно таком же роуторе), так как роуторы Cude шьются на openwrt через переходную прошивку насколько помню.

 

В статье есть отдельный блок про прошивку, включая переходную firmware и sysupgrade, как раз под Cudy TR3000.

Если на этом этапе «возникают вопросы», значит дело не в отсутствии информации, а в том, как читается статья.

Ну так и скажите конкретно, чего не хватает. А не серчайте на отсутствие скриншотов. У меня нет роутера, который бы я мог настроить по этой статье, но как появится, я ей воспользуюсь.

Про переходную прошивку в статье сказано. И какую надо брать тоже. Вы бы сами ещё раз её внимательно перечитали, м? Но статья не про прошивку роутера, ей простительно. А то мы докатимся до того, что будем обсуждать, где: на Озоне, в DNS или на каком-нибудь Али этот роутер лучше купить.

Я на ВБ заказывал, если интересно :)

Но да, сделаю вторую часть: разложу спорные моменты подробнее и учту комментарии.

Изначально статья была про саму схему (TPROXY + Xray + routing), а не про полный гайд «с нуля до продакшена», поэтому какие-то вещи оставил за рамками.

REDIRECT (DNAT) — подменяет адрес назначения на 127.0.0.1:порт. Проблема: оригинальный адрес теряется. 

Вообще-то нет. Точно не знаю как оно работает, но проходит любой TCP трафик. Ядро как-то сохраняет оригинальный адрес и передаёт xray. Для UDP трафика почему-то не работает и нужен tproxy

Он не «сохраняется сам».

При REDIRECT адрес реально теряется (DNAT на 127.0.0.1), а то, что у тебя работает с TCP - это либо sniffing (SNI/Host), либо SO_ORIGINAL_DST. Это не универсально.

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

Да нету у меня сниффинга

iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 10

sing-box redirect inbound видит айпи адрес любого tcp протокола, xray тоже, нормальная универсальность. Если нужен только TCP то настраивается в 10 раз проще чем tproxy (можно прямо из веб интерфейса openwrt добавить правило).

*

Скорее всего у тебя это через SO_ORIGINAL_DST работает, а не потому что ядро само «сохраняет адрес».

С REDIRECT это в целом ок для TCP, но всё равно не совсем универсально и зависит от реализации. Поэтому TPROXY обычно используют, когда нужна более предсказуемая прозрачная схема.

"network": "tcp"

Я думаю 90% читателей будут ожидать проксирование и UDP трафика в том числе. А тут такая подстава.

Кстати QUIC блочат даже при рабочем UDP в целях увеличения производительности vless:

  1. Xtls не делает двойное шифрование https трафика, т.е. quic трафик будет жрать ресурсы проца на шифрование

  2. Quic имеет свой congestion control, ваш прокси сервер тоже, получается два congestion control что даёт производительность ниже

  3. UDP over TCP потребляет больше ресурсов проца

Тут только TCP сделан специально.

QUIC (UDP 443) я режу, чтобы весь трафик уходил в TCP и нормально проксировался. UDP в прозрачной схеме - отдельный уровень сложности.

Так что это не «подстава», а осознанное решение :)

я и так из статьи понял зачем вы блокируете quic. здесь речь не о вас, а о читателях.

напишите в самом верху что весь UDP трафик пропущен напрямую.

и вообще, вроде бы не хватает 1 строчки nft чтобы UDP проксился, но точно не уверен

*

Да, хорошее замечание, можно это явнее подчеркнуть, позднее сверху помечу про UDP, спасибо :)

Но также замечу, что там не совсем «1 строчка»: для UDP нужно ещё inbound в Xray, отдельные правила и нюансы с тем же QUIC. Я поэтому решил не усложнять и оставить только TCP.

для UDP нужно ещё inbound в Xray

network: tcp поменять на network: tcp,udp или вообще убрать строчку, по дефолту вроде оба слушает. quic как блокировался так пусть и блокируется (ниже писал почему)

Спасибо, подумаю над этим

Транспорт — чистый TCP (не WebSocket, не gRPC). TCP даёт минимальную задержку и не добавляет лишних заголовков.

а так же даёт потенциальную сибирскую блокировку (моя последняя статья), стоило бы добавить что лучше иметь в запасе gRPC траспорт (из-за встроенного мультиплекса).

кстати TCP транспорт так-то не даёт минимальную задержку, тратится много времени на tcp и tls хендшейки, если впска где-то далеко в США, то это очень заметно (ещё одна причина быть фанатом протоколов с мультиплексом, хотя там есть минусы)

Да, тут согласен - TCP не серебряная пуля, особенно если сервер далеко, хендшейки начинают чувствоваться.

Я скорее имел в виду, что TCP без WS/gRPC даёт минимальный оверхед в рамках самой схемы (без лишних слоёв), а не вообще минимальную задержку в любых условиях.

Про запасной транспорт тоже хорошее замечание :)
gRPC/WS с мультиплексом действительно могут быть полезны как fallback, особенно если начинаются блокировки или высокий RTT, спасибо, добавлю это в схему позднее

P.S. из практики: основная проблема, с которой столкнулся - забивающийся overlay.

В итоге вынес Xray и AdGuard в /tmp, а при загрузке разворачиваю их из архивов через init-скрипт и запускаю. Так удалось разгрузить overlay и всё работает стабильно.

Простите, не могу не написать)

телевизор вообще не умеет в VLESS

умеет

колонка — тем более

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

У меня Яндекс Алиса с выходом на TV, которая поддерживает ютуб. Но при этом с момента блокировки ютуба она не смогла загрузить мне ни одного видео толком. Теперь может :)

Ааа. Тогда логично. Я подумал у вас Станция без видео и ТВ/приставка на Android TV.

Судя по роутингу, запрос 2ip.io выдает адрес впн, и любой подключенный к роутеру телефон с максом может спокойно слить ip. Лучше роутинг "перевернуть" и geosite:ru-blocked заворачивать в впн, а по умолчанию сделать путь в директ. Хотя лучше не лениться и прописать категории нужных сайтов руками (geosite:youtube, geosite:telegram и т.д.). Вдруг список geosite:ru-blocked просто бесконечно разрастается и старые адреса никто не проверяет, и ушлый ркнщик найдет уже неиспользуемый домен из этого списка и запилит на нем ip чекер? А приложения встроят к себе обращения на него, и поймают всех с простым роутингом geosite:ru-blocked -> vpn. Он конечно может и новый домен создать и заблокировать, но вроде при добавлении в geosite:ru-blocked есть какая-то модерация сообществом? И свежий ноунейм сайт надеюсь не пропустят

Да, замечание справедливое :)

У меня сейчас действительно схема proxy-by-default, так что любой домен, который не вынесен в direct, может уйти через VPN - в том числе и 2ip-подобные сервисы. Для более строгого privacy-first подхода логичнее делать default direct и отдельно перечислять нужные категории.

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

Отличный гайд. Но я не могу пока придумать решение против активного пробинга по разным ip со стороны МАХ и т.п. И я пока перестал маршрутизировать трафик на роутере, пока не найдется решение. Поставил ip MAX в блок, домашних научил выключать wifi, если нужен MAX

У меня все телефоны, на которых стоит МАХ, имеют фиксированный IP и маршрутизируются по нему в direct. А следующее правило - блокировка МАХ, как и у вас.

на компьютере в браузере сайты озона-валбериса и т.д. не открываете? Там тоже может присутствовать несложный js который сделает пару запросов к сайтам и отправит оба ip в базу пользователей квн.

Мужчина, можно у вас роутер со всем этим купить? :)

Предложение, кстати, на полном серьёзе.

Это как-то разом можно накатить на новый роутер или каждый раз руками ставить?

А то готовая бизнес-идея.

Понятно - до первого не штатного случая (там разберемся).

Пока что это недокрученный "набор шагов", скорее, но вполне реально реализовать автоустановку всей системы "из коробки".
Поэтому давайте я отлажу эту систему до идеала, так как много полезных советов получил от коллег в комментариях, и после уже спишемся с вами и обсудим ваш вопрос более подробно :)

Тоже приобрел бы готовый комплект -)

На Авито подобного добра навалом.

Вот не поверите - реально всю текущую неделю именно на Авито искал роутер под работу блок-сайтов.

Пообщался, наверное, с 12-15 продавцами.

Из них 2-ое в теме (на мой взгляд).

Один прям достаточно глубоко в теме (но явно проигрывает автору этой статьи).

Остальные продавцы - полное ощущение - по какому-то гайду прошивку накатили и дальше кто во что горазд.

Глубокого понимания нет (я сам для себя тоже и WireGuard и Amnesia по "букварю" поставлю - но глубокого понимания нюансов у меня нет).

Я к чему - предложений такого уровня (читаю и перевожу со словарем) - много и я сам примерно так и могу.

А вот некая система с подходом как выше - такое редко вижу.

Со своей стороны я это называю "профессионализм" и готов за это платить.

При этом и у меня (а главное - у автора) есть понимание, что может у него и не идеальное Retail-издание, но он слушает и слышит - готов следовать дельным советам.

Поэтому - я за такое бы платил.

Ничем не хуже скилла "заменить смеситель", "установить розетки/УЗО", "сварить кофе вкусно".

Точно стоит денег.

Конкретно за модель Cudy TR3000, которая упоминается в статье, есть даже целые видео-обзоры, к которым приложены ссылки на готовые прошивки. Прошить сам аппарат несложно, хоть и какие-то знания для этого нужны. Другое дело, насколько эти прошивки в плане ошибок обкатаны. Я списывался с человеком, который сейчас допиливает OpenWrt под этот аппарат. Недавно он мне написал, что выловил следующий баг - "при отсутствие интернета V2rayA перезапускается и пишет лог, после заполнения лога, роутер выходит в режим аварии на низком уровне, переходит в режим “кирпич”.

По этому готовые решения не всегда подойдут. Если в них нет ошибок (а если есть?), то можно покупать готовое.

Сам жду TR3000. Буду пробовать. Если с vless на уровне роутера сложно, то для того же СмартТВ можно прикрутить ТВ-приставку на Android и туда накатить клиенты V2ray (и много чего ещё) и раздавать по кабелю уже с неё на ТВ. Я так около года смотрел Тюбик (без рекламы, бесплатно) на СмартТВ. На ПК тоже есть свои клиенты, на свою довольно-таки старую Windows 7, да ещё с поломанным .NET Framework, смог найти клиент. Недавно купил Mesh-систему Cudy M1200, в ней протокол WG работает из коробки, СмартТВ показывает и таким образом, даже меньше кнопок нажимать перед просмотром. Приставка теперь не нужна. Решил с роутером эксперимент провести.

Да, готовые решения есть, но там главный вопрос - насколько они понятны и поддерживаемы.

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

А так да, через приставку или клиенты на устройствах тоже вполне рабочий вариант, просто менее централизованный.

Идете на озон, заказываете Routerich AX3000, он там 5к стоил. В нем уже с завода настроен WARP и Opera Turbo, стоит Zapret 2 и ZeroBlock. AWG, кстати, тоже.
Все, можно смотреть, хоть и медленно.
Если хотите не медленно - покупаете у той же amnesia премиум-ключ - смотрите быстро. Все в веб-интерфейсе, с подробными инструкциями и консультациями в чате в телеге.

Если еще чуть времени потратить, купить VPS, поставить на него awg 2.0 одной командой, все.
Хочется больше контроля - 3X-UI (одной командой в консоли), настроить vless + XTLS + Reality прямо в вебе, получить ключ, вставить в роутер и все.

P.S. Маршрутизация из коробки в ZeroBlock (который форк podkop, как я понял) - тоже есть.

Вот спасибо за совет.

Вот в этом и дело - вы так круто и понятно расписали, что даже ради интереса хочется купить этот роутер.

А вот ни в описании этого продукта, ни в тысяча коментах - ничего подобного нет.

Максимум - поддержка молодцы, смотрю теперь ютуб (что не сильно отличает этот продукт от других в глазах покупателя).

Так что снова приходим к важности понятного продукта, который закрывает потребности/боли человека.

Или как принято в виндовс-среде - скачать 1 файл инсталлятора, проставить галочки, Далее, Далее, Готово. 21-й век давно, уже даже ИИ создан, а здесь всё как в 90-е, какие-то магические заклинания в командной строке, недоступные большинству пользователей интернета.

Всё так.

Или готовый роутер (с обновлениями) или понятный инсталятор all-in-one ))

Возникло несколько вопросов после прочтения статьи:

  1. Правильно ли я понимаю, что списки серверов VPN и базы данных geoip и geosite скачиваются не через этот самый VPN, а потому провайдер спокойно видит, что вы их качаете, и, соответственно, может понять, что сейчас его будут дурить?

  2. Вроде как IPv6 более лучший протокол (все предпочитают использовать его из статьи), но вы сознательно его выключаете. В чём с ним сложность, почему нельзя всё то же самое настроить и для IPv6?

  3. Будут ли работать торренты в этой схеме? Там же peer-to-peer соединения, всё будет заворачиваться на VPN всё равно?

Хорошие вопросы :)

  1. Да, всё это качается напрямую. Провайдер может это видеть, но это обычный HTTPS-трафик и редкие запросы.

  2. IPv6 можно настроить, но там сильно больше нюансов и легко словить утечку - я поэтому его просто отключил.

  3. Торренты будут работать, но пойдут через VPN и без входящих соединений раздача может быть хуже.

По пункту 2: вот интересно было бы почитать, что это за «куча нюансов» и как «легко словить утечку». И почему через IPv4 нет этой «кучи» и «тяжело».

Кстати, забыл ещё спросить про категории в geoip и geosite. Как и откуда вообще узнать, какие существуют? Как решить практические вопросы: в какую категорию попадает этот домен / IP (ну или хотя бы более простой: попадает ли этот домен / IP в эту категорию)? Как добавить домен / IP в категорию? Как создать свою категорию?

По IPv6 - да, там реально больше нюансов. В Xray при IPIfNonMatch / IPOnDemand домен может резолвиться и в IPv4, и в IPv6, а встроенный DNS работает с A и AAAA-записями, так что IPv6 нужно отдельно учитывать в DNS, firewall и маршрутизации; OpenWrt прямо отдельно предупреждает про отключение ISP prefix delegation, чтобы не ловить IPv6 leaks на VPN-клиенте. Я поэтому и упростил схему, отключив IPv6, а не потому что он “плохой” сам по себе.

По geoip/geosite: geosite - это список доменных наборов из репозитория domain-list-community, где каждый файл в data/ превращается в правило вида geosite:filename, а внутри используются include:, domain:, full:, keyword:, regexp: и атрибуты вроде @ads / @cn; geoip - отдельный проект с месячными релизами и CLI для сборки своих баз. Практически проще всего смотреть исходные списки и plain-экспорт (dlc.dat_plain.yml, текстовый вывод geoip CLI), а свою категорию делать либо отдельным файлом в data/, либо через CLI-сборку своих geoip-файлов.

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

Впрочем теперь этим будет заниматься не только мах но и валберисы с озонами и т.д. Хотя никто не мешает в js наших маркетплейсов внести небольшой код который будет пробивать внешний (зарубежный) ip и на компьютере при открытии сайта в браузере.

те кто считает что раздельное маршрутизирование спасает могут поэкспериментировать - https://api.ipify.org или https://ipinfo.io/json

Очень круто и многое уже продумано, респект :) На гитлаб или около того планируете выкладывать? У вас сейчас изложено в порядке как думали и проблемы решали - это познавательно, погружает в контекст и будет здорово итоговый вариант для развертывания ) И да, про ipv6 имхо все-таки стоит проработать, через него обходы зачастую эффективнее работают.

Спасибо! Да, сейчас хочу сначала довести всё до более-менее стабильного состояния, а потом уже, возможно, выложить в более удобном для развёртывания виде, пока продумываю, как будет лучше.

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

Насколько безопасно пропускать трафик банков и госуслуг через кастомные прошивки наподобие OpenWRT ?

скажу банальность, но самое безопасное сейчас не пользоваться вообще никакими vpn, openwrt и полностью погрузится в заботливые обьятия ркн. Все остальное в той или иной мере не безопасно.

а так из боле-менее безопасного - что-то "xray" в режиме прокси, firefox с расширением "firefox мульти-аккаунт контейнер" и настройка проксирования для разных контейнеров. Ну а затем нужные сайты закреплять за выбранными контейнерами.

Всё это красиво конечно но влес уже устаревший и его активно блочат.

Если я не ошибаюсь, все же в каком-то отношении использование локальных средств обхода выигрывает по безопасности за счет возможности настройки раздельной маршрутизации для разных приложений, конечно, при условии отсутствия уязвимостей SOCKS5 без авторизации. Проблема может возникнуть, например, если у жены / ребенка / гостя на устройстве есть вредоносное ПО, которое может пингануть ресурсы из реестра РКН, обнаружить факт использования средств обхода и скомпрометировать ваш ВПН. Хотя эту проблему можно частично решить с помощью каскадного ВПН (так, по крайней мере, впн сервер не попадет под подозрение) и польностью - с помощью белого списка устройств, трафик с которых нужно проксировать

А как обстоят дела с поставщиками подписок, у которых требуется передача HWID клиента? В этом решении получится получить подписку или каким-то образом передать HWID? Понимаю, что из подписки можно выдернуть ключи для каждого сервера, а потом их добавить, но подписка все же удобнее, тк могут добавляться, убираться серверы.

Да, у меня подписка как раз тянется с передачей HWID - через заголовок x-hwid в скрипте обновления.

То есть если провайдеру нужен HWID, это уже поддержано на уровне fetch-скрипта; роутерная схема тут не мешает.

Насколько хорошим решением будет развернуть все это дело на NanoPi?

Да, если речь про R5S/R6S - это уже хороший вариант под такую схему. У R5S нормальный запас по CPU и 2/4 ГБ RAM, у R6S запас ещё больше.

Для моего стека критична именно память: Xray + geodata + AdGuard уже ощутимо едят RAM, так что 1-2 ГБ хватит спокойно.

Удивительно, как у вас Filogic 820 тянет с такой низкой загрузкой tproxy + pppoe. Xiaomi AX3000T с таким же процем и активным tproxy дает 350-400 мбит в лучшем случае с маской распределения нагрузки на все ядра (правда mihomo, не xray, но суть одна). Поэтому 2.5 гбит wan с таким userspace-проксированием невозможно, да даже гигабит нереально. А под торрентами этот проц ложится даже на 300 мбитах. С таким конфигом лучше перейти на x86.

Да, тут всё очень зависит от конкретной схемы и профиля нагрузки. У меня не “просто tproxy”, а TCP-only стек с Xray+Reality, QUIC отдельно режется, и в статье я как раз показывал, что роутер живёт без заметной нагрузки в простое и без проблем тянет обычный домашний трафик.

Под торренты и сотни коротких соединений картина, конечно, хуже - это уже совсем другой сценарий. Но из этого не следует, что Filogic 820 “в принципе не тянет” такую схему: в моём случае узкое место сейчас скорее не CPU, а память/overlay и обвязка.

ТС, у меня один вопрос! А зачем так усложнять? Есть же пакет V2RayA и все можно сделать без отдельных скриптов и прочего и главное - в 10 раз легче

Можно и через V2RayA, если нужен простой рабочий вариант.

Я же специально пошёл в более сложную схему: чтобы был контроль над роутингом, DNS, QUIC, автоперезапуском, обновлением подписок и чтобы было понятно, что где ломается. Для домашнего роутера это уже не только “включить прокси”, а отдельная система.

> Flash: 128 МБ NAND (overlay ~44 МБ)

В сети есть мануалы прошивки c u-boot, после чего доступно около 95 Мб, и хватит места для ADH, Podkop, ещё и останется с запасом.

Кстати, этот роутер есть с флешем 256 Мб(китайская версия, либо перепаивают память), есть ещё Cudy TR30 - это то-же самое что и TR 3000 (вроде как коллаборация Cudy и Wildberries)

Да, вариант с 256 МБ и расширением overlay встречается, но это уже не базовая TR3000 из коробки, а отдельная ревизия/модификация. У Cudy для TR3000 официально указаны 128 МБ flash, а в OpenWrt Wiki есть отдельные techdata и для 128 МБ, и для 256 МБ версии.

Поэтому в статье я бы оставил цифры для обычной ревизии, а про 256 МБ и U-Boot-правки упомянул бы как про отдельный вариант. TR30, кстати, у Cudy в каталоге идёт как отдельная модель, а не просто другое название TR3000.

Обращу внимание, что бывают домены, например 17.doramalive.la, контент которых работает только из рф, либо блочится некоторыми странами, поэтому полезно иметь еще список исключений доменов и ip, которые отправлять напрямую в ру-сегнент. Список доменов нужен потому, что на одном серваке могут находиться разные сайты, какие-то работают только из ру сети, несмотря на то, что находятся на сервере вне ру сети, а какие-то размещены могут быть там же, но блочить уже клиентов из ру сети.

Да, это хороший аргумент, поэтому я как раз и добавлял исключения по доменам, а не только по IP.

На практике одного geoip:ru мало: сервис может жить на внешнем IP, но при этом нормально работать только из ру-сегмента, либо наоборот - блокировать клиентов из РФ. Так что доменные исключения тут реально нужны.

Приветствую. Я конечно не эксперт. Но чем это принципиально отличается от какого нибудь подкопа, который устанавливается и настраивается минут за 10?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации