bol-van
3 years ago
committed by
GitHub
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with
11 additions and
2 deletions
-
docs/readme.txt
|
|
|
@ -1,4 +1,4 @@ |
|
|
|
zapret v.44 |
|
|
|
zapret v.44 |
|
|
|
|
|
|
|
English |
|
|
|
------- |
|
|
|
@ -428,10 +428,19 @@ IP ФРАГМЕНТАЦИЯ |
|
|
|
В современной сети с этом все очень плохо. Фрагментированные пакеты застревают по пути, часто отбрасываются. |
|
|
|
Иногда доходят. Иногда то доходят, то не доходят. Может зависеть от версии ipv4/ipv6. |
|
|
|
Роутеры на базе linux и freebsd могут самопроизвольно собирать или перефрагментировать пакеты. |
|
|
|
Linux всегда собирает проходящие ipv6 фрагменты, и это неотключаемо, но может отсылать фрагменты сам. |
|
|
|
Позиция фрагментации задается отдельно для tcp и udp. По умолчанию 24 и 8 соответственно, должна быть кратна 8. |
|
|
|
Смещение считается с заголовка, следующего за ip. В большинство случаев это транспортный заголовок. |
|
|
|
|
|
|
|
Существует ряд моментов вокруг работы с фрагментами на Linux, без понимания которых может ничего не получиться. |
|
|
|
ipv4 : Linux дает отсылать ipv4 фрагменты, но стандартные настройки iptables в цепочке OUTPUT могут их дропать. |
|
|
|
ipv6 : Нет способа для приложения гарантированно отослать фрагменты без дефрагментации в conntrack. |
|
|
|
На разных системах получается по-разному. Где-то нормально уходят, где-то пакеты дефрагментируются. |
|
|
|
Для ядер <4.16 похоже, что нет иного способа решить эту проблему, кроме как выгрузить модуль nf_conntrack, |
|
|
|
который подтягивает зависимость nf_defrag_ipv6. Он то как раз и выполняет дефрагментацию. |
|
|
|
Для ядер 4.16+ ситуация чуть лучше. Из дефрагментации исключаются пакеты в состоянии NOTRACK. |
|
|
|
Чтобы не загромождать описание, смотрите пример решения этой проблемы в blockcheck.sh. |
|
|
|
|
|
|
|
|
|
|
|
tpws |
|
|
|
----- |
|
|
|
|
|
|
|
|
