Как правильно оформить custom для обхода замедления YouTube?

[rockenren]

Собственно вопрос в заголовке.

OpenWRT, nftables. В txt соответственно 1 строка: googlevideo.com.
Сейчас использую такую дурацкую конструкцию на основе custom на обработку QUIC, ибо не силен в скриптах OpenWRT:

QNUM2=$(($QNUM+10))

zapret_custom_daemons()
{
	# stop logic is managed by procd

	local MODE_OVERRIDE=nfqws
	local opt

	start_daemons_procd

	opt="--qnum=$QNUM2 -dpi-desync=split2 --dpi-desync-split-pos=1 --hostlist=zapret-hosts-user-yt.txt"
	run_daemon 100 $NFQWS "$opt"
}
zapret_custom_firewall()
{
	# $1 - 1 - run, 0 - stop

	# PLACEHOLDER
	echo !!! NEED ATTENTION !!!
	echo Configure iptables for required actions
	echo Study how other sections work
}
zapret_custom_firewall_nft()
{
	# stop logic is not required

	local MODE_OVERRIDE=nfqws
	local f
	local first_packets_only="$nft_connbytes 1-9"
	local desync="mark and $DESYNC_MARK == 0"

	zapret_apply_firewall_rules_nft

	f="tcp dport 443"
	nft_fw_nfqws_post "$f $first_packets_only $desync" "$f $first_packets_only $desync" $QNUM2
}

Но у меня сомнения в правильности конфига и будет ли вообще это работать.

[bol-van]

Зачем кастом для обхода ютубе ?
Достаточно добавить в стратегию split2. Если уже есть split или disorder, то не надо ничего делать.
Лишь убедиться, что googlevideo.com проходит по ip/hostlist фильтру

Если речь идет об отдельной стратегии для googlevideo, то пока это нереализуемо иначе, чем через ipset, но у гугла прыгающие ип, так что это не вариант тоже.
В будущем планирую сделать несколько десинк профилей с фильтром по хостлистам

дурацкую конструкцию на основе custom на обработку QUIC

она точно не рабочая. хотя бы потому, что QUIC это udp

[rockenren]

Зачем кастом для обхода ютубе ?

Потому что с текущей --dpi-desync=fake,disorder2 --dpi-desync-ttl=4 --dpi-desync-split-pos=1 с ютубом происходит херня. То режется скорость, то нет. При добавленном googlevideo.com yt-dlp валится с ошибками TLS при попытке скачать видео, до этого скорость резалась до минимума (около 200КБ/с), но если при этом пускать yt-dlp через прокси, то скачивается на полной скорости без проблем. В браузере периодически то тормозит видео, то нет, в дебаге плеера это видно сразу (скорость то 200 то полная). Убрал googlevideo.com из хостлиста, yt-dlp начал все качать на полной скорости, в браузере также без проблем все. Потом в моменте все ломается опять нафиг.

она точно не рабочая. хотя бы потому, что QUIC это udp

Так у меня тут вроде как f="tcp dport 443", это не UDP.

Если речь идет об отдельной стратегии для googlevideo, то пока это нереализуемо иначе, чем через ipset

понял, бросаю эту затею тогда.

[bol-van]

В вашем случае я бы поискал компромисс. Найти другую стратегию без disorder, которая не ломает ютуб и сохраняет обход, вместе с тем обходит замедление

[rockenren]

Увы, это единственная стратегия которая работает на большинство заблокированных ресурсов. Блокчеком гоняю периодически.

[bol-van]

А еще присмотритесь к TTL
Возможно, у вас идет обращение к ближнему GGC серверу, который ломается именно по TTL (очень вероятно)
В таком случае добавьте дополнительный ограничитель --dpi-desync-fooling=md5sig - так наиболее совместимо

[rockenren]

--dpi-desync-fooling=md5sig

добавил, пока все вроде прекрасно. Буду наблюдать.

[rockenren]

За чел конечно спасибо, от души.

Да, есть GGC у провайдера, QUIC без обхода (перестали с год назад блокировать, убрал обход).

Ну попытка получить знаний задавая вопросы, чтобы лучше понимать вместо копировать, провалилась.

[bol-van]

Эта ситуация не у вас только.
Народ как правило действительно копи-пастит стратегии как китайскую грамоту.
И обычно это работает, пока не случается что-то наподобии вашей ситуации