Настройка sing-box. Как зароутить в прокси ipv6-only домены не сломав все остальное?

не использую sing-box, но всё равно оставлю примеры для xray

{
  "dns": {
    "disableFallback": true,
    "servers": [
      {
        "address": "localhost",
        //можно включить локальный дох так: "https+local://..."
        "domains": [
          "geosite:category-ru"
        ],
        "queryStrategy": "UseIPv4",
        "skipFallback": true
      },
      "https://..."
    ]
  }
}

если ваш провайдер выдает ip6, то можно убрать queryStrategy, потому что в этом случае 6to4 тоннель не будет влиять на приоритеты системы и работоспособность сайтов с прямым доступом

inbound можно создать по аналогии с inbound для ip4 в режиме tproxy. примерно так

{
  "inbounds": [
    {
      "tag": "ip6",
      "listen": "::1",
      "port": "<port>",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "routeOnly": true
      }
    }
  ]
}

дальше инструкция для linux. как настраивать винду, не знаю

нужно создать таблицу маршрутизации и правило по умолчанию для неё. делается по аналогии с tproxy для ip4

# ip -6 route add local default dev lo table 100
# ip -6 rule add fwmark 1 table 100

теперь добавим таблицу xray в nftables. делается по аналогии с tproxy для ip4

destroy table ip6 xray

define reserved = {
  ::/127,
  fc00::/7,
  fe80::/10,
  ff00::/8
}

table ip6 xray {
  chain prerouting {
    type filter hook prerouting priority mangle; policy accept;
    meta l4proto { tcp, udp } meta mark 1 tproxy ip6 to [::1]:<port>
  }
  chain output {
    type route hook output priority mangle; policy accept;
    meta skuid xray return
    ip6 daddr $reserved tcp dport != 53 return
    ip6 daddr $reserved udp dport != 53 return
    meta l4proto { tcp, udp } meta mark set 1
  }
}

инструкция meta skuid xray return будет работать, если xray поднимается под отдельным пользователем xray. если это не так, то можно пропускать нужный трафик по meta mark 0x000000ff return, но тогда в каждом outbound придётся указывать метку

"streamSettings": {
  "sockopt": {
    "mark": 255
  }
}

всего этого хватит, чтобы пустить ip6 пакеты в тоннель, если на клиенте есть ip6

про винду не знаю, но в случае с linux без ip6 на клиенте этого не хватит, потому что в системе не будет ни одного маршрута по умолчанию для пакетов. это можно очень просто решить, если создать маршрут по умолчанию в lo

# ip -6 route add default dev lo

теперь 6to4 тоннель будет работать, хотя ip6 на клиенте отсутствует. значит, сайты типа ntc будут открываться, если xray включён, а сайты с прямым доступом будут резолвиться только в ip4, поэтому останутся доступны

Хотел как раз с TPROXY поэкспериментировать, спасибо :slight_smile:

Через putty? Я локально просто запускаю, а вы что-то удаленное имеете ввиду?

Ах да, я же с ПК скрипт sing-box на роутере запускаю).

Так и подумал :slight_smile:

Пожалуйста. Если версия старее 1.8, то обновиться до новейшей можно только переустановкой. В общем читайте файлы “Readme-ru.txt” и “Изменения.txt” на странице проекта. Удачи.

У вас все еще странная конфигурация.

Зачем вы совмещаете geosite:category-ru и suffix .ru? В category-ru уже входит .ru и много чего другого. Не нужно дублировать поля.

Далее по правилам: у вас resolve идет до sniff. Что вы собрались резолвить, если даже тип трафика неизвестен? Вы уверены, что это работает именно так, как вы задумали? Правила применяются последовательно.

