Я уже написал тут много статей на тему установки и настройки прокси-серверов XRay с недетектируемыми протоколами Shadowsocks-2022, VLESS (с XTLS), и т.п. И один из очень часто поднимаемых в комментариях вопросов звучит так: можно ли с использованием XRay-прокси как-то организовать проброс портов или получать доступ к внутренностям корпоративной сети? Можно, и сейчас я расскажу как.
XRay поддерживает механизм под названием "reverse proxy", что в купе с богатыми возможностями настройки правил маршрутизации позволяет сделать довольно много интересных схем. Механизм в документации упомянут как "...in the testing phase" и "may have some issues", но я попробовал, и все работает.
Итак, что же можно сделать с помощью реверс-проксирования?
Можно получать доступ к каким-либо сервисам на хосте за NAT'ом или строгим фаерволом, и даже более того - можно получать доступ к сервисам на других устройствах в локальной сети, к которой имеет доступ этот самый хост за NAT'ом или файерволом.
Можно маршрутизировать весь (или некоторый в зависимости от настроенных правил) трафик на хост за NAT'ом или фаерволом и выпускать его оттуда в Интернет.
Например, вы проживаете за границей, хотите оплачивать счета за ЖКХ вашей недвижимости оставшейся России, но сервис оплаты не пускает вас с забугорных IP и не пускает вас с IP-адресов даже российских VPS-хостеров. Тогда можно поставить у кого-нибудь из друзей или родственников в РФ преднастроенный роутер или одноплатник типа Raspberry Pi, который подключится к вашему прокси-серверу, а вы, в свою очередь, через прокси-сервер сможете достучаться до этого роутера/р-пишки и выйти через него во внешний интернет как обычный пользователь, находящийся в России - и всем ресурсам будет виден IP-адрес российского домашнего интернет-провайдера.Можно обманывать тупые DPI, фильтрующие подключения по "белым спискам" в одну сторону. Например, от вас к серверу X подключиться нельзя (потому что его IP-адрес забанен), а с сервера X к вам - можно (когда у вас есть белый IP-адрес, пусть даже не статический, а с DynDNS). Тогда сделаем так, чтобы сервер X подключался к вам, а вы выходили через него в свободный интернет.
Можно выборочно пробрасывать порты, например, все подключения на 80 порт прокси-сервера будут переадресовываться на 80 (или любой другой) порт "изолированного" хоста или еще куда-то дальше.
Можно даже теоретически попробовать соорудить псевдо-VPN, чтобы подключенные клиенты прокси-сервера могли коммуницировать друг с другом.
Итак, поехали. Суть механизма reverse-proxy проста. Есть у нас прокси-сервер на каком-нибудь VPS, доступный для всего интернета. Нам через него надо попасть на какой-нибудь хост, который не доступен из всего интернета - например, он находится за NAT'ом без своего белого IP.
Решение простое: нужно сделать так, чтобы не сервер пытался достучаться до хоста (это невозможно), а хост первым подключился к серверу, а потом по уже установленному подключению запросы будут бегать в противоположном направлении. Это и есть reverse proxy.
Далее нужно разобраться с терминологией, которая используется в документации и конфигах XRay, потому что там все немного не очевидно и можно запутаться. Нужно знать и понимать три слова:
"client" - это клиент (логично, да), которому надо получить доступ куда-то или выйти в Интернет;
"portal" - это ваш прокси-сервер на VPS, связующее звено между client'ом и bridge'м;
"bridge" - это другой xray-клиент, изолированный за NAT'ом и фаерволом, к которому надо получить доступ.
Слово "bridge" может запутать, но скорее всего такое название разработчики решили использовать, потому что bridge является точкой соприкосновения внешнего интернета и ресурсов внутри сети - то есть финальной точкой назначения до которой мы хотим достучаться, может быть не сам bridge, а какие-то хосты в его локалке.
А теперь давайте разбираться, как это все настроить. Конфигурация reverse proxy описана в документации XRay: https://xtls.github.io/en/config/reverse.html, но описание довольно куцее. Еще есть гит-репа с примерами настройки реверс-прокси: https://github.com/XTLS/Xray-examples/blob/main/ReverseProxy/README.ENG.md
В качестве транспортного протокола может использоваться любой, который поддерживается XRay'ем. Я буду использовать в примерах для простоты обычный Shadowsocks, но ровно то же самое можно сделать и с VLESS, и с VLESS с Reality, и с VLESS через вебсокеты и CDN, и вообще как угодно - см. мои предыдущие статьи.
Начнем с настройки сервера ("portal")
{
"reverse": {
"portals": [
{
"tag": "portal",
"domain": "reverse.hellohabr.com"
}
]
},
"inbounds": [
{
"port": 5555,
"tag": "incoming",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "...",
"network": "tcp,udp"
}
}],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["incoming"],
"outboundTag": "portal"
}]
}
}
И давайте разбираться, что все это значит. В inbound у нас все как обычно - описание параметров для входящих соединений, простой shadowsocks. А вот дальше начинается интересное.
В начале конфига в секции "reverse" и объявляем один объект в массиве "portals", назначая ему тег "portal" и виртуальный домен "reverse.hellohabr.com". Этот домен именно виртуальный - он может не существовать, а правильнее сказать, он не должен быть каким-то из реально существующих доменов. Он используется только для того, чтобы XRay понял, что конкретно вот этот входящий запрос (с таким доменом) - не что-то, что нужно обработать как обычно и выпустить в интернет, а специальный запрос на установление соединения от bridge'а для того чтобы поднять reverse proxy.
Самое важное тут в routing - rules. Правило маршрутизации говорит о том, что все запросы, которые приходят от клиентов, нужно переадресовывать на reverse-proxy (тег "portal").
Естественно, если у нас другие пожелания, можно это правило маршрутизации немножко усложнить - например, переадресовывать на portal только запросы к определенным IP-адресам (диапазонам IP-адресов) или хостнеймам, а все остальное отправлять сразу в интернет (outbound "freedom"), или не пускать никуда (outbound "block"). Про правила маршрутизации можно почитать в документации XRay, плюс я еще немного касался этой темы в своем недавнем FAQ.
Дальше настраиваем "изолированного клиента" ("bridge")
{
"reverse": {
"bridges": [
{
"tag": "bridge",
"domain": "reverse.hellohabr.com"
}]
},
"outbounds": [
{
"protocol": "shadowsocks",
"settings": {
"servers": [{
"address": "....",
"port": 5555,
"method": "2022-blake3-aes-128-gcm",
"password": "...",
}]
},
"tag": "outgoing"
},
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["bridge"],
"domain": ["full:reverse.hellohabr.com"],
"outboundTag": "outgoing"
},
{
"type": "field",
"inboundTag": ["bridge"],
"outboundTag": "direct"
}]
}
}
В outbounds у нас тоже все просто - настройки подключения к серверу на VPS, который мы настроили в предыдущем шаге. Тоже есть секция "reverse", но на этот раз там объявлен объект "bridge" с тегом "bridge", и тем же виртуальным служебным хостнеймом, что мы задали для portal'а на предыдущем шаге - они должны совпадать.
А вот в routing-rules у нас все чуть-чуть сложнее. Первое правило определяет, как именно мы должны подключаться к нашему прокси на VPS (порталу) - мы говорим, что все подключения от bridge с виртуальным служебным адресом должны уходить на прокси через outbound, который мы описали чуть выше в этом же конфиге.
А второе правило определяет, что мы должны сделать с запросами, которые пришли к нам с прокси-сервера (с портала). В данном случае мы сразу выпускаем их всех наружу. То есть если пунктом назначения в запросе будет IP-адрес какого-либо хоста в локальной сети, к которому подключен bridge, подключение будет установлено к этому хосту в локальной сети. Если пунктом назначения в запросе будет какой-нибудь ресурс в публичности интернете - бридж установит соединение с ним. И т.д. Также как и в прошлом пункте, эти правила можно кастомизировать под себя - например, выпускать на outbound "direct" только запросы к определенным IP-адресам или хостнеймам, а все остальное отправлять в block, если мы не хотим, чтобы через нас лазили в интернет, а могли достучаться только до туда, до куда мы разрешили.
Готово!
В принципе, на этом настройка закончена. Когда вы запустите Xray на bridge, благодаря объявленному объекту "bridge" в конфиге, он инициирует и будет поддерживать специальное служебное подключение к прокси-серверу.
Прокси-сервер на вашем VPS, благодаря объекту "bridge" в конфиге, поймет, что это подключение - не обычно, а специальное служебное для reverse-проксирования, и обработает его как надо.
Когда вы своим обычным клиентом (например, с мобильного телефона или десктопа) подключитесь к прокси-серверу и попробуете подключиться через него к какому-нибудь ресурсу, прокси (portal) следуя правилам, переадресует этот запрос на подключение на bridge, а bridge, в свою очередь, следуя своим правилам, выпустит этот вопрос в свою локальную сеть или в интернет.
Как я уже сказал ранее, вы можете настроить правила так, как надо вам - например, на вашем прокси на VPS отправлять на bridge только запросы к определенным IP-адресам или доменам, а все остальное выпускать сразу в интернет и блокировать. Можно настроить несколько разных inbound's или несколько разных пользовательских ID в рамках одного inbound'а, и применять разные правила для разных пользователей. На самом bridge (хосте за NAT'ом) тоже можно применять разные правила - например, пропускать только запросы на определенные IP, а все остальное блокировать.
Про правила маршрутизации можно почитать в документации XRay, плюс я еще немного касался этой темы в своем недавнем FAQ.
Из того, что еще может оказаться полезным: в настройках outbound'а с протоколом "freedom" можно указывать конкретный сетевой интерфейс или IP-адрес для исходящих подключений, и даже routing mark в Linux, чтобы разруливать доступ к локалке так, как нужно вам, см. документацию Xray для подробностей.
А если нужен проброс портов?
На базе описанных выше конфигов можно строить разные схемы - например, пробрасывать порты.
Допустим, нам нужно, чтобы все подключения к 80 порту portal'а переадресовывались на 80 порт bridge'а.
Добавим на portal'е специальный inbound и правило для него:
"inbounds":
[
....,
{
"tag": "web_server_forward",
"port": 80,
"protocol": "dokodemo-door",
"settings": {
"address": "127.0.0.1",
"port": 80,
"network": "tcp"
}
}
]
....
"routing": {
"rules": [
....,
{
"type": "field",
"inboundTag": ["web_server_forward"],
"outboundTag": "portal"
}
]
}
а и добавим соответствующие директивы на bridge:
"outbounds":
[
...,
{
"tag": "web_server_local",
"protocol": "freedom",
"settings": {
"redirect": "127.0.0.1:80"
}
}
]
...
"routing": {
"rules": [
...,
{
"type": "field",
"inboundTag": ["bridge"],
"outboundTag": "web_server_local"
}
]
}
После этого все запросы, пришедшие на 80 порт portal'а, будут переадресованы на 80 порт bridge'а через reverse-прокси подключение.
Если ничего не работает
Если вы пытаетесь получить доступ к локальной сети через reverse proxy, но ничего не работает, и даже на сервере в логах не видно запросов, проверьте настройки клиента. Во многих клиентах по умолчанию запросы на "geoip:private" (то есть как минимум локальные IP-адреса классов A, B и C) отправляются в block.
Так же не забываем, что есть основания предполагать, что в случае чего РКН будет блокировать вообще все неопознанные протоколы (и судя по всему, они уже это делали). Поэтому вместо Shadowsocks лучше использовать VLESS с TLS, см. предыдущие статьи.
Еще, из того, с чем столкнулся я: после настройки на bridge XRay запускался, но почему-то не поднимал подключение к portal'у, и в логах была тишина.
На portal же, при попытке сходить куда-то через bridge, в логах были сообщение
v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/app/reverse: empty worker list
означавшее, что portal-то и не против сходить куда-нибудь через bridge, вот только ни одного подходящего bridge'а к нему не подключилось. Я так и не понял, в чем было дело, в какой-то момент я просто снес конфиг и переписал его заново более внимательно и все заработало.
При правильной настройке при попытке подключиться, на стороне portal в логах будет что-то типа такого:
xray[1856216]: 11.11.11.11:10457 accepted 22.22.22.22:443 [incoming -> portal]
xray[1856216]: proxy/shadowsocks_2022: tunnelling request to tcp:reverse.hellohabr.com:0
xray[1856216]: app/dispatcher: taking detour [portal] for [tcp:reverse.hellohabr.com:0]
xray[1856216]: common/mux: dispatching request to udp:reverse.internal.v2fly.org:0
xray[1856216]: [33.33.33.33]:63786 accepted reverse.hellohabr.com:0 [incoming -> portal]
а на bridge:
xray[648852]: [Info] app/dispatcher: taking detour [outgoing] for [tcp:reverse.hellohabr.com:0]
xray[648852]: [Info] proxy/shadowsocks_2022: tunneling request to tcp:reverse.hellohabr.com:0 via 11.11.11.11:5555
xray[648852]: [Info] transport/internet/tcp: dialing TCP to tcp:[11.11.11.11]:5555
xray[648852]: [Info] common/mux: received request for udp:reverse.internal.v2fly.org:0
Псевдо-VPN?
Сообразительный читатель наверное догадается, что в теории таким образом можно даже сделать какое-то подобие VPN. Если на каждом клиенте настроить и outbound до прокси и bridge, а на прокси для каждого клиента создать portal и соответствующие правила (например, выдумав набор виртуальных IP-адресов и routing rules для них, типа подключения к 10.0.0.1 отправляй на этот портал, а к 10.0.0.2 на другой), то можно соорудить схему, когда клиенты смогут подключаться через прокси друг к другу. Скажу честно - я не пробовал. Может заработает, а может и нет. Если кто-то попробует и получится - расскажите. Если не получится - тоже расскажите. Из явных минусов: конфиг будет страшный, и отлаживать все это дело будет непросто. Плюс на мобильных клиентах (да и в простых десктопных) bridge-функционал просто так не настроить.
Поэтому в случае необходимости подобного, я бы предложил все-таки использовать классические VPN-протоколы, например, AmneziaWG, или OpenVPN завернутый в Cloak, или что-то из TLS VPN, о которых я расскажу в следующей статье.
Комментарии (38)
Sklif
18.11.2023 18:26+2До выпила статьи осталось: 3...2...1
Kenya-West
18.11.2023 18:26Кстати, да, спасибо за напоминание. Хотел бы сохранить PDF'ки статей, но вдруг у Хабра есть годное зеркало даже для удалённых статей?
Johan_Palych
18.11.2023 18:26+2Изменения в пользовательском соглашении и политике конфиденциальности на сервисах Хабра:
https://habr.com/ru/companies/habr/articles/487528/
https://account.habr.com/info/agreement/
https://company.habr.com/ru/"Если ранее управление сервисом осуществлялось российской компанией ООО «Хабр», то теперь за бразды правления взялась наша головная компания — Habr Blockchain Publishing Ltd, зарегистрированная и действующая в юрисдикции и по законам Республики Кипр и Европейского Союза."
Mupok
18.11.2023 18:26можно в личку ссылку на сайт, где это можно потом почитать, когда начнут вырезать на сайте полезную информацию?)
p.s. Или тут, потом будет, в зависимости от региона IP-адреса как на joyreactor плашка вылезать "Контент на территории РФ запрещен"?))MiraclePtr Автор
18.11.2023 18:26Нету никакого сайта, да и заниматься им нету времени и лень.
Администрация Хабра недавно сказала, что по требованию органов будут ограничивать доступ к проблемным статьям из проблемных локаций.
Kenya-West
18.11.2023 18:26Это не поможет, если госорган попросит удалить статью физически из сервера для всез - либо придёт бан всему домену. Дешевле (до определенного предела) выполнять требования местного царька, если его рыночек приносит хороший доход.
m00vie
18.11.2023 18:26предположим ситуацию, в которой хабр удаляет (именно удаляет, а не блокирует) ваши статьи "про это" - тогда вас где-то еще почитать можно будет? есть какая-то запасная площадка?
MiraclePtr Автор
18.11.2023 18:26Неа, нету.
Создавать какой-то отдельный блок или телеграм-канал нет ни времени, ни желания.
Да и статей больше особо писать не планирую (кроме пары последних на очереди), вроде все основные темы уже осветил и разобрал.
А так, есть известный форум NTC.party, если ещё что-то интересное будет происходить, то скорее всего, там об этом будет.
Buliway
18.11.2023 18:26Можно скачать приложение для заметок, по типу Obsidian, и туда копировать эти статьи. А заметки бекапить куда нибудь. Там можно удобно и скрины и блоки кода сохранять.
prorusnet
18.11.2023 18:26-2Вопрос, зачем так усложнять жизнь, если можно использовать тот же netbird, где не нужен внешний сервер или белый ип, только поставь и авторизуй клиентов, а на том же одноплатнике в довесок можно поставить любой VPN сервер и подключаться через канал netbird. Аналоги есть и даже можно на своем сервере netbird подгять. Поясните для чего мучиться с настройкой всего этого?
MiraclePtr Автор
18.11.2023 18:26+6NetBird
NetBird is a simple and fast alternative to corporate VPNs built on top of WireGuard
WireGuard
Wireguard элементарно детектируется на DPI и РКН его уже легко умеет блочить, и будет это делать в случае чего когда захочет. Следовательно в российских реалиях решение... ну, такое себе.
Суть XRay и подобных - именно в недетектируемости и неблокируемости. Прочтите первую и вторую статьи из цикла, я там разбирал этот вопрос.
prorusnet
18.11.2023 18:26-2Есть аналоги (OpenGNB, tailscale, zerotier) где другие протоколы и есть вообще без шифрования. Я понял что суть только в супер зашифрованном канале, только и оно до поры до времени.
MiraclePtr Автор
18.11.2023 18:26+3Для всех перечисленных вами решений проблема та же самая - если их протокол не похож ни на что и не детектируется DPI, то подключения к ним могут порезать вместе со всеми остальными неопознанными протоколами - как это периодически делают китайцы (см. последний GFW-Report) и как это уже делал Роскомнадзор во время недавних событий на юге страны. А если их протоколы детектируемы DPI, то это ещё хуже - значит уж их-то точно при желании легко заблокируют, учитывая, что с их использованием можно получать доступ к "неразрешенным" ресурсам. Пока что они "Неуловимые Джо", но технически в любой момент это может легко измениться.
Поэтому нет, в XRay и ему подобным нет никакого супер-шифрования нв самом деле, там в большинстве случаев обычный AES как везде, суть скорее в маскировке под легитимные протоколы (типа HTTPS) с защитой от active probing, детектирования TLS-in-TLS, replay-атак, плюс возможности работать через CDN и маскировки под SNI и сертификаты популярных сайтов.
valera_efremov
18.11.2023 18:26с недетектируемыми протоколами Shadowsocks-2022
Смотрим п.49.
MiraclePtr Автор
18.11.2023 18:26+12РКН в своих писульках может писать любую чушь. Достоверно детектировать SS-2022 они не умеют.
Но это не значит, что они его не могут заблокировать :) Могут, так же как это делают китайцы (согласно последнему отчёту GFW-Report) - методом тупого блокирования всех подключений, протокол которых опознать не получилось (с соответствующим сопутствующим ущербом). И они это, по ряду признаков, уже делали во время недавних событий на юге России (возможно, ненамеренно - пытались заблокировать телеграм-прокси, и случайно грохнули заодно SS).
olegtsss
18.11.2023 18:26А где в таблице основные vpn протоколы для блокирования-то? Openvpn, wireguard, ikev2, gre, l2tp, sstp, pptp? Или их блочить будут по-умолчанию? Или пункт 23 - это про них (но тогда почему только в РФ)?
Squoworode
18.11.2023 18:26нет, п. 23 - это название приложения из гугл плея, в предыдущей статье была ссылка
olegtsss
18.11.2023 18:26Что-то мне кажется, что п.23 - это как раз все vpn протоколы в ... И именно протоколы, а не сервера, и куда они бегут (внутри периметра или за) будет не важно. Ровно как в мае и августе.
Squoworode
18.11.2023 18:26И тем не менее, это не мешает этому словосочетанию быть названием приложения.
P.S. Если это "все протоколы", то зачем остальные пункты списка?
Kenya-West
18.11.2023 18:26+2Просьба не путать обычный ShadowSocks и ShadowSocks-2022 — это очень разные протоколы. С SS-2022 можно даже в Китае обходить блокировки, если грамотно это всё дерьмо настроить и уметь бегать быстрее полисменов.
naimjon94
18.11.2023 18:26Мой провайдер блокирует все трафик кроме Телеграмм, Инстаграма, Фейсбук, Вотсап, можно ли как то обойти эти ограничении, с помощью этой прокси?
MiraclePtr Автор
18.11.2023 18:26+2Смотря как именно он определяет, что доступ идёт до Телеграма/Фейсбука/итд.
Если только по SNI, то сработает XTLS-Reality с маскировкой под нужный сервер.
Если условие и по SNI и по диапазонам IP, то нужно копать очень глубоко - например, если они пользуются услугами какой-то CDN, и эта CDN разрешает domain fronting, и разрешает проксировать вебсокеты - то тоже может сработать. Но будет стоить денег, ибо таки CDN обычно не щедры на бесплатных тарифах. Можно даже без вебсокетов, достаточно просто требуемой CDN и domain fronting'а, и какого-нибудь Meek - но работать все будет очень медленно, настраивать геморройно, и только под десктоп.
olegi
18.11.2023 18:26это в РФ такой провайдер?
MiraclePtr Автор
18.11.2023 18:26У некоторых мобильных операторов есть услуги типа "доступ к мессенджерам и соцсетям за два рубля в день без лимита трафика", возможно это про это
vasilijmooduckovic
18.11.2023 18:26труд конечно тектоникстический, но яра зачеровался в етой всей теме, потому что москируй-не москируй всё равно... они просто дропают неизвестный трафик через границу и всех дел
MiraclePtr Автор
18.11.2023 18:26+1Вы, кажется, невнимательно читали предыдущие статьи. При использовании VLESS с XTLS все ровно наоборот - трафик не выглядит "неизвестным", а наоборот, выглядит очень даже известным (по стандартному протоколу к адресу популярного сайта, с фингерпринтами похожими на настоящий браузер и с сертификатом настоящего сервера). Поэтому его практически невозможно детектировать и заблокировать, тем более через границу.
stripwire
18.11.2023 18:26Есть ли разница, что я гоню во vless xtls-rprx-vision? К примеру с просым подключениям к сайтам всё ок, но будут ли палиться идущие внутри wireguard/ssh/??? ?
Будет ли рабочей такая схема подключения: между linux машинами cloak(vless | wg(всё ~локальное)), а на android vless(tls | любые обращения в локалку wg).
Поднять на дроиде и cloak, и vless как я понимаю, будет запарно, тк это нужны два vpn подключения.
postdig
18.11.2023 18:26А возможно ли на том же XRAY или чёмто ином из современного настроить подключение через обычный socks5 ?
PS: Через Proxifier тот же nekoray/nekobox работает, но вот как бы обойтись без этого костыля ?
MiraclePtr Автор
18.11.2023 18:26+1Эм... А в чем проблема то? Вам надо чтобы к клиенту приложения подключались через SOCKS, или чтобы клиент к серверу подключался через SOCKS?
Для первого случая - это вообще основной режим работы XRay/Sing-box и подобных. В Nekobox внизу окна отображается адрес и порт (обычно 127.0.0.1:2080), на котором слушают сразу HTTP и SOCKS-прокси.
Для второго случая - аналогично, socks с первых версий является одним из возможных outbound'ов, и практически в каждом клиенте он есть в списке протоколов для настройки. В Nekobox можно строить цепочки прокси, например, подключаться к VLESS через SOCKS, я в FAQ это недавно описывал.
postdig
18.11.2023 18:26Я про случай когда nekobox как клиент стороннего удаленного ss сервера.
но вот что-то не пойму (я только разбираюсь с этим софтом) как построить цепочку, или как задать профиль с socks5 сервером как outbound для всех других профилей (чтоб можно было быстро переключать)
MiraclePtr Автор
18.11.2023 18:26Нужно создать в Nekobox одно подключение типа SOCKS. Потом создать отдельно ещё одно подключение SS.
И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.postdig
18.11.2023 18:26Бгагодарю, с цепочкой все получилось. Понятно и логично.
Но я надеялся что существует иной вариант настройки. Задать некое правило (роутинг, outbound, или как оно еще может называться) чтобы весь выходной трафик клиента Nekobox к серверу ss/vless/etc выпускать через постоянный socks5 адрес.
При этом профили (Active Server) с SS подключениями иметь возможность переключать через интерфейс Nekobox что называется одним кликом. А не править цепочки через меню редактирования....
PS: если тут нельзя, может знаете альтернативу Nekoray/Nekobox с таким функционалом ?
Fadmin
18.11.2023 18:26Спасибо за статью!
подправил конфиг бриджа, иначе не работает{
"reverse": {
"bridges": [
{
"tag": "bridge",
"domain": "reverse.hellohabr.com"
}
]
},
"outbounds": [
{
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "....",
"port": 5555,
"method": "2022-blake3-aes-128-gcm",
"password": "..."
}
]
},
"tag": "outgoing"
},
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["bridge"],
"domain": ["full:reverse.hellohabr.com"],
"outboundTag": "outgoing"
},
{
"type": "field",
"inboundTag": ["bridge"],
"outboundTag": "direct"
}
]
}
}
entze
если на хабре была бы номинация "Автор года", то уважаемый определенно её достоин. Спасибо!