Closed Euphoreka7 closed 2 weeks ago
или можно твикнуть скрипт дискорда на использование автохост-лист. есть подозрение, что может быть проблема с невхождением какого-то айпи адреса в тот список что есть изначально
у меня при использовании предыдущей версии запрета с автохостлистом он дополнился этим:
finland10059.discord.media
finland10048.discord.media
singapore11165.discord.media
singapore8290.discord.media
discord-attachments-uploads-prd.storage.googleapis.com
india10026.discord.media
хотя вроде как поддомены должны учитываться в полном списке доменных имен дискорда, который здесь не раз выкладывали
Автохостлист работает только с известными протоколами, где есть хост. В случае дискорда нет ни того, ни другого. Протокол проприетарный, IP выдаются серверами без хостнейм.
tamper работает только на DHT. здесь он бесполезен
Вот так можно посмотреть не ходят ли udp 50000-50099 налево мимо сета discord.
nft add rule inet zapret postnat "oifname @wanif udp dport 50000-50099 ip daddr != @discord counter log"
nft list chain inet zapret postnat
dmesg | tail
Будет счетчик в правилах считать левые пакетики. Инфа о них будет писаться в dmesg. Чтобы результат был достоверным, надо остановить торент клиент и все, что может сыпать пакетами на произвольные порты. i2pd, например
Что касается web части, то 50-discord с ней никак не работает. Обход блокировок веб сайтов работает через основную функцию
Автохостлист работает только с известными протоколами, где есть хост. В случае дискорда нет ни того, ни другого. Протокол проприетарный, IP выдаются серверами без хостнейм.
tamper работает только на DHT. здесь он бесполезен
Вот так можно посмотреть не ходят ли udp 50000-50099 налево мимо сета discord.
nft add rule inet zapret postnat "oifname @wanif udp dport 50000-50099 ip daddr != @discord counter log" nft list chain inet zapret postnat dmesg | tail
Будет счетчик в правилах считать левые пакетики. Инфа о них будет писаться в dmesg. Чтобы результат был достоверным, надо остановить торент клиент и все, что может сыпать пакетами на произвольные порты. i2pd, например
# dmesg | tail
[2157664.705080] IN=br-lan OUT=eth1 MAC=00:e0:20:51:05:76:c8:89:f3:ee:46:63:08:00 SRC=x.x.x.x DST=192.42.116.241 LEN=132 TOS=0x04 PREC=0x00 TTL=63 ID=58905 PROTO=UDP SPT=36840 DPT=50033 LEN=112
[2157665.090443] IN=br-lan OUT=eth1 MAC=00:e0:20:51:05:76:c8:89:f3:ee:46:63:08:00 SRC=x.x.x.x DST=31.132.166.158 LEN=132 TOS=0x04 PREC=0x00 TTL=63 ID=39864 PROTO=UDP SPT=36840 DPT=50003 LEN=112
[2158298.482898] IN=br-lan OUT=eth1 MAC=00:e0:20:51:05:76:c8:89:f3:ee:46:63:08:00 SRC=x.x.x.x DST=223.166.89.154 LEN=143 TOS=0x04 PREC=0x00 TTL=63 ID=49491 PROTO=UDP SPT=36840 DPT=50000 LEN=123
обновила предыдущий коммент. надо было рестарт сделать
Если добавить эти хосты в ipset discord, лучше становится ?
nft add element inet zapret discord "{192.42.116.241, 31.132.166.158, 223.166.89.154}"
Судя по whois там вряд ли будут discord сервера
inetnum: 223.166.0.0 - 223.167.255.255
netname: UNICOM-SH
inetnum: 31.132.164.0 - 31.132.167.255
netname: RU-RAID-20110617
inetnum: 192.42.116.0 - 192.42.116.255
netname: TOR-EXIT-AND-MORE
пробовала изначально в конец списка DISCORD_SUBNETS добавлять - проблема всё так же имеет место.
nft add попробовала (предполагаю что делает то же самое) - та же ситуация
новых записей в логе не появилось
насчет этих доменных имен - хез откуда они. торрент клиент выключен. вроде ничего особо специфичного не запущено что в теории могло бы нестандартные юдп порты использовать. игры использующие пир-ту-пир соединения типа пейдея не запускала (не в курсе насчет используемых там портов)
хотя... на одном компе торрент выключила. на втором остался висеть. вырубила и его. может оттуда что
пробовала еще менять значения --dpi-desync-repeats что были в дискорде изначально - разницы тоже не заметила
Этот тест был призван убедиться, что никакие добавления IP не помогут. Дело не в IP. Надо отдельно анализировать веб часть и voice часть. Вырубить все программы, работающие с сетью. Закрыть броузер. Запустить шарк. Потом discord клиент. Снять дамп проблемы. В этом дампе можно уже копаться и смотреть раздельно сеансы по udp.port 50000-50099 и tls.handshake. Возможно, еще по quic. Какие из них стопорятся
насколько я поняла дискорд клиент при попытке коннекта в войс пытается стучаться в тсп режиме через порт 443 к одному из айпи-адресов из списка DISCORD_SUBNETS
я это "полечила" добавлением сабнетов и айпиадресов дискорда в zapret-hosts-user.txt, но вижу это как костыль из-за дублирования. помимо стандартного списка юдп пакетов еще используются тсп 443. вопрос насчет возможного твика скрипта запрета - можно ли там же заимвстовать из конфижного NFQWS_OPT (или TPWS_OPT) флаги для --filter-tcp=443 и на уровне сервиса дискорда делать плюс правило?
возможно доп головняк с вытаскиванием этого регуляркой (да и будет зависеть от форматирования. в предыдущем варианте конфига с этим было бы проще). но всё же...
более простая альтернатива - возможность указать NFQWS_OPT_DISCORD (как пример именования) на уровне конфига и брать оттуда. может плюс флаг на включение\выключение тсп 443 для дискорд сервиса
как уже писал, веб часть дурится стандартными средствами в идеале найти общую стратегию для всех заблокированных доменов. не замечал, чтобы блокировки веб сайтов дискорда были какие-то особенные. если не получается, использовать отдельный профиль с хостлистом.
в кастом вносить это бессмысленно и вредно, потому что для всех провайдеров стратегии разные
--filter-tcp=443 <- в конфигурации обозначается как HTTPS. Причем соединение из дампа с использованием TLS 1.3 Если стратегию обхода засовывать под .. NFQWS_OPT (или TPWS_OPT) в некоторых версиях можно получить некоторые трудности.
А IP принадлежит клаудфрейму Другими словами для нормальной стратегии придеться Блокчек запустить на дискорд и клаудфрейм (сайтах)
PS К проблемам войса это никак не относится. PS2 TPWS не может обрабатывать UDP пакеты
PS3 Но никто походу не хочет думать о том, что сервера уже не выдерживают из-за борьбы государства с данным программным средством. Сервера дискорда пришлось прикрывать на территории РФ и/или переводить трафик, что приводит к увеличению нагрузки каналов и серверов где-то ещё...
как уже писал, веб часть дурится стандартными средствами в идеале найти общую стратегию для всех заблокированных доменов. не замечал, чтобы блокировки веб сайтов дискорда были какие-то особенные. если не получается, использовать отдельный профиль с хостлистом.
в кастом вносить это бессмысленно и вредно, потому что для всех провайдеров стратегии разные
в том то и дело, что стандартным средством удалось обмануть. при этом несмотря на наличие в хостах ранее выкладывавшегося списка доменов дискорда - упомянутый айпи адрес из того списка не определялся. в авто-хост-листе записи относящейся к дискорду не появилось
пробовала через реверс днс лукап смотреть 162.159.138.232 - ничего не нашлось
в данном случае предлагаю идею того чтобы бралась пользовательская стратегия для тсп и для списка ай-пи дискорда применялось правило на уровне сервиса дискорда. что-то на уровне хостов может быть. чего-то может не оказаться. избавит от возможного наступления на грабли (как в моем случае) так и от необходимости копипастить в пользовательский список того что уже и так прописано.
можно, конечно, костылить как я. но, блин... такое себе решение
потому что для всех провайдеров стратегии разные
идея как раз заимвствовать уже используемую и рабочую стратегию или из конфига или отдельную, которую можно будет указать в конфиге. можно даже сделать проверку на наличие значения определенного параметра. если он не закомменчен - брать оттуда и включать правило для тсп 443
да и с логической точки зрения. если есть отдельный сервис для правил дискорда - почему он ограничивается только юдп?
Если обращение идет по TLS, и неизвестен домен, то берется шарк, находится это соединение и смотрится поле SNI в TLS ClientHello. Реверс лукапить смысла нет. PTR записи редко соответствуют ожидаемому имени. Если там не TLS, не QUIC, не HTTP, то никакие хостлисты работать не будут.
да и с логической точки зрения. если есть отдельный сервис для правил дискорда - почему он ограничивается только юдп?
потому что для udp сделан ipset не от хорошей жизни. там нет способа определить hostname, тк протокол нестандартный. а стандартный TLS может фильтроваться по hostname. И в этом случае надо, чтобы со всеми хостами работал единственный инстанс nfqws, а не разные. Разные работать не будут, потому что идет перехват целого порта 443 на любые адреса и направление в единственную очередь. 2 раза перехватить порт 443 и направить на 2 разных очереди невозможно.
пасиб за пояснение. насчет разных инстансов не знала. тогда, наверн, воспользуюсь подходом вида
NFQWS_OPT="
--filter-tcp=80 [flags] <HOSTLIST> --new
--filter-tcp=443 --hostlist=/opt/zapret/ipset/discord.txt [flags] --new
--filter-udp=443 --hostlist=/opt/zapret/ipset/discord.txt [flags] --new
--filter-tcp=443 [flags] <HOSTLIST> --new
--filter-udp=443 [flags] <HOSTLIST_NOAUTO>
"
проблема появилась недавно. может пару дней назад. иногда (может в половине или трети случаев) при попытке подключения к какому-то войсу - долго висит "connecting...". если переподключиться к другому войсу и снова постучаться в предыдущий - может быть коннект. может быть нужна еще одна попытка для успешного и быстрого подключения. иногда всё срабатывает сразу. странная лотерея
аналогичная проблема с просмотром стрима. временами когда пытаюсь подключиться - анимация загрузки. приходится переподключаться несколько раз чтобы стрим начал отображаться нормально
в настройках войса регион обычно стоит или российский или авто
пробовала провести подобный эксперимент через браузер клиент - там таких проблем не было
решила попробовать обновить запрет (включая custom.d скрипт дискорда) - ситуация не изменилась. пробовала там подправить стратегию (ранее использовала по рекомендациям --dpi-desync=fake,tamper и порты 9993,50000-65535) - ничего не изменилось
хост на котором эта проблема была обнаружена "russia1860" (из "дебага" дискорда). подключилась к войсу с этим хостом примерно спустя минуту
что стоит попробовать поменять или как включить дебаг именно для 50-discord чтобы понять в чем именно проблема?