loop-uh
0ad0bcc8dd
Some checks failed
Published content check / validate (push) Failing after 5s
Каждая публикуемая заметка получила callout-шапку со ссылкой на свою страницу wiki.zapret.moe (на самой вики она вырезается транформером RemoveMirrorCallout, видна только на зеркале Obsidian Publish и в Forgejo) и SEO-поле description — 1–2 предложения для meta description обоих сайтов. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
84 lines
4.3 KiB
Markdown
84 lines
4.3 KiB
Markdown
---
|
||
date: 2026-01-21
|
||
tags:
|
||
- zapret
|
||
- zapret2
|
||
- nfqws2
|
||
- winws2
|
||
- networking
|
||
- learning
|
||
aliases:
|
||
- Zapret2 учебник 03
|
||
description: "Как Zapret2 перехватывает пакеты через NFQUEUE и WinDivert и что значат вердикты PASS, MODIFY, DROP: урок 03 для новичков с мини-практикой в логах."
|
||
---
|
||
|
||
> [!mirror] Резервное зеркало
|
||
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/Zapret/manual/zapret2_03](https://wiki.zapret.moe/Zapret/manual/zapret2_03)
|
||
|
||
# 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 вернулся”.
|