update docs

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[=<dirname>]`.
-nfqws создает каталог, назначает на него такие права, чтобы LUA код смог писать туда файлы, передает имя директории в переменной env `WRITEABLE`.
+nfqws2 создает каталог, назначает на него такие права, чтобы LUA код смог писать туда файлы, передает имя директории в переменной env `WRITEABLE`.
 Если dirname не задан, на Windows создается каталог внутри `%USERPROFILE%/AppData/LocalLow`
 
 ## Вызов LUA кода