Template
1
0
mirror of https://github.com/bol-van/zapret2.git synced 2026-03-22 17:25:47 +00:00

update docs

This commit is contained in:
bol-van
2025-12-25 12:06:39 +03:00
parent b0ce5c0c1b
commit 1696f1b552

View File

@@ -1508,7 +1508,7 @@ ipv6 extension headers и tcp options представляются в форме
Она производится автоматически C кодом, если встречен пейлоад, требующий сборки, доступен conntrack и не указан запрет на сборку через `--reasm-disable`.
На текущий момент таких пейлоадов 2 - tls_client_hello и quic_initial. Оба могут содержать постквантовую криптографию kyber, которая не помещается в один пакет.
Для tls_clien_hello производится обычная сборка пейлоадов последовательных tcp сегментов и обьединение их в единый блок reasm_data.
Для tls_client_hello производится обычная сборка пейлоадов последовательных tcp сегментов и обьединение их в единый блок reasm_data.
Для quic_initial отдельные пакеты накапливается во внутреннем буфере, после чего происходит их дешифровка, обьединение и дефрагментация разбросанных по пакетам и разным смещениям частей пейлоада (так делает chrome, чтобы заставить всех не упрощать свои алгоритмы, следовать стандартам и уметь корректно собирать пейлоад по частям).
@@ -2833,7 +2833,7 @@ function payload_check(desync, def)
Обычно идет работа с целым [reasm](#особенности-приема-многопакетных-пейлоадов), вместо отдельных его частей. В этом и есть смысл сборки, чтобы не копаться в отдельных пакетах, а разбираться со всем сообщением сразу.
Стандартный сценарий предполагает работу после приема первой части [replay](#особенности-приема-многопакетных-пейлоадов) и игнорирование, либо drop остальных частей. Выбор между игнорированием или drop может зависеть от успешности действий с [reasm](#особенности-приема-многопакетных-пейлоадов). Например, удалось или не удалось отправить [reasm](#особенности-приема-многопакетных-пейлоадов) сегментированно. Если удалось - нужно дропнуть все остальные части, потому что иначе они пойдут дублями в оригинальной сегментации. Если возникла какая-то ошибка, сегментированные пакеты отправить не удалось, и при этом дроппнуть все остальное, до адресата не дойдет полное сообщение, начнутся ретрансмиссии, поэтому лучше оставить как есть - так хоть ничего не поломается.
Стандартный сценарий предполагает работу после приема первой части [replay](#особенности-приема-многопакетных-пейлоадов) и игнорирование, либо drop остальных частей. Выбор между игнорированием или drop может зависеть от успешности действий с [reasm](#особенности-приема-многопакетных-пейлоадов). Например, удалось или не удалось отправить [reasm](#особенности-приема-многопакетных-пейлоадов) сегментированно. Если удалось - нужно дропнуть все остальные части, потому что иначе они пойдут дублями в оригинальной сегментации. Если возникла какая-то ошибка, сегментированные пакеты отправить не удалось, и при этом дропнуть все остальное, до адресата не дойдет полное сообщение, начнутся ретрансмиссии, поэтому лучше оставить как есть - так хоть ничего не поломается.
```
function replay_first(desync)
@@ -3827,7 +3827,7 @@ blockcheck2 не является панацеей, не является сре
Не стоит так же ждать от blockcheck каких-то сверхсложных алгоритмов выбора стратегий. shell скрипты не являются полноценным языком программирования, не содержат средств работы со сложными структурами данных. Программирование на shell при работе со сложными данными часто превращается в мучение, поскольку их надо как-то записывать в линейный набор переменных окружения.
blockcheck2 работает не всех поддерживаемых платформах - Linux, FreeBSD, OpenBSD, Windows. На Windows самый простой способ им воспользоваться - через [win bundle](https://github.com/bol-van/zapret-win-bundle) - минимальную систему cygwin, преднастроенную для zapret.
blockcheck2 работает на всех поддерживаемых платформах - Linux, FreeBSD, OpenBSD, Windows. На Windows самый простой способ им воспользоваться - через [win bundle](https://github.com/bol-van/zapret-win-bundle) - минимальную систему cygwin, преднастроенную для zapret.
## Проверка DNS