Мы — долго запрягаем, быстро ездим, и сильно тормозим.

FreeBSD
  настройка
  начальная настройка
  Установка FreeBSD
  DUMMYNET
  Сборка ядра
  IPFW
  обновление
  portsnap
  CP1251 на FreeBSD
  loader.conf
  defaults/rc.conf
  jail
  Ntpdate/Ntpd
  diskless
  Обновление мира ("world")
  PBR & PF
  bsnmpd
  newsyslog
  if_bridge
  make.conf
  PBR & IPFW
  Работа с HDD
  sshd & AD
  Удаленное разбиение HDD
  Заметки об IPFW
  FreeBSD на VDS
  CVSUP и софт через Proxy
  i386=>amd64
  ALTQ в IPFW
  Виртуальный свитч
  VPN сервер по средствам mpd5.
  NTP
  sysupdate
  mpd5 L2TP
  freebsd + webcamera
  IPFW policy (PBR)
  RAID1 via LAN
  зеркальный RAID1 на ОС FreeBSD
  4.x => 7.x
  portdowngrade
  Быстрое обновление портов
  ipfw nat
  Использование csup
  UTF-8 console
  dump/restore
  hast carp zfs ucarp cluster
  ng_nat
  Wi-FI роутер + DHCP + DNS
  backup/restore & ZFS
  Обновление ОС и портов через SVN.
  подсчёт трафика
  программы
  почтовые системы
  Шелезяки
  Мелочи
  Файловая система
  WWW
  Security
  system
  Games Servers
  X11
  Programming
Очумелые Ручки
OpenBSD
Cisco


www.lissyara.su —> статьи —> FreeBSD —> настройка —> ipfw nat

Подробное руководство по ipfw nat

Автор: terminus.


Версия статьи 1.3.6

