--dpi-desync-ttl=<int> ; set ttl for desync packet
@ -439,6 +441,21 @@ All unix OS except Solaris preserve last received data. This is not the case for
Disorder requires `seqovl` to be less than split position. Otherwise `seqovl` is not possible and will be cancelled.
Method allows to avoid separate fakes. Fakes and real data are mixed.
### IP_ID assignment
Some DPIs check ipv4 ip_id value. OS normally increment ip_id value every packet. Some anti-DPI software may send fakes or tcp segments with the same ip_id as original causing block trigger.
Sequental ip_id will be broken in case of sending fakes or additional tcp segments because OS knows nothing about them. But still there are options how to assignt ip_id to generated packets.
`ip-id` parameter sets ip_id assignment scheme for a desync profile :
* `seq` (default) : increment ip_id for every next packet. in `multidisorder` case increase ip_id for the number of tcp segments then decrease by 1 every packet.
* `seqgroup` : same as `seq` but send fake replacements with the same ip_id as original parts. related only to fake tcp segments with the same size and same sequence as originals.
* `rnd` : assign random ip_id
* `zero` : always set zero. Linux and BSD will send zero, Windows will replace zero with it's own counter.
ipv6 header lacks ip_id field, `ip-id` parameter ignored for ipv6.
### ipv6 specific modes
`hopbyhop`, `destopt` and `ipfrag1` desync modes (they're not the same as `hopbyhop` fooling !) are ipv6 only. One `hop-by-hop`,
@ -543,20 +543,22 @@ Windows оставляет старые данные, поэтому disorder с
Некоторые DPI секут поле ipv4 заголовка ip_id. Защита заключается в распознавании нехарактерного для разных ОС порядка назначения ip_id,
но характерного для некоторого anti-DPI софта. Обычно ОС инкрементируют ip_id для каждого следующего пакета.
Например, на ТСПУ повторение ip_id фейка и не фейка вызывает триггер блока на диапазонах IP googlevideo.com.
Например, на ТСПУ повторение ненулевых ip_id фейка и не фейка вызывает триггер блока на диапазонах IP `googlevideo.com`.
Если отсылаются фейки или дополнительные tcp сегменты, то в любом случае последовательность будет нарушена, поскольку ОС ничего не будет знать о всунутых фейках
и не увеличит свой счетчик ip_id на количество фейков или дополнительных tcp сегментов.
Чтобы сохранить последовательность, потребовалось бы перехватывать все соединение до конца, что очень затратно по ресурсам.
Поэтому после отработки серии генерированных пакетов ip_id возвращается к тому значению, о котором знает ОС.
Параметр `ip_id` относится к профилю и задает режим назначения ip_id при отсылке генерированных в nfqws пакетов.
Параметр `ip-id` относится к профилю и задает режим назначения ip_id при отсылке генерированных в nfqws пакетов.
* `seq` (по умолчанию) : взять последний ip_id реального пакета. последующие генерированыне пакеты получают увеличенные на 1 ip_id, кроме случая `multidisorder`.
для `multidisorder` в пределах сегментов, где есть сплит-позиции, значение ip_id увеличивается на количество частей, затем уменьшается на 1 с каждой отосланной частью.
* `seqgroup` : то же, что и `seq`, но фейки того же размера, что и оригинальные сегменты, и максирующиеся под оригинал получают те же ip_id.
* `seqgroup` : то же, что и `seq`, но фейки того же размера, что и оригинальные сегменты, маскирующиеся под оригинал получают те же ip_id.
* `rnd` : всем генерированным пакетам назначать случайный ip_id
* `zero` : всем генерированным пакетам назначать ip_id=0 . в этом случае Linux и BSD отошлют 0, Windows назначит последовательные ip_id всем пакетам.
* `zero` : всем генерированным пакетам назначать ip_id=0 . в этом случае Linux и BSD отошлют 0, Windows назначит последовательные ip_id всем пакетам (тем самым автоматически решается проблема сбоя счетчика пакетов).
В заголовках ipv6 поле ip_id отсутствует, параметр игнорируется для ipv6.
bol-van
8 months ago