From 5bcec4aadab8ae676585187a2abd7fa73bc14731 Mon Sep 17 00:00:00 2001 From: bol-van Date: Sat, 13 Dec 2025 19:50:16 +0300 Subject: [PATCH] update docs --- docs/manual.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 70 insertions(+), 1 deletion(-) diff --git a/docs/manual.md b/docs/manual.md index a788a44..4102418 100644 --- a/docs/manual.md +++ b/docs/manual.md @@ -634,6 +634,75 @@ nfqws2 <глобальные_параметры> В остальных системах нужно копаться в powershell или лезть в реестр, чтобы раскидать подключения по нужным GUID, если вдруг они раскидались системой неправильно. Но можно и не бороться, а просто внести список GUID, назначенных системой автоматически. +## Серверный режим + +Некоторые виды воздействий можно осуществлять не только со стороны клиента, но и сервера. +nfqws2 создавался с учетом полноценной работы как по входящему, так и по исходящему трафика, +как на клиентской стороне, так и на стороне сервера. + +Понятие направления в сети во многом условно. Для адресатов обмена пакетов все ясно - +что-то отсылается, что-то принимается. Но для роутера это неясно совсем. +Есть только входящий интерфейс и исходящий. По сути 2 направления равнозначны, +если рассматривать только уровень L3 - уровень отдельных IP пакетов. + +Поэтому направление в nfqws2 учитывается за счет слежения за потоками. +Поток - это либо tcp соединение, либо последовательность udp пакетов. +udp не предполагает понятия соединения, поэтому оставлено общее название - поток. + +Поток характеризуется 4 величинами : ip1:port1-ip2:port2. Их совокупность +определяет принадлежность пакета к конкретному потоку. + +За потоками в nfqws2 следит conntrack. +Тот, кто первым послал SYN (tcp) или первый UDP пакет, считается клиентом, +а противоположный конец - сервером. +Если создание записи о потоке в conntrack произошло по SYN,ACK пакету (tcp), +то этот конец считается сервером, а противоположный - клиентом. +Таким образом conntrack определяет роли в установлении соединения и хранит +по каждой роли отдельный набор счетчиков - сколько пакетов прошло, +сколько пакетов с данными, сколько байт передано и тд. + +В клиентском режиме исходящим направлением считается направление от клиента, +в серверном (`--server`) - от сервера. Входящим считается противоположное направление. + +При указании `--server` направления инвертируются. +`--in-range`, `--out-range`, а так же признак `desync.outgoing` в LUA функциях +меняются местами, чтобы соответствовать фактически отсылаемым или принимаемым данным +со стороны сервера. Клиент шлет запросы (http_req) и принимает ответы (http_reply). +Сервер шлет ответы (http_reply) и принимает запросы (http_req). + +Для обоих режимов - клиентского и серверного - поиск в ipset осуществляется по IP адресу +назначения для исходящего направления и IP адресу источника для входящего направления. + +В клиентском режиме фильтры портов проверяют порт назначения для исходящего направления и порт источника для входящего направления. + +В серверном режиме фильтры портов проверяют порт назначения для входящего направления и порт источника для исходящего направления. + +Это сделано потому, что в фильтрации реальный смысл имеет только порт сервера. +Порт клиента выбирается как правило случайно из некоторого диапазона и не подходит для осмысленной фильтрации. + +Таким образом, сервер фильтрует по ipset ip клиентов, а клиент - ip серверов. +Но и сервер, и клиент фильтруют порт сервера. + +Linux conntrack имеет похожий способ определения направлений. +Для клиента исходящими будут пакеты original, входящими - reply. Для сервера - наоборот. +Это нужно учитывать при написании правил перехвата, полагающихся на направление conntrack. + +Можно определять направление и по именам интерфейсов. При стандартной конфигурации lan-wan +входящими считаются пакеты, полученные с wan , а исходящими - отправленные через wan. +Именно wan, поскольку обычно используется NAT, а для nfqws2 важно перехватывать исходящие пакеты после NAT +и принимать входящие до NAT. + +Если роутер работает без NAT (типично для ipv6), не имеет значения на каком этапе перехватываются пакеты. +Все IP адреса равнозначны. Вы можете подключаться к интернету, интернет - к вам. Вы - его составная часть +с прямой IP адресацией. Но на практике все же к вам подключаться скорее всего не будут, а вы защититесь +от таких подключений фаерволом. Поэтому направление все равно по интерфейсу определяется достаточно однозначно. +Но если у вас все-же есть внутренний сервер, вы можете для него запустить отдельный инстанс nfqws2 в серверном режиме, +а для клиентского трафика - в обычном режиме. + +В BSD правила ipfw или pf обычно так и пишутся - "xmit wan", "recv wan" + добавляются фильтры по номерам +портов назначения для xmit и портов источника для recv (или наоборот для серверного режима). +Это достаточно надежно идентифицирует необходимый к перехвату трафик по направлению. + ## Песочница В целях безопасности nfqws2 после инициализации сбрасывает свои привилегии. @@ -654,7 +723,7 @@ Windows : Это предотвращает доступ на запись практически ко всем файлам и обьектам, защищенным security descriptor. Есть простой способ передать LUA коду каталог, доступный на запись - параметр `--writeable[=]`. -nfqws создает каталог, назначает на него такие права, чтобы LUA код смог писать туда файлы, передает имя директории в переменной env `WRITEABLE`. +nfqws2 создает каталог, назначает на него такие права, чтобы LUA код смог писать туда файлы, передает имя директории в переменной env `WRITEABLE`. Если dirname не задан, на Windows создается каталог внутри `%USERPROFILE%/AppData/LocalLow` ## Вызов LUA кода