Zapret2 для новичков — 03: перехват пакетов и вердикты (NFQUEUE/WinDivert)

Цель: понять “где” стоит zapret2 и что значит PASS/MODIFY/DROP.

1) Где стоит программа в системе

Linux (nfqws2)

Обычно схема такая:

1. правила nftables/iptables направляют некоторые пакеты в NFQUEUE
2. nfqws2 читает их в userspace
3. программа решает: пропустить/изменить/дропнуть
4. ядро применяет решение и продолжает обработку

По коду это видно в nfq2/nfqws.c: callback NFQUEUE получает raw байты и вызывает обработчик, который возвращает вердикт.

Windows (winws2)

Аналогичная идея, но вместо NFQUEUE используется перехват на уровне драйвера WinDivert:

1. драйвер отдаёт пакеты в userspace
2. winws2 решает, что делать
3. пакет либо возвращается обратно (modified/unmodified), либо отбрасывается

2) Что такое “вердикт”

В zapret2 есть три ключевых исхода для перехваченного пакета:

• PASS: “пропусти пакет дальше как есть”
• DROP: “не отдавай этот пакет дальше” (он как будто “потерялся”)
• MODIFY: “пропусти, но с изменёнными байтами”

Важно:

• MODIFY обычно означает, что пакет пересобран из диссекта (reconstruct), а не “чуть поправлен в сыром виде”.

3) Почему отправка фейков не равна MODIFY

fake и похожие функции часто делают:

• отправляют дополнительный пакет “сами” (rawsend),
• но не обязаны менять перехваченный пакет.

Поэтому возможна типичная комбинация:

• fake отправил “лишний” пакет,
• перехваченный пакет дальше пошёл как обычно (PASS), если его никто не дропнул.

Это нормальная модель: “сделали дополнительный шум” и “не трогали оригинал” (или трогали другим инстансом).

4) Почему нужно ограничивать перехват (производительность)

Перехватывать “весь порт” — дорого:

• каждый пакет будет идти в userspace,
• Lua будет запускаться часто,
• CPU может улететь в 100%.

Поэтому в zapret2 активно используют:

• фильтры --filter-*
• --payload=...
• --in-range/--out-range
• cutoff (чтобы перестать вызываться после “критической фазы”)

5) Мини‑практика: “увидеть вердикты в логах”

Самое простое для обучения:

• включить --debug
• добавить --lua-desync=pass или --lua-desync=pktdebug

Цель: заметить, что каждый перехваченный пакет даёт лог “что пришло” → “какие Lua инстансы вызвались” → “какой verdict вернулся”.