Какого он размера ? Он должен быть таким, чтобы не превышать MTU.
Максимальный размер фейка - 1472 байта, что для ipv4 соответствует MTU 1500. Больше прога не даст ввести. Будет молча обрезано. Но если MTU<1500 или используется ipv6, то может превысить
Лог нужен вокруг сообщения. В процессе чего он отсылает то, что не влезает в MTU
quic_initial_www_google_com.bin что по умолчанию прилагается, 1200 байт.
Ничего другого вокруг от zapret или по теме нет, по крайней мере в journalctl выстреливают 3 таких сообщения разом без контекста, примерно каждые 2-3 минуты.
Сейчас сделаю прогон с --debug=1
Есть ощущение что это чаще происходит если youtube включать одновременно в двух вкладках, например музыку в одной слушать на фоне, а в другой смотреть видео.
мар 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
Да, это простейший случай, bind-fix вряд ли поможет.
Еще скажите rawsend каждый раз при сплите такое возвращает или хаотично ?
Есть ли в этот момент какая-то мощная выгрузка в сеть ?
Может быть множество запросов валится на nfqws ?
Если поменять сплит позицию, чтобы куски стали поменьше (в пределах 1400), что-то меняется ?
Верно, добавил --bind-fix4 --bind-fix6, не помогло.
Проверю, отпишусь.
Не подскажете как лучше эти моменты отловить и что именно имеется ввиду под мощной выгрузкой в сеть?
На глаз по графикам в системном мониторе сеть ведёт себя как обычно.
Правильно понимаю, в моём случае для youtube --filter-tcp=80 и --filter-tcp=443--dpi-desync-split-pos=2,midsld пойдёт для теста?
Внутренности ядра сложны, поэтому рассматриваю даже потенциальные варианты с переполнением каких-то очередей
Нет, сделайте --dpi-desync-split-pos=1400
И крутите его вверх, наблюдая есть ли взаимосвязь с размером отсылаемого пакета. Если есть , найдите точку, после которой начинается.
У провайдера какой MTU ?
Проблем с MTU по идее не должно быть. Если сама система шлет TCP пакет длиной 1448, значит она выполнила PMTU discovery, был согласован MSS. Пакеты меньше не должны вызывать проблем с MTU.
1448 скорее всего означает, что у провайдера 1500
В последних исходниках сделал вывод фактического параметра length, передаваемого sendto(), в случае ошибки. Мало ли из-за бага туда передается что-то большое. Соберите, так будет более информативно
Приветствую. Использую такой профиль, в целом всё работает нормально, но заметил, что при upload’e чего-либо в телеграм - подскакивает использование cpu от winws. При этом в условном qBittorrent’e - всё нормально. Это связано с неоптимальными правилами, или, возможно, с тем, что телега разбивает файл на кучу частей при отправке и поэтому много соединений?