Я уже написал тут много статей на тему установки и настройки прокси-серверов XRay с недетектируемыми протоколами Shadowsocks-2022, VLESS (с XTLS), и т.п. И один из очень часто поднимаемых в комментариях вопросов звучит так: можно ли с использованием XRay-прокси как-то организовать проброс портов или получать доступ к внутренностям корпоративной сети? Можно, и сейчас я расскажу как.

XRay поддерживает механизм под названием "reverse proxy", что в купе с богатыми возможностями настройки правил маршрутизации позволяет сделать довольно много интересных схем. Механизм в документации упомянут как "...in the testing phase" и "may have some issues", но я попробовал, и все работает.

Традиционная нейрокартинка для отвлечения внимания
Традиционная нейрокартинка для отвлечения внимания

Итак, что же можно сделать с помощью реверс-проксирования?

  1. Можно получать доступ к каким-либо сервисам на хосте за NAT'ом или строгим фаерволом, и даже более того - можно получать доступ к сервисам на других устройствах в локальной сети, к которой имеет доступ этот самый хост за NAT'ом или файерволом.

  2. Можно маршрутизировать весь (или некоторый в зависимости от настроенных правил) трафик на хост за NAT'ом или фаерволом и выпускать его оттуда в Интернет.
    Например, вы проживаете за границей, хотите оплачивать счета за ЖКХ вашей недвижимости оставшейся России, но сервис оплаты не пускает вас с забугорных IP и не пускает вас с IP-адресов даже российских VPS-хостеров. Тогда можно поставить у кого-нибудь из друзей или родственников в РФ преднастроенный роутер или одноплатник типа Raspberry Pi, который подключится к вашему прокси-серверу, а вы, в свою очередь, через прокси-сервер сможете достучаться до этого роутера/р-пишки и выйти через него во внешний интернет как обычный пользователь, находящийся в России - и всем ресурсам будет виден IP-адрес российского домашнего интернет-провайдера.

  3. Можно обманывать тупые DPI, фильтрующие подключения по "белым спискам" в одну сторону. Например, от вас к серверу X подключиться нельзя (потому что его IP-адрес забанен), а с сервера X к вам - можно (когда у вас есть белый IP-адрес, пусть даже не статический, а с DynDNS). Тогда сделаем так, чтобы сервер X подключался к вам, а вы выходили через него в свободный интернет.

  4. Можно выборочно пробрасывать порты, например, все подключения на 80 порт прокси-сервера будут переадресовываться на 80 (или любой другой) порт "изолированного" хоста или еще куда-то дальше.

  5. Можно даже теоретически попробовать соорудить псевдо-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)


  1. entze
    18.11.2023 18:26
    +17

    если на хабре была бы номинация "Автор года", то уважаемый определенно её достоин. Спасибо!


  1. Sklif
    18.11.2023 18:26
    +2

    До выпила статьи осталось: 3...2...1

    https://habr.com/ru/news/774786/


    1. Kenya-West
      18.11.2023 18:26

      Кстати, да, спасибо за напоминание. Хотел бы сохранить PDF'ки статей, но вдруг у Хабра есть годное зеркало даже для удалённых статей?


    1. 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, зарегистрированная и действующая в юрисдикции и по законам Республики Кипр и Европейского Союза."


      1. Hawkeyeru
        18.11.2023 18:26

        значит можно готовиться, что весь хабр отъедет..


  1. Mupok
    18.11.2023 18:26

    можно в личку ссылку на сайт, где это можно потом почитать, когда начнут вырезать на сайте полезную информацию?)
    p.s. Или тут, потом будет, в зависимости от региона IP-адреса как на joyreactor плашка вылезать "Контент на территории РФ запрещен"?))


    1. MiraclePtr Автор
      18.11.2023 18:26

      Нету никакого сайта, да и заниматься им нету времени и лень.

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


      1. Kenya-West
        18.11.2023 18:26

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


      1. m00vie
        18.11.2023 18:26

        предположим ситуацию, в которой хабр удаляет (именно удаляет, а не блокирует) ваши статьи "про это" - тогда вас где-то еще почитать можно будет? есть какая-то запасная площадка?


        1. MiraclePtr Автор
          18.11.2023 18:26

          Неа, нету.

          Создавать какой-то отдельный блок или телеграм-канал нет ни времени, ни желания.

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

          А так, есть известный форум NTC.party, если ещё что-то интересное будет происходить, то скорее всего, там об этом будет.


    1. Buliway
      18.11.2023 18:26

      Можно скачать приложение для заметок, по типу Obsidian, и туда копировать эти статьи. А заметки бекапить куда нибудь. Там можно удобно и скрины и блоки кода сохранять.


  1. prorusnet
    18.11.2023 18:26
    -2

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


    1. MiraclePtr Автор
      18.11.2023 18:26
      +6

      NetBird

      NetBird is a simple and fast alternative to corporate VPNs built on top of WireGuard

      WireGuard

      Wireguard элементарно детектируется на DPI и РКН его уже легко умеет блочить, и будет это делать в случае чего когда захочет. Следовательно в российских реалиях решение... ну, такое себе.

      Суть XRay и подобных - именно в недетектируемости и неблокируемости. Прочтите первую и вторую статьи из цикла, я там разбирал этот вопрос.


      1. prorusnet
        18.11.2023 18:26
        -2

        Есть аналоги (OpenGNB, tailscale, zerotier) где другие протоколы и есть вообще без шифрования. Я понял что суть только в супер зашифрованном канале, только и оно до поры до времени.


        1. MiraclePtr Автор
          18.11.2023 18:26
          +3

          Для всех перечисленных вами решений проблема та же самая - если их протокол не похож ни на что и не детектируется DPI, то подключения к ним могут порезать вместе со всеми остальными неопознанными протоколами - как это периодически делают китайцы (см. последний GFW-Report) и как это уже делал Роскомнадзор во время недавних событий на юге страны. А если их протоколы детектируемы DPI, то это ещё хуже - значит уж их-то точно при желании легко заблокируют, учитывая, что с их использованием можно получать доступ к "неразрешенным" ресурсам. Пока что они "Неуловимые Джо", но технически в любой момент это может легко измениться.

          Поэтому нет, в XRay и ему подобным нет никакого супер-шифрования нв самом деле, там в большинстве случаев обычный AES как везде, суть скорее в маскировке под легитимные протоколы (типа HTTPS) с защитой от active probing, детектирования TLS-in-TLS, replay-атак, плюс возможности работать через CDN и маскировки под SNI и сертификаты популярных сайтов.


  1. valera_efremov
    18.11.2023 18:26

    с недетектируемыми протоколами Shadowsocks-2022

    Смотрим п.49.
    Ой, а что с лицом? Значит, всё таки научились детектить? Или РКН бежит впереди паровоза?
    Ой, а что с лицом? Значит, всё таки научились детектить? Или РКН бежит впереди паровоза?


    1. MiraclePtr Автор
      18.11.2023 18:26
      +12

      РКН в своих писульках может писать любую чушь. Достоверно детектировать SS-2022 они не умеют.

      Но это не значит, что они его не могут заблокировать :) Могут, так же как это делают китайцы (согласно последнему отчёту GFW-Report) - методом тупого блокирования всех подключений, протокол которых опознать не получилось (с соответствующим сопутствующим ущербом). И они это, по ряду признаков, уже делали во время недавних событий на юге России (возможно, ненамеренно - пытались заблокировать телеграм-прокси, и случайно грохнули заодно SS).


    1. olegtsss
      18.11.2023 18:26

      А где в таблице основные vpn протоколы для блокирования-то? Openvpn, wireguard, ikev2, gre, l2tp, sstp, pptp? Или их блочить будут по-умолчанию? Или пункт 23 - это про них (но тогда почему только в РФ)?


      1. Squoworode
        18.11.2023 18:26

        нет, п. 23 - это название приложения из гугл плея, в предыдущей статье была ссылка


        1. olegtsss
          18.11.2023 18:26

          Что-то мне кажется, что п.23 - это как раз все vpn протоколы в ... И именно протоколы, а не сервера, и куда они бегут (внутри периметра или за) будет не важно. Ровно как в мае и августе.


          1. Squoworode
            18.11.2023 18:26

            И тем не менее, это не мешает этому словосочетанию быть названием приложения.

            P.S. Если это "все протоколы", то зачем остальные пункты списка?


            1. olegtsss
              18.11.2023 18:26

              Интересно тоже))


    1. Kenya-West
      18.11.2023 18:26
      +2

      Просьба не путать обычный ShadowSocks и ShadowSocks-2022 — это очень разные протоколы. С SS-2022 можно даже в Китае обходить блокировки, если грамотно это всё дерьмо настроить и уметь бегать быстрее полисменов.


  1. naimjon94
    18.11.2023 18:26

    Мой провайдер блокирует все трафик кроме Телеграмм, Инстаграма, Фейсбук, Вотсап, можно ли как то обойти эти ограничении, с помощью этой прокси?


    1. MiraclePtr Автор
      18.11.2023 18:26
      +2

      Смотря как именно он определяет, что доступ идёт до Телеграма/Фейсбука/итд.

      Если только по SNI, то сработает XTLS-Reality с маскировкой под нужный сервер.

      Если условие и по SNI и по диапазонам IP, то нужно копать очень глубоко - например, если они пользуются услугами какой-то CDN, и эта CDN разрешает domain fronting, и разрешает проксировать вебсокеты - то тоже может сработать. Но будет стоить денег, ибо таки CDN обычно не щедры на бесплатных тарифах. Можно даже без вебсокетов, достаточно просто требуемой CDN и domain fronting'а, и какого-нибудь Meek - но работать все будет очень медленно, настраивать геморройно, и только под десктоп.


    1. olegi
      18.11.2023 18:26

      это в РФ такой провайдер?


      1. MiraclePtr Автор
        18.11.2023 18:26

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


  1. FastJack24
    18.11.2023 18:26

    Полагаю статью стоит скачать, а то не все сейчас долговечное долговечно


  1. vasilijmooduckovic
    18.11.2023 18:26

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


    1. MiraclePtr Автор
      18.11.2023 18:26
      +1

      Вы, кажется, невнимательно читали предыдущие статьи. При использовании VLESS с XTLS все ровно наоборот - трафик не выглядит "неизвестным", а наоборот, выглядит очень даже известным (по стандартному протоколу к адресу популярного сайта, с фингерпринтами похожими на настоящий браузер и с сертификатом настоящего сервера). Поэтому его практически невозможно детектировать и заблокировать, тем более через границу.


  1. stripwire
    18.11.2023 18:26

    Есть ли разница, что я гоню во vless xtls-rprx-vision? К примеру с просым подключениям к сайтам всё ок, но будут ли палиться идущие внутри wireguard/ssh/??? ?

    Будет ли рабочей такая схема подключения: между linux машинами cloak(vless | wg(всё ~локальное)), а на android vless(tls | любые обращения в локалку wg).

    Поднять на дроиде и cloak, и vless как я понимаю, будет запарно, тк это нужны два vpn подключения.


  1. postdig
    18.11.2023 18:26

    А возможно ли на том же XRAY или чёмто ином из современного настроить подключение через обычный socks5 ?

    PS: Через Proxifier тот же nekoray/nekobox работает, но вот как бы обойтись без этого костыля ?


    1. 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 это недавно описывал.


      1. postdig
        18.11.2023 18:26

        Я про случай когда nekobox как клиент стороннего удаленного ss сервера.

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


        1. postdig
          18.11.2023 18:26

          PS: когда nekobox подключается к ss через промежуточный socks5


        1. MiraclePtr Автор
          18.11.2023 18:26

          Нужно создать в Nekobox одно подключение типа SOCKS. Потом создать отдельно ещё одно подключение SS.
          И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.


          1. postdig
            18.11.2023 18:26

            Бгагодарю, с цепочкой все получилось. Понятно и логично.

            Но я надеялся что существует иной вариант настройки. Задать некое правило (роутинг, outbound, или как оно еще может называться) чтобы весь выходной трафик клиента Nekobox к серверу ss/vless/etc выпускать через постоянный socks5 адрес.

            При этом профили (Active Server) с SS подключениями иметь возможность переключать через интерфейс Nekobox что называется одним кликом. А не править цепочки через меню редактирования....

            PS: если тут нельзя, может знаете альтернативу Nekoray/Nekobox с таким функционалом ?


  1. 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"
    }
    ]
    }
    }