local петля на линуксах имела похожие симптомы. Проблема была в том, что sing-box старых версий делегировал DNS запросы стороннему приложению, которое отправляло их на удаленный сервер. Эти запросы вновь перехватывались sing-box и повторно делегировались. В логах один DNS запрос вызывал цепочку из 4-5 попыток отрезолвить домен, пока не включался fallback на встроенный в Go резолвер, который сам читал resolv.conf и отправлял пакет куда надо. Весь процесс занимал 3-5 секунд (если домена нет в кэше).

Советую вам внимательно посмотреть и подумать, как именно гуляют DNS запросы в системе. У вас не обязательно петля, но что-то явно идет не туда.

И на линуксе вам не нужен tproxy с sing-box (это в xray иначе нормально не сделать). Посмотрите документацию:
auto_redirect is always recommended on Linux, it provides better routing, higher performance (better than tproxy), and avoids conflicts between TUN and Docker bridge networks.

Хотя и здесь не все однозначно. Вы уверены, что узкое место именно в TUN?

Порядок resolve видимо из моего конфига. И это точно работает (может в другом порядке было бы лучше, не знаю). Из документации: Rule Action - sing-box (resolve request destination from domain to IP addresses). То есть по-моему тут sniff не влияет. У меня браузеры подключаются к sing-box через socks5 к mixed. В настройках браузера стоит “Отправлять DNS-запросы через прокси при использовании SOCKS 5”. Если убрать action resolve (пусть он и самым первым идет), то домены ru начинают разрешаться через прокси, а не напрямую. А если добавить это правило (как в конфиге), то ru запросы идут без прокси (их видно локальным сниффером) с учетом dns rules, как и хотелось бы.

Вы используете socks5, поэтому у вас все хорошо. Там сам протокол подразумевает отправку клиентом (браузером) IP или домена в connection request’е, поэтому для sing-box все как на ладони.

TUN же, в моем понимании, получает IP пакеты, т.е. работает на уровне 3 модели OSI. Что там внутри этих IP пакетов – неизвестно пока не выполнен sniff. Т.е. resolve просто всегда фейлится.

Имхо, не нужно использовать resolve, если нет четкого понимания когда где и зачем оно подменяет домен на IP. Это как раз случай Tsb.

  1. Суфикс был с 2023 года, может тогда category-ru не использовал, а потом все смешалось :melting_face:
  2. Нет, не уверен. Дока такая, что тут ни в чем нельзя быть уверенным. Только исходники если читать)
    1. Взял у товарища hdrover
    2. жпт говорит: правило type: “resolve” всегда работает ПОСЛЕ sniff, даже если в конфиге оно стоит “выше”. Порядок в файле не влияет на внутренний порядок операций. Где правда - хз, но на всякий случай поменяю местами, спасибо)
  3. Про local-dns выше писал - выдернул/воткнул ethernet и все само прошло. Не знаю в чем была проблема.
  4. Я не уверен, я и не утверждал, что TUN узкое место, если вы правильно вопрос адресовали) Я только говорю, что использую TUN на роутере и вижу CPU под 100%, а speedtest 200 Мб/c.
    1. Но, справедливости ради, не первый раз слышу, что tproxy должен в теории работать быстрее чем tun на том же роутере. Например, тут. Сам не проверял

Кстати по поводу category-ru - у меня там не только .ru:

example
    "domain_suffix": [
      ".ru",
      ".su",
      ".рф",
      ".by",
	  ".ru.com",
	  ".ru.net",
	  ".moscow",
	  ".xn--p1ai",
	  ".xn--p1acf",
	  ".xn--80aswg",
	  ".xn--c1avg",
	  ".xn--80asehdb",
	  ".xn--d1acj3b",
	  ".xn--90ais"
    ],

И category-ru у меня по другой ссылке качается. Я его распаковал и вижу, что тут нет нескольких доменов, которые я в суфиксе указал. Так что не просто так они тут указаны. Хотя может это что-то лишнее, я не уверен)

Конкретно:

  • .xn–90ais
  • .ru.com
  • .ru.net