Оглавление:

  • Опции конфигурации ipfw nat
  • Пример 1
  • Пример 2
  • Пример 3
  • Пример 4
  • Пример 5
  • Пример 6
  • Пример 7
  • Дополнительная информация


    По странному стечению обстоятельств в Сети встречается очень мало внятных руководств описывающих функции и сценарии применения механизма ipfw nat, несмотря на то, что его поддержка появилась уже давно - начиная с версии FreeBSD 7.0. Самое обидное, что удручающе выглядит секция man ipfw посвященная nat. А ведь именно ее начинает читать любой кто хотел бы попробовать в деле "ядерный нат", и, что закономерно - не всегда разбирается. В итоге люди переходят на natd, а некоторый горячие головы начинают использовать даже альтернативные фаерволы такие как pf/ipf. Целью заметки является детализированное (по мере сил) описание ipfw nat, а так же опыта использования этого инструмента в различных сетевых конфигурациях. В заметке будет много смысловых отсылок на замечательную  статью Вадима Гончарова (nuclight) где давалось подробное описание внутреннего устройства ipfw и сетевой подсистемы FreeBSD.

    Примеры приводимые в моей заметке отрабатывались на FreeBSD 7.2-STABLE.


    Прежде всего необходимо детально описать как именно происходит движение трафика в сетевом стеке FreeBSD. Без этого понимания целостной картины того "что же мы делаем", не сложится и все скатится просто к набору "хавтушек". На рисунках 1-а и 1-б показана гипотетическая система оборудованная двумя сетевыми адаптерами fxp0 и fxp1. Схема 1-а показывает физическое подключение, а схема 1-б уже логическое. Нас больше интересует схема логическая - на ней мы видим, что в каждом сетевом поключении для трафика существует два прохода - IN и OUT. Как легко можно догадаться в проход IN поступает трафик пришедший к нам из сети, а в проход OUT уходит то, что адресовано уйти в сеть к которой подлючен данный сетевой адаптер. Таким образом, возвращаясь к примеру системы с двумя сетевыми адаптерами, мы видим, что у нее существует четыре прохода для трафика. При добавлении к системе дополнительных сетевых адаптеров схема масштабируется.

    Но предыдущая схема не главная. На самом деле схема проходжения трафика через сетевой стек FreeBSD имеет только одну логическую сторону с проходами IN и OUT, независимо от количества сетевых адаптеров. Просто при движении трафика через стек, операционная система самостоятельно избирет какой именно из доступных IN и/или OUT проходов были и/или будут задействованы для передачи трафика. В соответствии с этим, к пакетам находящимся внутри сетевой подсистемы, добавляются метки указывающие на то, через какой IN проход конкретного сетевого адаптера к нам пришел трафик, и через какой OUT какого сетевого адаптера он уйдет из машины.


    Указанные два прохода IN и OUT важны тем, что при поступлении в них сетевого трафика, этот трафик попадает в фаервол где проходит через правила фильтрации ipfw. Таким образом, трафик проходящий через маршрутизатор проходит через правила ipfw два раза - на проходе IN сетевого адаптера через который он был получен, и на проходе OUT сетевого адаптера через который он будет передан (сейчас не рассматриваем случай включение фильтрации на уровне Ethernet - в таком случае трафик проходит через ipfw четыре раза). Точно так же трафик исходящий от самого маршрутизатора обязательно будет иметь свой OUT проход, а трафик адресованный непосредственно маршрутизатору войдет через свои IN проход.

    Ниже я привожу перепечатку части материала статьи Вадима Гончарова - того кусочка где объясняется движение трафика через Схему 2. Лучше самого автора я не напишу, а включить в статью это обьяснение очень-очень надо.



    ...Допустим, набор правил у нас такой:

    ipfw add 1        deny  tcp from any to any 135,445
    ipfw add 2 divert 8668  all from any to any via ext0
    ipfw add 3       count icmp from any to any
    ipfw add 4       allow  all from any to any
    # в 65535 по умолчанию deny

    Когда пакет проходит через машину, к нему системой прикрепляется дополнительная информация, помимо собственно его содержимого, видного в tcpdump. Например, на каком интерфейсе он был получен, через какой отправляется, и т.п. Их можно проверять соответствующими опциями в правилах ipfw, на рисунке показаны места, где будут срабатывать соответствующие указания in/out и recv/xmit для сетевух.

    Рассмотрим одну сторону роутера с рисунка выше более подробно, с точки зрения вызовов функций в ядре (чуть более подробная картинка из мана). На самом деле, с точки зрения функций, на рисунке выше нет двух сторон, она только одна, и различается параметром - обрабатываемой сетевухой.

    То есть, пакет на входе передается драйвером в ether_demux(), затем он попадает в ip_input(), в точку (2), где выполняются базовые проверки на корректность пакета, после чего пакет прилетает в ipfw - функция ipfw_chk(). Допустим, правила были простые, без задействования других подсистем. Тогда, вернувшись из ipfw, пакет продолжает движение по ip_input(), которая смотрит, предназначен ли пакет нашей машине ("to me" в терминах ipfw), либо кому-то другому. Если нам, то пакет уходит в точку (3), где решится, в какой сокет какой юзерлэндной программе его отправить.

    Если же пакет был предназначен не нам, пакет из ip_input() направится в точку (4), где ip_forward() проверит, установлен ли sysctl, разрешающий форвардинг, произведет декремент TTL и т.п. действия, после чего пакет придет в точку (6), функцию ip_output(). Туда же он попадет напрямую, когда какая-нибудь программа решит что-то отправить в сеть и передаст данные ядру.

    Функция ip_output() первым делом смотрит в таблицу маршрутизации, определяя, каков шлюз и на каком интерфейсе он находится. С этой информацией пакет вновь передается в ipfw, в котором опять пробегается по всем правилам. После выхода из ipfw_chk() в ip_output(), если ядро было скомпилировано с соответствующей опцией, проверяется, не был ли применен ipfw fwd - если да, то просмотр  таблицы маршрутизации выполняется заново с целью получить MAC-адрес нового шлюза. Затем пакет в точке (7) покидает ip_output() и передается дальше, на L2 и потом к драйверам интерфейсов.

    Это всё было для случая простых правил файрвола. Теперь, предположим, там появляется divert, рассмотрим на примере правил выше. Пакет из внутренней сети куда-то в Интернет на порт 80 войдет на внутреннем интерфейсе в точку (1), пройдет начальные проверки ip_input() в (2), будет передан в ipfw_chk() и начнет проходить по правилам. Под правило 1 он не подпадает, под 2 тоже, так как имя интерфеса сейчас int0, правило 3 опять-таки не срабатывает, но под правило 4 подходят все пакеты, и он выходит из ipfw_chk() дальше в ip_input(). Там выясняется, что предназначен он идти в Интернет, поэтому пакет попадает в точки (4) и затем (6), где ip_output() определяет адрес шлюза и то, что интерфейс будет ext0, с чем пакет и попадает опять в ipfw_chk() и снова идет по правилам. Правило 1 снова не подходит, но условие правила 2 срабатывает - "via ext0, проходим прямо сейчас через интерфейс ext0, в любом направлении".

    И вот здесь срабатывает divert - пакет из ipfw_chk() передается в точку (8), в подсистему divert, при этом к нему предварительно прикрепляется метаинформация с направлением (out), интерфейсом (ext0) и номером правила 2. Подсистема divert передает этот пакет в указанный в правиле порт (8668), на котором в нашем случае работает natd. Тот обрабатывает пакет, метаинформацию же - не трогает, и возвращает подсистеме divert вместе с измененным пакетом как есть (так поступают большинство divert-демонов, хотя любой их них, в принципе, может поменять эту информацию, и пакет будет передан в другое место).

    Подсистема divert выводит полученный из natd пакет из точки (9) в точку (6). Следует обратить внимание - пакет попадает в ip_output() ЕЩЕ РАЗ! Это необходимо, так как демон мог вернуть пакет с совершенно другими адресами или вообще создать новый пакет. Но в нашем случае пакет несет с собой диверт-тег, метаинформацию, самая важная часть которой - номер правила. При входе в ipfw_chk() пакет первым делом проверяется на наличие этого самого тега. Он найден, и в нем содержится номер правила - 2. Поэтому ipfw_chk() пропускает правила номер 1 и 2, и начинает с номера 2+1, то есть 3 (если бы пакет применялся к указанному номеру, а не следующему, то он снова попал бы в divert, то есть получился бы бесконечный цикл).

    На этом месте пакет продолжит движение с правила номер 3 и дальше, как обычно, уйдет в точке (7) в сеть. Таким образом, несмотря на то, что пакет попадал в ip_output() два раза, с точки зрения пользователя это выглядит так, как если бы он был там один раз и никуда из файрвола не убегал - просто на правиле 2 в нем волшебным образом поменялись адреса и порты.

    Аналогичным образом, ответный пакет, возвращающийся из Интернета на интерфейс ext0, пройдет через машину по пути (1) - (2) - начало ipfw_chk() - правило 1 - правило 2 - (8) - divert - natd - divert - (9) - (2) - проверка в ipfw_chk() - правило 3 - правило 4 - (4) - (6) - начало ipfw_chk() - правило 1 - правило 2 - правило 3 - правило 4 - (7) - отправка через интерфейс int0.

    Подобное выведение пакета из обработки ipfw в другую подсистему - не уникально для divert, это общая схема работы в стеке FreeBSD. Например, действия pipe и queue в dummynet, передача пакета в netgraph (а также появившийся в 7.0 ipfw nat) действуют по тому же принципу. Отличие, однако, в том, что в этих подсистемах пакет остается внутри ядра, никакому демону не передается. Поэтому, во-первых, подсистемы вместо номера правила сохраняют на него полный указатель, и пакет вернется непосредственно в следующее правило, даже если оно имеет тот же номер. Во-вторых, для таких подсистем действует настройка one_pass в соответствующем sysctl - если она включена, то при повторном входе пакета в ipfw после возврата из подсистемы dummynet (netgraph), ipfw_chk() сразу вернется без прохода по правилам, как если бы к пакету был применен allow. Это поведение позволяет упростить правила файрвола, когда известно, что если пакет попал в трубу, то он уже точно отправляется дальше, и не требуется после каждого pipe вставлять allow (чтобы пакет не попал в следующие правила и следующие pipe/queue). Если же конфигурация требует сначала ограничить трафик, а потом уже разбираться по замысловатым требованиям, что из него разрешить, а что запретить, то упрощению правил наоборот будет способствовать отключенный one_pass - поскольку с ним вместо allow, расположенных до pipe, пришлось бы делать skipto.

    Итак, как уже было сказано, пакет проходит по списку правил последовательно, в порядке возрастания номеров правил. Список правил можно рассматривать как таблицу с тремя столбцами: номер, действие (и его параметры, например log), и условия, при которых пакет соответствует правилу (например, от адреса 1.1.1.1 адресу 2.2.2.2). Таблица просматривается сверху вниз, пакет сравнивается с условиями. На первом совпавшем условии смотрим в столбец действий, выполняем действие, прекращаем просмотр...



    Теперь, зная, что именно и в какой последовательности происходит с пакетами на их пути через сетевой стек FreeBSD мы можем приступать к изучению правил ipfw nat.

    Механизм ipfw nat можно рассматривать как своеобразный фильтр-преобразователь трафика. В зависимости от того как настроен нат, и от того какие IP адреса отправителя и получателя есть в проходящем через него пакете, нат будет преобразовывать в пакете IP адрес отправителя, либо IP адрес получателя, или же просто отвергать пакет. Важно помнить то, что нат разделяет трафик на исходящий (тот который надо маскировать) и входящий (тот который надо демаскировать) в зависимости от того на каком проходе (OUT или IN) он был получен. Так, трафик попавший в нат из прохода OUT требуется маскировать (заменить IP адрес отправителя на IP адрес нат машины), а трафик пришедший из прохода IN демаскировать. Развернуть это поведение можно используя директиву revers - тогда все поведение поменяется и можно будет запускать нат не на внешнем сетевом интерфейсе (который смотрит в интернет), а на внутреннем (том который смотрит в локальную сеть). Детальное описание того как работает механизм нат приводить, наверное, излишне. На поведение механизма nat влияет настройка параметра one_pass - в зависимости от ее значения трафик прошедший через нат может либо вернуться в проход фаервола из которого он был направлен в нат, либо выйти из фаервола. Такая гибкость дает возможность делать с трафиком много интересных вещей. ipfw nat позволяет запускать множество своих экземпляров каждый из которых имеет свою нат-таблицу и настройки. Объеденить несколько экземпляров для использования ими общей нат-таблицы - нельзя.


    Возможности ipfw nat и опции конфигурации.

    ipfw nat основан на коде библиотеки libalias. На ней же построенны как natd так ng_nat. Функционал libalias перенесенный в ipfw nat практически полностью повторяет все то, что есть в natd за исключением некоторых специфических вещей. К сожалению man страница для ipfw nat дает очень скупое описание его возможностей, поэтому при изучении опций конфигурации можно пользоваться man страницей для natd.

    Параметры конфигурации и их перевод.

         ip ip_address
    
    	Параметр предписывает IP адрес используемый при маскировании и
    	демаскировании. Этот параметр (или же параметр "if") должны быть
    	указаны. Установка параметра "proxy_only" отменяет действие
    	параметров "ip" и "if". В этом параметре обычно указывается адрес
    	назначенный "внешнему" сетевому интерфейсу. Может быть указан только один
    	IP адрес.
    
    	Во всех уходящих во вне пакетах, исходный IP адрес отправителя будет
    	замещен на адрес указанный в этом параметре. Все приходящие из вне пакеты
    	будут проверяться на совпадение с параметрами для какого-либо из ранее
    	установленных соединений, и в случае нахождения совпадения, пакет будет
    	демаскирован. Если совпадения не будет найдено, проверяются и применяются
    	все директивы redirect_port, redirect_proto и redirect_addr.
    	Если пакет не подпадает не под один из установленных
    	критериев демаскировки и не установлен параметр "deny_in", то тогда
    	пакет будет принят для локальной машины. Если параметр
    	"deny_in" установлен, то тогда пакет будет удален.
    

         if nic
    
    	Параметр предписывает IP адрес используемый при маскировании и
    	демаскировании, на основе имеющихся настроек для сетевого
    	интерфейса с именем "nic".
    	В случае динамического изменения IP адреса на сетевом интерфейсе,
    	адрес маскировки и демаскировки будет так же динамически изменен.
    

         log
    
    	Параметр предписывает включение накопления внутренней статистики по
    	количеству и типу активных соединений.
    

         deny_in
    
            Параметр предписывает запрет пропускать через nat входящие пакеты для
    	которых нет совпадения во внутренней таблице активных соединений,
    	или же нет совпадения с другими правил демаскировки.
    
    	Если данный параметр не установлен то для входящих соединений
    	будет создаваться новая запись в таблице активных соединений
    	и пакет будет пропускаться.
    

         same_ports
    
    	Параметр предлагает механизму nat поведение при котором тот будет
    	стараться сохранять оригинальные номера портов в уходящих
    	(маскируемых) пакетах.
    
    	При установке данного параметра такие протоколы как RPC будут иметь больше
    	шансов на успешную работу. Если по какой-либо причине сохранить оригинальные
    	номера портов невозможно, то пакет будет молча приобразован без учета этого
    	предписания.
    

         unreg_only
    
    	Параметр предписывает проводить маскировку только для тех исходящих пакетов,
    	чей адрес отправителя находится в классах "незарегистрированных" IP адресов.
    	В соответсвии с RFC 1918 к такими классам относятся адреса из диапазонов
    	10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.
    

         reset
    
    	Параметр предписывает очищать внутреннюю таблицу активных соединений при
    	изменениях параметра "ip" указывающего адрес используемый при маскировании
    	и демаскировании.
    

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

         proxy_only
    
    	Параметр предписывает применять только правила прозрачного проксирования.
    	Правила маскировки и демаскировки при этом применяться не будут.
    

        redirect_addr localIP publicIP
    
    	Параметр предписывает проводить перенаправление трафика поступающего на
    	внешний IP адрес (publicIP), на машину с IP адресом во внутренней
    	сети (localIP). Этот механизм так же известен под названием
    	"статический NAT". Обычно статический NAT применяется в случаях, когда
    	провайдер выделил вам небольшой диапазон IP адресов, но он так же может
    	применяться при случаях с одним адресом:
    
    		redirect_addr 10.0.0.8 0.0.0.0
    
    	Данная команда будет пересылать весь входящий трафик на машину с
    	адресом 10.0.0.8
    
    	В случае, когда несколько внутренних адресов назначены для пересылки с
    	одного внешнего адреса:
    
    		redirect_addr 192.168.0.2 public_addr
    		redirect_addr 192.168.0.3 public_addr
    		redirect_addr 192.168.0.4 public_addr
    
    	весь входящий трафик будет пересылаться на последний из назначенных
    	адресов (192.168.0.4), но трафик исходящий с первых двух адресов по
    	прежнему будет маскироваться под адрес указанный в public_addr.
    

        redirect_addr localIP[,localIP[,...]] publicIP
    
    	Данная форма записи для параметра redirect_addr (а так же для
    	redirect_port) используется для прозрачного распределения сетевой нагрузки
    	между набором из нескольких серверов. Данная функция известна под
    	названием LSNAT (RFC 2391).
    
    	Например данная конфигурация для redirect_port:
    
    		www1:http,www2:http,www3:http www:http
    
    	означает, что входящие HTTP соединения для хоста www будут прозрачно
    	перенаправленны на хосты www1, www2 или www3, при этом выбор хоста для
    	перенаправления соединения будет произходить по алгоритму round-robin
    	(по очереди), но без учета текущей нагрузки на хосты или сеть.
    
    	Пример:
    
    	redirect_addr 192.168.0.10,192.168.0.11,192.168.0.12 10.0.0.100
    

        redirect_port proto targetIP:targetPORT[-targetPORT]
    	[aliasIP:]aliasPORT[-aliasPORT]
    	[remoteIP[:remotePORT[-remotePORT]]]
    
    	Параметр предписывает проводить перенаправление входящих соединений
    	поступающих на указанный номер порта(ов), на другой хост и порт(ы).
    	Аргумент "proto" может устанавливаться либо как tcp, либо как udp.
    	Аргумент "targetIP" указывает IP адрес на который должна происходить
    	пересылка трафика, а аргумент "targetPORT" порт (или диапазон портов)
    	на который будет перенаправлен трафик.
    	Аргумент "aliasIP" указывает IP адрес на который будут поступать
    	входящие соединения, а аргумент "aliasPORT" указывает номер порта
    	(или диапазон портов) на которые будут поступать входящие соединения.
    	Аргумены "remoteIP" и "remotePORT" при необходимости могут быть
    	использованы для более точного указания того какие именно входящие
    	соединения необходимо обрабатывать указанным правилом, устанавливая
    	соотвествие с удаленным источником/назначением трафика.
    	Если аргумент "remotePORT" не указан, то подразумевается, что
    	имеются в виду номера всех портов.
    	
    	Аргументы targetIP, aliasIP и remoteIP могут указываться как в
    	виде IP адресов, так и в виде имен хостов. Аргументы targetPORT,
    	aliasPORT и remotePORT указывающие диапазоны портов, не обязательно
    	должны полностью совпадать по начальным и конечным значениям
    	диапазонов, но обязаны иметь одинаковый размер диапазонов.
    	Когда арументы targetPORT, aliasPORT или remotePORT указывают
    	на единственный порт (не диапазон), то их значения могут указываться
    	как имена соответвующих сервисов перечисленных в services(5).
    
    	Примеры:
    
    		redirect_port tcp inside1:telnet 6666
    
    	это означает, что входящие TCP пакеты направляемые на порт
    	6666 данной машины будут перенаправленны на порт 23 (telnet)
    	машины с именем inside1
    
    		redirect_port tcp inside2:2300-2399 3300-3399
    
    	это означает перенаправление входящих соединений поступающих на
    	диапазон портов 3300-3399 на машину с именем inside2, в диапазон
    	портов 2300-2399. В данном случае произойдет сопоставление
    	портов 1:1 - это значит, что порт 3300 будет перенаправляться
    	в 2300,	порт 3301 в 2301 и так далее.
    
    	Примеры:
    
    	redirect_port tcp 192.168.0.1:80 500
    
    	redirect_port tcp 192.168.0.1:80,192.168.0.10:22 500
    
    	redirect_port tcp 192.168.1.2:20-25 70-75
    
    	redirect_port tcp 192.168.0.1:80 1.2.3.4:500 5.6.7.8:1024
    

        redirect_proto proto localIP [publicIP [remoteIP]]
    
    	Параметр предписывает проводить перенаправление входящих соединений
    	протокола "proto" поступающих на внешний IP адрес "publicIP", на
    	машину с IP адресом "localIP" во внутренней сети. Аргумены "remoteIP"
    	при необходимости может быть использован для более точного указания того
    	какие именно входящие соединения необходимо обрабатывать указанным
    	правилом, устанавливая соотвествие с удаленным
    	источником/назначением трафика.
    
    	Если аргумент publicIP не указан, то по-умолчанию будет использоваться
    	адрес настроенный для маскировки/демаскировки.
    
    	Пример:
    
    		redirect_proto udp 192.168.1.43 1.2.3.4
    



    Примеры и сценарии применения механизма ipfw nat

    Теперь, когда мы познакомились как с описанием принципов прохождения трафика через стек, так и с описание доступных опций конфигурирования механизма ipfw nat, можно приступать к составлению правил и рассмотрению их работы. Дальнейшее описание будет строиться по принципу "задача - решение", а так же по принципу постепенного усложнения конфигурации с детальными описаниями того как работает предлагаемое решение. Есть мнение, что на примерах проще понять изучаемый материал, а кроме того эти примеры можно будет использовать в работе.

    Включение ipfw nat и Dummynet

    Либо пересборка ядра с дополнительными параметрами:
    options         IPFIREWALL
    options         IPFIREWALL_VERBOSE
    options         IPFIREWALL_VERBOSE_LIMIT=50
    options         IPFIREWALL_NAT
    options         LIBALIAS
    options         ROUTETABLES=2
    options         DUMMYNET
    options         HZ="1000"
    

    Либо включение без пересборки (но так меньше возможностей для конфигурации)

    /etc/rc.conf
    firewall_nat_enable="YES"
    dummynet_enable="YES"
    




    Пример 1

    Простейший случай: рутер с двумя сетевыми адаптерами подключенными в локальную сеть и в интернет. Адрес в локальной сети 192.168.1.1 (сетевой адаптер fxp0), адрес в интернете 1.2.3.4 (сетевой адаптер em0).

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



    Конфигурация:

    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em0="inet 1.2.3.4 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    defaultrouter="1.2.3.254"
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=1
    



    /etc/firewall
    # правила разрешающие трафик через локальный интерфейс lo0
    # будут добавляться автоматически сами при старте фаервола
    # 100 allow ip from any to any via lo0
    # 200 deny ip from any to 127.0.0.0/8
    # 300 deny ip from 127.0.0.0/8 to any
    
    # разрешаем все через интерфейс локальной сети
    add 1040 allow ip from any to any via fxp0
    
    # боимся непонятного
    add 1050 deny ip from any to 192.168.0.0/16 in recv em0
    add 1060 deny ip from 192.168.0.0/16 to any in recv em0
    add 1070 deny ip from any to 172.16.0.0/12 in recv em0
    add 1080 deny ip from 172.16.0.0/12 to any in recv em0
    add 1090 deny ip from any to 10.0.0.0/8 in recv em0
    add 10100 deny ip from 10.0.0.0/8 to any in recv em0
    add 10110 deny ip from any to 169.254.0.0/16 in recv em0
    add 10120 deny ip from 169.254.0.0/16 to any in recv em0
    
    # настройка ната.
    # опции переноса строк "\" надо убрать все должно быть в одну строчку
    # опции redirect_port приведены для примера - как делать "проброс портов"
    nat 1 config log if em0 reset same_ports deny_in \
    redirect_port tcp 1.2.3.4:6881 6881 \
    redirect_port udp 1.2.3.4:4444 4444 \
    redirect_port tcp 192.168.1.24:25 25
    
    # заварачиваем все что проходит через внешний интерфейс в нат
    add 10130 nat 1 ip from any to any via em0
    
    # боимся непонятного
    add 65534 deny all from any to any
    




    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:

    Трафик инициализированный непосредственно от рутера из точки (5) рис.2 пройдет в точку (6). Попав ip_output() ему будет присвоен шлюз по-умолчанию и тег с сетевым интерфейсом em0 через который он должен выйти в интернет (via em0, а точнее xmit em0). Трафик войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 10130 и будет передан в точку (8) то есть на обработку в нат как выходящий трафик так как поступит он из прохода OUT. В подсистеме нат для трафика в таблице соединений будет создана запись соответствия пар IP_локальный:порт <-> IP_удаленный:порт. После этого в точке (9) трафик выйдет из подсистемы нат и будет передан обратно в точку (6), заново попав в ip_output(). Так как значение one_pass выставлено в 1 (то есть разрешено) то трафик выйдет из ipfw (как если бы для него было применено правило allow) и уйдет в интернет через em0.

    Трафик возвращающийся в виде ответа зайдет в точку (1) и попадет в проход IN имея при этом тег с сетевым интерфейсом em0 (via em0, а точнее recv em0) через который он был получен. Далее трафик зайдет в точку (2) и попадет в функцию ip_input() после чего войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 10130 и будет передан в точку (8) то есть на обработку в нат как входящий трафик так как поступит он из прохода IN. В подсистеме нат для трафика в таблице соединений будет найдена ранее созданая запись соответствия пар IP_локальный:порт <-> IP_удаленный:порт, после чего он будет демаскирован (в данном случае изменения фактически не будет так как адрес маскировки/демаскировки один и тот же - локальный 1.2.3.4). После этого в точке (9) трафик выйдет из подсистемы нат и будет передан обратно в точку (2) заново попав ip_input(). Так как значение one_pass выставлено в 1 (то есть разрешено) то трафик выйдет из ipfw (как если бы для него было применено правило allow) и поступит в локальный сокет на котором работает программа ранее  инициализировавшая соединение.

    Если из интернета приходит трафик не имеющий в таблице соединений записи соответсвия, то такой трафик при поступлении в нат будет отвергнут, так как в настройках выставлен параметр deny_in.

    Если из интернета приходит трафик адресованный для tcp 1.2.3.4:6881 то он дойдя до точки (8) и попав в нат, будет успешно демаскирован так как в таблице для него уже будет иметься статическая запись соответствия 1.2.3.4:6881 <-> IP_любой:любой_порт. После чего он так же как и в случае с любым трафиком возвращающимся из интернета, будет принят и поступит в локальный сокет на порту 6881.
    Ответный, уходящий с этого сокета трафик, пройдет через то же статическое правило и будет успешно обработан как это было в случае с любым трафиком уходящим в интернет.

    Для сети 192.168.1.0/24:

    Трафик инициализированный от хоста 192.168.1.56 из сети 192.168.1.0/24 войдет в рутер через ссетевой интерфейс fxp0 и пройдя через точку (1) получит тег с сетевым интерфейсом fxp0 (via fxp0, а точнее recv fxp0) через который он был получен. Далее трафик зайдет в точку (2) и попадет в функцию ip_input() после чего войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 1040 после чего выйдет из прохода IN фаервола, и попадет обратно в ip_input() где будет принято решение о том, что он предназначен не нам, а следовательно должен быть направлен в точку (4), в функцию ip_forward(). Попав в ip_forward() у IP трафика будет уменьшено значение TTL, а кроме того, после проверки разрешено ли проводить маршрутизацию (установка соответвующего значения sysctl выполненная из rc.conf через gateway_enable="YES") он будет передан в точку (6) в функцию ip_output(). Попав ip_output() ему будет присвоен шлюз по-умолчанию и тег с сетевым интерфейсом em0 через который он должен выйти в интернет (via em0, а точнее xmit em0). Трафик войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 10130 и будет передан в точку (8) то есть на обработку в нат как выходящий трафик так как поступит он из прохода OUT. В подсистеме нат для трафика в таблице соединений будет создана запись соответствия пар 192.168.1.56:порт <-> 1.2.3.4:порт <-> IP_удаленный:порт, а оригинальный адрес отправителя (192.168.1.56) в заголовке IP пакета будет заменен на IP адрес указанный для параметре "if" в настройках нат. После этого в точке (9) трафик выйдет из подсистемы нат и будет передан обратно в точку (6), заново попав в ip_output(). Так как значение one_pass выставлено в 1 (то есть разрешено) то трафик выйдет из ipfw (как если бы для него было применено правило allow) и уйдет в интернет через em0 имея IP адрес отправителя 1.2.3.4.

    Трафик возвращающийся в виде ответа зайдет в точку (1) и попадет в проход IN имея при этом тег с сетевым интерфейсом em0 (via em0, а точнее recv em0) через который он был получен. Далее трафик зайдет в точку (2) и попадет в функцию ip_input() после чего войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 10130 и будет передан в точку (8) то есть на обработку в нат как входящий трафик так как поступит он из прохода IN. В подсистеме нат для трафика в таблице соединений будет найдена ранее созданая запись соответствия пар 192.168.1.56:порт <-> 1.2.3.4:порт <-> IP_удаленный:порт, после чего он будет демаскирован - адрес получателя в заголовке IP пакета будет заменен с 1.2.3.4 на 192.168.1.56. После этого в точке (9) трафик выйдет из подсистемы нат и будет передан обратно в точку (2) заново попав ip_input() Так как значение one_pass выставлено в 1 (то есть разрешено) то трафик выйдет из прохода IN фаервола (как если бы для него было применено правило allow) и попадет обратно в ip_input() где будет принято решение о том, что он предназначен не нам, а следовательно должен быть направлен в точку (4), в функцию ip_forward(). Попав в ip_forward() у IP трафика бцдет уменьшено значение TTL, а кроме того, после проверки разрешено ли проводить маршрутизацию (установка соответвующего значения sysctl выполненная из rc.conf через gateway_enable="YES") он будет передан в точку (6) в функцию ip_output(). Попав ip_output() ему будет присвоен шлюз по-умолчанию и тег с сетевым интерфейсом fxp0 через который он должен выйти в локальную сеть (via fxp0, а точнее xmit fxp0). Трафик войдет в фаервол и начнет проходить через цепочку правил. Трафик дойдет до правила 1040. После этого трафик выйдет из ipfw и уйдет в локальную сеть через fxp0 имея IP адрес получателя 192.168.1.56.

    Если из интернета приходит трафик не имеющий в таблице соединений записи соответсвия, то такой трафик при поступлении в нат будет отвергнут, так как в настройках нат выставлен параметр deny_in.

    Если из интернета приходит трафик адресованный для tcp 1.2.3.4:25 то он дойдя до точки (8) и попав в нат, будет успешно демаскирован так как в таблице для него уже будет иметься статическая запись соответсвия 192.168.1.24:25 <-> 1.2.3.4:25 <-> IP_любой:любой_порт. После чего он так же как и в случае с любым трафиком возвращающимся из интернета, будет принят и пройдя по тому же маршруту через IN и OUT уйдет в локальную сеть на машину с IP 192.168.1.24.
    Ответный, уходящий с этого IP 192.168.1.24 трафик, пройдет через то же статическое правило и будет успешно обработан как это было в случае с любым трафиком уходящим в интернет.


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


    Пример 2

    Более сложный случай: рутер с двумя сетевыми адаптерами подключенными в локальную сеть и в интернет. Адрес в локальной сети 192.168.1.1 (сетевой адаптер fxp0), адреса в интернете 1.2.3.4 и 1.2.3.5 (сетевой адаптер em0).

    Задача: "раздавать интернет" для локальной сети, обеспечить проброс портов для внутренних адресов, разрешить прохождение трафика на отдельные порты самого рутера, а главное - используя шейпер Dummynet обеспечить честное распределение пропускной способности между клиентами локальной сети. Так же обеспечить проброс всего трафика для 1.2.3.5 на 192.168.1.36 используя redirect_addr.



    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em0="inet 1.2.3.4 netmask 255.255.255.0 -rxcsum"
    ifconfig_em0_alias0="inet 1.2.3.5 netmask 255.255.255.255"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    defaultrouter="1.2.3.254"
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=0
    



    /etc/firewall
    
    add 1040 allow ip from any to any via fxp0
    
    add 1050 deny ip from any to 192.168.0.0/16 in recv em0
    add 1060 deny ip from 192.168.0.0/16 to any in recv em0
    add 1070 deny ip from any to 172.16.0.0/12 in recv em0
    add 1080 deny ip from 172.16.0.0/12 to any in recv em0
    add 1090 deny ip from any to 10.0.0.0/8 in recv em0
    add 10100 deny ip from 10.0.0.0/8 to any in recv em0
    add 10110 deny ip from any to 169.254.0.0/16 in recv em0
    add 10120 deny ip from 169.254.0.0/16 to any in recv em0
    
    pipe 1 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1 
    queue 1 config pipe 1 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 2 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 2 config pipe 2 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    nat 1 config log if em0 reset same_ports deny_in \
    redirect_port tcp 1.2.3.4:6881 6881 \
    redirect_port udp 1.2.3.4:4444 4444 \
    redirect_port tcp 192.168.1.24:25 25
    
    nat 2 config log same_ports redirect_addr 192.168.1.36 1.2.3.5
    
    add 10130 skipto 10190 ip from 192.168.1.36 to any out xmit em0
    add 10140 skipto 10210 ip from any to 1.2.3.5 in recv em0
    
    add 10150 queue 1 ip from any to any out xmit em0
    add 10160 nat 1 ip from any to any via em0
    add 10170 queue 2 ip from any to any in recv em0
    
    add 10180 allow all from any to any
    
    add 10190 queue 1 ip from any to any out xmit em0
    add 10200 nat 2 ip from 192.168.1.36 to any out xmit em0
    add 10210 nat 2 ip from any to 1.2.3.5 in recv em0
    add 10220 queue 2 ip from any to any in recv em0
    
    add 10230 allow all from any to any
    
    add 65534 deny all from any to any
    






    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Настройки параметров queue mask 0xffffffff указывают на то, что динамические очереди будут создаваться на основании разницы любого бита из IP адресов отправителя или получателя. Скорость исходящего и входящего трафика будет ограничеваться под 10 Mbit/s.

    Для рутера:

    Трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до правила с номером 10150. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10160. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10180 будет выведен из фаервола и уйдет во внешнюю сеть.

    Ответный трафик пройдет через проход IN фаервола до правила 10160 где попадет в нат и будет демаскирован (в данном случае не сущесвенно) и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10170 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10180 где будет разрешен и выйдет из фаервола направившись в сокет программы инициализировавшей соединение.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10160 будет отвергнут так как нат запущен с опцией deny_in.

    Трафик идущий на порты 6881, 4444 и 25 будет заведен в нат на правиле 10160, потом в Dummynet на правиле 10170, а потом пропущен либо на сам рутер, либо на хост 192.168.1.24 соответственно.

    Для IP адресов 192.168.1.36 и 1.2.3.5

    Трафик приходящий из интернета на внешний IP адрес 1.2.3.5 должен быть проброшен на 192.168.1.36. Когда такой трафик пойдет через проход IN фаервола, он будет обработан на правиле 10140 которое перенесет обработку на 10210 - трафик будет передан во второй экземпляр ната где произойдет демаскировка (1.2.3.5 в IP  адресе получателя будет заменено на 192.168.1.36). После этого трафик вернется в фаервол и через правило 10220 попадет в Dummynet. Выйдя от туда он вернется в фаервол и дойдет до правила 10230 после чего будет выведен из прохода IN фаервола и уйдет в проход OUT где дойдя до правила 1040 будет принят, выйдет из фаервола, и будет отправлен на 192.168.1.36.

    Ответный трафик (а так же любой другой исходящий трафик) от 192.168.1.36 пройдет на проходе IN через 1040, потом на проходе OUT через 10130, 10190, 10200 и 10230 после чего уйдет во внешнюю сеть.

    Для сети 192.168.1.0/24:

    Трафик исходящий из сети 192.168.1.0/24 (например от хоста с IP 192.168.1.24), зайдет через сетевой адаптер fxp0 в проход IN фаервола и дойдет до правила 1040 после чего выйдет из IN и будет разрешен. Трафик зайдет в проход OUT где пройдет по правилам до 10150. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10160. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10180 будет выведен из фаервола и уйдет во внешнюю сеть.

    Ответный трафик пройдет через проход IN фаервола до правила 10160 где попадет в нат, будет демаскирован и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10170 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10180 где будет разрешен и выйдет из прохода IN фаервола. Трафик попадет в проход OUT фаервола где дойдет до правила 1040, после чего выйдет из IN и будет передан в сеть 192.168.1.0/24 через адаптер fxp0.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10160 будет отвергнут так как нат запущен с опцией deny_in.


    Пример 3

    В локальной сети из примера 2 появилась машина 192.168.1.80 на которой работает web сервер. Кроме того появился еще один компьютер с FreeBSD у которого есть два сетевых интерфейса (em1 со стороны интернета, и fxp1 со стороны локальной сети). Адаптер fxp1 подключен в ту же сеть и имеет IP 192.168.1.254, а адаптер em1 подключен ко второму провайдеру и имеет IP 5.6.7.8.

    Задача: не меняя настройки фаервола у имеющегося рутера 192.168.1.1 и TCP/IP настройки машины 192.168.1.80, обеспечить доступ к веб серверу работающему на 192.168.1.80 через подключение 5.6.7.8 используя два экземпляра ната.




    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em1="inet 5.6.7.8 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp1="inet 192.168.1.254 netmask 255.255.255.0"
    defaultrouter="5.6.7.254"
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=1
    



    /etc/firewall
    nat 2 config log if fxp1 same_ports reset deny_in
    
    add 1040 nat 2 ip from any to any via fxp1
    
    add 1050 deny ip from any to 192.168.0.0/16 in recv em1
    add 1060 deny ip from 192.168.0.0/16 to any in recv em1
    add 1070 deny ip from any to 172.16.0.0/12 in recv em1
    add 1080 deny ip from 172.16.0.0/12 to any in recv em1
    add 1090 deny ip from any to 10.0.0.0/8 in recv em1
    add 10100 deny ip from 10.0.0.0/8 to any in recv em1
    add 10110 deny ip from any to 169.254.0.0/16 in recv em1
    add 10120 deny ip from 169.254.0.0/16 to any in recv em1
    
    nat 1 config log if em1 reset same_ports deny_in \
    redirect_port tcp 192.168.1.80:80 80
    
    add 10130 nat 1 ip from any to any via em1
    
    add 65534 deny all from any to any
    




    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:

    Трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до правила с номером 10130 где попадет в нат. После прохождения ната трафик выйдет из фаервола и будет передан в интернет.

    Ответный трафик пройдет через цепочку правил прохода IN фаервола до правила 10130 где попав в нат будет демаскирован (в данном случае не существенно) и выйдет из фаервола попав в сокет программы инициировавшей соединение.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10130 будет отвергнут так как нат запущен с опцией deny_in.

    Для 192.168.1.80 и 5.6.7.8:

    Трафик приходящий из интернета на 5.6.7.8:80 пройдет через цепочку правил ipfw прохода IN до правила с номером 10130 где попадет в первый экземпляр ната и будет демаскирован на основании статического правила (внешний_IP <-> 5.6.7.8 будет заменено на внешний_IP <-> 192.168.1.80). После этого трафик попадет в проход OUT фаервола и дойдет до правила 1040 где попадет во второй экземпляр ната. Трафик будет маскирован (внешний_IP <-> 192.168.1.80 будет заменено на 192.168.1.254 <-> 192.168.1.80). После этого трафик выйдет из ната и будет передан на 192.168.1.80:80

    Цепочка преобразования адресов при проходе была следующей:

    отправитель:		получатель:
    внешний_IP		5.6.7.8
    внешний_IP		192.168.1.80
    192.168.1.254		192.168.1.80
    



    Ответный трафик уходящий от 192.168.1.80:80 будет передан на 192.168.1.254 где попав в фаервол пройдет до правила 1040. Попав во второй экземпояр ната трафик будет демаскирован (192.168.1.80 <-> 192.168.1.254 будет заменено на 192.168.1.80 <-> внешний_IP) и выйдя из прохода IN перейдет в проход OUT где пройдя через правила дойдет до 10130. Попав в первый экземпляр ната трафик будет повторно маскирован (192.168.1.80 <-> внешний_IP будет заменено на 5.6.7.8 <-> внешний_IP) после чего трафик уйдет в интернет.

    Цепочка преобразования адресов при проходе была следующей:

    отправитель:		получатель:
    192.168.1.80		192.168.1.254
    192.168.1.80		внешний_IP
    5.6.7.8			внешний_IP
    



    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10130 будет отвергнут так как нат запущен с опцией deny_in.

    Пример 4

    Есть два подключения к двум независимым провайдерам и две локальных сети. На рутере имеется четыре сетевых адаптера каждый из которых подключен к своему провайдеру или к своей локальной сети. Адаптеры em0 и em1 подключены к провайдерам ISP1 (IP 11.22.33.44) и ISP2 (IP 55.66.77.88). Адаптеры fxp0 и fxp1 подключены к локальным сетям LAN1 (IP 192.168.1.1) и LAN2 (IP 10.1.1.1). Ядро рутера собранно с поддержкой двух таблиц маршрутизации (options ROUTETABLES=2).

    Задача: обеспечить выход в интернет первой сети через первого провайдера, а второй сети через второго. Все это через нат и используя шейпер Dummynet обеспечить честное распределение пропускной способности между клиентами в локальных сетях.




    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em0="inet 11.22.33.44 netmask 255.255.255.0 -rxcsum"
    ifconfig_em1="inet 55.66.77.88 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    ifconfig_fxp1="inet 10.1.1.1 netmask 255.255.255.0"
    
    defaultrouter="11.22.33.254"
    
    setfib1_enable="YES"
    setfib1_defaultroute="55.66.77.254"
    
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=0
    




    /etc/firewall
    add 1040 setfib 0 ip from any to any in recv fxp0
    add 1050 setfib 1 ip from any to any in recv fxp1
    
    add 1060 allow ip from any to any via fxp0
    add 1070 allow ip from any to any via fxp1
    
    add 1080 deny ip from any to 192.168.0.0/16 in recv em0
    add 1081 deny ip from any to 192.168.0.0/16 in recv em1
    add 1090 deny ip from 192.168.0.0/16 to any in recv em0
    add 1091 deny ip from 192.168.0.0/16 to any in recv em1
    add 10100 deny ip from any to 172.16.0.0/12 in recv em0
    add 10101 deny ip from any to 172.16.0.0/12 in recv em1
    add 10110 deny ip from 172.16.0.0/12 to any in recv em0
    add 10111 deny ip from 172.16.0.0/12 to any in recv em1
    add 10120 deny ip from any to 10.0.0.0/8 in recv em0
    add 10121 deny ip from any to 10.0.0.0/8 in recv em1
    add 10130 deny ip from 10.0.0.0/8 to any in recv em0
    add 10131 deny ip from 10.0.0.0/8 to any in recv em1
    add 10140 deny ip from any to 169.254.0.0/16 in recv em0
    add 10141 deny ip from any to 169.254.0.0/16 in recv em1
    add 10150 deny ip from 169.254.0.0/16 to any in recv em0
    add 10151 deny ip from 169.254.0.0/16 to any in recv em1
    
    pipe 1 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 1 config pipe 1 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 2 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 2 config pipe 2 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 3 config bw 20Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 3 config pipe 3 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 4 config bw 35Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 4 config pipe 4 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    nat 1 config log if em0 same_ports reset deny_in
    nat 2 config log if em1 same_ports reset deny_in
    
    add 10160 queue 1 ip from any to any out xmit em0
    add 10170 nat 1 ip from any to any via em0
    add 10180 queue 2 ip from any to any in recv em0
    
    add 10190 queue 3 ip from any to any out xmit em1
    add 10200 nat 2 ip from any to any via em1
    add 10210 queue 4 ip from any to any in recv em1
    
    add 10220 allow all from any to any
    
    add 65534 deny all from any to any
    




    /usr/local/etc/rc.d/setfib1
    
    #!/bin/sh
    # PROVIDE: SETFIB1
    # REQUIRE: NETWORKING
    # BEFORE: DAEMON
    #
    # Add the following lines to /etc/rc.conf to enable setfib -1 at startup
    # setfib1 (bool): Set to "NO" by default.
    #                Set it to "YES" to enable setfib1
    # setfib1_defaultroute (str): Set to "" by default
    #       Set it to ip address of default gateway for use in fib 1
    
    . /etc/rc.subr
    
    name="setfib1"
    rcvar=`set_rcvar`
    
    load_rc_config $name
    
    [ -z "$setfib1_enable" ] && setfib1_enable="NO"
    [ -z "$setfib1_defaultroute" ] && setfib1_defaultroute=""
    
    start_cmd="${name}_start"
    stop_cmd="${name}_stop"
    
    setfib1_start()
    {
    if [ ${setfib1_defaultroute} ]
    then
    setfib 1 route delete default
    setfib 1 route add default ${setfib1_defaultroute}
    else
    echo "Can not set default route for fib 1!"
    fi
    }
    
    setfib1_stop()
    {
    setfib 1 route delete default
    }
    run_rc_command "$1"
    
    

    Напомининие.
    Скрипт setfib1 необходимо сделать исполняемым. Для этого после его создания надо выполнить:
    
    chmod 755 /usr/local/etc/rc.d/setfib1
    




    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:

    Трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до правила с номером 10160. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10170. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен их фаервола и уйдет во внешнюю сеть через 11.22.33.254..

    Ответный трафик пройдет через проход IN фаервола до правила 10170 где попадет в нат и будет демаскирован (в данном случае не сущесвенно) и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10180 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен и выйдет из фаервола направившись в сокет программы инициализировавшей соединение.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10170 будет отвергнут так как нат запущен с опцией deny_in.

    Для 192.168.1.0/24:

    Трафик исходящий из сети 192.168.1.0/24 (например от хоста с IP 192.168.1.24), зайдет через сетевой адаптер fxp0 в проход IN фаервола и дойдет до правила 1040 где ему будет назначенна таблица маршрутизации 0 (таблица по-умолчанию). Далее трафик пройдет до правила 1060 после чего выйдет из IN и будет разрешен. Трафик зайдет в проход OUT где пройдет по правилам до 10160. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10170. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен их фаервола и уйдет во внешнюю сеть через 11.22.33.254.

    Ответный трафик пройдет через проход IN фаервола до правила 10170 где попадет в нат, будет демаскирован и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10180 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен, и выйдет из прохода IN фаервола. Трафик попадет в проход OUT фаервола где дойдет до правила 1060, после чего выйдет из IN и будет передан в сеть 192.168.1.0/24 через адаптер fxp0.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10170 будет отвергнут так как нат запущен с опцией deny_in.

    Для 10.1.1.0/24:

    Трафик исходящий из сети 10.1.1.0/24 (например от хоста с IP 10.1.1.24), зайдет через сетевой адаптер fxp1 в проход IN фаервола и дойдет до правила 1050 где ему будет назначенна таблица маршрутизации 1 (вторая таблица имеющая default gateway 55.66.77.254). Теперь для трафика в качестве сетевого адаптера через который он должен быть передан наружу, будет установлено em1. Далее трафик пройдет до правила 1070 после чего выйдет из IN и будет разрешен. Трафик зайдет в проход OUT где пройдет по правилам до 10190. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 20Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10200. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен из фаервола и уйдет во внешнюю сеть через 55.66.77.254.

    Ответный трафик пройдет через проход IN фаервола до правила 10200 где попадет в нат, будет демаскирован и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10210 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 35Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен, и выйдет из прохода IN фаервола. Трафик попадет в проход OUT фаервола где дойдет до правила 1070, после чего выйдет из IN и будет передан в сеть 10.1.1.0/24 через адаптер fxp1.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10200 будет отвергнут так как нат запущен с опцией deny_in.





    Пример 5

    Есть два подключения к двум независимым провайдерам и одна локальная сеть. На рутере имеется три сетевых адаптера два из которых подключены провайдерам, а третий к своей локальной сети. Адаптеры em0 и em1 подключены к провайдерам ISP1 (IP 11.22.33.44) и ISP2 (IP 55.66.77.88). Адаптер fxp0 подключен к локальной сети LAN1 (IP 192.168.1.1). Ядро рутера собранно с поддержкой двух таблиц маршрутизации (options ROUTETABLES=2).

    Задача: обеспечить выход в интернет локальной сети через обоих провайдеров используя балансировку трафика между подключениями. Все это через нат и используя шейпер Dummynet обеспечить честное распределение пропускной способности между клиентами в локальной сети.




    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em0="inet 11.22.33.44 netmask 255.255.255.0 -rxcsum"
    ifconfig_em1="inet 55.66.77.88 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    
    defaultrouter="11.22.33.254"
    
    setfib1_enable="YES"
    setfib1_defaultroute="55.66.77.254"
    
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=0
    




    /etc/firewall
    add 1010 prob 0.5 skipto 1060 ip from any to any in recv fxp0
    
    add 1040 setfib 0 ip from any to any in recv fxp0 keep-state
    add 1050 allow ip from any to any via fxp0
    
    add 1060 setfib 1 ip from any to any in recv fxp0 keep-state
    add 1070 allow ip from any to any via fxp0
    
    add 1080 deny ip from any to 192.168.0.0/16 in recv em0
    add 1081 deny ip from any to 192.168.0.0/16 in recv em1
    add 1090 deny ip from 192.168.0.0/16 to any in recv em0
    add 1091 deny ip from 192.168.0.0/16 to any in recv em1
    add 10100 deny ip from any to 172.16.0.0/12 in recv em0
    add 10101 deny ip from any to 172.16.0.0/12 in recv em1
    add 10110 deny ip from 172.16.0.0/12 to any in recv em0
    add 10111 deny ip from 172.16.0.0/12 to any in recv em1
    add 10120 deny ip from any to 10.0.0.0/8 in recv em0
    add 10121 deny ip from any to 10.0.0.0/8 in recv em1
    add 10130 deny ip from 10.0.0.0/8 to any in recv em0
    add 10131 deny ip from 10.0.0.0/8 to any in recv em1
    add 10140 deny ip from any to 169.254.0.0/16 in recv em0
    add 10141 deny ip from any to 169.254.0.0/16 in recv em1
    add 10150 deny ip from 169.254.0.0/16 to any in recv em0
    add 10151 deny ip from 169.254.0.0/16 to any in recv em1
    
    pipe 1 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 1 config pipe 1 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 2 config bw 10Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 2 config pipe 2 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 3 config bw 20Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 3 config pipe 3 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 4 config bw 35Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 4 config pipe 4 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    nat 1 config log if em0 same_ports reset deny_in \
    redirect_port tcp 192.168.1.5:25 25
    nat 2 config log if em1 same_ports reset deny_in
    
    add 10160 queue 1 ip from any to any out xmit em0
    add 10170 nat 1 ip from any to any via em0
    add 10180 queue 2 ip from any to any in recv em0
    
    add 10190 queue 3 ip from any to any out xmit em1
    add 10200 nat 2 ip from any to any via em1
    add 10210 queue 4 ip from any to any in recv em1
    
    add 10220 allow all from any to any
    
    add 65534 deny all from any to any
    




    /usr/local/etc/rc.d/setfib1
    
    #!/bin/sh
    # PROVIDE: SETFIB1
    # REQUIRE: NETWORKING
    # BEFORE: DAEMON
    #
    # Add the following lines to /etc/rc.conf to enable setfib -1 at startup
    # setfib1 (bool): Set to "NO" by default.
    #                Set it to "YES" to enable setfib1
    # setfib1_defaultroute (str): Set to "" by default
    #       Set it to ip address of default gateway for use in fib 1
    
    . /etc/rc.subr
    
    name="setfib1"
    rcvar=`set_rcvar`
    
    load_rc_config $name
    
    [ -z "$setfib1_enable" ] && setfib1_enable="NO"
    [ -z "$setfib1_defaultroute" ] && setfib1_defaultroute=""
    
    start_cmd="${name}_start"
    stop_cmd="${name}_stop"
    
    setfib1_start()
    {
    if [ ${setfib1_defaultroute} ]
    then
    setfib 1 route delete default
    setfib 1 route add default ${setfib1_defaultroute}
    else
    echo "Can not set default route for fib 1!"
    fi
    }
    
    setfib1_stop()
    {
    setfib 1 route delete default
    }
    run_rc_command "$1"
    

    Напомининие.
    Скрипт setfib1 необходимо сделать исполняемым. Для этого после его создания надо выполнить:
    
    chmod 755 /usr/local/etc/rc.d/setfib1
    




    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:

    Трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до правила с номером 10160. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10170. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен их фаервола и уйдет во внешнюю сеть через 11.22.33.254..

    Ответный трафик пройдет через проход IN фаервола до правила 10170 где попадет в нат и будет демаскирован (в данном случае не сущесвенно) и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10180 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен и выйдет из фаервола направившись в сокет программы инициализировавшей соединение.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10170 будет отвергнут так как нат запущен с опцией deny_in.

    Для 192.168.1.0/24:

    Трафик исходящий из сети 192.168.1.0/24 (например от хоста с IP 192.168.1.24), зайдет через сетевой адаптер fxp0 в проход IN фаервола и дойдет до правила 1010 на котором с вероятностью 1/2 будет либо произведен переход на правило 1060, либо переход к следующему по списку правилу 1040. Правила 1040 и 1060 имеют директиву keep-state (это динамические правила). Допустим, что 192.168.1.24 инициировал две сессии - первую на адрес IP 3.3.3.3:80, а вторую на адрес IP 9.9.9.9:22.

    Допустим, что первая сессия на правиле 1010 не была обработана. В таком случае трафик адресованный на IP 3.3.3.3 пройдет до правила 1040 где ему будет назначена таблица маршрутизации по-умолчанию, а кроме того в таблицу динамических правил будет занесена информация о сессии 192.168.1.24:12345 <-> 3.3.3.3:80 и о действии родительского правила (setfib 0) которое надо применять к трафику в рамках сессии. Далее, дойдя до правила 1050 трафик будет принят, выйдет из прохода IN и будет разрешен.

    Допустим, что вторая сессия на правиле 1010 была обработана. В таком случае трафик адресованный на IP 9.9.9.9 пройдет до правила 1060 где ему будет назначена вторая таблица маршрутизации, а кроме того в таблицу динамических правил будет занесена информация о сессии 192.168.1.24:56789 <-> 9.9.9.9:22 и о действии родительского правила (setfib 1) которое надо применять к трафику в рамках сессии. Далее, дойдя до правила 1070 трафик будет принят, выйдет из прохода IN и будет разрешен.

    Трафик первой сессии зайдет в проход OUT где пройдет по правилам до 10160. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10170. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен их фаервола и уйдет во внешнюю сеть через 11.22.33.254.

    Трафик второй сессии зайдет в проход OUT где пройдет по правилам до 10190. Трафик попадет в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость выходящего трафика будет ограничена в 20Mbit/s. После выхода из Dummynet трафик вернется в фаервол (так как выключен параметр one_pass) и попадет в правило 10200. После прохождения ната трафик сново вернется в фаервол и дойдя до правила 10220 будет выведен их фаервола и уйдет во внешнюю сеть через 55.66.77.254.

    Ответный трафик в рамках первой сессии пройдет через проход IN фаервола до правила 10170 где попадет в нат, будет демаскирован и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10180 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 10Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен, и выйдет из прохода IN фаервола. Трафик попадет в проход OUT фаервола и дойдет до правила 1040 - там он будет обработан на неявном check-state где к нему будет применено действие родительского правила (setfib 0). Далее трафик перейдет на правило 1050 после чего выйдет из IN и будет передан в сеть 192.168.1.0/24 через адаптер fxp0.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10170 будет отвергнут так как нат запущен с опцией deny_in.

    Ответный трафик в рамках второй сессии пройдет через проход IN фаервола до правила 10200 где попадет в нат, будет демаскирован и принят так как в нате уже есть активное соединение. Выйдя из ната трафик попадет в правило 10210 и будет передан в Dummynet - зайдет в динамически созданную очередь и трубу в результате чего скорость входящего трафика будет ограничена в 35Mbit/s. После выхода из Dummynet трафик вернется в фаервол и попадет в правило 10220 где будет разрешен, и выйдет из прохода IN фаервола. Трафик попадет в проход OUT фаервола и дойдет до правила 1040 - там он будет обработан на неявном check-state где к нему будет применено действие родительского правила (setfib 1). Далее трафик перейдет на правило 1070 после чего выйдет из IN и будет передан в сеть 192.168.1.0/24 через адаптер fxp0.

    Если на рутер из интернета придет случайный трафик, то он пройдя через правило 10200 будет отвергнут так как нат запущен с опцией deny_in.

    Если при следующем обмене трафиком в рамках первой сессии (192.168.1.24:12345 <-> 3.3.3.3:80) исходящий от 192.168.1.24 трафик на правиле 1010 будет передан не на 1040, а на 1060 то сессия не поломается так как при попадании на 1060 к трафику сессии на неявном check-state будет применено действие его родительского правила (setfib 0).

    Если при следующем обмене трафиком в рамках второй сессии (192.168.1.24:56789 <-> 9.9.9.9:22) исходящий от 192.168.1.24 трафик на правиле 1010 будет передан не на 1060, а на 1040 то сессия не поломается так как при попадании на 1040 к трафику сессии на неявном check-state будет применено действие его родительского правила (setfib 1).

    Замечания:
    Пример абсолютно не учитавает распределение DNS/UDP трафика между провайдерами. Я предрологаю, что на самом нат-рутере запущен локальный DNS-кеш сервер (Unbound, BIND, etc...) - в таком случае клиенты запрашивают разрешение имен у него, а он сам выходит в интернет только по одному каналу... Иначе DNS запросы к серверам одного провайдера могут уходить через сеть другого провайдера и не разрешаться.

    Подобная "балансировка" трафика не учитывает такие факторы как выход из строя одного из провайдеров. Если есть необходимость обрабатывать еще и это, то надо делать систему мониторинга (пинговалку?) обоих провайдеров, и в случае выпадения одного из них, перестраевать правила фаервола на задействование только одного канала как в примере 1. Подобное поведение можно удобно реализовать используя функцию наборов правил (set) ipfw.

    Так как таблица динамических правил не хранит их у себя вечно ;) то при неактивности сессии в течение какого-то времени, и после ее возобновления позже, эта сессиия может получить другую fib и уйти к получателю с другого IP. Если возникнут проблемы такого плана с какими-нибудь конкретными IP адресами (например с однокамерника... то есть с одноклассниками), то для этих конкретных IP можно создать отдельную таблицу и повесить ее обработку на отдельное правило жестко назначающее таким IP одну единственную таблицу маршрутизации.

    В данном примере "пробрасывать порты" можно только с того внешнего IP адреса который имеет default route в таблице маршрутизации по-умолчанию (fib 0). В данном случае это сетевой адаптер em0 с IP 11.22.33.44 - в экземпляре его ната выставлен проброс соединений приходящих на 25 порт на внутреннюю машину 192.168.1.5. Чтобы иметь возможность делать это с обеих внешних IP адресов, надо добавить в пример еще и такие правила:
    
    add 1011 skipto 1040 ip from any to any out xmit fxp0 tagged 1
    add 1012 skipto 1060 ip from any to any out xmit fxp0 tagged 2
    add 10171 skipto 10180 tag 1 ip from any to any in recv em0
    add 10201 skipto 10210 tag 2 ip from any to any in recv em1
    

    Пример 6

    Конфигурация практически полностью повторяет Пример 1: рутер с двумя сетевыми адаптерами подключенными в локальную сеть и в интернет. Адрес в локальной сети 192.168.1.1 (сетевой адаптер fxp0), адрес в интернете 1.2.3.4 (сетевой адаптер em0).

    Задача: "раздавать интернет" для локальной сети, обеспечить проброс портов для внутренних адресов, разрешить прохождение трафика на отдельные порты самого рутера, а главное - ввести жесткий лимит на количество одновременных исходящих TCP соединений для всего трафика уходящего в интернет (максимум 20 одновременных соединений с каждого внутреннего IP адреса).




    Конфигурация:

    /etc/rc.conf
    
    gateway_enable="YES"
    ifconfig_em0="inet 1.2.3.4 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    defaultrouter="1.2.3.254"
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=1
    



    /etc/firewall
    add 1040 allow ip from any to any via fxp0
    
    add 1050 deny ip from any to 192.168.0.0/16 in recv em0
    add 1060 deny ip from 192.168.0.0/16 to any in recv em0
    add 1070 deny ip from any to 172.16.0.0/12 in recv em0
    add 1080 deny ip from 172.16.0.0/12 to any in recv em0
    add 1090 deny ip from any to 10.0.0.0/8 in recv em0
    add 10100 deny ip from 10.0.0.0/8 to any in recv em0
    add 10110 deny ip from any to 169.254.0.0/16 in recv em0
    add 10120 deny ip from 169.254.0.0/16 to any in recv em0
    
    nat 1 config log if em0 reset same_ports deny_in \
    redirect_port tcp 1.2.3.4:6881 6881 \
    redirect_port udp 1.2.3.4:4444 4444 \
    redirect_port tcp 192.168.1.24:25 25
    
    add 10130 nat 1 tcp from any to any out xmit em0 limit src-addr 20
    add 10140 nat 1 ip from any to any out xmit em0
    
    add 10150 nat 1 ip from any to any in recv em0
    
    add 65534 deny all from any to any
    



    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:
    Исходящий TCP трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до правила с номером 10130. В следствии наличия директивы limit, трафик попадет в функцию обработки динамических (keep-state) правил - на неявный обработчик check-state. Будет проверено: нет ли соответсвия с какой-либо ранее инициализированной сессией (это окончется неудачей так как в таблице динамических правил, конечно же, не будет никаких совпадений). После неудачной проверки на активную сессию обработка вернется на тело правила 10130 где будет установлено, что пакет подпадает под критерий отбора (tcp from any to any out xmit em0). После этого в таблицу динамических правил будет помещена первая запись соответствия локальный_IP:порт <-> удаленный_IP:порт (по правилам в таблице может быть максимум 20 записей с одинаковым значением "локальный_IP") имеющая таймер устанавливающий время ее жизни. После этого трафик выйдет из функции обработки динамических правил и будет передан на поле действия правила 10130 - трафик будет перенаправлен в нат. Выйдя из ната трафик будет передан в интернет так как значение параметра one_pass=1.

    Для каждого из последующих 19 TCP соединений инициализированных от рутера обработка будет такой же. Когда таблица динамических правил заполниться, то следующие TCP соединения будут молча отвергаться до тех пор пока в динамической таблице активных соединений не освободиться место.

    Любой IP (UDP, ICMP, etc) трафик инициализированный непосредственно от рутера пройдет через цепочку правил ipfw прохода OUT до 10140 где попадет в нат и выйдя из него будет отправлен в интернет. Лимиты на данный трафик не распространяются.


    Ответный TCP трафик пройдет через проход IN фаервола до правила 10130. Не смотря на то, что тело правила (tcp from any to any out xmit em0) не имеет совпадения с параметрами трафика, из-за присутвия директивы limit трафик попадет в функцию обработки динамических (keep-state) правил - на неявный обработчик check-state. Будет проверено: нет ли соответсвия с какой-либо из ранее инициализированных сессий, и такое совпадение будет обнаружено. В следствии этого таймер устанавливающий время жизни динамической записи будет сброшен. После этого трафик выйдет из функции обработки динамических правил и будет передан на поле действия правила 10130 - трафик будет перенаправлен в нат. Выйдя из ната трафик будет передан в сокет процесса создавшего соединение.

    Любой ответный IP (UDP, ICMP, etc) трафик пройдет через проход IN фаервола до правила 10150 где попадет в нат. Выйдя из ната трафик будет передан в локальную систему.

    Трафик приходящий на порты 6881, 4444 и 25 пройдет до правила 10150 и будет принят.

    Любой случайный трафик пришедший из интернета (как TCP так и IP) пройдет до правила 10150 и будет отброшен так как нат запущен с директивой deny_in


    Для 192.168.1.0/24:

    Исходящий TCP трафик инициализированный от хостов из сети 192.168.1.0/24 (например от 192.168.1.56) пройдет через цепочку правил ipfw прохода IN до правила 1040 после чего выйдет из фаервола и будет передан в проход OUT. Зайдя в OUT трафик дойдет до правила с номером 10130. В следствии наличия директивы limit, трафик попадет в функцию обработки динамических (keep-state) правил - на неявный обработчик check-state. Будет проверено: нет ли соответсвия с какой-либо ранее инициализированной сессией (это окончется неудачей так как в таблице динамических правил, конечно же, не будет никаких совпадений). После неудачной проверки на активную сессию обработка вернется на тело правила 10130 где будет установлено, что пакет подпадает под критерий отбора (tcp from any to any out xmit em0). После этого в таблицу динамических правил будет помещена первая запись соответствия 192.168.1.56:порт <-> удаленный_IP:порт (по правилам в таблице может быть максимум 20 записей с одинаковым значением 192.168.1.56) имеющая таймер устанавливающий время ее жизни. После этого трафик выйдет из функции обработки динамических правил и будет передан на поле действия правила 10130 - трафик будет перенаправлен в нат. Выйдя из ната трафик будет передан в интернет так как значение параметра one_pass=1.

    Для каждого из последующих 19 TCP соединений инициализированный от 192.168.1.56 обработка будет такой же. Когда таблица динамических правил заполниться, то следующие TCP соединения будут молча отвергаться до тех пор пока в динамической таблице активных соединений не освободиться место.

    Любой IP (UDP, ICMP, etc) трафик инициализированный непосредственно от 192.168.1.56 пройдет через цепочку правил ipfw прохода IN до 1040, а затем в проходе OUT до 10140 где попадет в нат и выйдя из него будет отправлен в интернет. Лимиты на данный трафик не распространяются.


    Ответный TCP трафик пройдет через проход IN фаервола до правила 10130. Не смотря на то, что тело правила (tcp from any to any out xmit em0) не имеет совпадения с параметрами трафика, из-за присутвия директивы limit трафик попадет в функцию обработки динамических (keep-state) правил - на неявный обработчик check-state. Будет проверено: нет ли соответсвия с какой-либо из ранее инициализированных сессий, но такое совпадение не будет обнаружено так как пришедший из интернета трафик еще не прошел деалиасинг в нате. В следствии этого таймер устанавливающий время жизни динамической записи не будет сброшен. Трафик пройдет до правила 10150 на котором будет перенаправлен в нат. Выйдя из ната трафик покинет проход IN (так как one_pass=1) и перейдет в проход OUT где на правиле 1040 будет разрешен и уйдет в сеть 192.168.1.0/24.

    Любой ответный IP (UDP, ICMP, etc) трафик пройдет через проход IN фаервола до правила 10150 где попадет в нат. Выйдя из ната трафик будет передан в проход OUT (так как one_pass=1), где на правиле 1040 будет разрешен и уйдет в сеть 192.168.1.0/24.

    Любой случайный трафик пришедший из интернета (как TCP так и IP) пройдет до правила 10150 и будет отброшен так как нат запущен с директивой deny_in

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


    Пример 7



    Подключение к провайдеру имеет выделенный диапазон IP адресов - для использования доступно пять адресов. На рутере установлено два сетевых адаптера. Адаптер em0 подключен к провайдеру и имеет IP адреса в диапазоне от 11.22.33.[1-5]. Адаптер fxp0 подключен к локальной сети (IP 192.168.1.1).

    Задача: обеспечить выход в интернет локальной сети задействуя все имеющиеся внешние адреса (использовать пул адресов). Все это через нат и используя шейпер Dummynet обеспечить честное распределение пропускной способности между клиентами в локальной сети.



    /etc/rc.conf
    
    gateway_enable="YES"
    
    ifconfig_em0="inet 11.22.33.1 netmask 255.255.255.0 -rxcsum"
    ifconfig_em0_alias0="inet 11.22.33.2 netmask 255.255.255.255"
    ifconfig_em0_alias1="inet 11.22.33.3 netmask 255.255.255.255"
    ifconfig_em0_alias2="inet 11.22.33.4 netmask 255.255.255.255"
    ifconfig_em0_alias3="inet 11.22.33.5 netmask 255.255.255.255"
    
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    
    defaultrouter="11.22.33.6"
    
    firewall_enable="YES"
    firewall_type="/etc/firewall"
    



    /etc/sysctl.conf
    
    net.inet.ip.fw.one_pass=0
    




    /etc/firewall
    
    add 1011 prob 0.2 skipto 1061 ip from any to any in recv fxp0
    add 1012 prob 0.25 skipto 1063 ip from any to any in recv fxp0
    add 1013 prob 0.333 skipto 1065 ip from any to any in recv fxp0
    add 1014 prob 0.5 skipto 1067 ip from any to any in recv fxp0
    add 1015 prob 1 skipto 1069 ip from any to any in recv fxp0
    
    add 1061 skipto 1070 tag 1 ip from any to any via fxp0 keep-state
    add 1063 skipto 1070 tag 2 ip from any to any via fxp0 keep-state
    add 1065 skipto 1070 tag 3 ip from any to any via fxp0 keep-state
    add 1067 skipto 1070 tag 4 ip from any to any via fxp0 keep-state
    add 1069 skipto 1070 tag 5 ip from any to any via fxp0 keep-state
    
    add 1070 allow ip from any to any via fxp0
    
    add 1080 deny ip from any to 192.168.0.0/16 in recv em0
    add 1090 deny ip from 192.168.0.0/16 to any in recv em0
    add 2000 deny ip from any to 172.16.0.0/12 in recv em0
    add 2010 deny ip from 172.16.0.0/12 to any in recv em0
    add 2020 deny ip from any to 10.0.0.0/8 in recv em0
    add 2030 deny ip from 10.0.0.0/8 to any in recv em0
    add 2040 deny ip from any to 169.254.0.0/16 in recv em0
    add 2050 deny ip from 169.254.0.0/16 to any in recv em0
    
    
    pipe 1 config bw 20Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 1 config pipe 1 queue 60 mask src-ip 0xffffffff gred 0.002/10/30/0.1
    
    pipe 2 config bw 35Mbit/s queue 60 gred 0.002/10/30/0.1
    queue 2 config pipe 2 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
    
    
    nat 1 config log ip 11.22.33.1 same_ports reset deny_in \
    redirect_port tcp wsrv:80 80
    nat 2 config log ip 11.22.33.2 same_ports reset deny_in
    nat 3 config log ip 11.22.33.3 same_ports reset deny_in
    nat 4 config log ip 11.22.33.4 same_ports reset deny_in
    nat 5 config log ip 11.22.33.5 same_ports reset deny_in
    
    
    add 10000 queue 1 ip from any to any out xmit em0
    
    add 10190 skipto 10601 tag 1 ip from me to any out xmit em0
    
    add 10201 nat 2 ip from any to any out xmit em0 tagged 2
    add 10202 nat 2 ip from any to 11.22.33.2 in recv em0
    
    add 10301 nat 3 ip from any to any out xmit em0 tagged 3
    add 10302 nat 3 ip from any to 11.22.33.3 in recv em0
    
    add 10401 nat 4 ip from any to any out xmit em0 tagged 4
    add 10402 nat 4 ip from any to 11.22.33.4 in recv em0
    
    add 10501 nat 5 ip from any to any out xmit em0 tagged 5
    add 10502 nat 5 ip from any to 11.22.33.5 in recv em0
    
    add 10601 nat 1 ip from any to any out xmit em0 tagged 1
    add 10602 nat 1 ip from any to 11.22.33.1 in recv em0
    
    
    add 20000 queue 2 ip from any to any in recv em0
    
    
    add 20220 allow all from any to any
    
    
    add 65534 deny all from any to any
    




    Детальное описание прохождения трафика через фаервол в данной конфигурации:

    Для рутера:
    Трафик инициированный непосредственно от рутера пройдет через цепочку правил до правила номер 10000. На правиле с номером 10000 трафик будет передан в dummynet - скорость выходящего потока будет ограничена в 20Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до 10190 где ему будет присвоен тег 1. После этого трафик перепрыгнет на 10601. На правиле 10601 произойдет совпадение с уточняющим параметром tagged 1, и трафик будет передан в нат. Выйдя из ната трафик продолжит движение по правилам, и дойдя до правила 20220 выйдет из фаервола и уйдет во внешнюю сеть через интерфейс em0.

    Ответный трафик принимаемый из внешней сети через интерфейс em0, пройдет по цепочке правил до правила 10602 на котором будет передан в нат. Выйдя из ната трафик продолжит движение по правилам до правила с номером
    20000 на котром он будет передан в dummynet - скорость входящего потока будет ограничена в 35Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до правила 20220, после чего выйдет из фаервола и будет принят рутером.

    Если на рутер из внешней сети, на адрес 11.22.33.1 придет случайный трафик, то он будет отвергнут так как нат запущен с опцией deny_in.

    Если на рутер из внешней сети, на адрес 11.22.33.1 придет трафик адресованный для tcp порта 11.22.33.1:80, то он будет принят так как в настройках ната указанна опция форвардинга redirect_port. Адрес назначения будет заменен IP адресом машины с именем wsrv. Трафик пройдет до правила с номером 10602 где попадет в нат. Далее трафик зайдет в правило 20000 на котром он будет передан в dummynet - скорость входящего потока будет ограничена в 35Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до правила 20220, после чего выйдет из прохода IN фаервола и перейдет в проход OUT. В проходе OUT трафик пройдет по правилам до 1061 где попадет на неявный check-state. Так как в таблице динамических правил нет соединения для пар адресов внешнего и внутреннего адреса из IP заголовка, и трафик подпадает под действие правила from any to any via fxp0 то, следовательно, запись в таблице динамических правил будет создана, к трафику будет применен параметр действия родительского правила (tag 1), а так же применено действие родительского правила (skipto 1070). Перейдя на правило 1070 трафик выйдет из фаервола и будет передан через интерфейс fxp0 во внутреннюю сеть.

    Ответный трафик от машины с именем wsrv пройдет через любое из правил 1011-1015 с параметром prob и попадет на любое из правил 1061-1069 с параметром keep-state, в результате чего на вызове неявного check-state будет установлено, что в таблице динамических правил уже есть запись с соответсвующими параметрами для ранее установленной сессии. Трафик будет переброшен на правило впервые породившее сессию - это было правило 1061. К трафику будет применен параметр действия родительского правила (tag 1), а так же применено действие родительского правила (skipto 1070). Попав на правило 1070 трафик будет принят и выйдет из прохода IN фаервола.

    Трафик зайдет в проход OUT где на правиле с номером 1061 сново попадет на неявный check-state. Так как в таблице есть данные о сессии, то трафик будет переброшен на правило впервые породившее сессию - это было правило 1061. К трафику будет применен параметр действия родительского правила (tag 1), а так же применено действие родительского правила (skipto 1070). Так как на проходе OUT правило 1070 совпадения не даст то трафик пройдет по фаерволу далее до правила с номером 10000 на котором он будет передан в dummynet - скорость выходящего потока будет ограничена в 20Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до 10601. Так как трафик имеет присвоенный ему ранее тег равный 1, то он будет обработан на последнем экземпляре ната у которого установлен уточняющий параметр tagged 1. Выйдя из ната трафик продолжит движение по правилам, и дойдя до правила 20220 выйдет из фаервола и уйдет во внешнюю сеть через интерфейс em0.

    Для 192.168.1.0/24:
    Допостим, что хост 192.168.1.83 инициировал две сессии. Обе сессии будут приняты рутером и на проходе IN пройдут через секцию правил с номерами 1011-1015. Эти правила имеют параметр определяющий вероятность их срабатывания. Каждое из правил делит проходящий через него поток по вероятности обработки на части. В итоге рассматривая поток из 100 случайных пакетов получим, что каждый пакет так или иначе будет обработан на каком-либо из правил, а в итоге все 100 пакетов в среднем будут поделены на пять равновероятных групп по 20 пакетов в каждой.

    Допустим, что первая сессия была обработана на правиле 1012. При этом произойдет переход на правило 1063 на котором сработает неявный check-state - будет установлено, что в таблице динамических правил еще нет записи для параметров первой сессии, в результате чего при вызове keep-state такая запись будет создана, к трафику будет применен параметр действия (tag 2) и само действие правила (skipto 1070). После перехода на правило 1070 трафик будет разрешен и выйдет из прохода IN перейдя в проход OUT фаервола. На проходе OUT трафик дойдет до первого правила с keep-state где на неявном check-state будет обработан - так как в таблице динамических правил уже есть ранее созданная запись с параметрами сессии, то к трафику будет применен параметр действия (tag 2) и само действие родительского правила (skipto 1070). После перехода на правило 1070 трафик продолжет движение до правила 10000. На правиле с номером 10000 трафик будет передан в dummynet - скорость выходящего потока будет ограничена в 20Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до 10201. Так как трафик имеет присвоенный ему ранее тег равный 2, то произойдет совпадение с уточняющим параметром tagged 2 и трафик будет передан в экземпляр ната с номером 2. Выйдя из ната трафик продолжит движение по правилам, и дойдя до правила 20220 выйдет из фаервола и уйдет во внешнюю сеть через интерфейс em0.

    Ответный трафик полученный из внешней сети через интерфейс em0 на проходе IN пройдет до праила 10202 на котором будет передан в нат. Выйдя из ната трафик продолжит движение по правилам до правила с номером 20000 на котром он будет передан в dummynet - скорость входящего потока будет ограничена в 35Mbit/s. После выхода из шейпера, трафик пройдет по цепочке правил до правила 20220, после чего выйдет из прохода IN и перейдет в проход OUT фаервола. В проходе OUT трафик дойдет до правила 1061 где на неявном check-state будет определено, что в таблице динамических правил есть совпадение с параметрами сессии в результате чего трафик перескочет на свое родительское правило 1063 где к нему будет применен параметр действия (tag 2) и само действие правила (skipto 1070). После перехода на правило 1070 трафик будет разрешен, выйдет из прохода OUT фаервола и будет передан во внутреннюю сеть на хост 192.168.1.83.

    Ответный трафик в рамках сессии проходя через check-state всегда будет попадать на родительское правило 1063 где к нему будет применен параметр действия (tag 2) и само действие правила (skipto 1070). Таким образом, до тех пор пока в таблице динамических правил есть информация о сессии, проходящий трафик конкретной сессии всегда будет помечаться своим тегом, а позже направляться в свой экземпляр ната.

    Аналогичное поведение будет для трафика второй сессии, но, если допустить, что на секции правил с номерами 1011-1015 эта сессия была обработана правилом 1015, то тогда вся цепочка преобразований будет давать присвоение трафику тега с номером 5 и последующую обработку его на пятом экземпляре ната.

    Если на рутер из внешней сети, на адреса 11.22.33.[1-5] придет случайный трафик, то он будет отвергнут так как все экземпляры натов запущены с опцией deny_in.



    Дополнительная информация.

    Модули протоколов:

    Для ipfw nat есть возможность запускать модули помогающие улучшать работу через нат различных протоколов прикладного уровня. На момент написания заметки в FreeBSD 7.2-STABLE были достуаны следующие модули:

    alias_cuseeme.ko
    alias_ftp.ko
    alias_irc.ko
    alias_nbt.ko
    alias_pptp.ko
    alias_skinny.ko
    alias_smedia.ko
    

    Так, например, после запуска модуля alias_ftp.ko (или вручную через kldload alias_ftp.ko или через /boot/loader.conf alias_ftp_load="YES") поведение ipfw nat изменяется к лучшему - он начнет пропускать через себя активные FTP сессии инициализированные от клиентов находящихся за ним. Модуль alias_ftp отслеживат FTP трафик проходящий через нат и динамически изменяет внутреннюю таблицу ната для установления соответствия номеров портов используемых в сессии. Аналогично и для прочих модулей.
    Файл /etc/libalias.conf не влияет на работу ipfw nat. Этот конфигурационный файл используется только "user space" программами такими как natd.


    Мониторинг:

    Время процессора потребляемое ipfw и Dummynet:
    top -SH -n 500 | grep swi1
    
    PID USERNAME   PRI NICE   SIZE    RES STATE    TIME   WCPU  COMMAND
    14  root       -44 -      0K      8K  WAIT     0:00   0.00% swi1: net
    
    
    top -SH -n 500 | grep dummynet
    
    PID USERNAME   PRI NICE   SIZE    RES STATE    TIME   WCPU  COMMAND
    44  root       -68 -      0K      8K  -        1:14   0.00% dummynet
    



    Размер памяти съедаемый ipfw nat:
    vmstat -m | grep libalias
    
    Type 		InUse MemUse HighUse Requests  Size(s)
    libalias	19    35K       -    580       128
    




    Тюнинг:

    Так как ipfw nat работает в ядре, то память для своей работы он потребляет из диапазона доступного для аллокации ядру. Объем памяти ядра устанавливается через переменную sysctl vm.kmem_size. На момент написания заметки для FreeBSD 7.2-STABLE i386 это значение по-умолчанию было:
    sysctl -a | grep vm.kmem_size
    vm.kmem_size: 335544320
    vm.kmem_size_min: 0
    vm.kmem_size_max: 335544320
    vm.kmem_size_scale: 3
    

    Что есть 335544320 байт = 320 Мб.

    Потолок для i386 - 2Гб. Чтобы выставить его, необходимо пересобрать ядро с опцией options KVA_PAGES=512.

    Для архитектуры AMD64 этот параметр может быть выставлен вплоть до 6 Гб и для этого нет необходимости в пересборке ядра - достаточно установить соответсвующие sysctl значения через /boot/loader.conf.


    Описание известных проблем:

    Чем лучше какая-либо штука, тем она сложнее, а в сложных вещах бывают и свои проблемы :) Механизм ipfw nat тоже не идеален. Далее я просто перечислю некоторые его косячки и возможные решения.

    - При больших нагрузках (когда через нат создается очень много соединений) внутренняя таблица ната может разростись до очень больших размеров и исчерпать всю доступную память ядра. Такая проблема встречалась в первых релизах версии FreeBSD 7, и насколько мне известно ее решением занимались путем оптимизации механизма создания/удаления записей в таблице - патчили его чтобы он более агрессивно следил за используемой памятью. Насколько проблема актуальна сейчас я проверить не могу так как не обладаю каналом с трафиком в сотни мегабайт/сек и тысячами юзеров.
    В качестве меры профилактики можно удалять экземпляр старого ната, а потом создавать новый. Удаление делается через:
    ipfw nat delete 1
    



    - Нет возможности получить дамп внутренне таблицы ната. При включении параметра конфигурации log накапливается довольно скудная статистика которую можно просмотреть с помощью команды:
    # ipfw nat 1 show
    nat 1: icmp=0, udp=6, tcp=3, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=9
    



    - Библиотека libalias, на которой основан ipfw nat, плохо дружит с функциями аппаратного ускорения расчета контрольных сумм и управления потоками, которые доступны на некотроых сетевых адаптерах. Рекомендуется выключать tcp segmentation offloading (TSO), а так же rxcsum на том сетевом адаптере где работает нат (ifconfig em0 -rxcsum -tso).


    - Тайной осталось то, каким образом применять директиву proxy_only. В natd кроме нее есть так же и деректива proxy_rule с помощью которой можно настраевать правила. Здесь же ее почему-то нет (недопилили?) и как завести правила проксирования - непонятно. В natd правила проксирования позволяют организовать что-то вроде ipfw fwd - пакеты адресованные на определенный порт можно модифицировать заменив в них IP адрес и порт назначения на произвольные. Без этого правила мы можем менять в пакете только адрес отправителя на тот что указан в директиве IP, или только адрес получателя на один конкретный при использовании redirect_port или redirect_addr. Функциональность proxy_rule позволила бы менять адрес получателя без привязки к конкретному IP указанному в настройках экземпляра ната. Такое нельзя сделать через связку revers+redirect_port. Например для пересылки всего исходящего http трафика на сервер srv1 порт 81, можно было бы применить правило: proxy_only proxy_rule port 80 server srv1:81


    - На момент написания заметки в FreeBSD 7.2-STABLE не работали правила redirect_proto.


    - В FreeBSD 7.1 и более ранних версиях размер redirect_port имел какое-то внутреннее ограничение приводящее к ошибкам "logical string limit" при составлении длиных правил. В FreeBSD 7.2-STABLE этой проблемы больше нет.


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


    - Параметры sysctl которые влияют на динамические (keep-state) правила.

    срок жизни инамических правил для UDP и TCP:
    net.inet.ip.fw.dyn_udp_lifetime
    net.inet.ip.fw.dyn_ack_lifetime

    максимальное количество динамических правил:
    net.inet.ip.fw.dyn_max

    размер хеш-таблицы для поиска в списке динамических правил:
    net.inet.ip.fw.dyn_buckets

    автоматическая отсылка TCP keep-alive сообщений для динамических правил:
    net.inet.ip.fw.dyn_keepalive


    - В версии FreeBSD 8.1-RELEASE не работает параметр sysctl one_pass - трафик после прохода через нат  возвращается обратно в фаервол. Чтобы избавиться от этой неприятности надо делать правило "allow all from any to any" после правила ната. Эту проблему должны будут исправить в релизе 8.2.



    Ссылка на обсуждение: http://forum.lissyara.su/viewtopic.php?t=18967.

    размещено: 2009-08-30,
    последнее обновление: 2011-01-28,
    автор: terminus

    оценить статью:

    vitiko007, 2009-08-08 в 22:15:53

    Супер... !!! Автор молодца :)

    www2, 2009-08-10 в 8:05:08

    Отличная работа!

    beerman, 2009-08-10 в 8:39:06

    зачем так мучицца, если во фришке есть ipfilter  с ipnat??? И работает без бубнов и доки по нему вполне вменяемые

    MadMike, 2009-08-10 в 9:36:16

    Классная статья! Автору спасибо!

    terminus, 2009-08-10 в 11:55:42

    >зачем так мучицца, если во фришке есть ipfilter  с ipnat???

    Это все конечно есть, но я предпочитаю отечественного производителя =)

    Харон, 2009-08-10 в 12:50:48

    может для кого pf и сильно альтернативный, а я перешёл на него сразу после внедрения с большим удовольствием. Однако ipfw тоже имеет право быть :)

    Прохожий, 2009-08-10 в 14:23:04

    Очепятк хорошо бы поправить...
    ...так как в настройках выстален параметр deny_in.

    AFly, 2009-08-10 в 18:23:14

    В первом примере нет правила 10140, о котором есть упоминание в тексте.

    terminus, 2009-08-10 в 18:38:26

    >В первом примере нет правила 10140

    Упс - опечался я где-то?
    Уточните пожалуйста в какой части текста первого примера про 10140.

    vales, 2009-08-10 в 18:51:06

    А где бы pf такую же красивую доку найти, где весь путь пакетов расписан и где что срабатывает и куда идет?

    vales, 2009-08-10 в 18:52:04

    ..про pf то бишь..

    GR, 2009-08-10 в 19:20:29

    Мужики - не будте неблагодарными <beeep!>
    Статья называется \"Подробное руководство по ipfw nat\" - зметьте не \"чего можно заюзать вместо\" или \"IPFILTER - город контрастов\" ...
    Автору респект, глядя на себя в зеркало - мне было бы ломы после походов по граблям, занудно и монотонно разжевывать для других. А он - сделал. Одна такая вещь стоит 99% всех ваших комментов.
    Так что Viva Terminus! Молодца!

    PS: А ошибки - вычистит.

    vales, 2009-08-10 в 19:44:46

    Да не, автору большущий респект! Но вопрос прямо по статье: я правильно понял, что общая схема остается прежней, независимо от того, какой фильтр применяется? Т.е. в случае с pf на месте ipfw_chk() будет что-то вроде pf_chk(), а прочие вещи типа ip_input(), ip_output() и ip_forward() остаются прежними, поскольку это часть ядра? Только наверное pf сам делает подмену адресов/портов для NAT и ему не нужно отклонение на ветку (8)-(9), все делается в точке (7) для выхода и в точке (2) для входа. Я прав?

    terminus, 2009-08-10 в 21:44:23

    >я правильно понял, что общая схема остается прежней, независимо от того, какой фильтр применяется?


    Не могу сказать. Я использовал объяснение nuclight про стек FreeBSD и ipfw как опорный материал. Сам я внутрях FreeBSD не копался и как все эту будет выглядеть в случае pf/ipf незнаю...

    AFly, 2009-08-11 в 10:32:14

    >Уточните пожалуйста в какой части
    Извини, все в статье нормально. Это я смотрю в книгу и вижу … не то что написано :-)

    terminus, 2009-08-12 в 18:18:26

    >я правильно понял, что общая схема остается прежней, независимо от того, какой фильтр применяется?

    вот кстати интересное выступление nuclight\'a - там кажется есть ответ на ваш вопрос.

    http://smotri.com/video/view/?id=v9864889761#none

    vales, 2009-08-13 в 19:10:12

    Посмотрел. Большое спасибо за ссылку! Действительно кое-что проясняет и дает повод подумать.

    vlad, 2009-08-21 в 12:22:58

    # боимся непонятного
    Уважаемый автор, можно можно использовать эту строку конфига у себя? :)
    P.S. спасибо за труд.

    terminus, 2009-08-21 в 14:36:24

    Это комментарий - его использовать не нужно (его использование ни на что не повлияет) ;)

    Vit, 2009-08-21 в 15:35:35

    Спасибо большое автору, хорошая статья. Молодцом, как говорил Хенкок :).

    prince, 2009-08-23 в 19:49:22

    Присоединяюсь к общей волне благодарностей!
    Есть вопрос по примеру 2, а именно:

    Какой адрес подразумевается при настройке nat 2?
    Если я правильно понимаю, машина 192.168.1.36 может ходить в инет от имени 1.2.3.4 или 1.2.3.5, а входящие соединения принимаются только через 1.2.3.5, тем самым создавая некую путаницу

    Логично ли будет отдать 192.168.1.36 отдельный коридор 192.168.1.36 <--> 1.2.3.5?

    nat 2 config if em0_alias0 log same_ports redirect_addr 192.168.1.36 1.2.3.5

    terminus, 2009-08-23 в 22:00:21

    Вот спасибо - вы нашли ошибку! Я забыл указать настройки IP для второго экземпляра :) Сейчас исправлю.

    terminus, 2009-08-23 в 22:06:11

    Хотя нет!
    На самом деле там все правильно, просто при настройке redirect_addr нельзя использовать if или ip. Такая настройка для второго экземпляра корректная - ip для своей работы он берет из последнего атрибута redirect_addr 192.168.1.36 1.2.3.5

    Я не знаю почему именно так, но этот пример был проверенн в работе.

    terminus, 2009-08-23 в 22:07:59

    И про 192.168.1.36 <--> 1.2.3.5

    192.168.1.36 будет ходить в мир ТОЛЬКО из-под 1.2.3.5.

    Jungo, 2009-08-28 в 19:16:53

    Спасибо за статью! У самого работает такой nat около года в личных целях. Когда настраивал было очень много проблем с прохождением пакетов, причем наблюдались такие вещи что при нате порты на сервере оказывались открытыми! причем все. это при том что тип default to deny. Видимо как то они подпадали под нат и не находя получателя терялись. Сути всей не знаю.

    Теперь почитаю) может что нового найду.

    Дмитрий, 2009-08-30 в 17:35:46

    Спасибо за статью!
    К примеру 4 я бы ещё добавил пример, в котором 2 провайдера и одна локалка

    Александр, 2009-08-30 в 17:56:57

    Статья сама что нужна. Ошибки ошибками, кто работает и учится с этим работать, разберутся с ними. Но интересный был бы случай, когда два провайдера и одна локалка, но один провайдер дает интернет через впн, к тому же предоставляя ресурсы в своей локалке. В остальном, большая благодарность!

    DemonSKED, 2009-08-31 в 1:10:18

    Спасибо огромное. А то ковырял нат - еле настроил. Криво вышло, но теперь есть этот шедевр на русском!

    terminus, 2009-08-31 в 10:36:09

    >К примеру 4 я бы ещё добавил пример, в котором 2 провайдера и одна локалка

    >Но интересный был бы случай, когда два провайдера и одна локалка

    Я пока не знаю как красиво сделать такое на 7.Х. Есть, конечно, вариант жестко разделить диапазон адресов локальной сети на две части, и каждую часть заводить через своего провайдера, но это кривое решение.
    Вот в 8.0 обещали ввести Equal cost multipath routing - надо будет потом посмотреть как эта штука сделана. Главная задача обеспечить прозрачную балансировку и отказоустойчивость при выпадении одного из провайдеров.

    alik, 2009-09-02 в 8:19:57

    Сразу видно, статья основана на практике!
    Да и с примерами вы хорошо постарались. Отлично.

    DoMeN, 2009-09-02 в 23:21:04

    Статья отличная натолкнула на пару мыслей. Спасибо.
    >Вот в 8.0 обещали ввести Equal cost multipath routing - надо будет потом посмотреть как эта штука сделана. Главная задача обеспечить прозрачную балансировку и отказоустойчивость при выпадении одного из провайдеров.
    Да это актуально.

    ktulhu, 2009-09-05 в 16:09:23

    автор молодец. осталось написать похожую статью для pf. и конечно же обновлять эту по мере добавления информации

    terminus, 2009-09-05 в 22:54:32

    Люди, для кого актуальна ситуация с "одной локалкой и двумя провайдерами" - потестируйте пожалуйста вот этот пример:
    http://forum.lissyara.su/viewtopic.php?f=8&t=18967&p=189375#p189375

    terminus, 2009-09-07 в 22:49:16

    В общем я прогнал пример с "двумя провайдерами" в голове и ошибок не нашел. Объяснить движение трафика через схему тоже получилось без особых затруднений...

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

    Мягков Василий, 2009-09-16 в 19:05:30

    Злостный оффтоп, прошу прощения за это, вопрос автору: в чем схемы рисовались, редактор имеется ввиду?

    terminus, 2009-09-16 в 21:51:48

    В Visio 2007 + клипарт встроенный.

    kpp, 2009-09-17 в 14:55:37

    небольшая придирка, но всеже ухо(глаза) режет ;)
    "Пример 5
    ...
    Задача: обеспечить выход в интернет локальной сети через обеих провайдеров
    ..."

    нужно

    "обоих провайдеров"

    Статья - супер, имею фрю7.2 сегодня же перейду с natd на ядренный нат. У меня будет похоже на пример5, но не 2 а 3 провайдера ;)

    terminus, 2009-09-17 в 15:51:53

    мидифицировать 5й пример для 3х провайдеров сможете?

    о результатах потом на форуме (в теме для обсуждения) напишите пожалуйста.

    kpp, 2009-09-17 в 16:11:06

    Конечно модифицируем полностью и отпишусь ;)

    Kolesya, 2009-09-18 в 23:23:17

    Придется связку ipfw+natd у себя перенастроить на ядерный нат :)

    +100 "за разжеваное описалово"

    staskur, 2009-09-30 в 16:17:02

    Автор.

    куда денег закинуть за статью ?
    нереально помог.

    terminus, 2009-10-01 в 10:22:14

    Деньги в FreeBSD Foundation закиньте =)

    reekoff, 2009-10-01 в 13:59:55

    Что-то не понятно по 3-му примеру для второго экземпляра нат:
    Трафик приходящий из интернета на 5.6.7.8:80 пройдет через цепочку правил ipfw прохода IN до правила с номером 10130 где попадет в первый экземпляр ната и будет демаскирован на основании статического правила (внешний_IP <-> 5.6.7.8 будет заменено на внешний_IP <-> 192.168.1.80).
    Разве после посещения нат на этом правиле трафик не готов уже пойти на 192.168.1.80?
    nat 1 config log if em1 reset same_ports deny_in redirect_port tcp 192.168.1.80:80 80, по-моему, об этом и говорит (тобишь, 5.6.7.8 будет демаскирован в 192.168.1.80). Зачем нужен второй нат, поясните пожалуйста.
    В общем, непонятны правила преобразования адресов в обоих натах.


    terminus, 2009-10-01 в 14:55:12

    Второй нат там нежен для того чтобы вычеркнуть из пакета еще и оригинальный "внешний_IP" IP адрес - чтобы на 192.168.1.80 пакет пришел как бы от 192.168.1.254, тогда и ответ уйдет на него же.

    В описании задачи скзано, что дуступ к веб серверу надо обчеспечить только через второго провайдера не меняя настройки TCP/IP.

    Если не пропускать трафик через второй нат, то ответ на "внешний_IP" уйдет через 192.168.1.1 (через подключение к первому провайдеру).

    ---
    >непонятны правила преобразования адресов в обоих натах

    первый нат производит "демаскировку" заменяя в пакете адрес получателя. второй нат производит "маскировку" заменяя адрес отправителя.

    reekoff, 2009-10-01 в 15:28:31

    Извиняюсь,
    а (внешний_IP <-> 5.6.7.8 будет заменено на внешний_IP <-> 192.168.1.80) что здесь внешний_IP? Это который [remote IP] для redirect_port по ману?

    terminus, 2009-10-01 в 15:34:35

    ну да, я наверно не очень удачно выбрал названия... внешний_IP - это адрес удаленного клиента в интернете.

    потом переделаю там названия.

    reekoff, 2009-10-01 в 15:40:41

    тогда, может быть в конфиге первого ната нужно редирект так задать:
    redirect_port tcp 192.168.1.80:80 remote_IP:remote_port
    ?

    reekoff, 2009-10-01 в 15:45:51

    Сорри, туплю я )))

    FilosofBeer, 2009-10-22 в 12:11:31

    Странно, а в статье http://www.lissyara.su/?id=1127 IPFW - штатный файрволл FreeBSD всё по другому описано !?
    И где правда ???

    lissyara, 2009-10-22 в 15:14:22

    Посередине.
    Это не винда, где одну задачу можно решить ограниченным набором галочек, и только одним способом.
    Тут каждый волен сделать по своему, и каждый способ будет рабочим.

    FilosofBeer, 2009-10-22 в 19:34:33

    А ещё в примере 6 не описано как сделать ограничения для инета по конкретным ИП из всей локалки и ограничения скорости.

    terminus, 2009-10-22 в 20:31:06

    Примеры в статье по большому счету приведены для того чтобы показать на них концепции, а не как 100% варианты для использования... Более-менее "готовыми" являются 2, 4 и 5. Остальные - до кучи.

    Если вы на основе статьи nuclight'а и 6-го примера поймете по какому принципу действет связка nat + limit (keep-state) то осмысленно перенести ограничение количества сессий на второй или пятый примеры проблем не составит.

    Я ведь не могу заранее предусмотреть все возможные варианты использования ipfw nat, правильно? ;)

    chilllivilli, 2009-10-23 в 14:21:47

    не работает ядерный нат в клетке....http://forum.lissyara.su/viewtopic.php?f=8&t=21055&p=202097#p202097

    godlike, 2009-12-05 в 1:42:51

    Отлично.
    До всего этого доходил сам с граблями начиная с 7.0 и до сейчас (8.0).
    Преклоняюсь перед вами!
    Вы сделали по истине титанический труд.

    terminus, 2009-12-05 в 13:54:06

    Титанический труд сделал nuclight, описав в своей статье внутреннюю структуру стека, ipfw, и его взаимодействие с тем же натом, да keep-state правилами. Я только применил полученные от него знания - расписал касающееся ната по возможности подробнее. :)

    havarz, 2009-12-11 в 9:03:10

    Еще бы также подробненько про Layer2. И было бы вообще круто.

    terminus, 2009-12-11 в 22:33:48

    А что про Layer2 неясно? Да и как же прицепить его к теме про ipfw nat? =)

    havarz, 2009-12-12 в 9:11:15

    Понятно, что не про nat, просто хотелось бы также подробно и про Layer2. Четыре прохода, по манам не догоняю.
    А за статью большой респект. Перевожу свой сервер с natd на ядерный nat.

    terminus, 2009-12-12 в 19:43:59

    На форуме было какое-то обсуждение про Layer2:
    http://forum.lissyara.su/viewtopic.php?f=8&t=21660

    Если будут какие-то вопросы - спрашивайте там.

    chpoqxie, 2009-12-14 в 16:49:52

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

    огромное спасибо за упоминание rxcsum. про tso написано в мане ipfw, его я отключил. не помогло. а вот отключение rxcsum вылечило падения.

    8.0-release-p1 amd64.

    terminus, 2009-12-14 в 21:16:41

    Интересно блин... А сетевуха у вас какая? em?

    chpoqxie, 2009-12-15 в 20:08:30

    ага, em две встроенные, забыл написать :)

    InventoR, 2010-01-08 в 15:32:25

    http://www.online66.ru/?id=156
    Не приятно однако

    terminus, 2010-01-09 в 14:02:12

    >Не приятно однако

    ipfw nat завоевывает мир! =)

    Пофиг. Статьи на сайте у Лисяры считай, что под BSD - то есть "юзай на здоровье". Тем более, что там ссылки стоят на оригинал.

    f0s, 2010-01-27 в 15:43:38

    InventoR, а собственно что неприятного? автор и там и там один и тот же.

    dm, 2010-05-18 в 10:33:34

    firewall_type="/etc/firewall"
    наверное firewall_script="/etc/firewall" ?

    terminus, 2010-05-19 в 11:53:37

    Можно и так, и так.

    Разница в том, что при использовании type сначала выполняются системные скрипты которые добавляют разрешения для localhost и др. что система считает нужным по-умолчанию, кроме того там не надо писать ipfw. Но и нельзя использовать переменные...

    При использовании script все правила надо составлять самому и можно юзать переменные.

    Я использую type по привычке так как считаю такой способ более предпочтительным. Например при апгрейде системы что-нить может поменяться в настройках ipfw и это будет учтено в системных скриптах которые сейчас добавляют разрешения для трафика localhost. При использовании type мои настройки не повлияют на систему, а при использовании script придется разбираться что же изменилось... Так как я сижу на STABLE/CURRENT для меня это чуть-чуть актуально.

    А вообще type/script - это дело вкуса.

    ASM, 2010-05-24 в 14:57:11

    Заметил такую штуку, что если в опциях ната есть проброс порта внутрь, а в то время, когда сервер поднимается, машина, на которую проброшен порт, выключена, то нат вроде бы и поднимается, но не работает. Пока не смог найти объяснение сему.

    SSh, 2010-06-03 в 23:07:09

    Статья - супер !!! Автору большое человеческое спасибо !!!

    alex_471, 2010-07-08 в 10:45:48

    Статья мощная, прямо как научная работа - автору респект, но переходить с natd на ipfw nat опять перехотелось. Поясню: os - 7.3, железо Intel3420+Core5i, 4GB RAM, 1 провайдер - 100 Мб. нагрузка на сервак неслабая - более 200 пользователей почты и пр. Natd работает как танк. Выключать -rxsum на Intel-ском гигабитном адаптере не собираюсь. Получаеться ipfw nat - мне не нужен. Попробуйте меня переубедить.

    www2, 2010-07-08 в 16:02:46

    >работает как танк.
    >Попробуйте меня переубедить.

    Сдалось кому-то переубеждать танкистов...

    terminus, 2010-07-08 в 17:50:32

    >Выключать -rxsum на Intel-ском гигабитном адаптере не собираюсь.

    Сетевуха какая? em или igb? На em из-за драйвера все еще есть проблемы, а про igb ничего не знаю. Попробуйте - расскажите потом.

    Dog, 2010-07-08 в 17:56:30

    Как вариант - попробовать врубить ядреный NAT на тестовой машине с аналогичной (или похожей) конфигурацией и посмотреть, что хуже скажется на производительности: отключений опции rxsum при работе kernel NAT или перелопачивание трафика с уровня ядра на пользовательский и обратно при использовании NATD.

    staskur, 2010-07-30 в 9:18:03

    " - ipfw nat любит перезагрузки при изменениях в конфигурации. "

    это мягко сказано...

    abibas, 2010-08-26 в 22:54:39

    чувак, а про pf не надо гнать, единственый его минус это то, что он не пропускает pptp сквозь нат.

    сергей, 2010-10-02 в 16:27:29

    большое спасибо за статью

    Макс, 2010-10-07 в 13:36:57

    ipfw nat конечно хорошо, но как на нем реализовать вот такое, чтобы заменить им natd?

              instance default
              interface sis0
              port 1000

              instance sis2
              interface sis2
              port 2000

              globalport 3000

    А?

    terminus, 2010-10-07 в 14:21:14

    Нету такого - запустить два экземпляря ядерного ната с общей таблицей нельзя. Если нужна балансировка между подключениями, то воркаунд с keep-state показан в пятом примере.

    Batonius, 2010-12-22 в 17:49:05

    Кажется, ошибка в пятом примере:
    add 1040 setfib 0 ip from any to any via fxp0 keep-state
    add 1050 allow ip from any to any via fxp0

    add 1060 setfib 1 ip from any to any via fxp0 keep-state
    add 1070 allow ip from any to any via fxp0


    Тогда как в форуме:
    add 1040 setfib 0 ip from any to any in recv fxp0 keep-state
    add 1050 allow ip from any to any via fxp0

    add 1060 setfib 1 ip from any to any in recv fxp0 keep-state
    add 1070 allow ip from any to any via fxp0


    А я долго бился, не мог понять, почему не работает. :( С исправлением на in recv всё заработало.
    Большое спасибо за статью! :)

    Batonius, 2010-12-22 в 17:54:50

    Забыл упомянуть. У меня FreeBSD-8.1.

    terminus, 2010-12-22 в 21:22:05

    Интересно. По логике результат должен быть один и тот же... Ладно, исправлю на in recv. Спасибо.

    ASM, 2010-12-22 в 21:37:35

    Но ведь via разрешает оба направления, а in recv - только входящие к ОС соединения.

    terminus, 2010-12-22 в 21:47:59

    Да там на том участке без разници должно быть. Единственное, я счас прикинул - если Batonius пытался делать проброс портов, то в этом случае могли быть грабли - там этот via имел бы значение, да...

    Проброс не работал или с клиентскими сессиями проблемы были?

    Batonius, 2010-12-23 в 17:33:31

    >Проброс не работал или с клиентскими сессиями проблемы были?
    Проблемы были с клиентскими сессиями, до проброса я тогда еще не дошел.
    Сегодня попробовал все еще раз на свежую голову и  сдается мне, что я слегка облажался. :) Очевидно, нужно было всего лишь перезагрузиться. И после все заработало. И с via и с in recv.

    Beginner, 2011-01-28 в 14:07:36

    Уважаемые форумчане. Уже 2 суток мучаюсь с IPFW + NATd, и у меня складывается впечатление что NATd не умеет делать divert во внутреннюю сеть если она не RFC совместима т.е. не 10, 192, 172. Срочно нужна альтернатива которая работает с не RFC подсетями. Может ли быть такой альтернативой IPFW NAT? Или есть другие варианты?

    стас , 2011-01-28 в 14:29:23

    у меня в двух местах исторически юзается сеть вида 1.2.3.ххх  ...  ipfw+NATD  там живет нормально..

    ыть, 2011-06-10 в 14:05:32

    Уважаемый, terminus, всё очень доходчиво и основательно "разжевано", приложено немало труда..

    Единственно режет\корёжит глаз\слух - "рутер".. %((
    Интересно, как вы произнесете фразу "пропишите маршрут такой-то туда-то, туда-то.." ??
    http://translate.google.ru/translate_t?hl=&ie=UTF-8&text=route&sl=en&tl=ru
    Даж и не знаю, как свои сетки роутить теперь %(
    Поверте, очень сильно корёжит..

    По-сути - мегастатья, респект!

    www2, 2011-06-10 в 15:32:17

    2 ыть

    Правильно произносится именно "рутер" (сюрприз! сюрприз!), а американцы вообще говорят "раутер". На google translat можно услышать именно американский вариант произношения.

    ыть, 2011-06-10 в 17:46:06

    ну в вашем варианте "сетки раутить" еще можно..

    статья написана русскими буквами с расчетом на то, что читать ее будут те, кто "made in USSR", т.е., общеупотребимое\понятное в повседневном лексиконе..

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

    Ну, наизнанку выворачивает, чесслово! %)

    www2, 2011-06-11 в 12:28:38

    >Ну, наизнанку выворачивает, чесслово! %)

    У вас какие-то проблемы с желудком. Вы поосторожнее с этим. А то сначала гастрит, потом язва...

    terminus, 2011-06-13 в 13:15:57

    Не знаю, всю жизнь все везде говорили просто рутер.

    sergko, 2011-06-24 в 15:14:49

    ipfw nat любит перезагрузки при изменениях в конфигурации. Я не могу привести конкретных примеров, но иногда случается, что после больших изменений в конфигурации экземпляра ната, новые настроки могут вступить в действие только после перезагрузки модуля ipfw, или же после перезагрузки машины. Бездоказательное утверждение из опыта и на уровне "ощущений".

    Обсалютно верно! Пол дня сидел настраивал НАТ, перезагружал ipfw и тоже самое было! Пока сервак не перезагружу или не уберу из правил НАТ

    Vasiliy P. Melnikm, 2011-08-05 в 0:17:54

    В первом примере ошибка, хотя возможно все и работает.

    gateway_enable="YES"
    ifconfig_em0="inet 1.2.3.4 netmask 255.255.255.0 -rxcsum"
    ifconfig_fxp0="inet 192.168.1.1 netmask 255.255.255.0"
    defaultrouter="1.2.3.254"
    firewall_enable="YES"
    firewall_type="/etc/firewall"

    А вместо этого надо
    firewall_script="/etc/rc.firewall"
    # Which script to run to set up the firewall

    terminus, 2011-08-07 в 20:12:05

    Все нормально там.

    Если используется firewall_type то при этом команды перечисленные в нем  обрабатываются напрямую ipfw, а если firewall_script то там уже просто любые shell команды/конструкции можно использовать.

    На любителя - никто не запрещает использовать то, что больше нравиться.

    Феликс, 2011-08-28 в 13:27:15

    Вот это сила, вот это жесть, да я в сетке не видел не чего подобного да так что бы было все в одном месте дэк еще и разжеванно, статья очень сильная! БООООЛЬЬЬШОЕ СПАСИБО АфФтору, отжоГ прямо в Ад.

    очень и очент интересно позновательно, до многово что бы додуматься у некоторых ушли бы месяцы а тут 1ч чтения и понятная картина, спасибо еще раз, обязательно использую правила, когда буду уходить в мелкомяхкого вин(д)овоза!

    Thanks!!!
    такой вопрос, пример:
    add 1050 deny ip from any to 192.168.0.0/16 in recv em0
    add 1060 deny ip from 192.168.0.0/16 to any in recv em0
    add 1070 deny ip from any to 172.16.0.0/12 in recv em0

    откуда они берутся ? или Мы их сами указываем как индефикатор правила для дольшейшего использования, или как вообще, я баран в этом так что чур не дратся!

    Феликс, 2011-08-28 в 13:31:39

    Соррии я имеюю ввиду цыфры 1050.1060.1070

    terminus, 2011-08-29 в 16:43:36

    Это "индефикатор правила для дольшейшего использования". порядковый номер правила - то, что показывает ipfw show.

    man ipfw

    Феликс, 2011-08-30 в 10:21:39

    Thanks!!!Thanks!!!Thanks!!!

    Klop, 2011-09-01 в 10:51:58

    Вот интересно: кто-нибудь разобрался, какова схема прохождения пакета в случае использования не natd в user space, а именно ipfw kernel nat?
    Пока не дошло. Вывод tcpdump уже снится...(((

    terminus, 2011-09-01 в 10:57:59

    точно такая же, читайте nuclihgt'а:
    ---
    Подобное выведение пакета из обработки ipfw в другую подсистему — не уникально
    для divert, это общая схема работы в стеке FreeBSD. Например, действия pipe и
    queue в dummynet, передача пакета в netgraph (а также появившийся в 7.0
    ipfw nat) действуют по тому же принципу. Отличие, однако, в том, что в этих
    подсистемах пакет остается внутри ядра, никакому демону не передается.
    ---

    gonzo111, 2011-10-15 в 17:40:23

    Нагуглил как сделать доступным пинг сервера из интернета

    "Перед НАТом добавляем такое правило:
    ipfw add 1350 allow icmp from any to 195.98.163.142 icmptypes 8 in via rl0
    Если разрешить, например, еще и эхо-ответ (icmptypes 0), то пинг из локальной сети уже не будет работать, поскольку ответ от удаленного ресурса будет сразу обрабатываться сервером напрямую, не попадая в НАТ. "
    http://forum.muff.kiev.ua/index.php?PHPSESSID=ac794d2b4f9d27cfa296b89f5c4ac9e1&topic=25.15
    спасибо ребята

    Стас, 2011-11-17 в 21:14:18

    Заместо setfib лучше юзать ipfw fwd. Не надо будет мучаться с двумя таблицами маршрутизации. Опять же это снимает ограничения с кол-ва каналов, которые натятся. Т.е. вы можете спокойно занатить хоть 15 каналов и правилами ipfw fwd указать для каждого свой дефолт, не применяя для этого дополнительных таблиц маршрутизации. Ну и конечно при этом не надо забывать one_pass=0. А для того, чтобы заработал ipfw fwd надо добавить в опции ядра options IPFIREWALL_FORWARD

    terminus, 2011-11-17 в 21:17:14

    fwd накладнее по ресурсам чем setfib

    Стас, 2011-11-17 в 21:28:46

    Но для каналов больше 2, придётся создавать на этапе компиляции ядра соответственное кол-во таблиц маршрутизации. Так что, если каналов много, то fwd более выгоден.

    terminus, 2011-11-17 в 21:50:40

    когда при компиляции было задано 2 fib то для использования 3,4,5...16 fib-ов можно использовать sysctl (то есть каждый раз перекомпиливать не надо):

    ===
    www.freebsd.org/releases/7.1R/errata.html

    This number can be modified on boot time. To do so, add the following to /boot/loader.conf and reboot the system:
    net.fibs=6
    ===

    adsh, 2011-12-12 в 1:10:51

    В чём смысл указания:

    queue, gred

    для пайпов, если они уже указаны для очередей?

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

    SkiNNi, 2011-12-19 в 13:25:19

    Естли сделать так. redirect_proto ip 192.168.1.11 то весь трафик пойдёт на 192.168.1.11, как и нету шлюза? И шлюз не получит ни какого пакета на уровень приложений?

    Стас, 2011-12-19 в 16:41:16

    Да, весь входящий tcp трафик пойдёт на хост 192.168.1.11 минуя уровень приложений

    adre, 2012-04-20 в 20:51:02

    Вот сижу и думаю. Зачем выставляется в данной системе HZ=1000 чем HZ=100 не устраивает?

    potf, 2012-04-24 в 12:25:50

    Прекрасная работа! Спасибо и Респект Автору!

    Мфынф, 2013-10-20 в 16:44:16

    ТУПАЯ ХИРНЯ

    bit suid, 2015-01-18 в 18:52:37

    FreeBSD 8.4 x64
    настраивал NAT  по примеру 1
    так нифига и не получилос НАТ не заработал
    КОНФИГ НЕ ПРАВИЛЬНЫЙ ДЛЯ НОВИЧКОВ СОВСЕМ НЕ ПОНЯТНЫЙ

    add 1040 allow ip from any to any via em1
    Это праило не отрабатывает КУДА СМОТРЕЛ АВТОР КОГДА ПИСАЛ СТАТЬЮ

    нужно исправить
    ipfw add 1040 allow ip from any to any via em1
    вот так работает

    terminus, 2015-01-19 в 15:01:38

    >КУДА СМОТРЕЛ АВТОР КОГДА ПИСАЛ СТАТЬЮ

    Автор предпологает, что у вас в /etc/rc.conf прописано:
    firewall_type="/etc/firewall"

    Если у вас прописано так:
    firewall_script="/etc/firewall"
    то работать не будет.

    _type и _script это разные вещи...

    Anton, 2015-04-21 в 14:52:21

    Возможно, баг или я не врубаюсь. В пятом примере редирект 25-го порта. Если пришёл входящий пакет, на проходе IN он зацепит 10170, 10180 и 10220. На проходе OUT он выйдет через 1050 и направится к 192.168.1.5. Но при этом никакие динамические правила не созданы и ответный пакет с вероятностью 50% может уйти через em1.
    Я думаю, что в правиле 1040 нужно исправить in recv fxp0 на via fxp0, тогда входящий пакет зацепит 1040 на проходе OUT для создания необходимого динамического правила.

    Rader, 2015-08-24 в 6:41:27

    Как составить конфигурация ipfw, чтобы все запросы DNS из локальной сети перенаправлялись только в мой DNS сервер?

    ama, 2015-10-13 в 18:39:48

    Просьба исправить рутор на роутер или маршрутизатор, читать ведь, неприятно!

    Pavel, 2016-07-19 в 17:30:43

    Подскажите пожалуйста, почему в статье используется параметр type, а не script? Для NAT это более предпочтительно или просто статья старая?

    Pizdyk, 2016-07-20 в 7:30:52

    Type типфаервола, а скрипт, это какие правила сам пилишь.

    Fahri Hasan, 2017-08-25 в 22:53:33

    Оптимизированные правила ipfw:

    net.inet.ip.fw.one_pass=1

    https://github.com/mysticall/imslu/blob/master/conf/freebsd/usr/local/etc/imslu/rc.firewall

    tauri, 2017-09-21 в 10:37:22

    а вот такой вопрос. Как "net.inet.ip.fw.dyn_keepalive" пакеты на выходе занатить? D


    Оставьте свой комментарий:
    Ваше имя:   *
    e-mail:  
    жирный
    наклонный
    подчёркнутый
    ссылка
    цвет
    Нынешний год:   *
     


  • Хостинг HOST-FOOD

    2014-07-27, lissyara
    gmirror

    Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
    2013-08-20, zentarim
    Scan+Print server FreeBSD 9

    Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
    2011-11-20, BlackCat
    Разъём на WiFi-карту

    Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
    2011-09-14, manefesto
    Настройка git+gitosis

    Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
    2011-08-14, zentarim
    Wi-FI роутер + DHCP + DNS

    Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
    2011-06-15, -ZG-
    Охранная система на FreeBSD+LPT

    В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
    2011-03-13, terminus
    ng_nat

    Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
    2011-02-20, Капитан
    Nagios+Digitemp

    Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
    2011-02-17, Le1
    Zyxel Configuration

    Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
    2011-02-16, fox
    hast carp zfs ucarp cluster

    HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
    2011-02-04, BlackCat
    Восстановление ZFS

    История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
    2011-02-03, Капитан
    1-Wire

    Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
    2011-01-28, Капитан
    Температура в серверной

    Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
    2011-01-21, m4rkell
    Syslog server

    Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
    2011-01-07, lissyara
    Canon/gphotofs

    Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
    2010-12-13, Al
    IPSec

    Описание принципов работы IPSEC и способов аутентификации.
    2010-12-07, manefesto
    FreeBSD on flash

    Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
    2010-12-05, Fomalhaut
    root ZFS, GPT

    Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
    2010-09-05, Cancer
    Настройка аудиоплеера на ximp3

    Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
    2010-08-31, Cancer
    Установка и настройка OpenVPN

    На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
    2010-08-25, manefesto
    freebsd lvm

    Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
    2010-04-30, gonzo111
    proftpd file auth&quota

    Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
    2010-04-22, lissyara
    tw_cli

    Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
    2010-04-14, fox
    MySQL Master+Master

    MySQL (Master Master) and (Master Slave) Как настроить репликацию…
    2010-03-09, terminus
    DNS zones

    Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
    2010-03-09, aspera
    Squid+AD (group access)

    Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
    2010-03-02, BlackCat
    Шлюз: Часть 4

    Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
    2010-03-01, BlackCat
    Шлюз: Часть 3

    Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
    2010-03-01, BlackCat
    Шлюз: Часть 2

    Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
    2010-03-01, BlackCat
    Шлюз: Часть 1

    Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
    2010-02-23, Morty
    darkstat

    Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
    2010-01-23, gonzo111
    squid+sams+sqstat

    Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
    2009-12-19, schizoid
    mpd5 + radius + ng_car + Abills

    Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
    2009-11-16, lissyara
    UFS->ZFS

    Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
    2009-11-13, gx_ua
    fusefs-ntfs

    Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
    2009-11-12, Morty
    LiveCD

    Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
    2009-09-27, lissyara
    Samba как PDC

    Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
    2009-08-30, terminus
    ipfw nat

    Подробное руководство по ipfw nat, сложные случаи конфигурации.
    2009-08-24, levantuev
    HotSpot

    Установка Hotspot системы в общественное заведение.
    2009-08-18, lissyara
    diskless

    Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
    2009-07-29, BAV_Lug
    Видеонаблюдение

    Настройка бюджетного варианта видеонаблюдения на удаленном объекте
    2009-07-22, Cancer
    OpenLDAP адресная книга

    Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
    2009-06-30, SergeySL
    AimSniff

    Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
    2009-06-25, atrium
    Управление правами доступа

    Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
    2009-06-16, DNK
    Exim+PgSQL

    Установка почтовой системы exim+pgsql на FreeBSD 7.1
    2009-05-30, mvalery
    HDD(mbr) -> HDD(gpt)

    Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
    2009-05-22, Cancer
    SendXMPP

    Отправка сообщений на Джаббер сервер по средствам SendXMPP
    2009-05-11, Raven2000
    Network UPS Tools

    Network UPS Tools представляет собой набор программ, которые обеспечивают общий интерфейс для мониторинга и администрирование UPS оборудования.
    2009-04-29, m0ps
    IPSEC over GRE with RIP

    Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
    2009-04-24, WhiteBear777
    qemu network

    Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
    2009-04-22, vp
    freebsd + huawei 162 gsm modem

    В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
    2009-04-12, mvalery
    Мониторинг RAID

    Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
    2009-04-09, texnotronic
    RAID1 via LAN

    Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
    2009-04-03, Raven2000
    Оптимизация хоста для CMS

    В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и ~10 сайтов/CMS.
    2009-04-01, atrium
    VSFTPD + AD && MySQL

    Настройка самого безопасного сервера FTP - vsftpd.
    2009-03-31, Dron
    Peoplenet + C-motech (3G)

    Описание подключения к сети Peoplenet посредством 3G модема С-motech CCu-650U на FreeBSD
    2009-03-25, lissyara
    mod_auth_external

    mod_auth_external - авторизация пользователей в apache c помощью внешней программы - например, системных пользователей.
    2009-03-24, gx_ua
    Lightsquid

    Частично lightsquid может заменить sams: быстрая и простая инсталляция, быстрый парсер, cgi скрипт для динамической генерации отчета, нет привязки к БД, различные графические отчеты, мультиязычный инт
    2009-03-18, LHC
    Установка Zabbix-1.6

    Установка и первоначальная настройка системы мониторинга Zabbix (версия 1.6)
    2009-03-16, Cancer
    Принт-Сервер Samba+LPD & AD

    Простейшая настройка Принт-Сервера на FreeBSD используя Samba+LPD & AD
    2009-03-04, Mad_caterpillar
    ipsec_vpnc

    Настройка VPN IPSec концентратора на FreeBSD 6.2 для клиента cisco с использованием ipsec-tools и авторизацией в активной директории
    2009-02-18, Andy
    Free-SA

    Программа анализирует log файлы Squid'а и формирует по ним отчет.
    2009-02-02, Cancer
    Openfire Jabber Server

    Установка Jabber сервера на примере Openfire
    2009-01-28, Cancer
    mpd5 + сжатие и шифрование

    Установка VPN сервера mpd5 + сжатие и шифрование
    2009-01-26, vp
    freebsd + webcamera

    Подключение и настройка вебмкамеры для работы с freebsd на примере Logitech QCam STX
    2009-01-10, Grishun_U_S
    конфиг для офисов

    В статье разбирается конфиг для офиса, пользователи которого имеют строгие ограничения по портам. Заворачиваем www трафик на транспарентный прокси, а остальное NAT'им. Эффективно делим канал интернет
    2008-12-27, Storoge
    sftp+chroot

    Возникла необходимость дать возможность нескольким пользователям заливать на сервер контент для своих сайтов через sftp, чтобы при этом не страдала безопасность.
    2008-12-13, Morty
    PurefFTPd

    Администрирование pureftpd-сервера с помощью вэб интерфейса Usermanager
    2008-12-11, lissyara
    termlog

    Небольшая простая утилита, использующаяся для записи в файл всего что происходит на терминалах системы. Полезно, когда есть доступ по ssh у тех, кому не очень доверяете. Паранойя - это не плохо =)
    2008-11-26, Cancer
    SQUID+SAMS +Rejik-(ADLDAP)

    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
    2008-11-22, dvg_lab
    php5-oci8

    Решение проблем segmentation fault (core dumped) при работе с oracle8-client и php5-oci8
    2008-11-21, m0ps
    NTP

    Пример настройки NTP сервера для локальной сети и клиента, для синхронизации времени с локальный NTP сервером. Обновление ntpd из портов.
    2008-11-20, Cancer
    SQUID+SAMS +Rejik-(NTLM)

    Установка Прокси сервера SQUID с аутентификацией по NTL с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf, РЕЖИК собственно рубит банеры и запрещает пользователям хо
    2008-11-20, UA
    Hotspot

    Настройка безпроводной точки доступа (WiFi) на freebsd
    2008-11-12, Shaman
    Enemy Territory

    Появилась у меня такое желание поднять сервер Enemy Territory. Поискал погуглил, ничего толкового не нашел пришлось все самому делать. И вот решил поделиться опытом. Начинаем......
    2008-11-11, lissyara
    Samba+ NT ACL

    Использование vfs самбы - модули full_audit и recycle. Настройка для использования в качестве файлопомойки с 500+ одновременно работающих юзеров. Раздача прав через нативный виндовый интерфейс.
    2008-11-11, Raven2000
    Upgrading OpenBSD

    Сегодня мы будем обновлять OpenBSD. Систему необходимо поддерживать в актуальном виде и следить, чтобы все работало, как часы и все дырки были залатаны до прихода врага =)
    2008-11-10, lexy
    SMSTools 3

    Как автоматизировать отправку и обработку входящих сообщений при помощи мобильного телефона, датакабеля и компа
    2008-11-06, Cancer
    Asterisk IP PBX

    Установка VoiP сервера Asterisk IP PBX для соединения двух шлюзов и АТС
    2008-10-30, atrium
    Samba & CUPS & AD & ACL

    Настройка Samba в роли доменного файл-сервера, и CUPS в роли принт-сервера для Windows клиентов
    2008-10-17, Raven2000
    src & ports

    Конечно, в OpenBSD система портов никогда не сможет быть полной сравнение с той же системой во FreeBSD. Связано это с тем, что разработчики включают в порты лишь те приложение которые протестированн
    2008-10-13, Morty
    Mysql - базовое описание

    Базовое описание и принципы работы с MySQL
    2008-10-10, Cancer
    exim&dovecot + fetchmail + SSL

    Exim & Dovecot + Postfixadmin & Roundcube + Fetchmail & smtp_relay С возможностью отправлять письма через смтп релей провайдера. С использование SSL шифрование: POP3s IMAPs sSMTP
    2008-10-09, m0ps
    Дополнительные порты для роутера

    Увеличение количества Ethernet портов маршрутизатора за счет свободных портов коммутатора пробросив vlan с сабинтерфейса роутера на интерфейс коммутатора.
    2008-10-06, princeps
    Bacula

    Настройка сервера системы резервного копирования Bacula на FreeBSD для бэкапов FreeBSD и Windows машин
    2008-10-02, zheromo
    Postfix + DBMail

    Создание почтовой системы на основе Postfix + DBMail + SASL2 + TLS + DSpam + ClamAV + RoundCubeWebMail
    2008-10-02, Cancer
    SugarForge CRM

    SugarForge CRM предоставляет подавляющее большинство функциональных возможностей CRM систем
    2008-09-12, arksu
    ng_ipacct + squid

    Подсчет трафика с помощью ng_ipacct. Связка ng_ipacct + squid + парсер логов + авторизатор + nginx + mysql и куча служебных скриптов для работы всей системы.
    2008-09-03, Raven2000
    GLPI

    Мне надо было найти замену существующей программы инвентаризации, чтобы за компьютерами, принтерами, картриджами, лицензиями и тп был учет. Желательно с дополнительными бонусами типа системы подачи...
    2008-09-03, salimk
    POWERDNS

    Статья о том как мигрировать с DNS сетвера ISC Bind на POWERDNS
    2008-09-03, DNK
    Rinetd

    Редирект TCP портов с помощью утилиты rinetd - просто до безобразия - само прилодение простое, конфиг в одну строчку - что ещё надо для счастья? =)
    2008-09-03, L!Ner
    eGroupWare

    Это сервер групповой работы. Он укомплектован собственным веб-интерфейсом, который обеспечивает доступ к вашим данным с любой платформы по всей планете.
    2008-08-30, jafff
    MAC адрес

    У девайса VoIP Planet VIP-000 слетел MAC адрес и стал FF-FF-FF-FF-FF-FF, как я его востанавливал
    2008-08-30, Morty
    clonehdd

    Перенесение, бэкапирование HDD,легко и просто
    2008-07-31, Raven2000
    Proxy Auto Configuration

    Возникла необходимость автоматически настраивать прокси для всех компов и не бегать например если поменялось что-то на сервере прокси. Для этого давно существует технология Proxy Auto Configuration.
    2008-07-29, f0s
    NNTP сервер

    Конфигурирование собственного NNTP-сервера.
    2008-07-28, Al
    spamooborona

    настройка yandex spamooborona в качестве smtp-proxy для работы с exim
    2008-07-28, Cancer
    SQUID+SAMS +Rejik-(NCSA)

    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
    2008-07-20, Raven2000
    Pax

    Эта замечательная утилита поставляется с FreeBSD по умолчанию, и она имеет неплохой потенциал. Можно создавать архивы модифицировать их, а так же живьем переносить всю операционную систему с данными
    2008-07-16, Andy2k
    BIND & AD

    Настройка BIND для обслуживания запросов контроллеров Active Directory. Альтернатива поднятию DNS от Microsoft.
    2008-07-16, aleksey.kravchenko
    Samba (PDC+BDC)

    Поднять главный (офис) и резервный (филиал) контроллер домена на базе Samba и OpenLDAP, организовать синхронизацию и репликацию между ними. Запись в LDAP должена выполняться только на PDC.
    2008-07-14, aleksey.kravchenko
    OpenVPN + LDAP

    Статья о том, как настроить OpenVPN с авторизацией пользователей в OpenLDAP.
    2008-07-14, aleksey.kravchenko
    ProFTPd + LDAP

    ProFTPd с авторизацией пользователей в OpenLDAP
    2008-07-13, lissyara
    Asus Eee PC

    Дали на несколько дней поиграться Asus Eee PC - мелкий ноутбок по смешной цене. Ну, первым делом ставим правильный ОС и смотрим - что из этого получиться.
    2008-07-09, terminus
    DNS сервер Unbound

    Установка и настройка кеширующего DNS сервера Unbound под управлением FreeBSD 7.0
    2008-07-08, f0s
    mozilla autoconfig

    Автонастройка браузера и почты Mozilla Seamonkey пользователям
    2008-07-05, lissyara
    iftop

    Утилита предназначена для мониторинга загрузки канала в режиме реального времени - позволяет видеть кто именно занял полосу. Полезно для организаций с FreeBSD на шлюзовой машине.
    2008-07-02, manefesto
    snd_hda

    Патчим snd_hda для корректной работы с наушниками
    2008-06-27, Grishun_U_S
    dd : бэкапируем windows

    Клонирование разделов windows с помощью загрузочного диска FreeBSD
    2008-06-25, terminus
    DNS сервер NSD

    Установка и настройка авторитарного DNS сервера NSD под управлением FreeBSD 7.0
    2008-06-17, Al
    NetXtreme BCM5722

    Драйвер для сетевой карты NetXtreme BCM5722 Gigabit Ethernet
    2008-06-15, tango
    Amanda

    Установка и настройка сервера резервного копирования Amanda на FreeBSD.
    2008-06-12, LMik
    Виртуальный свитч

    Статья описывает создание виртуального коммутатора для соединения удаленных физических ethernet сетей.
    2008-06-08, littlesavage
    SiS*Mirage*1 на D201GLY2

    Как заставить работать видеоrарту SiS*Mirage*1 на материнской D201GLY2
    2008-06-06, nsand
    Рыбалка на FreeBSD

    Стьатья о том как настроить рыбалку со спутника под FreeBSD
    2008-06-06, nsand
    TT budget S-1401

    Настройка драйвера ttbudget (SkyStar3) под FreeBSD
    2008-05-30, Andy2k
    NOD32 mirror

    Скрипт для создания зеркала обновлений для антивируса NOD. Автоматически ищет нужные логин-пароль для получения обновлений. В теории не требует обслуживания.
    2008-05-25, Romzes
    метаданные exif

    Пример сортировки фотографий сделаных разными фотоаппаратами, с разными названиями, датами создания/модификации. Из под консоли, конечно.
    2008-05-23, FenX
    svn+apache+trac

    Установка связки Apache2.2 + Subversion + Trac (Установка и настройка SVN сервера с доступом к репозиториям по http протоколу)
    2008-05-22, Grishun_U_S
    простой конфиг PF

    В статье разбирается простой конфигурационный файл pf "изнутри можно все"
    2008-05-20, KrivoSoft
    HAVP

    HAVP(HTTP AntiVirus proxy)- работает как http прокси, проверяющий файлики используя LibClamav. В заметке описан процес прикручивания антивируса к уже работающему прокси серверу squid.
    2008-05-20, Covax
    ALTQ в IPFW

    Исполльзование ALTQ вместе с IPFW
    2008-05-19, nonalog2007
    pppoe

    Настройка ADSL-модема для подключения к Интернет.
    2008-05-04, Abigor
    php + mssql

    Настройка php на freebsd для работы с базами в mssql по доменной авторизации.
    2008-04-28, serge
    i386=>amd64

    Рассматриваеться способ удаленной миграции с архитектуры i386 на amd64 на рабочем сервере.
    2008-04-24, Mr.Y
    Lan over Bluetooth

    Статья описывает как используя Bluetooth, объединить две FreeBSD машины в сеть.
    2008-04-19, lissyara
    WiFi WPA

    Подключение FreeBSD к беспроводной WiFi сети с использованием шифрования WPA.
    2008-04-18, nikll
    nginx+php-fpm+mysql

    Статья о настройке мощного веб сервера который не ляжет от хорошей нагрузки.
    2008-04-16, nikll
    qmail-ldap + AD

    Статья о том как я прикрутил qmail к АД win2003 (с упровлением почтовыми аккаунтами через консоль mmc из под винды)
    2008-04-14, SHPAk
    Приглашение csh/tcsh

    Приглашение csh/tcsh не всегда удобно. Здесь описано как помянять оное...
    2008-04-07, inspirra
    deltup, xdelta, bdelta

    Некоторые тонкости создания бинарных патчей. И использование "The dynamic deltup server network" для экономии на обновлениях исходников программ устанавливаемых из портов.
    2008-04-02, fr33man
    exim + cyrus-imapd

    Руководство по настройке почтовой системы на базе OpenBSD-4.2: exim + cyrus-imapd + mysql
    2008-03-30, Morty
    LiveCD (+restore)

    LiveCD, который развернет мне на жёсткий диск готовую настроенную систему
    2008-03-25, lissyara
    BlueTooth mouse

    Краткое повествование о том, как привернуть BlueTooth мышь к FreeBSD. Краткое - потому как делается это с полпинка...
    2008-03-21, moonug
    ProFTPD+iconv

    Порт позволяющий включить перекодировку имён файлов в proftpd. Раньше для этого был патч, а щас всё поломали =))
    2008-03-11, helloworld
    vsftpd + mysql

    Настройка фтп сервера vsftpd с пользователями из mysql
    2008-03-06, Raven2000
    Call of Duty 4

    Call of Duty 4: Modern Warfare — компьютерная игра, продолжение серии COD, разработанное студией Infinity Ward. Это первая игра в серии, действие которой происходит не во время мировой войны.
    2008-03-04, schizoid
    NeTAMS 2

    Netams, статистика, биллинг, огрнаичение и подсчет трафика
    2008-03-04, schizoid
    NeTAMS

    Программа для учета и управления сетевым трафиком
    2008-03-01, Le1
    EA Battlefield 2 server

    Установка игрового сервера EA Battlefield 2 под ОС FreeBSD
    2008-02-25, dikens3
    Dynamic DNS

    Свой сервер с динамическим IP-Адресом.
    2008-02-23, fr33man
    squid ntlm

    Настройка Squid с аутентификацией ntlm, под OpenBSD. Решение проблем сборки с поддержкой АД.
    2008-02-18, lissyara
    BlueTooth

    Встала задача залить на Нокию гиг музыки через BlueTooth. ОС - правильный - FreeBSD, вот про то как это сделать из под неё - и рассказ. Также немного про нынешнее состояние дел с голубыми зубами =)
    2008-02-17, Raven2000
    NFS & Win2k3

    При работе с UNIX системами на предприятиях часто приходится организовывать совместную работу с Windows. Необходимо обеспечить взаимодействие UNIX<>WIN бывает, что доступ по FTP или др не устраивает.
    2008-02-14, Morty
    Lightsquid

    Снятие статистики с OOPS, SQUID с помощью lightsquid - нечто на подобии SARGa, и выполняет туже задачу, подбивает статистику пользования прокси сервером
    2008-02-14, Morty
    OOPS

    Краткое описание установки и настройки прозрачного прокси-сервера OOPS
    2008-02-12, fr33man
    Apache

    Настройка web-сервера apache, на базе OpenBSD. Нужен был web сервер. Стандартно нужно было ставить apache. Но я помнил, когда раньше работал с OpenBSD, что апач поставляется вместе с системой. Так
    2008-02-11, Raven2000
    Установка OpenBSD

    OpenBSD — свободная многоплатформенная операционная система, основанная на 4.4BSD — BSD-реализации UNIX системы. Основным отличием OpenBSD от других свободных операционных систем, базирующихся на
    2008-01-31, serge
    ApacheStats

    Сбор статистики с веб-сервера Apache в Cacti с использованием модулей mod_status и mod_info. Отображается число хитов в секунду, загрузка чилдренов и прочая полезная инфа.
    2008-01-30, Raven2000
    CVSUP и софт через Proxy

    При работе за прокси люди испытывают неудобство при обновление портов и установки портов. Хотя, наверное, догадываются, что FreeBSD может элегантно обходить эти камни, но не знают как.
    2008-01-25, nikll
    kde и smb

    статья о том как фрю сделать членом win2003 домена и о том как в кде 3.5 ходить по доменным шарам с нормальной русской кодировкой
    2008-01-21, Fastman
    Создание программ на QT4/С++

    Установка и настройка QT4. Пример создание приложения с GUI.
    2008-01-17, Morty
    stunnel для pop3,smtp

    Создание защищенного подключения для сервисов POP3, SMTP, Imap , www с помощью stunnel
    2008-01-09, lissyara
    Atheros AR5007EG

    Прикручивание карточки Atheros AR5007EG (в ноутбуке Toshiba L40-139) под FreeBSD.
    2008-01-04, LMik
    growfs

    Статья наглядно описывает изменение размера раздела диска в FreeBSD при помощи growfs, без потери данных находящихся на диске.
    2007-12-23, serge
    FreeBSD на VDS

    Рассматривается настройка FreeBSD6.2 на VDS с чистой ОС.
    2007-12-22, serge
    OTRS на Apache1

    Рассматривается установка Open Ticket Request System для работы на хостинг сервере в связке apache1.3 + mod_perl + mysql50.
    2007-12-11, INFected
    SkyStar-2+SlonAx

    Встала задача организовать прием трафика от спутникового провайдера. Естественно на раздающем сервере должна быть FreeBSD. А как же иначе?
    2007-12-08, netcat
    GEOM-ELI

    Шифрование файловых систем посредством класса GEOM-ELI
    2007-12-07, helloworld
    PVPGN

    Настройка сервера Battle.net в небольшой локальной сети.
    2007-12-06, seacon
    ESET NOD32

    Описание настройки антивирусной системы NOD32 ESET File Security
    2007-11-23, azu
    Bluetooth proximity monitor

    Описание и скрипты для отслеживания удаленности bluetooth устройства.
    2007-11-19, catdog_
    verlihub (p2p)

    описывается, как установить, настроить p2p-сервер и как им управлять
    2007-11-14, UA
    OpenVPN

    руководство по настройке openvpn между FreeBSD и Windows
    2007-11-11, AlkoGekS
    atacontrol

    Проверка работы raid-1 с помощью штатной утилиты atacontrol на freebsd 6.2
    2007-11-08, Raven2000
    Transport Tycoon Deluxe

    Transport Tycoon Deluxe (сокращенно - TTD) - экономическая транспортная стратегия, в которой целью игрока является создание максимально доходной транспортной империи.
    2007-11-06, lissyara
    squid+AD

    Инструкция - как авторизовать пользователей в домене, разделив доступ к ресурсам по виндовым группам - кому куда можно, а кому нельзя, с использованием squid2.6. Ну и объяснение - почему пока не 3.0.
    2007-11-03, schizoid
    icecast2

    Вещание интернет радио в локальной сети с помощью icecast2
    2007-11-02, AlkoGekS
    RoundCube

    Возникла необходимость перевести пользователей с squirrelmail на roundcube, завязать все это хотелось на postgresql, чтобы и в ней разобратьс заодно.
    2007-10-30, SniZ
    queues

    Краткая заметка по использованию очередей В IPFW
    2007-10-29, s@sh@
    LACP и VLAN

    Описание настройки LACP отдельно и совместно с VLAN во FreeBSD 7.0
    2007-10-26, Al
    portaudit

    Эти приложение используется для контроля уязвимостей и обновления приложений, установленных из портов.
    2007-10-24, -cat-
    Заметки об IPFW

    Заметки о настройке IPFW, подключение IPFW и NATD, принцип взаимодействия, принципы построения правил IPFW.
    2007-10-23, Raven2000
    X-Bomber

    Представляю вниманию отличную аркаду которая скрасит наш быт и существование в офисном пространстве именуемая как "работа" И так прошу любить и жаловать X-Bomber
    2007-10-22, Raven2000
    TeamSpeak

    Teamspeak (тимспик) — семейство программ, предназначенных для общения голосом в сети. От классического телефона отличается практически неограниченным количеством абонентов, разговаривающих одноврем
    2007-10-22, RageLT
    Nginx+php+fcgi

    "Nginx + PHP + Spawn-fcgi" - установка nginx под FreeBSD и настройка для выполнения PHP скриптов.
    2007-10-20, dikens3
    UFS2

    Как устроена UFS2. Небольшой взгляд изнутри.
    2007-10-19, Al
    Nagios - мониторинг сети

    настройка мониторинга сети с использованием Nagios
    2007-10-19, BlackCat
    FFS из-под WinXP

    Описание програмки для чтения BSD разделов под Windows. К сожалению, диск подключается в режиме только чтения - но и это уже неплохо.
    2007-10-14, dikens3
    recovery files

    Восстановление файлов на FreeBSD с использованием foremost, sleuthkit, photorec. Немного теории о хранении файлов на диске.
    2007-10-05, lissyara
    ClamAV mirror

    Понадобилось создать внутри локальной сети зеркало обновлений ClamAV, c учётом того, что разработчики это не привтствуют - пришлось изобретать подпорки и велосипеды.
    2007-10-04, SeeD
    irc + services

    Установка irc сервера (unreailircd) + сервисов (anope) на FreeBSD 6.0. Приведён тот необходимый минимум, который вполне подойдет для одиночных серверов.
    2007-10-04, lissyara
    установка по сети

    Столкнувшись с невозможностью поставить FreeBSD на старенький ноут с CD-ROM (толи диск царапаный, толи чё), пришлось изгаляться с установкой по сети - благо на нём был PXE у встроенной сетевухи.
    2007-10-04, Al
    cups-samba на samba+AD

    Пример настройки сервера печати с использованием CUPS, Samba и AD. Пример установки и настройки клиентских (для винды) драйверов принтера на сервер с использованием порта cups-samba.
    2007-10-03, schizoid
    ipcalc

    Скрипт для вычисления широковещательного адреса, диапазон хостов, шаблон сетевой маски по полученному IP и сетевой маске. Может использоваться для конструирования сетей и подсетей, а также в обучающих
    2007-09-26, lissyara
    немного о ssh

    Краткое описание как пробросить порты с удалённой локальной сети на локальную машину при помощи ssh. Может быть полезным, когда нет VPN в удалённую сеть, а есть ssh, и нужен доступ к какому-то сервису
    2007-09-26, SniZ
    mod_ntlm2

    mod_ntlm2 - модуль для apache22, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к содержимому корпоротивного
    2007-09-18, lissyara
    klaptopdaemon

    даемон KDE для мониторинга состояния батареи ноутбука. Наверное, самое удобное и функциональное из того, что я перебрал.
    2007-09-17, bisyarin
    Удаленное разбиение HDD

    В статье рассмотрен пример удаленной доразбивки винчестера. Показан путь решения задачи как с использованием sysinstall, так и с помощью утилит fdisk, bsdlabel и newfs.
    2007-09-14, freeman_tnu
    DSL-G804V и FreeBSD 6.2

    Настройка VPN-туннеля между D-Link DSL-G804V и FreeBSD 6.2
    2007-09-13, lissyara
    KNemo

    Служба KDE отображающая в трее значка сетевого подключения, с богатым функционалом - позволяет собирать статистику, строить графики, выполнять скрипты при изменении статуса сетевого подключения.
    2007-09-12, lissyara
    desktopbsd-tools

    Набор утилит для упрощения жизни под KDE. Включают в себя утилиты трея для слежения за сетью, монтирования/ демонтирования, информацию о заряде батереи. Также несколько апплетов для контрольной панели
    2007-09-06, lissyara
    nettop

    Приложение позволяющее отслеживать сетевую активность по портам-протоколам, и отображать скорость передачи данных по этим портам и протоколам. Весьма удобно для наблюдения - что происходит на сервере.
    2007-09-04, squid
    sshd & AD

    Использование одной учетной записи на FreeBSD и Windows - используя AD для авторизации пользователей по ssh
    2007-09-02, lissyara
    ISPmanager

    Краткое описание того, как заменить дефолтовый майлер на ISPmanager, если он у вас - sendmail. Может пригодится тем кто берёт виртуальный сервер, и хочет большей гибкости в настройке.
    2007-08-25, serge
    mod_ntlm

    mod_ntlm - модуль для apache13, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к сайту.
    2007-08-15, lissyara
    colorize

    colorize - утилита для подсветки ключевых слов в просматриваемых логах. Весьма удобно - становится более понятно и доходчиво, тока временами слишком уж пёстро :)))
    2007-08-13, Raven2000
    Документация на Unix

    Здесь представляем список необходимой документации для чтения и полного освоения FreeBSD как основной серверной операционной системы. И не только ее.
    2007-08-06, lissyara
    QTFW

    Графический интерфейс для составления и редактирования правил файрволла IPFW - абсолютно бесполезная приблуда...
    2007-08-01, Raven2000
    Counter-Strike 1.6

    По просьбам трудящихся, точнее по их заявлениям, о том что нужна им Counter-Strike 1.6 хоть "убейся об стену". Решил разобраться, наконец, с этим вопросом, что и сделал. И так поехали. :)
    2007-07-31, f0s
    LDAP: samba, dns, dhcp

    Настраиваем PDC на самбе, все данные в LDAP. Попутно вешаем DDNS+DHCP - их данные тоже храним в LDAP.
    2007-07-27, lissyara
    root-tail

    Практически бесполезное, но довольно забавное приложение, показывающее логи на рабочем стол. Может пригодится лишь если на ваш десктоп логи передаются с удалённых хостов.
    2007-07-27, lissyara
    laptop battery

    Краткий обзор программ мониторинга состояния заряда батареи ноутбука - что можно использовать на FreeBSD7.0 (CURRENT) и AMD64.
    2007-07-24, Raven2000
    phpBB-2/3

    phpBB – это мощное, полностью масштабируемое и легко изменяемое программное обеспечение с открытым исходным кодом для создания конференций. Основанный на мощном языке PHP и имеющий поддержку серверов
    2007-07-23, lissyara
    apache 2.0

    Настройка WEB-сервера на apache2 и php в режиме CGI с использованием mod_fastcgi.
    2007-07-15, lissyara
    geom_uzip

    Создание образа сжатой ФС с загрузкой по сети - данный метод может использоваться для создания загрузочных дисков/сидюков и прочего - на машинах где мало оперативки, например...
    2007-07-06, bdmalex
    2 CD -> 1 DVD

    FreeBSD: Заменим 2 инсталляционных диска на 1 DVD.... чтобы коллекцию дисков уменьшить....
    2007-07-04, Andy
    NSPluginWrapper

    Перевод с французского очень хорошего мануала, досконально объясняющего, как инсталлировать линуксовые плугины для firefox, используя NSPluginWrapper. В том числе и 9-й flash.
    2007-07-01, lissyara
    sshit

    Перловый скрипт мониторящий попытки подбора паролей для ssh/ftp в режиме реального времени, и блокирующий атакующего используя файрволл - pf/ipfw/ipfw2 - просто и со вкусом :)
    2007-06-19, Raven2000
    CMS - TYPO3

    Ставим CMS TYРOЗ - Корпоративная система управления веб-контентом TYРOЗ — система управления сайтами (CMS/CMF) с открытым исходным кодом и свободной лицензией. Написана на PHP, для хранения данных...
    2007-06-15, lissyara
    SAMBA+ACL

    SAMBA + правка расширенных пермишенов (ACL) через виндовые галочки - полезно для передачи управления шарами на самбе виндовым админам, ничё кроме галок и не умеющим :)
    2007-06-13, roygbiv
    ntop 4.10

    Установка, настройка, оптимизация сетевого анализатора трафика ntop 4.1 stable с плагинами (в т.ч.SPAN-Sniffer и NetFlow) на FreeBSD 8.2 release. Описание nProbe.
    2007-06-09, Andy
    vsftpd

    перевод мана на vsftpd
    2007-06-04, lissyara
    exim + dovecot + win2003 AD

    Как заставить связку exim+dovecot использовать в качестве БД пользователей виндовый домен. Статья неполноценная - тока основные моменты и ссылки, где взять остальное. Скорее - просто заметка для себя.
    2007-05-30, lissyara
    exim + exchange

    Настройка релея на exim для сервера M$ exchange находящегося внутри локальной сети. Настройка перезаписи адресов локального домена на внешний.
    2007-05-13, Raven2000
    Бронированный FreeBSD

    Как и любую другую систему FreeBSD нужно так же защищать от посягательств на нее. Она не так уж защищена, как много людей о ней думают и ее можно так же сломать и крякнуть, как и тот же Windows.
    2007-05-12, alex3
    Печать из фри в винду

    Печать из FreeBSD на сетевой принтер виндов
    2007-05-03, Raven2000
    Десктоп c FreeBSD

    По просьбам трудящихся возьмусь за неблагодарную тему по одомашниванию FreeBSD.Начнем с одомашниванием консоли закончим русским KDE и настройками видео карт.
    2007-04-28, fr33man
    iPod

    Использование iPod во FreeBSD
    2007-04-25, lissyara
    AutoMount

    Как настроить автоматическое монтирование флэшек и CD-ROM в KDE. Заодно пришлось победить грабли с неверной русской кодировкой на флэшках.
    2007-04-24, Fastman
    Socket сервер на FreeBSD.

    Пишем tcp демона на С++ !
    2007-04-14, BAV_Lug
    ATSlog

    Ведение статистики звонков с офисной мини-АТС.
    2007-04-11, nk
    Backup MX

    Настройка fetchmail для сбора писем с сервера провайдера или резервного сервера и дальнейшая передача их локальному MTA
    2007-04-11, Raven2000
    Quake III Arena

    Представляю установку всеми любимого игро-мясо-экшена Quake III Arena именно так и никак не иначе! Будет чем заняться Васе и Пете (и отделу) во время работы, т.е. вместо нее :) И так Kill'em All!!
    подписка

        вверх      
    Статистика сайта
    Сейчас на сайте находится: 22 чел.
    За последние 30 мин было: 69 человек
    За сегодня было
    10379 показов,
    1791 уникальных IP
     

      Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
      Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

    © lissyara 2006-10-24 08:47 MSK

    Время генерации страницы 0.1312 секунд
    Из них PHP: 65%; SQL: 35%; Число SQL-запросов: 95 шт.
    Исходный размер: 613511; Сжатая: 96079