4. Настройка и администрирование Fantomas


4.1     Настройка параметров
4.2     Настройка загрузки конфигурации iproute2, скрипт "tabloid"
4.3     Список подсетей
4.4     Список сетевых подключений
4.5     "Inits" - cписок произвольных правил Iptables
4.6     Политики
4.7     Управление сет-листами - списки Ipset, файл "ipsetlist"
4.8     Управление группами и клиентами
4.9     Глобальные процедуры: конфигурирование системы и обработка счетчиков
4.10     Консольная утилита iptconf.php
4.11     Ограничение скорости трафика клиентов, скрипт ifbtool






4.1 Настройка параметров



    В программе есть ряд параметров, которые касаются разных моментов работы программы. Они живут в файле config.php.
    Большинство из них них доступны для настройки из веб-интерфейса (Вы можете их найти в разделе "Настройки → Параметры"), а остальные, впрочем, настраиваются один раз и в дальнейшем редактировать их нежелательно.
    Часть из параметров была получена и записана при установке, а остальные имеют значения по умолчанию.

  • Настройки, доступные из веб:


  • $backup_dir = "/usr/local/iptconf/_backup";
    Путь к каталогу, в который сохраняются резервные копии файлов счетчиков.
  • $sets_dir = "/usr/local/iptconf/sets";
    Путь к каталогу, в котором хранятся файлы листов ipset.
  • $users_dir = "/usr/local/iptconf/usr";
    Путь к каталогу, в котором хранятся файлы описаний групп клиентов (IP-адресов).
    ### Внимание! Если Вы решите изменить значения этих путей, то соответственно, Вы должны скопировать файлы из текущих каталогов в новые, а также позаботьтесь о том чтобы у пользователя httpd было право на запись в каталоги, которые Вы укажете.

  • $filter_web_access = 1;
  • $allowed_ip = "127.0.0.1,192.168.0.1,78.78.78.78";
  • $site_to_redirect = "http://bash.org.ru";
  • $index_freename = "ayadvornik";
  • $index_freepass = "xtkjdtrcfvjktn";
        Если значение $filter_web_access установлено в 1, тогда при попытке входа на веб-интерфейс, проверяется IP-адрес входящего, и если он не совпадает ни с одним из списка $allowed_ip, вместо формы авторизации в виде фрейма грузится сайт что указан в переменной $site_to_redirect. Соответственно, при $filter_web_access=0 опция отключена.
        $allowed_ip может содержать один адрес или, как указано в примере, список адресов через запятую без пробелов.

        Хотите историю? Однажды cложилось так, что когда я был где-то посреди Москвы с ноутбуком, мне понадобилось пипец как срочно кое что поправить через веб-интерфейс. Нашел wi-fi, вышел в интернет, зашел на свой фантомас.. Сработала защита и пришлось читать баш...
        Поэтому существует "служебный" режим. Попробуйте убрать свой адрес из $allowed_ip и зайти на веб-интерфейс вот так:
           http://yourhost/fantomas/?ayadvornik=xtkjdtrcfvjktn

       Редиректа не произойдет - Вы увидите окно авторизации :)
       Как Вы уже поняли, "волшебные слова" настраиваются в $index_freename и $index_freepass. ( ##Прим: в предыдущих версиях эти настройки были непосредственно в самом index.php.)
       Из веб-интерфейса доступна настройка только первых трех опций, две последние можно настроить только в консольном режиме путем редактирования файла config.php. Обязательно смените значения опций $index_freename и $index_freepass на что нибудь свое.
  • $monitor_def_grp = "default";
       Имя группы пользователей, которая будет открываться по умолчанию в мониторе трафика.
  • $monitor_delay = 7;
       Время задержки (тайм-аут) в секундах, используемое по умолчанию в трафик-мониторе и мониторе процессов.
       Не советую ставить значение меньше чем 5 сек, т.к. к примеру, трафик-монитор показывает суммарный трафик каждого юзера по выбранной группе, а это требует некоторого времени на обработку данных.
       Для сравнения: группа из 15 клиентов у меня формируется примерно 3 сек.
  • $report_min_procent = "0.01";
       При формировании отчета по трафику из БД ulogd, рассчитывается процентное отношение трафика конкретного хоста назначения к общей сумме трафика. Так вот, в этой переменной задается уровень "отбивки" хостов, процент которых меньше или равен этому. Они не попадут в отчет с целью не захламлять его почти нулевыми значениями (обычно их много).
  • $report_whoisurl = "https://www.nic.ru/whois/?query=";
       URL для запроса информации whois в отчетах по веб-трафику, к этой строке в конец добавляется адрес IP, по которому запрашивается информация.
  • $_set_save_onchange = TRUE;
       Настройка сет-панели: Если значение указано TRUE, то после любой операции редактирования сет-листов, новое содержимое сет-листа будет сохраняться на диск в соответствующий файл в каталоге, указанном в переменной $sets_dir.
  • $_set_submit_query = TRUE;
       Настройка сет-панели: Если значение указано TRUE, то сет-панель будет запрашивать подтверждение при операциях редактирования или изменения сет-листов.
  • $_set_show_listinfo = TRUE;
       Настройка сет-панели: Если значение указано TRUE, то в сет-панели в списке сет-листов будет показываться табличная информация о количестве элементов и биндингах.
  • $viewlogs_system = "/var/logs/messages;/var/logs/secure;/var/logs/maillog;/var/logs/cron";
       Список лог-файлов, которые можно будет просматривать их веб на странице состояния системы.
  • $viewlogs_show_last = 100;
       Количество строк с конца лог-файла, которые программа будет загружать для показа.
  • $viewlogs_height = 650;
       Размер по высоте (в пикселах) окна просмотра лог-файла.
  • $viewlogs_width = 700;
       Размер по длине (в пикселах) окна просмотра лог-файла.
  • $_crontab = "/etc/crontab";
       Путь к файлу crontab (файл настроек демона-планировщика crond).
  • $_crond = "/usr/sbin/crond";
       Путь к исполняемому файлу демона crond.
  • $_crontabd = "/usr/bin/crontab";
       Путь к исполняемому файлу программы crontab.
  • $crond_logfile = "/var/log/cron";
       Путь к лог-файлу crond.
  • $_portfilter_enable = FALSE;
       Опция указывает состояние порт-фильтра: FALSE - порт-фильтр выключен, TRUE - включен.
  • $mysql_brief_dbinfo = FALSE;
       Если опция выставлена в TRUE, то в веб-интерфейсе в разделе "MySQL", при просмотре информации о состоянии баз, не показываются данные о таблицах входящих в БД, а только общая инфо о БД.
  • $_logs_enable = TRUE;
       Опция указывает состояние подсистемы ведения логов Fantomas: FALSE - логи не ведутся, TRUE - логи ведутся.
  • $_logs_dir = "/usr/local/iptconf/logs";
       Путь к каталогу с лог-файлами.
  • $_logs_level = 2;
       Порог уровня событий, записываемых в лог, значения могут быть от 1 (наиболее полный лог) до 5 (только самые критические и системные ошибки).
  • $_logs_logged_checkpass_nolog = TRUE;
       Указывает записывать ли в лог события о проверке пароля успешно авторизовавшегося в программе клиента во время его переходов из раздела в раздел (данные авторизации клиента перепроверяются при каждом новом запуске любого из разделов).
  • $syslogs = "fantomas.log";
       Имя текущего файла лога программы.
  • $_logs_log_maxsize = "5M";
       Максимально допустиммый размер файла лога, "М" - означает мегабайты ("k"-килобайты, "G"-гигабайты), при достижении файлом указанного размера, в имя файла добавляется метка текущего времени и создается новый файл с именем как указано в переменной $syslog.


  • Недоступные из веб настройки:
  • $cli_brief_mode = TRUE;
       Режим вывода информации для консольной утилиты iptconf.php: TRUE - информация выводится в сокращенном виде, FALSE - отображение полной информации.
  • $quota_chk_arg = "50k";
       Погрешность рассчета счетчиков при применении квот. При проверке достижения пользователем квоты, значение квоты уменьшается на это значение.
       Это нужно когда, например, бывает что значение счетчика байт приближается максимально близко к значению квоты, так, что может даже сработать блокировка квоты, а в веб-интерфейсе клиент виден все равно активным.    "k" - означает килобайты, при считывании переменной программа конвертирует в байты автоматически.
  • $_passw_crypt_key = "somekey";
       Ключ для шифрования данных авторизации, длина ключа должна быть 9 символов (только латинские буквы и цифры), иначе Fantomas самостоятельно дополнит на свое усмотрение или соответственно урежет длину ключа. Начиная с версии 0.1.5, если система поддерживает шифрование MD5, то Fantomas использует MD5-хеширование вместо шифрования по ключу и тогда эта опция не используется.
  • $_passw_md5_enable = TRUE;
       Если значение TRUE, то вместо шифрования по ключу, Fantomas использует MD5-хеширование без применения ключа.
  • $keep_counts_at_polunload = TRUE;
       Может быть TRUE или FALSE
       Отвечает за запуск функции сохранения счетчиков при отключении или удалении политики, ранее примененной к клиенту. Это нужно когда, например, с клиента удаляется политика или отключается его политика по умолчанию. Соответственно, удаляются правила из iptables и вместе с ними счетчики с текущими показаниями его трафика. Если потом политику добавить или включить обратно, то его счетчики могут быть по нулям. А в случае предварительной отработки рассматриваемой фунции, значения счетчиков считываются из файла counters, находящегося в каталоге iptconf.
       По умолчанию включена. Имейте ввиду что эта функция отрабатывает не по одному конкретному клиенту или политике, а по всем счетчикам всех клиентов. При огромном количестве клиентов может возникнуть какая-то задержка, но это оценить сложно, т.к. при моей обкатке на 60-ти клиентах этой задержки было не заметно.
       Кстати, при добавлении или включении политики, счетчики считываются одельно по этой политике для конкретного клиента .
       Понимаю что надо сделать функцию раздельного сохранения счетчиков, но пока не было необходимости, да и лень, поэтому эта функция возможно появится в следующей версии.
  • $mysql_host = "127.0.0.1";
  • $mysql_user = "root";
  • $mysql_password = "12345";
       Параметры подключения к серверу MySQL.
  • $mysql_logfile = "/var/log/mysqld.log";
       Путь к лог файлу MySQL. Он потребуется для того чтоб Вы смогли смотреть этот лог через веб-интерфейс.
  • $mysql_fantomas_db = "fantomas";
       Название БД, которую Fantomas использует для своих задач.
  • $ulog_dbname = "ulogd";
       Содержит имя БД MySQL демона Ulogd.
  • $ulog_dbname = "ulogd";
       Название БД MySQL демона ulogd.
  • $ulog_logfile = "/var/log/ulogd/ulogd.log";
       Путь к лог файлу демона Ulogd. Он потребуется для того чтоб Вы смогли смотреть этот лог через веб-интерфейс.
  • $syspage_show_procs = "ulogd,mysqld,named,httpd,sshd";
       Устаревшая переменная, в ранних версиях программы отсюда брался список процессов, информация о статусе которых отображалась на странице состояния системы. В последствии инфа о процессах стала не нужна, т.к. появился монитор процессов, а ее бывшее место заняла панель просмотра системных логов. Оставлена для обратной совместимости.
  • $index_login_timeout = 0;
       Настройка index.php: Тайм-аут в минутах, по истечению которого веб-интерфейс будет "забывать" логин и пароль текущей сессии и прийдется перелогиниться. Если указан 0, то таймаута нет, но параметры сессии будут забыты при выходе из веб-интерфейса.
  • $usr_cname_spaces = TRUE;
       Настройка отображения групп клиентов в веб: указавает подменять ли знаки подчеркивания "_" на пробелы для тегов "cname" при отображении имен клиентов в веб-интерфейсе.

    Наверх    Содержание



    4.2 Настройка загрузки конфигурации iproute2, скрипт "tabloid"



        Fantomas имеет возможность при старте своего init-скрипта iptcldr загружать список маршрутов Iproute2. Эта опция включается в разделе "Система -> Iproute2", там доступно включение/выключение самой опции, также там можно указать сам файл конфига cо списком маршрутов, и еще там есть панель таблиц маршрутизации в которой можно добавлять/удалять таблицы и просматривать загруженные маршруты по таблицам.

        Файл списка маршрутов называется iproute2-init и хранится в каталоге программы. Немного о самом файле: структура файла разбита на секции, каждая из которых должна принадлежать отдельной таблице маршрутизации и в этой секции должны располагаться правила этой таблицы, последняя же из секций должна содержать правила iproute2 (ip rule list).

        Обычная секция таблицы маршрутизации выглядит так:

    ### table <tablename> zone
    ip route add ... table <tablename>
    ip route add ... table <tablename>
    ######### end zone
        Обратите внимание на количество знаков "#" и написание "table >name< zone" - писать нужно именно так! Это связано с тем что именно по этим строчкам программа распознает где начинается и где заканчивается секции таблиц.
        Соответственно, сколько таблиц маршрутизации, столько и секций в файле должно быть.

        После описания таблиц маршрутизации в файле идет секция описания правил маршрутизации:
    ### rules zone
    ip rule add ... table <tablename>
    ip rule add ... table <tablename>
    ######### end zone
        Эта зона предназначена для размещения команд описания правил маршрутизации, которые являются общими для всех таблиц.

        Из веб-интерфейса файл не редактируется, т.к. имхо обычно такой файл вообще настраивается один раз и забывается, поэтому для редактирования файла iproute2-init пользуйтесь консолью.

        Для чего сделано такое разделение команд по секциям? Сделано это не просто так - в консоли есть специальная утилита для работы файлом iproute2-init - tabloid. Это скрипт располагается в каталоге iptconf/tools и позволяет обрабатывать отдельно каждую из секций файла iproute2-init, его синтаксис предельно прост:
    tabloid {up|down|reload} [target=<tablename>]
        Если не указан параметр "target", то обрабатываются все секции файла, в противном случае обрабатываются команды только конкретной секции.

        Собственно, инит-скрипт iptcldr при загрузке выполняет именно этот скрипт в виде "tabloid up".

    Наверх    Содержание



    4.3 Список подсетей



        Для любой маршрутизации нужно знать источник и адресата, не так ли? Более того, для вменяемой маршрутизации нужно видеть разницу между объектами в локальной сети и всеми остальными. Для этого при настройке установщик создал список подсетей, подключенных непосредственно к маршрутизатору, их можно настроить в веб или в консоли в файле "Networks". Веб-настройка выглядит примерно так:


        На основе данных о подсетях также формируется ipset-лист locals, который и используется для четкой идентификации локальных подсетей и их отличия от внешних.
        Файл "networks" располагается в каталоге где установлен Fantomas, при желании работать в консоли его можно править вручную. Синтаксис файла следующий:

    <subnet_address> [local] [notallforward]
       Здесь:

       <subnet_address> - адрес подсети ( например, 192.168.0.0/24 )

       local - Признак того что подсеть является локальной, а значит попадает в лист locals и будет использована как локальный dst или src при генерации правил iptables.

       notallforward - Если указан, то для этой подсети в цепочке FORWARD не создается правило, разрешающее маршрутизацию в нее трафика из остальных подсетей, по типу "-A FORWARD -s $other_subnet -d $this_subnet -j ACCEPT". Политика FORWARD по умолчанию ставится в DROP, поэтому сервер будет маршрутизировать в эту подсеть трафик только тех клиентов, для которых Вы вручную впишите разрешающее правило в файле inits (см. пункт 4.4).
       Опция полезна для фильтрации доступа между подсетями. К примеру, если у Вас несколько локальных подсетей, одна из которых имеет особый режимный статус и маршрутизировать туда трафик можно только с определенных IP-адресов.


         пример файла:
    127.0.0.1
    192.168.0.0/24 local
    10.120.6.0/24 local notallforward

       В этом примере у нас как и в примере выше, одна из подсетей обычная локальная, а вторая - локальная "режимная". При этом, в inits, если пропускаем весь трафик, разрешающие правила могут выглядеть так:
    -A FORWARD -s 192.168.0.10 -d 10.120.6.0/24 -j ACCEPT

       Или можно проявить немного фантазии:
    -A FORWARD -s 192.168.0.10 -d 10.120.6.0/24 -p tcp -m multiport ! --ports 25,3389,8080,3128 -j ACCEPT
    -A FORWARD -s 192.168.0.10 -d 10.120.6.0/24 -p udp --dport 53 -j ACCEPT
    -A FORWARD -s 192.168.0.103 -d 10.120.6.0/24 -p tcp --sport 80 -j DROP

       По умолчанию, в networks попадают только локальные подсети, по которым ведется подчет и ограничение трафика, провайдерских подсетей здесь может и не быть, поскольку по ним обычно не выполняется маршрутизация "сеть-в-сеть". Хотя, у меня были мысли реализовать поддержку openvpn чтоб рулить и удаленными подсетями, а возможно и непосредственно маршрутизацией с iproute2. Поэтому не удивляйтесь тому что, казалось бы, присутствие параметра local здесь кажется бессмысленным. Может и дойдут руки..

    Наверх    Содержание



    4.4 Список сетевых подключений



        Здесь все предельно просто - список содержит описания сетевых интерфейсов, с которыми работает программа.
        Аналогично списку подсетей, работать с со списком подключений можно как через веб-панель, так и в консоли. Данные списка хранятся в файле "providers".
        Синтаксис файла:

    link <link_name> [local] {
    ipaddr=<iface_ipaddr>
    ifname=<iface_name>
    }
       Здесь:

       <link_name> - Любое короткое имя подключения без пробелов и спецсимволов, логически понятное для Вас и Ваших коллег (например, mylocalnet или corbina).

       local - То же самое что в networks - признак локального сетевого интерфейса.

       <iface_ipaddr> - IP-адрес сетевого интерфейса.

       <iface_name> - Название сетевого интерфейса в системе ( eth0, eth1 .. ethN и т.п.).

       Фигурные скобки обязательны, причем именно в том виде как показано: открывающая скобка в одной строке с названием линка, а закрывающая обязательно в отдельной новой строке.

         пример:
    link propellernet local {
    ipaddr=192.168.0.1
    ifname=eth1
    }

    link tochka-ru {
    ipaddr=78.78.78.79
    ifname=eth2
    }

    Наверх    Содержание



    4.5 "Inits" - cписок произвольных правил Iptables



        Как и предыдущие списки настроек, этот список возможно редактировать как из веб так и в консольном режиме. Данные хранятся в файле "inits".
        Список предназначен для размещения написанных админом вручную команд iptables, которые при процедуре пересоздания конфигурации (RELOAD) будут выполняться перед генерацией правил по политикам клиентов.
    Целью его создания было иметь возможность производить вручную небольшие манипулиции с трафиком, как то например, маркировка, разрешение или запрещение трафика.

        Всю основную работу c трафиком Fantomas проводит в таблице mangle (цепочки PREROUTING, FORWARD, COUNT_IN, COUNT_OUT и PORTFILTER).
    Поэтому создавайте правила очень осторожно! Помните, что действие Ваших правил способно всерьез нарушить или вообще разрушить работу Fantomas. К примеру, если здесь дропать пакеты, которые могли бы принадлежать какому то клиенту, то уже никакие правила никаких политик эти пакеты не получат.
    Цепочки COUNT_IN и COUNT_OUT просто не используйте!

        Выше уже писалось о том что, штатно inits можно применять для раздавания вручную ACCEPT'ов на форвард трафика, в том случае, когда на одной из Ваших подсетей установлена опция "notallforward":

    -A FORWARD -s 192.168.0.10 -d 10.120.6.0/24 -j ACCEPT

        Второй вариант штатного использования касается как раз mangle - можно маркировать трафик циферкой 22, а потом исключать его из общего рассчета по принципу:
    -t mangle -A PREROUTING -s 192.168.0.10 -d 10.120.6.0/24 -p all -j MARK --set-mark 22
    -t mangle -A COUNT_IN -m mark --mark 22 -j RETURN
    -t mangle -A COUNT_OUT -m mark --mark 22 -j RETURN
        В этом случае указанный трафик не будет подсчитываться, т.к. при рассчете будет "вылетать" из COUNT-цепочек, не успев встретить подходящее по условиям правило. Это бывает полезно когда, как в примере выше, Вам нужно организовать маршрутизацию между локальными подсетями "для избранных", но при этом этот трафик является локальным и подсчитываться не должен.

    Наверх    Содержание



    4.6 Политики



        Политики хранятся в текстовом виде в файле "policies" в каталоге Fantomas. Работать со списком политик можно тоже как из веб-интерфейса, так и в консоли.

        Политика - это краткое схематичное, синтаксически соответственно оформленное, описание видов сетевого трафика с указанием действий, которые должен применять маршрутизатор к этим видам трафика.

        Мы уже говорили про основную идею политик и их назначение в разделе п.1.1.3 Как это работает?.

        Политика имеет краткое название (идентификатор), которое используется во всех операциях с политикой: ее можно назначить клиенту или большому числу клиентов (или вообще всем). Можно политику назначить группе клиентов - тогда она будет использоваться как политика по-умолчанию для членов этой группы и при создании нового клиента будет применяться автоматически (потом Вы, конечно, можете ее отменить и назначить другую политику).

        Каждому конкретному клиенту может быть назначено сколько угодно политик - их количество ограничено только аппаратными ресурсами сервера. Главное требование: виды трафика, описанные в каждой политике, не должны повторяться в других политиках, назначенных клиенту - иначе действия политик будут попросту конфликтовать.

        В качестве клиентов возможно использовать не только ip-адреса рабочих станций, но и адреса серверов, расположенных в локальной сети. Для серверов также возможно создавать политики, описывающие используемые ими виды трафика. Например, создать политику, разрешающую исходящий SMTP для почтового сервере или политику, разрешающую DNAT из интернет на внутренний сервер терминалов. А можно создать политику, выполняющую reject tcp (80,8080,3128) для сервера терминалов, если не хотите чтобы пользователи пытались ходить в интернет из под терминальной сесии.

        Еще пример: запросы к удаленным http и ftp-серверам могут быть описаны одной политикой, а к smtp-серверам - другой. При этом первая политика может направлять трафик через одного провайдера, при этом подсчитывая трафик , а вторая - через другого, и возможно без подсчета трафика. Или, допустим, первой политикой Вы можете описывать доступ к удаленным http-серверам c подсчетом трафика, поддержкой месячных квот и блэк-листов, а во второй политике Вы можете описать совершенно свободный доступ в интернет без ограничений. И далее, можете применить эти политики разным клиентам, к примеру, первую - основной массе клиентов, а вторую - начальнику и себе любимому :).

       В веб-интерфейсе работа с политиками ведется в меню "Настройки->Политики", там есть поиск по политикам, режим создания новой политики, редактирование, поиск использующих политик у пользователей и т.д..
       В консоли создавать новые и править существующие политики можно простым редактированием файла policies.

    ##Примечание: Будьте внимательны при редактировании политик, уже назначенных одному или нескольким клиентам - НЕЛЬЗЯ существенно видоизменять политику если она уже на ком то применена. Допускается дополнение таких политик новыми строками, но воздерживайтесь от их видоизменения.
       Объясню почему: При простом редактировании текста политик с ранее сгенерированными по ней правилами ничего не происходит - для вступления изменений в силу требуется запустить процедуру пересоздания конфигурации (RELOAD). Эта процедура сперва выгружает счетчики существующих правил, а потом, при формировании новых правил для Вашей политики, процедура загружает показания до этого выгруженных счетчиков... И на этом моменте Вас вполне объективно будут ждать грабли: чем сильнее Вы видоизменили строки политики, тем больше вероятность того что программа не сможет определить какие показания счетчиков соответствуют Вашей политике. В результате - счетчики по нулям.

    Далее разберем синтаксис политик, он имеет следующий вид:

    policy <policy_name> {
    title "любое описание политики"
    [accept | reject] <proto> <ports> [dst | src] [[from | to] <address>] [quota <quota>]
    [action] [ snat|masquerade|dnat|input [<destination>] ]
    [in | out] [<provider>]
    [manglemark <N>]
    [count [nolog] ]
    [[blacklist | allow_only] <list>]
    }

      ВНИМАНИЕ: если Вы создаете политику из веб-интерфейса, то первую строку "policy <policy_name> {" и последнюю строку "}" писать НЕ НУЖНО. Программа эти теги использует для идентификации политик и отделения их друг от друга, поэтому при созхранении политики начальные и конечные теги будут добавлены автоматически.
    Но если работаете с политиками из консоли, Вы должны обязательно использовать полный синтаксис.

    И еще кое что: обратите внимание что закрывающая скобка политики расположена на отдельной строке, а открывающая скобка - на одной строке с названием политики. Это "правильный" синтаксис, к которому программа приучалась с рождения, пожалуйста, используйте именно такое написание.

        По порядку:
       
  • строка 3: accept | reject - непосредственно описывает вид трафика и определяет главное действие над ним - accept или reject.
        <proto> может быть tcp, udp, icmp или all.
        <ports> может быть одним цифровым портом или несколькими портами через запятую в скобках: (25,1080,3128). Порт или набор портов может иметь отрицание, которое будет означать отрицание порта или ВСЕГО набора портов, причем ставится отрицание внутри скобок: (!25,1080,3128).
        dst | src указание направленности трафика (--sport/--dport) : если src, то трафик идет с вышеуказанных портов, а если dst - на вышеуказанные порты. По умолчанию dst. К примеру, если у нас стоит задача описать ответный трафик почтового сервера (внутри сети есть почтовый сервер, к которому из интернет создан доступ через DNAT, а у нас стоит задача описать в политике трафик, который идет ОТ почтового сервера в интернет), то в этом случае это будет src from 192.168.0.10, где ip-адрес это <address>
        from | to если указано, то при генерации правила, в качестве соответствующего аргумента (-s если from и -d если to) используется указанный в этой опции адрес. По умолчанию если iptables принимает в правиле сурс или дестинейшн пустым, то понимает его как all (разрешено все). К примеру, если Вам нужно разрешить трафик tcp (25,110,80) только на mail.ru, то так и пишем: accept tcp (25,110,80) to www.mail.ru. Имейте ввиду (!) что при генерации правила программа вместо www.mail.ru попытается подставить IP (доменное имя в правило iptables пихать как то некорректно), доменное имя от IP она пытается отличить по наличию трех точек, что может быть корректно не всегда. Поэтому желательно использовать все таки IP.
    Еще пример: Вам нужно сделать проброс порта tcp:3389 внутрь сети, но только с двух ip-адресов. Тогда политика будет выглядеть так:
    title "Terminal Services DNAT for 2piplz"
    accept tcp 3389 from 11.11.11.11
    accept tcp 3389 from 22.22.22.22
    in myprovider
    count
    action dnat 192.168.0.100
    Согласитесь, несложный синтаксис? :)

        quota <quota> Здесь указывается квота трафика, при достижении которого этот конкретный accept работать перестанет. Может указываться просто цифрами (понимается как байты), можно указывать обозначения мегабайт и гигабайт: 750mb, 2gb и т.п.. Т.е. если в политике несколько строк accept с разным трафиком, но quote указано только на одном accept, то при достижении лимита остальные два продолжат работать.
       
  • строка 4: action - Определяет действие, которое будет применяться ко всем строкам accept в политике. Действем может быть dnat, snat, masquerade или input. Из опций здесь можно указать только адрес destination у dnat.
        Заметьте, у действия SNAT адрес source не указывается, в этом нет необходимости т.к. через какой внешний интерфейс уходит трафик определяет опция out.
        Так жде происходит и при действии MASQUERADE. Собственно, описанные три действия имеют свои прямые корни из iptables и, надеюсь, будут понятны многим читателям.
        А вот о действии INPUT я поясню - это действие было специально добавлено для обработки трафика, идущего не транзитно через маршрутизатор, а локально к демону или процессу, работающему на сервере. В основном правила, генерируемые этим действием, выполняют accept для трафика своего демона и, если в политике указывается опция count, то "прогоняют" трафик через цепочки подсчета трафика. Таким образом это действие может использовать для подсчета и сбора статистики входящего и исходящего трафика для локальных приложений сервера.
       
  • строка 5: in | out - как уже было сказано, эта опция определяет через какого провайдера трафик будет уходить или наоборот, через какого он будет приходить (например для dnat).
       
  • строка 6: manglemark N - Если указано, то все пакеты, соответствующие политике, будут маркироваться цифрой N в таблице mangle, а действия над ними будут осуществляться уже с приминением в правиле условия на совпадение маркировки "-m mark".
       
  • строка 7: count [nolog] - Если указано, то по всем строкам accept будет проводиться обработка счетчиков пакетов и байт в специальных таблицах COUNT_IN и COUNT_OUT. Опция nolog указывается в том случае, если Вы не хотите чтоб сведения о пакетах (размер, адреса источника и назначения, порт и т.п.) записывались в базу демона ulog. Имейте при этом ввиду что в этом случае Вы не сможете смотреть статистику о посещаемых сайтах по клиентам с этой политикой.
       
  • строка 8: [[blacklist | allow_only] <list>] - управляет приминением листов ipset к данной политике (ко всем accept). Соответственно, если указано blacklist, то при адреса которые совпадают с указанным листом блокируются, а если указано allow_only, то блокируется все кроме указанного листа. Строк blacklist в политике может быть несколько, если необходимо применить к политике несколько листов, но опция allow_only должна быть только одна.


        Некоторые примеры политик Вы можете найти в дистрибутиве Fantomas в файле policies.

    Наверх    Содержание



    4.7 Управление сет-листами - списки Ipset, файл "ipsetlist"



        ...Файл "ipsetlist" представляет из себя перечисление листов ipset (по принципу один сет-одна строка), вообще используемых в Fantomas. При старте системы Fantomas ищет файлы с соответствующими именами в каталоге из переменной $sets_dir и загружает в память.
    Файлы листов ipset это файлы, сгенерированные самим ipset и, следовательно, в них можно использовать весь функционал ipset как Вам угодно, здесь Вас Fantomas никак не ограничивает.

        Работать с сет-листами возможно из веб-интерфейса или из консоли. Разница заключается в способах обработки сет-листов: для обработки сет-листов в консольном режиме Вы должны будете использовать "родной" инструментарий ipset и выполнять команды ipset вручную из коммандной строки, а что касается веб-интерфейса - для обработки сет-листов есть специальная сет-панель, в которой можно в реальном времени видеть состояние используемых сет-листов (загружен/не загружен, количество элементов и т.п.), создавать, изменять или удалять сет-листы. Вид фрагмента сет-панели:

        А это панель для работы с выбранным сетлистом:


        Также в веб-интерфейсе есть редактор сет-листов, в котором можно вручную редактировать сохраненные сет-листы как файлы на диске, но чтобы изменения вступили в силу, Вы должны будете выполнить RELOAD.

    В консоли, с помощью команд Ipset Вы можете создавать сетлисты, редактировать, связывать их, и сохранять в каталоге $sets_dir. После этого Вы должны добавить имена Ваших новых сетов в файл ipsetlist, иначе при перезагрузке или процедуре RELOAD они не будут загружены.

    Подробно на использовании ipset останавливаться не будем, т.к. для него существует его родная документация, с которой я Вам рекомендую ознакомиться. Ее можно найти в интернет или с консоли просто сделать man ipset.

    Хотя как закрепления информации давайте рассмотрим пример:
    ipset -N set_video_nets nethash
    ipset -A set_video_nets 208.117.224.0/19
    ipset -A set_video_nets 83.229.247.0/24
    ipset -N set_video_ip iphash
    ipset -A set_video_ip 94.100.179.115
    ipset -A set_video_ip 81.19.66.144
    ipset -A set_video_ip 81.19.66.145
    ipset -A set_video_ip 74.125.77.100
    ipset -A set_video_ip 74.125.77.113
    ipset -A set_video_ip 74.125.77.102
    ipset -A set_video_ip 74.125.77.139
    ipset -N set_videos setlist
    ipset -A set_videos set_video_nets
    ipset -A set_videos set_video_ip
    cd /usr/local/iptconf/sets
    ipset -S set_video_nets >./set_video_nets
    ipset -S set_video_ip >./set_video_ip
    ipset -S set_videos >./set_videos
    cd ..
    echo "set_video_nets" >>./ipsetlist
    echo "set_video_ip" >>./ipsetlist
    echo "set_videos" >>./ipsetlist
        Это пример создания из консоли сет-листа, состоящего из двух сетов разного типа - один из них имеет тип iphash, а другой nethash. Соответственно, в лист set_video_nets можно вносить подсети, а в set_video_ip - конкретные адреса, в итоге set_videos представляет их как один сет.

        ВАЖНО: Есть сет под названием locals. Он используется программой для определения локальных подсетей при генерации правил для iptables. НЕ УДАЛЯЙТЕ его! Иначе будут ошибки при генерации правил, если и сгенерируются, то вряд ли заработают.

    Наверх    Содержание



    4.8 Управление группами и клиентами



        Данные о группах и о клиентах лежат в каталоге из переменной $users_dir (по умолчанию /usr/local/iptconf/usr).

    В этом каталоге должны быть файлы с именами типа _usr_groupname. Собственно, здесь groupname это краткое название группы клиентов, а _usr_ - маска, которая должна быть перед названием группы. Причем, в названии файла не должно быть ".bak". Именно такие файлы ищет и читает Fantomas, а потом пытается найти в них сведения о своих клиентах.

    По умолчанию каталог может быть вообще пуст, если при установке программы, установщик для Вас не проводил сканирование сети с помощью nmap. Если хотите, скрипт, работающий с nmap, называется sbnetscan и лежит в каталоге tools. Этот скрипт просканирует подсеть, которую Вы ему укажете, создаст файл _usr_default с политикой по умолчанию для всех клиентов - default. Если это для Вас подходит, можете подправить по своим потребностям политику default и запустить sbnetscan.

    Синтаксис файлов "_usr_*" следующий:

    title "Подробное название группы клиентов"
    _default_policy=<default_policy_name>
    <client_ip1> [ policy:<policies> ] [ cname:"client_name" ]
    ...
    <client_ipN> [ policy:<policies> ]
        Полагаю здесь с первыми двумя строками все понятно, поясню по остальным: каждая строка начинается ip-адресом клиента, после которого может быть аргумент "policy", который через двоеточие указывает на одну или несколько политик, назначенных клиенту. Аргумент "cname" служит для указания имени клиента, которое должно указываться в кавычках и без пробелов.

        К примеру, если политика назначена одна, то она указывается просто через двоеточие: 192.168.0.11 policy:default_web .
    А если политик несколько, то они после двоеточия заключаются в скобки и перечисляются через запятую:
    192.168.0.11 policy:(default_web,out_smtp_allow,out_rdp_allow) .
        Если после адреса клиента аргумент "policy" отсутствует, то подразумевается что клиент использует политику по умолчанию для группы, которая задана выше в аргументе _default_policy.


  • Обработка клиентов в консоли

  •     Начиная с версии 0.1.5 в Fantomas был расширен функционал консольной утилиты программы iptconf.php (см.раздел 4.9.) - появилась возможность просматривать состояние счетчиков клиента и в реальном времени добавлять и удалять клиентам политики (как и в веб-интерфейсе, при добавлении политики по ней генерируются правила, и при удалении правила удаляются).
        Таким образом, можно просто вписать отдельной строчкой адрес клиента в файл группы, а затем воспользоваться утилитой iptconf.php для назначения политик этому клиенту. Подробней о работе утилиты см. в разделе 4.9..

        В более ранних версиях Fantomas работа с клиентами заключается в прямом редактировании файлов групп, при этом политики для клиента также необходимо вписывать вручную. Затем, для того чтобы изменения вступили в силу нужно запустить процедуру пересоздания конфигурации (RELOAD).


  • Работа с клиентами в веб-интерфейсе

  •    В веб-интерфейсе работа с клиентами происходит в реальном времени: при каждом изменении настроек клиента (добавлении или удалении политики) соответственно создаются или удаляются правила по обрабатываемой политике для текущего клиента: при добавлении клиенту политики генерируются соответствующие правила, при удалении политики с клиента - правила удаляются. Так выглядит страница клиента:

       Для того, чтобы применить для клиента новую политику нужно просто выбрать ее идентификатор из разворачивающегося списка и нажать "Ok".

       Создание нового клиента происходит через веб-форму аналогичного типа. Вообще, при создании веб-интерфейса изначально упор делался на удобство для администратора, простоту и юзабилити, поэтому многое в Fantomas, надеюсь, Вам будет интуитивно понятно.

       Из тонкостей хочу еще предупредить: при операциях с клиентом для упрощения работы и повышения юзабилити, Fantomas не спрашивает подтверждение, а сразу выполняет указанное действие. Поэтому будьте внимательны, кликая мышкой по иконкам. Впрочем, на всех иконках есть всплывающие подсказки...

    Наверх    Содержание



    4.9 Глобальные процедуры: конфигурирование системы и обработка счетчиков



        Fantomas имеет процедуры, которые выполняются не "на лету" по кому то отдельно, а глобально для всей конфигурации в целом.
        Например, Эти процедуры, прочитав настройки, генерируют конфигурацию Iptables при загрузке системы (service iptcldr start), аналогично при завершении работы эти же процедуры выгружают счетчики для того, чтобы при загрузке их прочитать.
        Также эти функции можно использовать и произвольно по необходимости, например, для бекапа счетчиков или для устранения каких либо ошибок в конфигурации путем ее полной перегенерации.

        Итак, глобальные процедуры:

  • SaveCounts (в консоли) он же Export counters (веб-интерфейс) - в этом режиме программа выгружает счетчики трафика по клиентам из iptables/kernel в файл counters в каталоге iptconf (по умолчанию /usr/local/iptconf).     Экспорт счетчиков также выполняется при остановке сервиса iptcldr, а при его запуске запускается режим RELOAD (генерирование конфигурации), который при генерации правил, из файла counters подставляет счетчики в формируемые правила.
        Также файл counters может использоваться и просто как бэкап показаний счетчиков - при каждом экспорте старый файл counters не затирается, а переименовывается и перемещается в каталог из переменной $backup_dir. К примеру, если вдруг каким то образом показания счетчиков сбились, можно взять самый актуальный файл счетчиков, подсунуть его на место counters и запустить RELOAD с опцией NoKeepCounts (об этом дальше).

  • RELOAD - режим, в котором происходит перегенерирование конфигурации iptables. Сначала вызывается Export_counters, счетчики сохраняются в файле counters, затем выполняется очистка iptables, перезагружаются листы ipset, отрабатывает inits, и дальше заново формируется конфигурация правил на основе данных о клиентах, о политиках и на основе сведений о счетчиках из файла counters.
        Режим имеет опцию NoKeepCounts - если она указана, то экспорт счетчиков не производится и при формировании правил сведения о счетчиках берутся из файла counters, который был записан при предыдущем экспорте (или который Вы заранее на его место подсунули).

  • NewPeriod (в консоли) он же Объявить Амнистию (веб-интерфейс) - в этом режиме производится экспорт счетчиков, бэкап файла счетчиков, очищаются показания счетчиков в правилах всех клиентов по всем их политикам, затем текущая дата записывается как дата начала нового периода.


        Запускать процедуры возможно как из веб-интерфейса так и в консольном режиме.
        В веб-интерфейсе панель глобальных процедур расположена на странице состояния Iptables, в меню "Система->Iptables".
    Скрин 2. панель глобальных процедур:

        В консольном режиме запуск процедур выполняется через параметры скрипта iptconf.php (см.ниже).

    Наверх    Содержание



    4.10 Консольная утилита iptconf.php



        Этот скрипт предназначен для доступа к базовому функционалу программы из коммандной строки.

    Синтаксис:

  • Вызов процедуры пересоздания конфигурации (RELOAD):
    iptconf.php [NoKeepCounts] Reload
        Заметьте, NoKeepCounts указывается перед самим Reload - это правильное написание аргументов. Если написать наоборот, то Reload может случайно "забыть" что ему говорили "NoKeepCounts" и станет выгружать счетчики без учета этого параметра...

  • Вызов процедуры сохранения счетчиков в файл counters (SaveCounts):
    iptconf.php SaveCounts
  • Процедура открытия нового периода (NewPeriod/Объявить Амнистию):
    iptconf.php NewPeriod
  • Просмотр состояния политик и счетчиков трафика по политикам:
    iptconf.php group=<groupname> client=<client_ipaddr> [ListPolicies] [ShowTraffic]
         возможен и сокращенный синтаксис:
    iptconf.php --grp=<groupname> --usr=<client_ipaddr> [lspols] [shtraf]
  • Работа со списком назначенных политик клиента:
    iptconf.php group=<groupname> client=<client_ipaddr> policy=<policyname> [AddPolicy|DeletePolicy]
         возможен и сокращенный синтаксис:
    iptconf.php --grp=<groupname> --usr=<client_ipaddr> --pp=<policyname> [addpol|delpol]


    Наверх    Содержание



    4.11 Ограничение скорости трафика клиентов, скрипт ifbtool


        Fantomas Iptconf использует шейпинг клиентского трафика на базе IFB.
        Я не буду вдаваться в глубокие теоретические излияния, если кому то интересны глубинные механизмы работы этой технологии - Вы можете почерпнуть всю интересующую информацию с официальной страницы ifb и iproute2, а я опишу механизм работы вкратце: ядро ОС Linux по умолчанию поддерживает модуль ifb и это делает эту технологию наиболее доступной для использования при шейпинге трафика. Работает это следующим образом: поднимается виртуальный интерфейс (к примеру, ifb0), в котором создаются несколько очередей обработки пакетов, каждая из которых может иметь свою дисциплину (htb, sfq, tbf &etc). Каждая из этих дисциплин обработки очереди пакетов имеет свои свойства, параметры и особенности, подробно об этом Вы можете прочитать в документации LARTC. Далее, на непосредственно существующем сетевом интерфейсе, к которому подключены клиенты, добавляются правила, переадресовывающие трафик указываемых Вами клиентов через созданный виртуальный интерфейс, при этом указывая какой именно из нескольких очередей пакетов этот трафик будет обработан. Соответственно, при поступлении трафика в очередь пакетов виртуального интерфейса, начинают отрабатывать алгоритмы дисциплины очереди и применяются указываемые Вами ограничения скорости трафика, а после этого пакеты возвращаются снова на физический сетевой интерфейс...

        Управлять этим механизмом Вы можете из веб-интерфейса в разделе "Клиенты и трафик->Шейпер трафика". На этой странице Вы можете включить/выключить шейпер и управлять набором правил шейпера.

        По параметрам шейпера следует пояснить следующее:
        HW Интерфейс - это физический сетевой интерфейс, обычно это внутренний интерфейс Вашего роутера, к которому подключена подсеть с Вашими клиентами.
        IFB Интерфейс - виртуальный ifb-интерфейс, через который будет осуществляться пересылка трафика, оба этих параметра настраиваются в веб-интерфейсе в разделе "Настройки->Параметры->Система".

        И еще кое что: когда Вы задаете скорость трафика для клиентов значения для входящей и исходящей скорости указываются слитно с единицами измерения - kbit, mbit, kbps, mbps.
        Если указаны только цифры, то по-умолчанию подразумеваются килобиты(kbit). Пример: 512kbit - 512 килобит, 256 - 256 килобит.

        По умолчанию, когда поднимается интерфейс ifb, система создает интерфейс с именем ifb0, поэтому если Вы не планируете использовать более одного ifb-интерфейса, то менять этот параметр смысла нет. Но Вам нужно настроить название HW-интерфейса.
        Я не зря упоминул о нескольких ifb-интерфейсах - в системе может быть и несколько таких интерфейсов и они могут содержать совершенно разные очереди пакетов для совершенно разных задач. Просто для "резания" скорости трафика в Fantomas вполне достаточно одного интерфейса.

        Более широкие возможности работы для работы с ifb дает консольный скрипт ifbtool, который идет в дистрибутиве Fantomas и лежит в каталоге tools, в том же каталоге есть и файл с описанием скрипта, поэтому на этом я позволю себе подробно не останавливаться.
        Для получения подробного описания синтаксиса ifbtool сделайте в консоли следующее:

    cd /usr/local/iptconf
    tools/ifb help

    Наверх    Содержание












    Назад