Есть VPS с настроенным vless reality.
В доме стоит роутер, на который openwrt встанет со скрипом, и уж точно без поддержки проксирования через vless.
Есть телевизор Samsung, на котором хочется смотреть youtube.
И есть лежащая без дела Raspberry Pi ранних ревизий, к которой есть парочка совместимых wifi usb адаптеров.
Напрашивается такая схема:
Роутер --(ethernet)-- Raspberry Pi --(usb wifi)-- Телевизор
Попробовал накатить последнюю Raspbian, подключил к роутеру кабелем (wifi пока не трогал), установил xray-core в режиме клиента для vless, в inbound listen прописал 0.0.0.0:1080. То есть xray-core создаёт прокси-сервер на порту 1080, всё что к нему подключается — заворачивается в vless. Потестировал с компа через FoxyProxy — работает на удивление неплохо, 4K поток тянет без проблем, особо не греется даже.
Но дальше я не понимаю, как настроить связку с телевизором. Подключил usb wifi адаптер к малине. Не прошло и года, как поднял точку доступа на wlan0 через NetworkManager, прописал
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
и нормально, устройства подключаются к малине по wifi и получают доступ в интернет. Но у меня вообще никак не получается завернуть трафик в прокси, вот совсем. Гуглом ничего подходящего не нашёл, chatgpt говорит что-то про redsocks и/или разные правила в iptables — в лучшем случае эти предложения ничего не делают, а в худшем ломают подключение.
Может, кто-то посоветует, как лучше сделать? Может, кто-то уже делал подобное? Ещё видел, что для малины есть openwrt - не будет ли проще использовать этот вариант? (Никогда не пользовался openwrt и не знаю, позволит ли она реализовать задуманное.)
Возможно туплю, поправьте если так. Но по ссылке вроде говорится о том, что у меня уже работает, а именно раздача интернета на другие устройства, которые подключаются к wi-fi точке доступа (ну, в моём случае к ней). POSTROUTING в iptables прописан, net.ipv4.ip_forward = 1 тоже включил. Интернет раздаётся, всё окей.
Только я не могу понять, как мне вот этот раздаваемый интернет завернуть в socks5 на порту 1080. Есть ощущение, что вот так напрямую это нельзя сделать, но я не понимаю, как можно и куда смотреть. Пробовал поменять на http и прописать системный прокси для http и https через raspi-config. После этого curl с малины начинает работать через vless, но подключенные устройства по-прежнему работают в обход прокси. Не понимаю, как этот момент настроить.
Возможно, мой подход вообще ошибочный, и мне не нужно создавать никакой прокси-сервер, а нужно заворачивать трафик в vless как-то иначе. Но я пока не понимаю, как это сделать.
Может лучше поднять вместо x-ray поставить sing-box. Он может поднимать интерфейс, а не как прокси работать. И уже между ними пересылку делать.
Об этом не думал, спасибо, завтра будет время почитаю об этом подробнее. Но думаю вы правы, что мой подход с xray-core и прокси изначально дурацкий 
Наверно проще использовать какой-нибудь VPN.
Если прям xray нужен, можно через tun2socks завернуть его в tun интерфейс, и с ним уже настраивать маршрутизацию.
Тебе нужно маркировать весь трафик и заворачивать его часть с помощью tproxy на inbound dokodemo-door в xray.
Почитать про это можно здесь, на русском Прозрачное проксирование TProxy (ipv4 и ipv6) | Project X и здесь, на китайском 透明代理(TPROXY) | 新 V2Ray 白话文指南
Честно говоря, ваша схема подключения довольно странная. Я решительно не понимаю, зачем тут usb wifi адаптер, и зачем подключать телевизор именно физически через Raspberry? Все ведь решается простыми сетевыми настройками на уровне L3.
Я бы сделал так: Raspberry подключен к роутер по ethernet, телевизор тоже подключен к роутеру любым способом (ethernet/wifi). Далее пошагово:
- Сносите с Raspberry xray-core и ставите sing-box. Это гораздо более производительный клиент/сервер, и обладает очень богатым функционалом. И что немаловажно, имеет качественную документацию на английском языке (Client - sing-box).
- Настраиваете конфиг sing-box. В интернете полно примеров, можно гуглить sing-box example config, если настраивали xray-core думаю разберётесь. В Inbounds создаёте инбаунд типа tun, обязательно с опцией “auto_route”: true. В outbounds ваш конфиг vless reality по сути такой же, как в xray. В Route создаёте правила, что именно вы хотите завернуть в туннель, например для телевизора рекомендую завернуть только “domain_suffix” = “.googlevideo.com”. Этого будет достаточно, чтобы вылечить ютуб. Но можно завернуть и весь трафик, только будьте осторожны с российскими стриминговыми сервисами, если пользуетесь ими! И обязательно опцию “auto_detect_interface”: true, без неё работать не будет у вас!
- В настройках телевизора вы ставите шлюз по умолчанию = ip адрес Raspberry.
Итог: трафик с телевизора роутится на Raspberry, попадает на tun интерфейс, далее либо заворачивается sing-boxом в vless туннель и идёт на роутер и далее в интернет, либо просто сразу на роутер и в интернет напрямую, в зависимости от правил в разделе Routes.
У меня в целом похожая схема дома реализована, только вместо Raspberry классическая x86 платформа, и заворачиваю я туда трафик с избранных устройств не через шлюз по умолчанию, а отдельным маршрутом на маршрутизаторе. А в sing-box я использую список всех заблоченных РКН доменов, то есть проксирую только “запрещенку”. Если интересно, могу потом рассказать подробнее.
Интересно, может быть, сделаете отдельную подробную статью?
Думал об этом уже, только пока не знаю, на какой ресурс лучше выкладывать. Сюда или на какой-то пока рабочий в рф ресурс, вроде гитхаба.
На телевизоре есть поддержка прокси ⇒ настроить HTTP-прокси-сервер на компьютере/Raspberry (xray input), настроить прокси на телевизоре.
На телевизоре нет поддержки прокси, хочется обойтись только отдельными программами ⇒
- настроить беспротокольный прокси-порт (в v2ray называется dokodemo-door) на компьютере/Raspberry на портах 80 и 443, в нём настроить sniffing трафика (определение домена/IP-адреса из содержимого запроса, а не из метаданных подключения)
- настроить DNS-сервер на компьютере/raspberry с отдачей IP-адреса компьютера/raspberry для доменов, которые необходимо проксировать (возможно, DNS можно поднять и средствами xray/v2ray, но не уверен)
- указать IP-адрес компьютера/rasbperry в качестве DNS-сервера на телевизоре
// Обход блокировки YouTube для любых Smart TV с GoodbyeDPI + V2ray + MaraDNS
На телевизоре нет поддержки прокси и VPN ⇒ настраивать компьютер/raspberry как шлюз, как пишет @MasterYoba. Можно сделать на компьютере в виртуальной машине с Linux, отдельное устройство не обязательно.
На телевизоре нет поддержки прокси, есть поддержка VPN (любого протокола) ⇒
- настроить VPN-сервер для этого протокола на компьютере/raspberry
- настроить перенаправление трафика на беспротокольный прокси-порт (dokodemo-door) v2ray/xray с VPN-интерфейса
- настроить телевизор на VPN-подключение к компьютеру/raspberry
Преимущество перед настройкой шлюзом (способ выше) только в удобстве настройки/соединения/разъединения VPN-подключения.
См. описание реализации VPN-подхода: hoogmoon-testing/TECH.md at master · ValdikSS/hoogmoon-testing · GitHub
Файлы: hoogmoon-testing/build/files/etc/v2ray at master · ValdikSS/hoogmoon-testing · GitHub — там много всего дополнительного, но как пример подобной настройки, надеюсь, будет полезно.
Приветствую @ValdikSS и @MasterYoba , благодарю за подробные ответы!
На всякий случай уточню, что телевизор не поддерживает VPN и вот это всё. Настройки ограничены вот этим списком (картинка из интернета, но у меня так же).
Если я правильно понял идею, нужно просто подключить Raspberry Pi кабелем к роутеру и не городить из него точку доступа, а использовать малину как шлюз в настройках телевизора. Это дельная мысль, она не пришла мне в голову потому что я нуб и всегда всё усложняю Вечером попробую настроить sing-box под это дело.
Окей, вот я на свежей raspbian os прописал net.ipv4.ip_forward=1, телевизор нормально использует малину в качестве шлюза и ходит в интернет. Больше ничего не делал.
sing-box поставил, правда не без приключений. Raspberry Pi 1B это armv6, а в репозитории sagernet видимо только для v7. Долго думал, почему процесс вылетает со status=4/ILL сразу после запуска, но в итоге собрал из исходников, всё запускается.
Сейчас проблема в том, что сразу после sudo systemctl start sing-box я теряю связь с малиной по SSH, и как шлюз она тоже отваливается на подключенных устройствах. Пробовал добавлять direct маршруты в routes для локальных IP или для 22 порта, но то ли я неправильно добавляю, то ли дело не в маршрутах. При log level=“debug” в логе только это (в systemd тоже ничего интересного):
+0300 2024-08-06 22:45:09 INFO router: updated default interface eth0, index 2
+0300 2024-08-06 22:45:09 INFO inbound/tun[tun-in]: started at tun0
+0300 2024-08-06 22:45:09 INFO sing-box started (0.100s)
Вопросы:
- Всё ли верно в конфиге из того, что заполнено помимо routes?
- Что прописывать в routes для базового тестирования? Я имею в виду, пусть он вообще всё, кроме локальных маршрутов, заворачивает в туннель, для наглядности. Если заработает, то пропишу для отдельных доменов.
- Что-то ещё нужно делать, помимо конфигурации sing-box?
{
"log": {
"disabled": false,
"level": "warn",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "tls://8.8.8.8"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"final": "google",
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"interface_name": "tun0",
"stack": "system",
"inet4_address": "172.19.16.1/30",
"auto_route": true,
"strict_route": true,
"sniff": true
}
],
"outbounds": [
{
"type": "vless",
"tag": "vless-out",
"server": "IP_ADDR",
"server_port": 443,
"uuid": "UUID",
"flow": "xtls-rprx-vision",
"network": "tcp",
"tls": {
"enabled": true,
"server_name": "DOMAIN_NAME",
"alpn": ["h2"],
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "PUBLIC_KEY",
"short_id": "SHORT_ID"
}
},
"packet_encoding": "xudp"
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
}
],
"auto_detect_interface": true
}
}
Я брал конфиг из этой статьи и все взлетело Поднимаем на OpenWrt клиент прокси VLESS, Shadowsocks, Shadowsocks2022. Настройка sing-box и tun2socks | ITDog.info
Отключите авто роутинг в конфиге и работайте с отдельной таблицей маршрутов (rt_tables), добавьте в неё вручную default route dev singbox_tun, и затем ip rule add from tv_ip/32 table second_route_table
Пример команд после запуска singbox
ip route add default tun0 table 100
ip rule add from 192.168.1.100/32 table 100
Можно попробовать, но в свете последних тестов не уверен, что в этом есть смысл, вроде бы можно настроить и через sing-box. Слегка измененный минималистичный конфиг по ссылкам от @Texsis действительно работает, хотя и своеобразно. Некоторые сайты показывают удалённый IP, а некоторые домашний.
{
"log": {
"disabled": false,
"level": "debug",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"auto_route": true,
"strict_route": false,
"sniff": true
}
],
"outbounds": [
{
"type": "vless",
"tag": "vless-out",
"server": "IP_ADDR",
"server_port": 443,
"uuid": "UUID",
"flow": "xtls-rprx-vision",
"network": "tcp",
"tls": {
"enabled": true,
"server_name": "DOMAIN",
"alpn": [
"h2"
],
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "PUBLIC_KEY",
"short_id": "SHORT_ID"
}
},
"packet_encoding": "xudp"
}
],
"route": {
"auto_detect_interface": true
}
}
Опытным путём выяснил, что всё падает, если задать "strict_route": true. Буду разбираться дальше.
Перезагрузите тв, возможно в кеше остался старый маршрут для некоторых айпи адресов
Попробую, вероятно вы правы, иногда обновление страницы меняет отображаемый айпишник, хоть и не всегда.
По поводу strict_route не особо понимаю, насколько нужна эта опция. В справке вижу вот это:
Всё равно не понимаю 
Это описание того, что оно делает, или описание того, что я должен сделать, чтобы оно работало? И насколько вообще нужно включать эту опцию? Под Windows для всех клиентов обычно советуют включать, но здесь не знаю. auto_route у меня таки включен.
Сейчас у вас всё идёт по умолчанию в первый по списку outbound - vless-out. Добавьте в rules такое правило, чтобы направить локальный трафик мимо прокси:
{
"ip_is_private": true,
"outbound": "direct"
}
auto_route отключать не обязательно, на машине с одним интерфейсом, вроде той же малины, с ним будет прекрасно работать. Его отключают обычно, когда настраивают sing-box на роутере, чтобы не мешать работе маршрутизации на нём.
Вы правильно сделали, что отключили “strict_route”, про нее мало информации в документации, в моём понимании она нужна в тех случаях, когда sing-box используется в качестве клиента на конечных устройствах типа Android для предотвращения утечек IP. Когда sing-box выступает в роли шлюза для других хостов, её нужно отключать, иначе ничего работать не будет.
Окей, спасибо ip_is_private установил да. Ещё почитаю подробнее справку по sing-box на тему маршрутов и DNS, всё руки не доходили, видимо пора.
It works!
Если кому интересно, на доисторической Raspberry Pi 1B все это работает далеко от идеала, но работает. Железо в ней очень слабое, и если в режиме прокси в sing-box все выглядит пристойно, то более тяжелый tun просаживает скорость по speedtest до 6,5 - 8 Mbps, и даже банальный веб-серфинг становится довольно тормозным. Но потом вспомнил, что можно активировать разгон через sudo raspi-config. В режиме Turbo тормоза уходят, а speedtest выдает уже 12,5 Mbps. Youtube в статистике для сисадминов почему-то показывает чуть более высокую скорость и работает хорошо вплоть до 1440p@60fps (но 4K уже нет). Температура не поднимается выше 55 градусов (без радиатора).
В /etc/sysctl.conf прописал:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.ip_forward = 1
Конфиг для sing-box в итоге такой (домены для обхода блокировок взял из файла russia-youtube.txt в архиве с GoodbyeDPI). Логи отключил, чтобы лишний раз не дергать карту памяти.
{
"log": {
"disabled": true,
"level": "warn",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "local",
"address": "192.168.1.1",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"mtu": 9000,
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true
}
],
"outbounds": [
{
"type": "vless",
"tag": "vless-out",
"server": "IP_ADDRESS",
"server_port": 443,
"uuid": "UUID",
"flow": "xtls-rprx-vision",
"network": "tcp",
"tls": {
"enabled": true,
"server_name": "DOMAIN",
"alpn": ["h2"],
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "PUBLIC_KEY",
"short_id": "SHORT_ID"
}
},
"packet_encoding": "xudp"
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"domain_suffix": ".youtube.com",
"outbound": "vless-out"
},
{
"domain_suffix": ".youtu.be",
"outbound": "vless-out"
},
{
"domain_suffix": ".ytimg.com",
"outbound": "vless-out"
},
{
"domain_suffix": ".googlevideo.com",
"outbound": "vless-out"
}
],
"final": "direct",
"auto_detect_interface": true
}
}
Обращу внимание на директиву "final": "direct" в секции route, без нее весь трафик пойдет на удаленный сервер, а нам это не нужно. Еще я пытался вынести домены в отдельный файл, чтобы не вводить для каждого новую секцию в конфиге (хотя вот сейчас дошло, что секцию можно оставить одну, а суффиксы вписать массивом, но все равно хотелось бы вынести их из конфига в отдельный файл). И я даже успешно создал srs файл через
sing-box rule-set compile [--output <file-name>.srs] <file-name>.json
Но пока так и не понял, как этот srs файл подключить в конфиг. Пытался через rule_set, но видимо неправильно, потому что sing-box наотрез отказывается запускаться, и в логах почему-то пусто (хотя были включены). Если кто-то знает, пожалуйста подскажите.
для большей производительности добавь в tun
"gso": true
или можно перейти на iptables redirect, сделать его нетрудно:
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100
}
iptables -t nat -A PREROUTING -s tv_ip/32 -p tcp -j REDIRECT --to-port 100
Правильно будет вот так:
Содержимое youtube.json файла с правилами:
{
"version": 1,
"rules": [
{
"domain_suffix": [
".googlevideo.com",
".youtube.com",
".ggpht.com",
".ytimg.com",
".googleapis.com",
".youtu.be"
]
}
]
}
Подключение его в правилах конфига:
"route": {
"auto_detect_interface": true,
"final": "direct",
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": "youtube",
"outbound": "vless-out"
}
],
"rule_set": [
{
"tag": "youtube",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/youtube.json"
}
]
Если сконвертили в .srs через sing-box rule-set compile, то тогда "format": "binary"
Правда .srs скорее нужно для оптимизации огромных наборов правил, вроде списков antizapret с миллионом строк, как у этого товарища - GitHub - savely-krasovsky/antizapret-sing-box: Пример конфига
@MasterYoba а, значит я просто одно лишнее правило добавлял. Попробую как вы сказали, спасибо.
Это кстати пробовал, но заметных изменений не дало. Возможно, потому что ethtool -k eth0 выдаёт generic-segmentation-offload: off [requested on], принудительно включить не удалось.
Вообще любопытно. Если правильно понял, inbound типа redirect слушает на 100 порту, на который мы переводим запросы с ТВ. Спасибо, попробую так сделать.
Здравствуйте! А подскажите может есть успешные кейсы с Docker контейнером?
У меня есть хост докера, у него есть macvlan я этому контейнеру прописываю статический айпишник в локальной сети:
versi
on: "3.8"
services:
sing-box:
image: ghcr.io/sagernet/sing-box
container_name: sing-box
restart: always
volumes:
- $PWD/:/etc/sing-box/
command: -D /var/lib/sing-box -C /etc/sing-box/ run
networks:
macnet8:
ipv4_address: 192.168.50.6
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun
networks:
macnet8:
external: true
Конфиг уже использую практически полностью такой же как финальный у xofamim548
Вроде всё запускается, в логах чисто:
+0000 2024-08-08 17:03:01 INFO router: updated default interface eth0, index 406
+0000 2024-08-08 17:03:01 INFO inbound/tun[0]: started at tun0
+0000 2024-08-08 17:03:01 INFO sing-box started (0.00s)
Но когда у себя указываю в качестве дефолт гейтвея этот контейнер, то у меня всё умирает, никакого интернета нет. Что-то уже не знаю куда копать)) Собираюсь доставать физическую распбери уже))
попробуйте
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.ip_forward=1
Поменял, запустил контейнер в привилегированном режиме, но картина та же. В логах пустота…
У меня такого опыта именно с docker macvlan не было, если команды @0ka не помогут, я бы попробовал посмотреть через tcpdump -v, что происходит с трафиком внутри контейнера, что он не попадает в петлю и не дропается например. Как вариант, попробовать добавить в контейнер второй интерфейс с маршрутом default, чтобы трафик от устройств заходил в один интерфейс (который будет их шлюзом), а выходил в интернет через другой.
Бросил докер, убил на него уже часов 5, достал распберри 4, но не могу даже простой роутинг что-то настроить, или туплю или там ещё что-то нужно сделать кроме как включить:
net.ipv4.ip_forward = 1
Чтобы просто без впн через него трафик хотя бы начал ходить?
После этого выполнить (если ещё не)
sudo sysctl -p
и возможно
sudo systemctl restart NetworkManager.
По идее больше ничего. После этого указываете малину как шлюз, в качестве DNS роутер или 8.8.8.8. У меня работает так.
Странно но дело было в DNS. Но теперь ютуб просто какими-то скачками работает))) как буто супер ускоренный
Скачками это в смысле немного потормозит и резко раздупляется?) На youtube включите статистику для сисадминов, посмотрите что там с буферизацией происходит. И на малине посмотрите что происходит в htop. По идее в качестве шлюза она вообще без проблем должна работать.
На телевизоре нормально показывает в 4к, на компе что-то стало с буферизацией как будто сразу на несколько секунд вперед прыгает, но я ещё изучу! Спасибо всем за помощь! Кстати, в докере тоже заработало, когда DNS прописал. Но блин когда я просто пинговать пробовал по адресу, а не по имени никакого пинга не проходило. На компе от браузера зависит, в хроме большой дроп кадров, в сафари нет звука, при этом на телеке нормально и изображение и звук
Бегло потестировал с ПК - работает! Нагрузка значительно меньше, чем в режиме tun, видео в 4k летают. Прямо вау.
Чот какой-то был глюк уже на замученном компе походу с ютубом. Сейчас перезагрузился и через докер нормально показывает 4к!
Эх… сколько нам открытий чудных) Здорово! Надо будет тоже попробовать
Я выше оставил в команде только tcp, и если вы убрали tun, то udp трафик (quic) будет идти напрямую. Но можно заблокировать udp (reject) на 443 порту чтобы не работал quic, тогда будет еще меньше нагрузка на железо
Все работает, большое спасибо!
Если честно, не до конца понимаю, что происходит и почему так.
Создал inbound redirect в sing-box, прописал вот это для ip адресов ПК и телевизора:
iptables -t nat -A PREROUTING -s tv_ip/32 -p tcp -j REDIRECT --to-port 100
С ПК все работает замечательно, а вот с телевизора начинаются проблемы. Если так и оставить, то youtube на ТВ упирается в 11 - 12 Mbps. Если я правильно понимаю, телевизор пытается работать через quic напрямую, потому что если в sing-box сделать вот так:
{
"protocol": "quic",
"outbound": "block"
}
то youtube на ТВ перестаёт работать совсем.
Попробовал прописать как вы сказали:
iptables -A INPUT -s 192.168.1.36/32 -p udp --dport 443 -j REJECT
Но и в этом случае youtube на ТВ просто не работает.
вы tun оставили или убрали после добавления redirect?
у себя quic блокировал так
iptables -A FORWARD -p udp --dport 443 -j REJECT
tun убрал, оставил только это (привожу секции inbounds и route, параметры dns и outbounds не менял):
"inbounds": [
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100
}
],
...
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": "youtube",
"outbound": "vless-out"
}
],
"rule_set": [
{
"tag": "youtube",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/youtube.json"
}
],
"final": "direct"
}
В iptables сейчас два правила:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- 192.168.1.36 anywhere redir ports 100
-A FORWARD -p udp -m udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
Почему-то после этого приложение youtube просто зависает с серым экраном при открытии. НО если поставить final: “vless-out”, то youtube снова начинает работать 
Это странно, потому что для tun набор правил route был точно такой же, только убрал auto_detect_interface. Посмотрел
sudo tcpdump -n -i any udp and src 192.168.1.36
никаких UDP кроме бродкаста на :15600 там нет. Насколько я понимаю, tcpdump показывает трафик ещё до фильтров iptables.
Но если честно, я вообще не понимаю, что происходит. Прописал такой же редирект в iptables для ПК, вписал шлюз в настройки подключения, UDP на малине режектятся для всех устройств по вашему правилу, в route прописал final vless-out. В итоге получаю какую-то шизу:
- speedtest.net на TV, sing-box и редиректы отключены: хорошая скорость, даже выше чем на ПК
- speedtest.net на TV, sing-box и редиректы включены: 12,5 Mbps в обе стороны
- speedtest.net на ПК, в обоих случаях хорошая скорость.
Айпишники во всех случаях speedtest показывает как должно быть, да и по малине в htop сразу видна нагрузка. Ерунда какая-то.
Попробую как-нибудь позже посмотреть на свежую голову, может я чего-то упускаю.
пробуй этот конф (добавил sniff, domain_strategy)
{
"dns": {
"servers": [
{
"address": "udp://1.1.1.1"
}
],
"strategy": "ipv4_only"
},
"inbounds": [
{
"domain_strategy": "ipv4_only",
"listen": "0.0.0.0",
"listen_port": 100,
"sniff": true,
"tag": "redirect-in",
"type": "redirect"
},
{
"auto_route": true,
"domain_strategy": "ipv4_only",
"gso": true,
"inet4_address": "198.18.0.1/30",
"interface_name": "singtun",
"mtu": 1500,
"sniff": true,
"tag": "tun-in",
"type": "tun"
},
{
"listen": "0.0.0.0",
"listen_port": 53,
"sniff": true,
"tag": "dns-cache",
"type": "direct"
}
],
"log": {
"level": "info"
},
"outbounds": [
{
#vless
},
{
"tag": "dns-out",
"type": "dns"
},
{
"tag": "direct",
"type": "direct"
},
{
"tag": "block",
"type": "block"
}
],
"route": {
"auto_detect_interface": true,
"final": "direct",
"rule_set": [
{
"format": "source",
"path": "/etc/sing-box/rule-set/youtube.json",
"tag": "youtube",
"type": "local"
}
],
"rules": [
{
"outbound": "dns-out",
"protocol": "dns"
},
{
"outbound": "vless-out",
"rule_set": "youtube"
}
]
}
}
iptables -A FORWARD -p udp --dport 443 -j REJECT
iptables -t nat -A PREROUTING -s tv_ip/32 -p tcp -j REDIRECT --to-port 100
редирект вроде бы не может в udp поэтому tun остаётся на всякий случай для udp трафика.
устройства перезагрузить после запуска сервиса и применения правил, или если винда, то можно выполнить
netsh interface ip delete destinationcache
Окей, большое спасибо, попробую на выходных. Про перезагрузки кстати, тоже думал, что может какой-то мусор остаётся, и малину перезагружал и телевизор от питания отключал, но нет. Попробую этот конфиг, посмотрим что получится.
Чтобы лишний раз не отнимать чужое время, уточню сразу: в принципе я добился того, что мне нужно, и текущая ситуация (с учётом нулевых затрат) меня вполне устраивает. Тем не менее, рассказываю, что в итоге получилось (спойлер: получилось странное) с ноткой некоторого недоумения.
В iptables следующее:
sudo iptables -t nat -A PREROUTING -s 192.168.1.36/32 -p tcp -j REDIRECT --to-port 100
sudo iptables -A FORWARD -p udp --dport 443 -j DROP
(Разницы между DROP и REJECT не увидел, да и дело по-моему совсем не в QUIC, я не вижу udp запросов с телевизора на 443 порт ни в логах, ни в tcpdump. Также прописал редиректы для ПК и смартфона, но об этом потом.)
Ваш конфиг тоже не заработал, но вы подбросили мне идею: я действительно забыл про sniff в инбаунде redirect. Если добавить sniff и sniff_override_destination, то что-то слегка меняется, по крайней мере приложение начинает открываться, но по-прежнему как будто бы идет через РФ. К тому моменту я уже почитал тему о маркировке российских IP гуглом и от греха подальше решил перейти к обычной гео фильтрации, которой уже сто лет пользуюсь во всех клиентах. Ссылки на srs украл из hiddify:
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geoip-ru.srs"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geosite-category-ru.srs"
}
],
"final": "vless-out",
"auto_detect_interface": true
}
Но и это ничего не изменило.
А потом я вспомнил, что во всех клиентах на ПК у меня всегда был прописан DoH без условий, да и в Firefox по вашему совету тоже. И наконец-то получил рабочий конфиг:
{
"log": {
"disabled": false,
"level": "debug",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"final": "google",
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"mtu": 1500,
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100,
"domain_strategy": "ipv4_only",
"sniff": true,
"sniff_override_destination": true
}
],
"outbounds": [
{
# vless-out
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geoip-ru.srs"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geosite-category-ru.srs"
}
],
"final": "vless-out",
"auto_detect_interface": true
}
}
Я не знаю, почему, но в отличие от всего остального оно работает.
Веселье, брызги шампанского, тему можно закрывать? Не совсем 
Осталась крайне загадочная проблема, корни которой я понять не могу. Скорость на ТВ действительно становится выше - ну, типа, с 8 - 9 Mbps по speedtest она вырастает до 13 - 14 Mbps (upload всегда на 1 - 2 мегабита выше, чем download, хотя в тестах без sing-box обычно наоборот). В приложении youtube изменения примерно такие же. В то же время на ПК с Windows 10 скорость становится намного выше, упираясь только в обычную ширину канала по wi-fi, а youtube без проблем открывает 4K 60 fps. Все тесты на speedtest делаются до одного и того же сервера, во всех случаях верно определяется удаленный IP-адрес.
Аналогичную проблему вижу на смартфоне с Android, для которого я тоже прописал редирект в iptables: там скорость опять-таки бьется в потолок 13 - 14 Mbps, и youtube тоже не воспроизводит 4K.
Что общего между смартфоном на Android и ТВ Samsung, чего нет у Windows - я понять не могу. Пробовал отключать в Firefox DoH и чистить кэш запросов, отключать http3 и даже http2, тестировать через Chrome, прописывать одни и те же dns-серверы на всех устройствах (8.8.8.8, или роутер, или малина) - и неизменно получаю высокую скорость на ПК, а на телевизоре и смартфоне неизменно упираюсь в 13 - 14 Mbps (с той же небольшой разницей в пользу upload). Единственная особенность ПК - то, что он подключен к Wi-Fi через Keenetic Start в режиме адаптера, но не уверен, что это как-то может влиять на ситуацию.
nload на rpi показывает ту же скорость что и пк при спидтесте?
а если включить bbr на rpi и сервере?
На сервере включен, на rpi включил сейчас, но увы - ничего не меняется.
Ладно, спасибо большое, думаю пора оставить это дело) Подумаю еще на досуге, может что-то придет в голову, должна же быть какая-то объяснимая разница между устройствами. Может еще с чего-нибудь потестирую.
Всем привет, столкнулся с такой же проблемой, что и автор, взял последний конфиг, но в секции outbounds заменил vless на socks
{
"type": "socks",
"tag": "socks-out",
"server": "192.168.1.182",
"server_port": 1080,
"version": "5",
"network": "tcp",
"udp_over_tcp": false
}
Такая конфигурация отлично работает на винде, но вот на телеке Samsung не работает, после запуска ютуба серый экран или лого ютуба висит.
Судя по логу sing box запрос до сервера доходит нормально
-0400 2024-08-13 06:50:55 DEBUG dns: exchange www.youtube.com. IN AAAA
-0400 2024-08-13 06:50:55 DEBUG dns: exchange www.youtube.com. IN A
-0400 2024-08-13 06:50:55 DEBUG dns: strategy rejected
-0400 2024-08-13 06:50:55 DEBUG dns: exchanged www.youtube.com NOERROR 300
-0400 2024-08-13 06:50:55 INFO dns: exchanged www.youtube.com CNAME www.youtube.com. 300 IN CNAME youtube-ui.l.google.com.
-0400 2024-08-13 06:50:55 INFO dns: exchanged www.youtube.com CNAME youtube-ui.l.google.com. 300 IN CNAME wide-youtube.l.google.com.
-0400 2024-08-13 06:50:55 INFO dns: exchanged www.youtube.com A wide-youtube.l.google.com. 300 IN A 142.251.1.198
-0400 2024-08-13 06:50:55 INFO [1466161358 0ms] inbound/tun[0]: inbound connection from 192.168.1.10:59817
-0400 2024-08-13 06:50:55 INFO [1466161358 0ms] inbound/tun[0]: inbound connection to 142.251.1.198:443
-0400 2024-08-13 06:50:55 DEBUG [1466161358 29ms] router: sniffed protocol: tls, domain: www.youtube.com
-0400 2024-08-13 06:50:55 DEBUG [1466161358 30ms] dns: resolved [142.251.1.198]
-0400 2024-08-13 06:50:55 INFO [1466161358 30ms] outbound/socks[socks-out]: outbound connection to 142.251.1.198:443
-0400 2024-08-13 06:50:56 INFO [4115249208 0ms] inbound/tun[0]: inbound packet connection from 192.168.1.10:53517
-0400 2024-08-13 06:50:56 INFO [4115249208 0ms] inbound/tun[0]: inbound packet connection to 8.8.8.8:53
-0400 2024-08-13 06:50:56 DEBUG [4115249208 0ms] router: sniffed packet protocol: dns
-0400 2024-08-13 06:50:56 DEBUG [4115249208 0ms] router: match[0] protocol=dns => dns-out
Подскажите куда капнуть, в какую сторону посмотреть
@xofamim548 добрый день, следил за вашим решением почти в прямом эфире. Возможно не до конца понимаю всех тонкостей. Я попробовал использовать ваше решение, но у меня какие то проблемы с geo-ip. Если можете подсказать буду крайне признателен. Проблема на скрине
Верно ли я понимаю, что UDP-запросы идут вникуда? Мой опыт показал, что на самсунге без UDP работать не будет, блокировать можно только на 443 порту. Если UDP идут куда-то мимо удалённого сервера, то скорее всего тоже не будет.
Всё хотел посмотреть, что там на UDP завязано, но малость устал всё это настраивать, так руки и не дошли.
Честно сказать, я тоже до сих пор не понимаю всех тонкостей Сбросьте сюда полный конфиг sing-box без чувствительных данных, возможно тег google где-то повторно используется не в тему. И заодно результат выполнения
cat /etc/resolv.conf
Т.е. UDP тоже надо пустить на удаленный сервер?
В iptables добавлял обе настройки как в вашем примере
Да, верно, UDP надо пропускать на удалённый. В соседней теме обсуждали проблему с Samsung и (Good)byeDPI, там тоже у людей странности, телевизор куда-то ещё обращается помимо доменов youtube. Подозреваю, что по UDP, хотя повторюсь, не проверял.
В iptables у меня два правила, это верно (дропы для udp :443 и редирект tcp на 100-й порт).
Сейчас вот попробовал зарезать весь UDP через iptables, та же ситуация, сразу перестает работать и серый экран. Выше по теме можно найти, когда я пускал в редирект только tcp и не делал tun интерфейс для udp (то есть udp шел напрямую), опять же было лого youtube или серый экран.
Спасибо огромное, в итоге ваш конфиг с небольшим изменением с vless на socks работает отлично!!!
Моя ошибка была в том, что я не сохранил изменения в iptables, поэтому ничего не работало.
Рано радовался, выключил телек, включил и снова приложение ютуба не работает
Если UDP настроили, попробуйте на телевизоре вписать DNS 8.8.8.8.
Вообще опять-таки слабо понимаю, как ходят DNS-запросы в моей последней конфигурации, @0ka не подскажете? Вот этот DoH гугла вообще используется или нет? Потому что я сейчас попробовал позахватывать UDP трафик, и у меня такое чувство, что нет.
capture-udp.pcap (57,2 КБ)
Поменял DNS на 8.8.8.8, результат тот же.
Для полной картины вот мой конфиг:
{
"log": {
"disabled": false,
"level": "trace",
"output": "/etc/sing-box/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "local",
"address": "192.168.1.1",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"mtu": 9000,
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100,
"domain_strategy": "ipv4_only",
"sniff": true,
"sniff_override_destination": true
}
],
"outbounds": [
{
"type": "socks",
"tag": "socks-out",
"server": "192.168.1.182",
"server_port": 1080,
"version": "5",
"network": "tcp",
"udp_over_tcp": true
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geoip-ru.srs"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geosite-category-ru.srs"
}
],
"final": "socks-out",
"auto_detect_interface": true
}
}
Без этой секции пробовали?
Мне она всё сильно портила почему-то. Пока не прописал тег google в качестве final, ничего не работало.
P. S. Надо все-таки сесть и разобраться с dns запросами в sing-box, не понимаю, как там разные секции друг с другом связаны.
Вообще я понял, что если я хочу всегда использовать DoH гугла (а я хочу), то конфиг можно упростить до такого состояния:
{
"log": {
"disabled": true,
"level": "info",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"final": "google",
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"mtu": 1500,
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100,
"domain_strategy": "ipv4_only",
"sniff": true,
"sniff_override_destination": true
}
],
"outbounds": [
{
# vless-out
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
}
],
"route": {
"rules": [
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geoip-ru.srs"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geosite-category-ru.srs"
}
],
"final": "vless-out",
"auto_detect_interface": true
}
}
Примерное понимание работы DNS и правил дает вот этот пример: Sing-Box DNS - VPN Router for Home Networks
Я, правда, так до конца и не уверен, какие ответы от 8.8.8.8 на 53 порту в итоге отображает tcpdump. Если я корректно понимаю, телевизор пытается обращаться к 8.8.8.8 (установлен в настройках тв), sing-box перенаправляет запрос согласно правилам, а потом как бы возвращает ответ от 8.8.8.8. Но это если я правильно понял.
Выкроил еще немного времени и протестировал кучу разных конфигов, в том числе те, которые у меня не работали. Тестировал с полной перезагрузкой телевизора с выключением из розетки на 30+ секунд. (Всем советую делать так же.)
Во-первых, как я и предположил выше, UDP на 443 порту можно не блокировать (хотя возможно зависит от модельного года, но у меня QUIC не используется).
Во-вторых, за эти дни что-то поменялось. Все конфиги с redirect+tun, которые у меня не работали по причинам, теперь работают. С локальными DNS, с удаленными DNS, с роутингом по geoip и geosite, с роутингом по файлику youtube.json - работают, и видео открываются, и поиск, и рекомендации, все как рукой сняло. Иногда проявляется странный нюанс: в тех конфигах, что раньше не работали, приложение youtube временами открывается со второго раза. В первый раз начинает загружаться, вылетает, и телевизор выдает сообщение “Произошла ошибка сети”. Снова открываешь youtube - работает. Но ошибка воспроизводится как-то нестабильно.
В итоге оставил так:
{
"log": {
"disabled": true,
"level": "info",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"final": "google",
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"mtu": 1500,
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "0.0.0.0",
"listen_port": 100,
"domain_strategy": "ipv4_only",
"sniff": true,
"sniff_override_destination": true
}
],
"outbounds": [
{
"type": "vless",
"tag": "vless-out",
"server": "IP_ADDR_HERE",
"server_port": 443,
"uuid": "UUID_HERE",
"flow": "xtls-rprx-vision",
"network": "tcp",
"tls": {
"enabled": true,
"server_name": "DOMAIN_HERE",
"alpn": ["h2"],
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "PUBLIC_KEY_HERE",
"short_id": "SHORT_ID_HERE"
}
},
"packet_encoding": "xudp"
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
}
],
"route": {
"rules": [
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"geoip-ru",
"geosite-ru"
],
"outbound": "direct"
}
],
"rule_set": [
{
"type": "remote",
"tag": "geoip-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geoip-ru.srs"
},
{
"type": "remote",
"tag": "geosite-ru",
"format": "binary",
"url": "https://raw.githubusercontent.com/Chocolate4U/Iran-sing-box-rules/rule-set/geosite-category-ru.srs"
}
],
"final": "vless-out",
"auto_detect_interface": true
}
}
Также если кому-то интересно, при роутинге по youtube.json сам файлик выглядел так:
{
"version": 1,
"rules": [
{
"domain_suffix": [
".googlevideo.com",
".youtube.com",
".ggpht.com",
".ytimg.com",
".googleapis.com",
".youtu.be",
".google.com",
".yt.be",
".youtubekids.com",
".nhacmp3youtube.com",
".googleusercontent.com",
".gstatic.com"
]
}
]
}
Еще пара мыслей для тех, у кого все работало, а потом перестало.
- Отключить ipv6, если не используете. Поначалу отключал так:
sudo nano /etc/sysctl.conf
Добавить в конец:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.ip_forward=1
и выполнить:
sudo sysctl -p
Оно даже срабатывает, но после перезагрузки ipconfig почему-то снова показывает ipv6 адрес, что может создавать неприятности. Есть статья по RPI, в которой написано, как надо:
sudo nano /boot/firmware/cmdline.txt
Добавить в конец строки: ipv6.disable=1
После этого сделать sudo reboot и выполнить ifconfig, чтобы убедиться, что ipv6 для eth0 больше не отображается.
- Не забывать сохранять правила iptables, чтобы не слетали после перезагрузки.
sudo iptables -t nat -A PREROUTING -s IP_ТЕЛЕВИЗОРА/32 -p tcp -j REDIRECT --to-port 100
sudo apt-get install iptables-persistent
sudo netfilter-persistent save
sudo systemctl enable netfilter-persistent
sudo systemctl start netfilter-persistent
- sing-box после перезагрузки может стартовать слишком рано. Если после ребута все перестало работать, проверить статус сервиса sing-box. Если он failed, хотя раньше запускался, то надо поправить конфиг sing-box.service примерно так (главным образом строку After):
[Unit]
Description=Sing-Box Service
After=network.target nss-lookup.target network-online.target
[Service]
ExecStart=/usr/local/bin/sing-box run -c /etc/sing-box/config.json
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Хотя по идее в репах должен быть правильный конфиг, но мало ли.
Поделюсь своим опытом настройки.
Дано
- SmartTV Samsung c TizenOS (т.е. не умеет в прокси и VPN),
- роутер с OpenWRT 23.05.0 с современным железом (поддержка WiFi 5 и выше),
- VPS на территории потанцевального противника
Задача
Реализация желания смотреть Ютуб, злоумышленно эксплуатируя уязвимость в виде статьи 29 Конституции РФ.
Решение
sing-box на роутере + пара правил nftables на нём же.
Подробности:
Ставим sing-box
opkg update && opkg install sing-box
Конфиг sing-box
cat /etc/config/sing-box
config sing-box 'main'
option enabled '1'
option user 'sing-box'
option conffile '/etc/sing-box/config.json'
option workdir '/usr/share/sing-box'
cat /etc/sing-box/config.json
{
"log": {
"level": "warn",
"disabled": false
},
"dns": {
"servers": [
{
"tag": "dns-google",
"address": "tls://8.8.8.8",
"detour": "vless-xtls-vision-out"
},
{ // в моём случае "address" не "local", т.к. на роутере крутится DNS-сервер для WAN и LAN сетей
// и настроены разные view для локальных и внешних клиентов.
// На интерфейсе 192.168.1.1 я гарантированно попадаю на view LAN и мой домен резолвится в его локальный IP, а не в белый.
"tag": "dns-local",
"address": "192.168.1.1",
"detour": "direct-out"
}
], //servers
"rules": [
{
"outbound": [
"direct-out"
],
"server": "dns-local"
},
{
"domain_suffix": [
"local",
"home",
"isp.local.site"
],
"server": "dns-local"
},
{
"outbound": [
"vless-xtls-vision-out"
],
"server": "dns-google"
}
]
}, // dns
"inbounds": [
{
"type": "redirect",
"tag": "redirect-in",
"listen": "192.168.1.1",
"listen_port": 3129,
"sniff": true,
"tcp_fast_open": true
},
{
"listen": "192.168.1.1",
"listen_port": 3130,
"tag": "vless-xtls-vision-mixed-in",
"type": "mixed"
}
],
"outbounds": [
{
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp",
"server": "REDACTED",
"server_port": 443,
"tag": "vless-xtls-vision-out",
"tls": {
"enabled": true,
"server_name": "REDACTED",
"utls": {
"enabled": true,
"fingerprint": "chrome"
}
},
"type": "vless",
"uuid": "REDACTED"
},
{
"type": "direct",
"tag": "direct-out"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{ // rule for connecting without proxy
"domain_suffix": [
"local",
"home",
"isp.local.site"
],
"outbound": "direct-out"
},
{ // Youtube for Samsung Smart TV
"inbound": "redirect-in",
"domain_suffix": [
"youtube.com",
"youtu.be",
"googlevideo.com",
"ytimg.com"
],
"outbound": "vless-xtls-vision-out"
},
{
"rule_set": "antizapret",
"outbound": "vless-xtls-vision-out"
},
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"inbound": "redirect-in",
"outbound": "direct-out"
},
{
"inbound": "vless-xtls-mixed-in",
"outbound": "vless-xtls-vision-out"
}
], //rules
"rule_set": [
{ // Remote rule-set will be cached if experimental.cache_file.enabled.
"tag": "antizapret",
"type": "remote",
"format": "binary",
"url": "https://github.com/savely-krasovsky/antizapret-sing-box/releases/latest/download/antizapret.srs",
"download_detour": "vless-xtls-vision-out",
"update_interval": "1d"
}
]
}
}
Правила nftables
В формате UCI:
/etc/config/firewall
config rule
option enabled 1
option name SamsungTV-block-quick
option target REJECT
option src lan
option dest wan
option proto udp
option src_ip 'SMART.TV.IP.ADDRESS'
option dest_port 443
option family ipv4
config redirect
option enabled 1
option name SamsungTV-redirect-HTTPS-to-sing-box
option target DNAT
option src lan
option dest wan
option proto tcp
option src_ip 'SMART.TV.IP.ADDRESS'
option src_dport 443
option dest_ip '192.168.1.1'
option dest_port 3129 # port of 'redirect-in' sing-box inbound
option family ipv4
В виде правил nftables:
fw4 print:
chain forward_lan {
ip saddr SMART.TV.IP.ADDRESS udp dport 443 counter jump reject_to_wan comment "!fw4: DNAT-SamsungTV-block-quick"
}
chain dstnat_lan {
ip saddr SMART.TV.IP.ADDRESS tcp dport 443 counter dnat 192.168.1.1:3129 comment "!fw4: DNAT-SamsungTV-redirect-HTTPS-to-sing-box"
}
В данном случае блочим QUICK (UDP/443) и редиректим только HTTPS (TCP/443). Можно редиректить и весь трафик Smart TV, но у меня и так прекрасно работает.
Crontab
crontab -e
# restart sing-box every 2 hours to avoid high memory consumption and OOM-killer spawning
0 */2 * * * /etc/init.d/sing-box restart
Итого
Редиректим HTTPS со смартТВ на “redirect”-вход sing-box и ходим на домены, имеющие отношение к YouTube, через прокси.
Также имеем HTTP/SOCKS прокси.
Маршрутизация несложная: сначала на локальные домены и на сайт провайдера лезем напрямую, затем правило для SmartTV, которое редиректит трафик Ютуба в прокси.
Далее бонусом идёт маршрутизация на основе правил Antizapret в новом формате (SRS).
Ещё далее - это скорее fallbacks, до них дело вряд ли дойдёт.
Каждые два часа рестартим sing-box во избежание прихода OOM-killer.
Тут нужно заметить, что sing-box (как и xray) просто не запускается, если ограничить виртуальную память процесса до менее чем 800 МБ. На роутере, как вы понимаете, пока таких объёмов RAM нет. По умолчанию sing-box заявляет себе 1.2 ГБ виртуальной памяти а мы надеемся что ему не понадобится больше, чем у нас есть (у меня на роутере 256 МБ RAM). Поэтому на всякий случай рестартим sing-box каждые 2 часа. На современном роутере (WiFi 5+) это происходит моментально. Почему эти программы требуют (не потребляют!) так много виртуальной памяти - я не погромист, поэтому не знаю, в коде гошечки не колупался.
Бегло протестировал - Ютуб на ТВ заработал как встарь. Пользуйтесь, друзья!
@ValdikSS , привет тебе из Гудлайновской сети!
Спустя некоторое время эксплуатации sing-box на Openwrt пришлось немного доработать напильником, чтобы это всё работало стабильно. Нестабильно это всё работало потому, что телевизор - не единственный клиент для sing-box на роутере, и коннектов довольно приличное количество круглосуточно.
Доработки:
-
Блокировка IPv6-коннектов в sing-box. Если IPv6 нет, то делать это обязательно, т.к. неотключение обязательно влёчёт за собой наличие большого количества соединений в таймауте, и они забивают таблицу nf_conntrack. Просто потому, что по умолчанию
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60. -
Увеличение количества открытых файлов для процесса sing-box
-
В
/etc/sing-box/config.jsonв секцию"dns"добавить опцию"strategy": "ipv4_only":
"dns": {
"strategy": "ipv4_only",
"servers": [
{
"tag": "dns-google",
...
- в
/etc/init.d/sing-boxпосле строк
procd_open_instance "$NAME.main"
procd_set_param command "$PROG" run -c "$conffile" -D "$workdir"
добавить
procd_set_param limits nofile="65536 65536"
ВАЖНО: Любое обновление пакета sing-box перезапишет файл /etc/init.d/sing-box на тот, который идёт с пакетом. Поэтому после каждого обновления sing-box нужно заново прописывать лимит.
- в
/etc/sysupgrade.confдобавить строку
/etc/init.d/sing-box, если сохраняете конфиги.
Без этих мер sing-box работал нестабильно и падал. Или не падал, но упирался в лимиты, спамил ошибками в лог и для меня как пользователя сервиса фактически сервис не предоставлялся. Сейчас sing-box не падает, в лимиты не упирается, спама ошибок нет, сервис работает вторые сутки стабильно.
Возможно поможет только пункт №1, т.к. все упоры в лимиты происходили из-за него. Но я не тестировал. Просто привожу мой подход к решению проблемы.
Хочу настроить sing-box, чтобы только определенные подсети и домены шли к VPS-серверу, а все остальное шло через bypass. После тестирования своего конфига было вроде все ок, но имеется проблема с udp трафиком.
На прокси сервере в локалке два правила для fw:
iptables -t nat -A PREROUTING -s 192.168.13.0/25 -p udp -j REDIRECT --to-port 100
iptables -t nat -A PREROUTING -s 192.168.13.0/25 -p tcp -j REDIRECT --to-port 100
Сам конфиг sing-box выглядит следующим образом:
{
"dns": {
"independent_cache": true,
"rules": [
{
"domain": [
"2ip.ru",
"youtube.com",
"googlevideo.com",
"ytimg.com",
"youtu.be",
"ggpht.com",
"youtubei.googleapis.com",
"yt4.ggpht.com",
"ytimg.l.google.com",
"nhacmp3youtube.com",
"googleusercontent.com",
"googleapis.com",
"gstatic.com"
],
"domain_keyword": [],
"domain_regex": [],
"domain_suffix": [],
"geosite": [],
"server": "dns-remote"
},
{
"query_type": [
32,
33
],
"server": "dns-block"
},
{
"domain_suffix": ".lan",
"server": "dns-block"
}
],
"servers": [
{
"address": "https://1.1.1.1/dns-query",
"address_resolver": "dns-local",
"detour": "proxy",
"strategy": "prefer_ipv4",
"tag": "dns-remote"
},
{
"address": "local",
"address_resolver": "dns-local",
"detour": "direct",
"strategy": "prefer_ipv4",
"tag": "dns-direct"
},
{
"address": "rcode://success",
"tag": "dns-block"
},
{
"address": "local",
"detour": "direct",
"tag": "dns-local"
}
]
},
"inbounds": [{
"type": "redirect",
"tag": "redirect-in",
"sniff": true,
"listen": "0.0.0.0",
"listen_port": 100
}],
"log": {
"level": "info"
},
"outbounds": [
{
"domain_strategy": "",
"flow": "xtls-rprx-vision",
"packet_encoding": "",
"server": "111.111.111.111",
"server_port": 44444,
"tag": "proxy",
"tls": {
"enabled": true,
"reality": {
"enabled": true,
"public_key": "wwwwwwwwwwwwwwwwwwwwwwwwwww",
"short_id": "ccccccccc"
},
"server_name": "google.com",
"utls": {
"enabled": true,
"fingerprint": "safari"
}
},
"type": "vless",
"uuid": "66666666666666666666"
},
{
"tag": "direct",
"type": "direct"
},
{
"tag": "bypass",
"type": "direct"
},
{
"tag": "block",
"type": "block"
},
{
"tag": "dns-out",
"type": "dns"
}
],
"route": {
"final": "bypass",
"rules": [
{
"outbound": "dns-out",
"protocol": "dns"
},
{
"domain": [],
"domain_keyword": [],
"domain_regex": [],
"domain_suffix": [],
"geosite": [
"category-ads-all"
],
"outbound": "block"
},
{
"domain": [
"2ip.ru",
"youtube.com",
"googlevideo.com",
"ytimg.com",
"youtu.be",
"ggpht.com",
"youtubei.googleapis.com",
"yt4.ggpht.com",
"ytimg.l.google.com",
"nhacmp3youtube.com",
"googleusercontent.com",
"googleapis.com",
"gstatic.com"
],
"domain_keyword": [],
"domain_regex": [],
"domain_suffix": [],
"geosite": [],
"outbound": "proxy"
},
{
"geoip": [],
"ip_cidr": [
"147.75.208.0/20",
"185.89.216.0/22",
"31.13.24.0/21",
"31.13.64.0/19",
"31.13.96.0/19",
"45.64.40.0/22",
"66.220.144.0/20",
"69.63.176.0/20",
"69.171.224.0/19",
"74.119.76.0/22",
"102.132.96.0/20",
"103.4.96.0/22",
"129.134.0.0/16",
"157.240.0.0/16",
"173.252.64.0/18",
"179.60.192.0/22",
"185.60.216.0/22",
"204.15.20.0/22",
"102.221.188.0/22",
"163.114.128.0/20",
"164.163.191.64/26",
"199.201.64.0/22",
"64.233.160.0/19",
"66.102.0.0/20",
"66.249.64.0/18",
"72.14.192.0/18",
"74.125.0.0/16",
"209.85.128.0/17",
"216.239.32.0/19",
"64.18.0.0/20",
"108.177.8.0/21",
"172.217.0.0/19",
"173.194.0.0/16",
"207.126.144.0/20",
"216.58.192.0/19",
"3.2.40.0/25",
"3.4.3.0/24",
"3.4.4.0/24",
"3.4.6.0/24",
"3.5.76.0/22",
"3.5.80.0/21",
"13.34.14.128/26",
"13.34.23.96/27",
"13.34.23.128/25",
"13.34.24.96/27",
"13.34.24.128/26",
"13.34.24.192/27",
"13.34.25.64/26",
"13.34.25.128/26",
"13.34.26.0/25",
"13.34.28.0/24",
"13.34.42.128/26",
"13.34.54.96/27",
"13.34.54.128/25",
"13.34.55.0/27",
"13.34.57.0/26",
"13.34.61.192/26",
"13.34.67.64/26",
"13.34.67.128/25",
"13.34.68.0/26",
"13.34.70.64/26",
"13.34.79.64/26",
"13.34.82.64/26",
"13.34.82.128/25",
"13.34.85.64/26",
"13.34.86.192/26",
"13.34.88.192/26",
"13.34.93.128/26",
"13.248.112.0/24",
"15.177.80.0/24",
"15.181.0.0/19",
"15.181.64.0/20",
"15.181.116.0/22",
"15.181.128.0/20",
"15.181.245.0/24",
"15.181.248.0/24",
"15.181.250.0/23",
"15.181.252.0/23",
"15.193.7.0/24",
"15.220.0.0/19",
"15.220.32.0/21",
"15.220.40.0/22",
"15.220.200.0/21",
"15.220.208.128/26",
"15.220.224.0/23",
"15.220.226.0/24",
"15.220.252.0/22",
"15.221.1.0/24",
"15.221.7.0/24",
"15.221.148.0/23",
"15.230.67.192/26",
"15.230.68.0/25",
"15.230.92.0/24",
"15.230.240.0/24",
"15.230.247.0/24",
"15.248.40.0/22",
"15.248.80.0/20",
"15.253.0.0/16",
"15.254.0.0/16",
"18.34.48.0/20",
"18.34.244.0/22",
"18.88.128.0/18",
"18.236.0.0/15",
"18.246.0.0/16",
"34.208.0.0/12",
"35.71.64.0/22",
"35.80.0.0/12",
"35.155.0.0/16",
"35.160.0.0/13",
"44.224.0.0/11",
"50.112.0.0/16",
"52.10.0.0/15",
"52.12.0.0/15",
"52.24.0.0/14",
"52.32.0.0/13",
"52.40.0.0/14",
"52.46.180.0/22",
"52.46.216.0/22",
"52.46.249.0/24",
"52.75.0.0/16",
"52.88.0.0/15",
"52.92.128.0/17",
"52.93.12.12/31",
"52.93.14.18/31",
"52.93.20.0/24",
"52.93.120.179/32",
"52.93.122.218/32",
"52.93.240.146/31",
"52.93.240.148/31",
"52.93.240.152/29",
"52.93.240.160/27",
"52.93.240.192/29",
"52.93.240.200/30",
"52.93.240.204/31",
"52.94.10.0/24",
"52.94.28.0/23",
"52.94.76.0/22",
"52.94.116.0/22",
"52.94.120.0/22",
"52.94.128.0/22",
"52.94.176.0/20",
"52.94.197.0/24",
"52.94.208.0/21",
"52.94.248.96/28",
"52.94.249.64/28",
"52.95.40.0/24",
"52.95.230.0/24",
"52.95.247.0/24",
"52.95.255.112/28",
"52.119.160.0/20",
"52.119.252.0/22",
"52.144.194.64/26",
"52.144.194.128/26",
"52.144.197.128/25",
"52.218.128.0/17",
"54.68.0.0/14",
"54.148.0.0/15",
"54.184.0.0/13",
"54.200.0.0/14",
"54.212.0.0/15",
"54.214.0.0/16",
"54.218.0.0/16",
"54.239.0.32/28",
"54.239.2.0/23",
"54.239.48.0/22",
"54.240.230.0/23",
"54.240.248.0/21",
"54.244.0.0/15",
"64.252.65.0/24",
"64.252.70.0/23",
"64.252.72.0/23",
"70.224.192.0/18",
"99.77.130.0/24",
"99.77.152.0/24",
"99.77.186.0/24",
"99.77.232.0/24",
"99.77.253.0/24",
"99.78.196.0/22",
"99.150.56.0/21",
"99.151.186.0/23",
"100.20.0.0/14",
"108.166.224.0/21",
"108.166.240.0/21",
"142.4.160.16/29",
"142.4.160.32/29",
"142.4.160.56/29",
"142.4.160.64/29",
"142.4.160.96/28",
"142.4.160.224/29",
"150.222.15.132/31",
"150.222.74.0/23",
"150.222.102.0/24",
"150.222.176.0/22",
"150.222.180.0/24",
"150.222.196.0/24",
"150.222.214.0/24",
"151.148.33.0/24",
"162.222.148.0/22",
"176.32.125.0/25",
"176.32.125.128/26",
"184.32.0.0/12",
"205.251.232.0/22"
],
"outbound": "proxy"
},
{
"network": "udp",
"outbound": "block",
"port": [
135,
137,
138,
139,
5353
]
},
{
"ip_cidr": [
"224.0.0.0/3",
"ff00::/8"
],
"outbound": "block"
},
{
"outbound": "block",
"source_ip_cidr": [
"224.0.0.0/3",
"ff00::/8"
]
}
]
}
}
Что нужно добавить или убавить чтобы с udp все было ок?
для udp надо использовать tproxy или tun. ну и правила у вас полная жесть
Парни! Не понимаю почему вы sing-box мучаете? Имея Малинку можно домашний трафик не заворачивать в WG чтобы толкнуть его VLESS-ом (или shadowsocks) на свой VPS. Устанавливайте 3X-ui на VPS и Малину! В панели 3X-ui Малины создайте HTTP-прокси (для домашних - без пароля), и делайте бридж на внешний VPS. В маршрутизации задаете правило и всё прекрасно работает. Настраивать довольно легко.
Дам пример, где человек тоже делает через WG. Можно пойти по его инструкциям, но… ещё раз - (наверное) достаточно HTTP-прокси для дома. В браузерах или в системе, указываете, что ходить в Интет нужно через прокси и… радуетесь! Если кто-то домашним биторентом пользуется, то можно добавить правило обхода в маршрутизации - direct - IP и порт, и поднять это правило над созданным Inboud.
Не реклама: “Настройка двойного VPN через 3X-UI”
Если честно, по приведенной ссылке на скринах вообще ничего не видно. Поэтому я не совсем понял, в чем плюс конкретно 3x-ui, у которого под капотом все тот же xray (который делает то же что и sing-box).
В браузерах или в системе, указываете, что ходить в Интет нужно через прокси
Так а если в браузерах или системе нельзя указать, что нужно через прокси ходить?
Когда начнете панель настраивать, то всё будет видно: смотрите на свой экран и на картинку - мелкие детали ничего не дают. Да и другого примера я не видел нигде, а так бы поделился.
А на счет прокси… ну, может, на ТВ может и не быть, конечно. А так… про всё браузеры не знаю, а системы трудно представить без настроек прокси. Может пример приведете?
Обратите внимание на Slimjet - очень удобен для работы с прокси - позволяет использовать несколько профилей и быстро их переключать.
Так я не спорю, по возможности всё надо делать наиболее простым способом. В теме как раз обсуждается проблема, при которой явное проксирование не вариант, потому что таких настроек на клиенте попросту нет.
Друзья, помогите разобраться, что не так с настройкой sing-box.
Дано:
-
виртуалка с Ubuntu (192.168.1.148), на ней настроен sing-box, все работает. Используется как маршрутизатор.
Домашний роутер перенаправляет на нее трафик, адресованный определенным ip-адресам и подсетям. Оттуда через sing-box в VPS. -
вторая такая же виртуала с Ubuntu (192.168.1.75).
Настроена с нуля, точно так же, такой же конфиг sing-box, заменен только ip-адрес в конфиге.
На второй никак не работает. Сам sing-box работает, в логах чисто, но через curl ничего не отдает, виснет:
curl --interface tun0 https://2ip.io
curl: (28) Failed to connect to 2ip.io port 443 after 136133 ms: Couldn't connect to server
Мне кажется, что с маршрутизацией на уровне ОС.
Сравнил две машины, нашел только одно различие в выводе “ip route”
На машине 192.168.1.148, где все работает:
# ip route show
default via 192.168.1.1 dev enp1s0 proto dhcp src 192.168.1.148 metric 100
169.254.0.0/16 dev enp1s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.148 metric 100
192.168.1.148/30 dev tun0 proto kernel scope link src 192.168.1.148
На машине 192.168.1.75, где не работает:
# ip route
default via 192.168.1.1 dev enp1s0 proto dhcp src 192.168.1.75 metric 100
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.75 metric 100
192.168.1.1 dev enp1s0 proto dhcp scope link src 192.168.1.75 metric 100
192.168.1.72/30 dev tun0 proto kernel scope link src 192.168.1.75
В последней строке маршрут, который добавляет сам sing-box. В первом случае он делает маршрут для адреса 192.168.1.148/30, где 192.168.1.148 - это и есть адрес виртуалки.
Во втором случае он делает маршрут для адреса 192.168.1.72/30, при этом адрес виртуалки другой - 192.168.1.75
Возможно, причина в этом? Но этот маршрут вручную поправить не могу. Удалить дает, а создать маршрут для “192.168.1.75/30” не дает, т.к. это некорректный адрес подсети.
На всякий случай прикладываю конфиг:
{
"log": {
"disabled": false,
"level": "debug",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"servers": [
{
"address": "tls://8.8.8.8"
}
]
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "192.168.1.75/30",
"auto_route": true,
"strict_route": false,
"sniff": true
}
],
"outbounds": [
{
"type": "vless",
"server": "xxx",
"server_port": 443,
"uuid": "xxx",
"flow": "xtls-rprx-vision",
"tls": {
"enabled": true,
"insecure": false,
"server_name": "microsoft.com",
"utls": {
"enabled": true,
"fingerprint": "chrome"
},
"reality": {
"enabled": true,
"public_key": "xxx",
"short_id": "xxx"
}
}
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "dns",
"tag": "dns-out"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
}
],
"auto_detect_interface": true
}
}
с постером выше решили в лс: inet4_address tun никак не связан с локальным ip устройства, там должно быть 172.19.0.1/30
Да, все заработало. Огромное спасибо за помощь!
если использовать tun, то что еще необходимо настроить помимо net.ipv4.conf.all.forwarding=1 ?
конфигурация inbound следующая:
{
"auto_route":true,
"domain_strategy":"prefer_ipv4",
"endpoint_independent_nat":true,
"inet4_address":"172.19.0.1/28",
"interface_name":"nekoray-tun",
"mtu":1500,
"sniff":true,
"sniff_override_destination":false,
"stack":"gvisor",
"strict_route":false,
"tag":"tun-in",
"type":"tun"
}
Всем привет! Слежу за этой темой самого его появления и собсна по ней же и настраивал малинку для всех устройств дома. Схема такая: Клиент - микротик - малина - микротик - мир. На днях обнаружил, что перестали скачиваться приложения с Google Play. Перепробовал уже кучу доменов исключать/добавлять. Не помогает. Есть у кого-нибудь соображения по этому поводу?
Сейчас использую следующие домены:
root@raspberrypi:/etc/sing-box# cat ./rule-set/youtube.json
{
"version": 1,
"rules": [
{
"domain_suffix": [
".googlevideo.com",
".youtube.com",
".ggpht.com",
".ytimg.com",
".googleapis.com",
".youtu.be",
".google.com",
".yt.be",
".youtubekids.com",
".nhacmp3youtube.com",
".googleusercontent.com",
".gstatic.com"
]
}
]
}
root@raspberrypi:/etc/sing-box# cat ./rule-set/discord.json
{
"version": 1,
"rules": [
{
"domain_suffix": [
"dis.gd",
"discord-activities.com",
"discord.co",
"discord.com",
"discord.design",
"discord.dev",
"discord.gg",
"discord.gift",
"discord.gifts",
"discord.media",
"discord.new",
"discord.store",
"discord.tools",
"discordactivities.com",
"discordapp.com",
"discordapp.net",
"discordcdn.com",
"discordmerch.com",
"discordpartygames.com",
"discordsays.com",
"discordsez.com",
"discordstatus.com"
]
}
]
}
пользуйтесь wireshark/tcpdump и смотрите на какие домены идут запросы
Проблема была конкретно в этом домене “.googleapis.com” . Пока без него ютюб работает нормально
Мое итоговое решение. Возможно кому пригодится. Ну и будет для меня шпаргалкой на всякий случай
Железо:
Raspberri Pi 4b + Mikrotik rb2011uias-2hnd + keenetic voyager pro (в самой схеме она не участвует, просто жертва обстоятельств)
Задача:
В квартире есть тв, планшет, 2 телефона и 2 ПК (ну и горстка “умных устройств”, но их мы лешим просмотра ютюба и посиделок в дискорде с друзьями). Необходимо сделать так, чтоб на всем этом работал Ютюб, дискорд и прочие выкидыши капиталистического загнивающего запада.
Ну и желательно чтоб ничего на клиентах настраивать не пришлось. Мне лень.
Решение:
Арендуем VPS. На ней поднимаем панель 3x-ui. Это делается в 2 команды. на этом заострять внимания не будем.
На малинке:
- Разрешаем форвардинг пакетов и отключаем ipv6
sudo nano /etc/sysctl.conf
Добавить в конец:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.ip_forward=1
и выполнить:
sudo sysctl -p
- Маскарадим буквально все, что через нас пролетает.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Сохраняем правила:
sudo apt-get install iptables-persistent
sudo netfilter-persistent save
sudo systemctl enable netfilter-persistent
sudo systemctl start netfilter-persistent
- Качаем и настраиваем Sing-box
bash <(curl -fsSL https://sing-box.app/deb-install.sh)
Конфиг /etc/sing-box/config.json
{
"log": {
"disabled": false,
"level": "warn",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query"
},
{
"tag": "local",
"address": "local",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"strategy": "ipv4_only"
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"inet4_address": "172.16.250.1/30",
"auto_route": true,
"strict_route": false,
"sniff": true,
"sniff_override_destination": true,
"gso": true
}
],
"outbounds": [
{
"domain_strategy": "",
"flow": "xtls-rprx-vision",
"packet_encoding": "",
"server": "XXXXXXXX",
"server_port": 443,
"tag": "vless-out",
"tls": {
"enabled": true,
"reality": {
"enabled": true,
"public_key": "XXXXXXXX",
"short_id": "XXXXXXXX"
},
"server_name": "google.com",
"utls": {
"enabled": true,
"fingerprint": "random"
}
},
"type": "vless",
"uuid": "XXXXXXXX"
},
{
"type": "dns",
"tag": "dns-out"
},
{
"type": "direct",
"tag": "direct"
},
{
"type": "block",
"tag": "block"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"ip_is_private": true,
"outbound": "direct"
},
// Изгои не достойные смотреть синий трактор на ютюбе
{
"source_ip_cidr": [
"10.10.0.13",
"10.10.0.29",
"10.10.0.220",
"10.10.0.251"
],
"outbound": "direct"
},
// Исключаем Российские домены. Можно еще добавить GOV
{
"domain_suffix": [
".ru",
".su"
],
"outbound": "direct"
},
{
"domain_suffix": "ntc.party",
"outbound": "vless-out"
},
{
"domain_suffix": "weather.com",
"outbound": "vless-out"
},
{
"rule_set": "antizapret",
"outbound": "vless-out"
},
{
"rule_set": "youtube",
"outbound": "vless-out"
},
{
"rule_set": "discord",
"outbound": "vless-out"
},
{
"rule_set": "discordipset",
"outbound": "vless-out"
},
{
"rule_set": "insta",
"outbound": "vless-out"
},
{
"rule_set": "meta",
"outbound": "vless-out"
}
],
// Этот список работы еле как. Но чет местами открывает ну и пускай будет.
"rule_set": [
{ // Remote rule-set will be cached if experimental.cache_file.enabled.
"tag": "antizapret",
"type": "remote",
"format": "binary",
"url": "https://github.com/savely-krasovsky/antizapret-sing-box/releases/latest/download/antizapret.srs",
"download_detour": "vless-out",
"update_interval": "1d"
},
{
"tag": "youtube",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/youtube.json"
},
{
"tag": "discord",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/discord.json"
},
{
"tag": "discordipset",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/discordipset.json"
},
{
"tag": "insta",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/instafasebook.json"
},
{
"tag": "meta",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/meta.json"
}
],
"final": "direct",
"auto_detect_interface": true
}
}
Пример правил /etc/sing-box/rule-set/youtube.json
{
"version": 1,
"rules": [
{
"domain_suffix":[
"1e100.net",
"ggpht.com",
"googleusercontent.com",
"googlevideo.com",
"gstatic.com",
"gvt1.com",
"l.google.com",
"m.youtube.com",
"nhacmp3youtube.com",
"play.google.com",
"wide-youtube.l.google.com",
"www.youtube.com",
"youtu.be",
"youtube-nocookie.com",
"youtube-studio.com",
"youtube-ui.l.google.com",
"youtube.be",
"youtube.ca",
"youtube.co",
"youtube.co.in",
"youtube.co.uk",
"youtube.com",
"youtube.com.au",
"youtube.com.br",
"youtube.com.mx",
"youtube.com.tr",
"youtube.com.ua",
"youtube.de",
"youtube.es",
"youtube.fr",
"youtube.googleapis.com",
"youtube.jp",
"youtube.nl",
"youtube.pl",
"youtube.pt",
"youtube.ru",
"youtubeapi.com",
"youtubechildren.com",
"youtubecommunity.com",
"youtubecreators.com",
"youtubeeducation.com",
"youtubeembeddedplayer.googleapis.com",
"youtubei.googleapis.com",
"youtubekids.com",
"yt-video-upload.l.google.com",
"yt.be",
"yt3.ggpht.com",
"ytimg.com",
"10tv.app",
"7tv.app",
"7tv.gg",
"7tv.io",
"api.7tv.app",
"cdn.7tv.app",
"cdn.7tv.gg",
"emotes.7tv.app",
"events.7tv.app",
"static.7tv.app"
]
}
]
}
Добавляем автозагрузку sing-box
systemctl enable sing-box.service
Ну и делаем автоматическую перезагрузку сервиса.
- А ОТКУДА РОЖАТЬ ТАКИЕ RULES-SET??
В тырнетах вы можете наткнуться на списки для zapret’a, но они лишь список.
instagramm.com
instagramn.com
instagrampartners.com
instagramphoto.com
instagramq.com
instagramsepeti.com
instagramtakipcisatinal.net
Есть два пути. 1. Прогнать этот список через онлайн редакторы/преобразователи и тому подобное и собрать конструкцию уже на месте.
2. Воспользоваться Python скриптом который изволил родить мне ChatGPT. Он ищет txt файлики в папке откуда его запустили и переделывает их в json c уже готовой конструкцией и даже определяет ip или домены вы добавляете.
import json
import ipaddress
import os
# Функция для чтения имен из текстового файла
def read_names_from_txt(file_path):
with open(file_path, 'r', encoding='utf-8') as file:
names = [line.strip() for line in file if line.strip()]
return names
# Функция для проверки, является ли строка IP-адресом или подсетью
def is_valid_ip_or_subnet(ip):
try:
ipaddress.ip_network(ip, strict=False)
return True
except ValueError:
return False
# Функция для записи имен в JSON файл с нужной структурой
def write_names_to_json(names, json_file_path):
data = {
"version": 1,
"rules": [
{
"ip_cidr": [],
"domain_suffix": []
}
]
}
for name in names:
if is_valid_ip_or_subnet(name):
data["rules"][0]["ip_cidr"].append(name)
else:
data["rules"][0]["domain_suffix"].append(name)
with open(json_file_path, 'w', encoding='utf-8') as json_file:
json.dump(data, json_file, ensure_ascii=False, indent=4)
# Основная программа
def main():
current_directory = os.getcwd() # Получаем текущую директорию
# Ищем все текстовые файлы в текущей директории
for filename in os.listdir(current_directory):
if filename.endswith('.txt'):
txt_file_path = os.path.join(current_directory, filename)
json_file_path = os.path.splitext(txt_file_path)[0] + '.json' # Сохраняем с тем же именем, но в формате JSON
names = read_names_from_txt(txt_file_path)
write_names_to_json(names, json_file_path)
# Удаляем исходный текстовый файл
os.remove(txt_file_path)
print(f"Файл {txt_file_path} успешно преобразован в {json_file_path} и удалён.")
if __name__ == "__main__":
main()
Где-то видел инфу, что сам sing-box что-то умеет, но я не разбирался. Мне лень
На этом моя настройка малинки закончена. Всем кто участвовал в обсуждении СПАСИБО, вы оказали огромную помощь в настройке и теперь я могу дальше деградировать.
Настройка Mikrotik
Есть 3 пути.
- Mangle.
Изначально я выбрал именно этот путь. Но как показала практика это режет скорость тырнетов и если на скачивание это ±20%, то на выгрузку это 50%. Поэтому этот вариант отпадает. (Возможно, у вас стоит дикая тварь, которая может пережевать весь трафик без потерь. Но у меня точно нет) - В DHCP сервере указать основным шлюзом малинку.
Это самый надежный способ в плане потери пропускной способности. Но если что-то произойдет с малиной то тырнетов вам дома не видать, пока вы не поменяете шлюз на DHCP сервере и аренда не обновится. Главное не забудьте задать статический ip на малине. - В DHCP сервере указать основным шлюзом малинку. НО делаем автоматическую проверку жизни малины и скрипт для смены основного шлюза
1.Делаем привило Mangle на Output, метим все исходящие маршруты до адреса 4.2.2.2
2.Добавляем маршрут в ip-routes, что все маршруты с этой меткой идут через малину.
3. system-scripts добавляем скрипт, который при падении малины сам поменяет шлюз и перезагрузит все порты, а при восстановлении вернет все в зад.
:local GATEWAY "4.2.2.2"
:local COUNT "2"
:local REPLY "1"
:local STATUS ([/ping $GATEWAY count=$COUNT]-$REPLY);
:if ($STATUS<0) do={
/log error message="vless not check"
/ip dhcp-server network set [find comment=main_server] gateway=10.10.0.1
/interface ethernet set ether2 disabled=yes
/interface ethernet set ether3 disabled=yes
/interface ethernet set ether5 disabled=yes
/interface ethernet set ether6 disabled=yes
/interface ethernet set ether7 disabled=yes
/interface ethernet set ether8 disabled=yes
/interface ethernet set ether9 disabled=yes
:delay 3
/interface ethernet set ether2 disabled=no
/interface ethernet set ether3 disabled=no
/interface ethernet set ether5 disabled=no
/interface ethernet set ether6 disabled=no
/interface ethernet set ether7 disabled=no
/interface ethernet set ether8 disabled=no
/interface ethernet set ether9 disabled=no
} else {
/ip dhcp-server network set [find comment=main_server] gateway=10.10.0.10
}
Малина имеет адрес 10.10.0.10, а сам микрот 10.10.0.1
Далее делаем задачу на запуск скрипта по времени ip-scheduler. Я запускаю скрипт каждые 30 сек.
При потери связи с малиной все пойдет через провайдера в течении 1 минуты максимум. А вот при восстановлении фильтрация появится в зависимости от срока аренды вашего DHCP сервера. Я поставил 5 мин.
Есть один минус - каждый раз будет в логи срать сообщениями о смене шлюза, но это мы переживем.
Ну и естественно не забываем про статику на малине и в лизесах залочить ip адрес малины
Итог:
В итоге мы имеем довольно надежную схему, которая не режет трафик от провайдера и не ест трафик на VPS т.к. него летят лишь отфильтрованные домены. Схема без особого труда масштабируется и поднимается за час времени с поднятием vps и обновлением малины.
Жду ваши комментарии и предложения. А также рассказы где я накосячил
З.Ы. Потратил на написание этого текста больше времени, чем на поднятие схемы
Спасибо, что собрали все в одном месте!
У самого успешно работает схема с маршрутизацией нужных подсетей на виртуалку с sing-box (маршрутизирует сам Keenetic).
Но с доавблением новых сервисов схема становится все более громоздкой. Сначала мучался с поиском и добавлением подсетей youtube, потом discord…
Возможно, проще сделать так же как у вас и пустить весь трафик на sing-box с правилами на основе доменных имен.
Тоже переживаю по поводу надежности и отказоутойчивости схемы, поэтому отлично, что вы сделали у себя watchdog.
Скажите, если делаю малину (или в моем случае виртуалку) шлюзом по-умолчанию, через нее же пойдет весь LAN-трафик тоже? опасаюсь просто, чтобы не стало узким местом всей домашей сети
LAN траффик идет как правило не доходя до маршрутизатора вообще. В одной локальной сети устройства работают напрямую, а это значит используют arp таблицу свитча/роутера, так что нет. на производительность локальной сети схема не повлияет. Если конечно вы не юзаете VLANы. Тогда это уже другой разговор. Там учувствует маршрутизация и там могут быть затыки, но это будет не большое снижение скорости траффика, при условии, что sing-box настроен верно.
Спасибо, все сделал, как у вас. Отлично работает!
Есть теперь только сложность с использованием VLESS-клиента на ПК.
Сейчас шлюзом по умолчанию стоит 192.168.1.65 - это виртуалка с поднятым sing-box, держит туннель VLESS (3X-UI) до VPS в Европе.
Когда на ПК запускаю клиент Foxray и соединяюсь с тем же VPS, трафик перестает ходить.
Если указываю на ПК (192.168.1.165) обычный шлюз - 192.168.1.1 (домашний роутер), все работает.
Насколько понимаю, проблема в том, что VLESS-трафик от клиента на ПК заворачивается повторно в тот же VLESS-туннель между шлюзом и VPS.
Видимо, нужно какое-то правило в конфиге sing-box, чтобы и входящий, и исходящий трафик в сторону
89.40.xx.xx шел напрямую.
+0300 2024-11-15 12:47:06 INFO [1162613644 0ms] inbound/tun[0]: inbound connection from 192.168.1.165:49977
+0300 2024-11-15 12:47:06 INFO [1162613644 0ms] inbound/tun[0]: inbound connection to 89.40.xx.xx:443
+0300 2024-11-15 12:47:06 DEBUG [1162613644 1ms] router: sniffed protocol: tls, domain: microsoft.com
+0300 2024-11-15 12:47:06 DEBUG [1162613644 2ms] dns: resolved [20.76.201.171 20.112.250.133 20.70.246.20 20.236.44.162 20.231.239.246]
+0300 2024-11-15 12:47:06 INFO [1162613644 2ms] outbound/direct[direct]: outbound connection to microsoft.com:443
+0300 2024-11-15 12:47:06 INFO [2452199677 0ms] inbound/tun[0]: inbound connection from 192.168.1.165:49978
+0300 2024-11-15 12:47:06 INFO [2452199677 0ms] inbound/tun[0]: inbound connection to 89.40.xx.xx:443
+0300 2024-11-15 12:47:06 DEBUG [2452199677 2ms] router: sniffed protocol: tls, domain: microsoft.com
Добавил в конфиг такое, но, похоже, это только для исходящего трафика. А VPN-сервер присылает и в обратную сторону.
{
"ip_cidr": "89.40.xx.xx",
"outbound": "direct"
},
Не подскажете, что можно сделать?
Честно говоря, у меня с этим тоже затык был. Решил просто добавлением маршрута в винде “route add…” указал в качестве шлюза ip маршрутизатора и все.
Сам задал вопрос, сам отвечу)
Нужно на машине, где sing-box добавить статический маршрут, чтобы она запросы в адрес европейского VPS перекидывала на шлюз роутера:
ip route add 89.40.xx.xx via 192.168.1.1
Мой актуальный конфиг для версии 1.11.4.
{
"log": {
"disabled": false,
"level": "debug",
"output": "/tmp/sing-box.log",
"timestamp": true
},
"dns": {
"strategy": "ipv4_only",
"servers": [
{
"tag": "google",
"address": "https://8.8.8.8/dns-query",
"detour": "direct"
},
{
"tag": "cloudflare",
"address": "https://1.1.1.1/dns-query",
"detour": "direct"
}
]
},
"inbounds": [
{
"type": "tun",
"interface_name": "tun0",
"domain_strategy": "ipv4_only",
"address": "172.16.250.1/30",
"auto_route": true,
"sniff": true,
"strict_route": false,
"sniff_override_destination": true
}
],
"outbounds": [
{
"domain_strategy": "prefer_ipv4",
"flow": "xtls-rprx-vision",
"packet_encoding": "xudp",
"server": "XXXXXXXXXXXXX",
"server_port": 443,
"tag": "vless-out",
"tls": {
"enabled": true,
"reality": {
"enabled": true,
"public_key": "XXXXXXXXXXXXXX",
"short_id": "XXXXXXXXX"
},
"server_name": "google.com",
"utls": {
"enabled": true,
"fingerprint": "random"
}
},
"type": "vless",
"uuid": "XXXXXXXXXXXX"
},
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"action": "hijack-dns"
},
{
"ip_is_private": true,
"outbound": "direct"
},
{
"rule_set": [
"antizapret",
"discord"
],
"outbound": "vless-out"
}
],
"rule_set": [
{
"tag": "antizapret",
"type": "remote",
"format": "binary",
"url": "https://cdn.jsdelivr.net/gh/runetfreedom/russia-v2ray-rules-dat@release/sing-box/rule-set-geosite/geosite-ru-blocked.srs",
"download_detour": "vless-out",
"update_interval": "1d"
},
{
"tag": "discord",
"type": "local",
"format": "source",
"path": "/etc/sing-box/rule-set/discord.json"
}
],
"final": "direct",
"auto_detect_interface": true
}
}