Еще, к слову, я точно знаю, что хотя бы эти базовые домены ловятся. А что там в category-ru творится - я не слежу каждый день) Завтра там под 0 случайно снесут все, а я даже не узнаю (узнаю, конечно, потому что на сервере режется тоже, но все же)

Чаще всего жпт несёт лютую ересь по конфигам sing-box. И если местами что-то правильно, то в общем и целом бред.

Что сложного заменить tun на tproxy в конфиге роутера и убедиться? Но всё же есть недостаток и у tproxy- он работает только с tcp и udp трафиком. Прочее, например icmp, прочее подобное и всякие экзотические протоколы не пройдут), с ними только tun работает. Но в принципе народу, которому просто нужен обход блокировок, и желательно с высокой скоростью, пох на такие мелочи).

Так icmp (не уверен что есть что-то кроме echo) в tun добавили совсем недавно, и работает он только в direct out или wireguard. а другие протоколы кроме tcp/udp/icmp работать не будут

Вот что касается tun именно в sing-box- не знаю, а вообще tun интерфейс , насколько я в курсе, не имеет ограничений по типам трафика, в рамках IP-трафика.
Хотя, верю вам, скорее всего в sing-box tun не полноценный, а просто как средство захвата трафика и не имеет полного IP-стека. Тестов с прохождением icmp и прочего не udp/tcp я не проводил, и вообще до этого момента не задумывался об этом.

У меня стоит старый sing-box 1.7.8, там вообще есть tproxy? А когда пытался накатить новый - были какие-то невнятные ошибки с cache.db. Пока не курил в чем там косяк. Если сталкивались - помогайте)

++ я не шарю за iptables и как правильно заворачивать трафик

sing-box 1.7.8 не запустился бы с конфигом, который вы привели в первом посте данного топика. Естественно в sing-box 1.7.8 есть поддержка tproxy. Возникает вопрос- вы о каком устройстве сейчас ведёте речь? И при чем тут iptables?

Изначально речь была про windows и sing-box 1.12.12, как и написано в топике. Потом вы пришли и САМИ написали про ваш скрипт для РОУТЕРА, раз всплыла эта тема - я спросил как правильно настроить sing-box чтобы была минимальная нагрузка на CPU на роутере, вы сказали про TProxy. Все что касается tproxy - про роутер и на нем у меня старая 1.7.8 версия. Вы как будто только в тред пришли)

А как у нас трафик в TUN/tproxy попадет на роутере? Не правилами iptables, которые в вашем скрипте расписаны?)

именно так. например, при попытке послать в TUN ICMP-ping до любого адреса, он не пройдет дальше (т.к. прокси не умеет в ICMP), а на него ответит сам sing-box

Версия sing-box 1.7.8 там может быть, только если вы сами ставили это старое ядро, т.к. когда вышла первая версия скрипта, актуальная версия sing-box уже была 1.9.*. Скрипта sbs версии 1.7.8 не было, была 1.7, после которой сразу 1.8 вышла. Поддержка tproxy появилась в скрипте только с версии 2.0. Так что не путайте версии скрипта с версиями sing-box

Правила iptables для заворачивания трафика в tun/tproxy создаёт сам скрипт sbs при старте, и удаляет их при остановке, вручную не надо их создавать/удалять.

Если у вас всё же версия скрипта sbs старее 1.8, то обновиться корректно до более новых версий можно только полной переустановкой скрипта. Я не просто так выше дал вам ссылки на ридми и Изменения.

Я ничего не путаю и про версии скрипта ничего не говорил. Речь только про sing-box, как я выше и писал. И да, я сам ставил sing-box давным давно, а потом уже поверх использовал ваш скрипт.

По поводу iptables - да, скрипт создает, вот только чтобы все нормально работало мне надо обновить и его, и sing-box. И все, видимо, в ручную. При этом sing-box новой версии с ходу не завелся.

В общем отвечая на вопрос “что сложного проверить tproxy” - много всего в моем случае)