Raspberry Pi + xray между роутером и телевизором

Если честно, не до конца понимаю, что происходит и почему так.

Создал 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 снова начинает работать :frowning_with_open_mouth: Это странно, потому что для 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
	}
}

Я не знаю, почему, но в отличие от всего остального оно работает.

Веселье, брызги шампанского, тему можно закрывать? Не совсем :upside_down_face:

Осталась крайне загадочная проблема, корни которой я понять не могу. Скорость на ТВ действительно становится выше - ну, типа, с 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 показывает ту же скорость что и пк при спидтесте?

:upside_down_face:

а если включить 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 завязано, но малость устал всё это настраивать, так руки и не дошли.

Честно сказать, я тоже до сих пор не понимаю всех тонкостей :slight_smile: Сбросьте сюда полный конфиг 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
	}
}