Zapret: обсуждение

Поймал для примераrawsend, как-то не густо.

мар 13 13:28:00 user zapret[63736]: packet: id=135 len=60 mark=00000000
мар 13 13:28:00 user zapret[63736]: IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=S seq=3658885761 ack_seq=0
мар 13 13:28:00 user zapret[63736]: desync profile search for tcp target=CENSORED_IP_2:443 l7proto=unknown hostname=''
мар 13 13:28:00 user zapret[63736]: desync profile 0 matches
мар 13 13:28:00 user zapret[63736]: packet: id=135 pass unmodified
мар 13 13:28:00 user zapret[63736]: packet: id=136 len=52 mark=00000000
мар 13 13:28:00 user zapret[63736]: IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=A seq=3658885762 ack_seq=899314698
мар 13 13:28:00 user zapret[63736]: using cached desync profile 0
мар 13 13:28:00 user zapret[63736]: packet: id=136 pass unmodified
мар 13 13:28:00 user zapret[63736]: packet: id=137 len=1500 mark=00000000
мар 13 13:28:00 user zapret[63736]: IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=A seq=3658885762 ack_seq=899314698
мар 13 13:28:00 user zapret[63736]: TCP: len=1448 : 16 03 01 07 61 01 00 07 5D 03 03 E2 90 DE 35 F0 20 32 E2 26 18 47 67 AE D3 08 9A 81 28 D6 18 79 ... : ....a...].....5. 2.&.Gg.....(..y ...
мар 13 13:28:00 user zapret[63736]: using cached desync profile 0
мар 13 13:28:00 user zapret[63736]: packet contains partial TLS ClientHello
мар 13 13:28:00 user zapret[63736]: starting reassemble. now we have 1448/1894
мар 13 13:28:00 user zapret[63736]: req retrans : seq interval 3658885762-3658887209
мар 13 13:28:00 user zapret[63736]: DELAY desync until reasm is complete (#1)
мар 13 13:28:00 user zapret[63736]: packet: id=137 drop
мар 13 13:28:00 user zapret[63736]: packet: id=138 len=498 mark=00000000
мар 13 13:28:00 user zapret[63736]: IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=AP seq=3658887210 ack_seq=899314698
мар 13 13:28:00 user zapret[63736]: TCP: len=446 : 2E D2 8D D0 6B E6 0F 04 CA 04 60 88 28 66 E7 0A 4C 0F 08 59 5E 40 4E C3 0F 87 72 EC 2B CF 28 1C ... : ....k.....`.(f..L..Y^@N...r.+.(. ...
мар 13 13:28:00 user zapret[63736]: using cached desync profile 0
мар 13 13:28:00 user zapret[63736]: reassemble : feeding data payload size=446. now we have 1894/1894
мар 13 13:28:00 user zapret[63736]: packet contains full TLS ClientHello
мар 13 13:28:00 user zapret[63736]: req retrans : seq interval 3658885762-3658887655
мар 13 13:28:00 user zapret[63736]: DELAY desync until reasm is complete (#2)
мар 13 13:28:00 user zapret[63736]: REPLAYING delayed packet #1 offset 0
мар 13 13:28:00 user zapret[63736]: REPLAY IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=A seq=3658885762 ack_seq=899314698
мар 13 13:28:00 user zapret[63736]: TCP: len=1448 : 16 03 01 07 61 01 00 07 5D 03 03 E2 90 DE 35 F0 20 32 E2 26 18 47 67 AE D3 08 9A 81 28 D6 18 79 ... : ....a...].....5. 2.&.Gg.....(..y ...
мар 13 13:28:00 user zapret[63736]: using cached desync profile 0
мар 13 13:28:00 user zapret[63736]: packet contains full TLS ClientHello
мар 13 13:28:00 user zapret[63736]: hostname: ntc.party
мар 13 13:28:00 user zapret[63736]: discovered l7 protocol
мар 13 13:28:00 user zapret[63736]: discovered hostname
мар 13 13:28:00 user zapret[63736]: desync profile search for tcp target=CENSORED_IP_2:443 l7proto=tls hostname='ntc.party'
мар 13 13:28:00 user zapret[63736]: * hostlist check for profile 4
мар 13 13:28:00 user zapret[63736]: [/opt/zapret/lists/ru-youtube-video.txt] include hostlist check for ntc.party : negative
мар 13 13:28:00 user zapret[63736]: hostlist check for party : negative
мар 13 13:28:00 user zapret[63736]: [/opt/zapret/lists/ru-youtube.txt] include hostlist check for ntc.party : negative
мар 13 13:28:00 user zapret[63736]: hostlist check for party : negative
мар 13 13:28:00 user zapret[63736]: * hostlist check for profile 5
мар 13 13:28:00 user zapret[63736]: [/opt/zapret/lists/ru-custom.txt] include hostlist check for ntc.party : negative
мар 13 13:28:00 user zapret[63736]: hostlist check for party : negative
мар 13 13:28:00 user zapret[63736]: [/opt/zapret/lists/ru-blacklist.txt] include hostlist check for ntc.party : positive
мар 13 13:28:00 user zapret[63736]: desync profile 5 matches
мар 13 13:28:00 user zapret[63736]: desync profile changed by revealed l7 protocol or hostname !
мар 13 13:28:00 user zapret[63736]: dpi desync src=CENSORED_IP_1:45004 dst=CENSORED_IP_2:443
мар 13 13:28:00 user zapret[63736]: regular split pos: 2
мар 13 13:28:00 user zapret[63736]: normalized regular split pos : 2
мар 13 13:28:00 user zapret[63736]: [153B blob data]
мар 13 13:28:00 user zapret[63736]: sending fake(1) 2nd out-of-order tcp segment 2-1447 len=1446 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : ................................ ...
мар 13 13:28:00 user zapret[63736]: rawsend: sendto: Message too long
мар 13 13:28:00 user zapret[63736]: SENDING delayed packet #1 unmodified
мар 13 13:28:00 user zapret[63736]: REPLAYING delayed packet #2 offset 1448
мар 13 13:28:00 user zapret[63736]: REPLAY IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=45004 dport=443 flags=AP seq=3658887210 ack_seq=899314698
мар 13 13:28:00 user zapret[63736]: TCP: len=446 : 2E D2 8D D0 6B E6 0F 04 CA 04 60 88 28 66 E7 0A 4C 0F 08 59 5E 40 4E C3 0F 87 72 EC 2B CF 28 1C ... : ....k.....`.(f..L..Y^@N...r.+.(. ...
мар 13 13:28:00 user zapret[63736]: using cached desync profile 5
мар 13 13:28:00 user zapret[63736]: packet contains full TLS ClientHello
мар 13 13:28:00 user zapret[63736]: hostname: ntc.party
мар 13 13:28:00 user zapret[63736]: dpi desync src=CENSORED_IP_1:45004 dst=CENSORED_IP_2:443
мар 13 13:28:00 user zapret[63736]: regular split pos: 2
мар 13 13:28:00 user zapret[63736]: regular split pos is outside of this packet
мар 13 13:28:00 user zapret[63736]: SENDING delayed packet #2 unmodified
мар 13 13:28:00 user zapret[63736]: reassemble session finished
мар 13 13:28:00 user zapret[63736]: packet: id=138 drop
мар 13 13:28:01 user zapret[63736]: packet: id=139 len=60 mark=00000000
мар 13 13:28:01 user zapret[63736]: IP4: CENSORED_IP_1 => CENSORED_IP_3 proto=tcp ttl=64 sport=51906 dport=443 flags=S seq=3675059095 ack_seq=0

Здесь он пытался отослать кусок TCP длиной 1446 , и sendto вернул ошибку
Есть ли какие-то правила iptables/nftables , кроме zapret-овских ?
Пакет проходной, система работает как рутер или как воркстанция и пакет исходил с самой системы ?
Какие интерфейсы в системе ? Есть ли VPN, особенные ip rules, возможность ухода пакетов с разных интерфейсов ? (policy routing, например)
Если хоть что-то есть из перечисленного, можно попробовать --bind-fix4 / --bind-fix6

Нет, только под zapret.

iptables -nL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
NFQUEUE    6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 connbytes 1:6 connbytes mode packets connbytes direction original mark match ! 0x40000000/0x40000000 NFQUEUE num 200 bypass

ip6tables -nL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
NFQUEUE    6    --  ::/0                 ::/0                 tcp dpt:443 connbytes 1:6 connbytes mode packets connbytes direction original mark match ! 0x40000000/0x40000000 NFQUEUE num 200 bypass
  • Обычный ПК, так что исходил с самой системы.
  • Интерфейс Ethernet, подключён напрямую из роутера.
  • VPN нет
  • ip rules насколько мне известно нет, по крайней мере ничего на эту тему вручную не делалось.
  • Policy routing та же история, насколько мне известно нет и вручную не делалось.

Ознакомлюсь в readme и попробую на всякий случай, чем чёрт не шутит.

Да, это простейший случай, bind-fix вряд ли поможет.
Еще скажите rawsend каждый раз при сплите такое возвращает или хаотично ?
Есть ли в этот момент какая-то мощная выгрузка в сеть ?
Может быть множество запросов валится на nfqws ?
Если поменять сплит позицию, чтобы куски стали поменьше (в пределах 1400), что-то меняется ?

У меня на виртуалке на убунте

multisplit pos: 2 
normalized multisplit pos: 2 
sending multisplit part 2 2-1447 len=1446 seqovl=0 : 01 07 5E 01 00 07 5A 03 03 5A 53 5A C2 7E D5 E6 7F 30 BC 53 75 A2 79 99 11 73 A0 ED 1B 68 7A 33 ... : ..^...Z..ZSZ.~..^?0.Su.y..s...hz3 ...
sending multisplit part 1 0-1 len=2 seqovl=0 : 16 03 : ..
DROPPING delayed packet #1
..........
regular split pos: 2
normalized regular split pos : 2
sending fake(1) 2nd out-of-order tcp segment 2-1447 len=1446 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : ................................ ...
sending 2nd out-of-order tcp segment 2-1447 len=1446 seqovl=0 : 01 07 5D 01 00 07 59 03 03 D9 00 12 5B DB 1E 05 8D 66 F7 B5 98 14 3D 3D 8E 80 74 79 F0 43 7A EE ... : ..]...Y.....[....f....==..ty.Cz. ...
sending fake(2) 2nd out-of-order tcp segment 2-1447 len=1446 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : ................................ ...
sending fake(1) 1st out-of-order tcp segment 0-1 len=2 : 00 00 : ..
sending 1st out-of-order tcp segment 0-1 len=2 : 16 03 : ..
sending fake(2) 1st out-of-order tcp segment 0-1 len=2 : 00 00 : ..

Верно, добавил --bind-fix4 --bind-fix6, не помогло.

Проверю, отпишусь.

Не подскажете как лучше эти моменты отловить и что именно имеется ввиду под мощной выгрузкой в сеть?
На глаз по графикам в системном мониторе сеть ведёт себя как обычно.

Правильно понимаю, в моём случае для youtube --filter-tcp=80 и --filter-tcp=443 --dpi-desync-split-pos=2,midsld пойдёт для теста?

  1. Общая загрузка канала на upload велика
  2. Много отдельных пакетов, которые валятся на nfqws

Внутренности ядра сложны, поэтому рассматриваю даже потенциальные варианты с переполнением каких-то очередей

Нет, сделайте --dpi-desync-split-pos=1400
И крутите его вверх, наблюдая есть ли взаимосвязь с размером отсылаемого пакета. Если есть , найдите точку, после которой начинается.
У провайдера какой MTU ?

Проблем с MTU по идее не должно быть. Если сама система шлет TCP пакет длиной 1448, значит она выполнила PMTU discovery, был согласован MSS. Пакеты меньше не должны вызывать проблем с MTU.
1448 скорее всего означает, что у провайдера 1500

ip link show dev eno1 показывает 1500
Ростелеком

Ростелеком по IPoE (DHCP)? Обычно же у них PPPoE, а MTU тогда должен быть ≤1492

Видимо да, в роутере WAN connection type - Dynamic IP
Правда изначально это был онлайм, увы ростелеком их выкупил…возможно пережитки прошлого.

В последних исходниках сделал вывод фактического параметра length, передаваемого sendto(), в случае ошибки. Мало ли из-за бага туда передается что-то большое. Соберите, так будет более информативно

Благодарю, сейчас опробую!

Приветствую. Использую такой профиль, в целом всё работает нормально, но заметил, что при upload’e чего-либо в телеграм - подскакивает использование cpu от winws. При этом в условном qBittorrent’e - всё нормально. Это связано с неоптимальными правилами, или, возможно, с тем, что телега разбивает файл на кучу частей при отправке и поэтому много соединений?

профиль winws

C:\Soft\zapret\zapret-winws\winws.exe --wf-l3=ipv4 --wf-tcp=80,443 --wf-udp=443,50000-50050 --filter-tcp=80 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake,split2 --dpi-desync-fooling=md5sig --dpi-desync-autottl --new --filter-udp=50000-50050 --dpi-desync=fake --dpi-desync-cutoff=d2 --dpi-desync-any-protocol --dpi-desync-repeats=3 --new --filter-tcp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fake-tls=C:\Soft\zapret\my_fakes\tls_clienthello_drive_google_com.bin --new --filter-udp=443 --hostlist-auto=c:\Soft\zapret\zapret-winws\blocked.txt --dpi-desync=fake --dpi-desync-repeats=3 --dpi-desync-fake-quic=C:\Soft\zapret\my_fakes\quic_pl_by_ori.bin

мар 13 13:26:34 user zapret[79717]: desync profile 5 matches
мар 13 13:26:34 user zapret[79717]: desync profile changed by revealed l7 protocol or hostname !
мар 13 13:26:34 user zapret[79717]: dpi desync src=CENSORED_IP_1:59120 dst=CENSORED_IP_2:443
мар 13 13:26:34 user zapret[79717]: regular split pos: 2
мар 13 13:26:34 user zapret[79717]: normalized regular split pos : 2
мар 13 13:26:34 user zapret[79717]: [153B blob data]
мар 13 13:26:34 user zapret[79717]: sending fake(1) 2nd out-of-order tcp segment 2-1447 len=1446 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : ................................ ...
мар 13 13:26:34 user zapret[79717]: rawsend: sendto (1514): Message too long
мар 13 13:26:34 user zapret[79717]: SENDING delayed packet #1 unmodified
мар 13 13:26:34 user zapret[79717]: REPLAYING delayed packet #2 offset 1448
мар 13 13:26:34 user zapret[79717]: REPLAY IP4: CENSORED_IP_1 => CENSORED_IP_2 proto=tcp ttl=64 sport=59120 dport=443 flags=AP seq=4208103237 ack_seq=439631969
мар 13 13:26:34 user zapret[79717]: [153B blob data]
мар 13 13:26:34 user zapret[79717]: using cached desync profile 5
мар 13 13:26:34 user zapret[79717]: packet contains full TLS ClientHello
мар 13 13:26:34 user zapret[79717]: hostname: ntc.party

Еще скажите rawsend каждый раз при сплите такое возвращает или хаотично ?

Похоже всё таки каждый.

1514 это ненормально. буду думать

Спасибо!

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

Было бы здорово сдампить то, что вызывает проблему.
Двойной пакет kyber hello или отдельно куски от него

Wireshark знаю посредственно, опишите процедуру.

Вероятно все просто. Причина в md5sig.
md5sig может плохо работать с kyber и сплитом на мелких позициях
Потому что первый сегмент полный под MTU, md5sig добавляет tcp option, она требует существенный размер
Надо наращивать сплит позицию или отказываться от md5sig или убирать кибер.
nfqws не умеет перераспределять данные между оригинальными tcp сегментами

Или надо отказываться от fakedsplit,fakeddisorder. Только в них генерятся фейки размером с оригинал

Вот как…неочевидный момент.
Пока попробую с datanoack погонять, посмотрю как пойдёт, это самый простой способ проверить.

А с md5sig,badsum или md5sig,badseq получится или тоже завалится?

Ни за что!
Эти двое - произведение искусства.

Без разницы. Если добавляется md5, то это требует места в пакете.
Остальные фулинги ничего не добавляют