Не так давно пришлось очень долго объяснять знакомому, как настроивать IPFW.

И вот у меня родилась идея нарисовать структурную схему прохождения пакетов и описать парочку правил ipfw для примера.

Первым делом, представляю к вашему вниманию схему нарисованную мной в MS VISIO.

PS. Имейте ввиду, что для наглядности я описываю ситуацию, когда пакет который входит на интерфейс rl0 должен выйти в интерфейсе rl1. Обратный вариант не описывается, хотя там ничего сложного, всё тоже, но только в обратном порядке.

ipfw схема

Теперь описываю по пунктам:
1. Входящий интерфейс, в нашем случае — это rl0;
2. Логический уровень обработки пакета;
3,4. Логический уровень обработки пакета, здесь рещается что делать с пакетом — оставить в системе или перенаправить его дальше;
5. Пакет принимает атрибут исходящего или локального и движется по направлению заданного в 3 и 4 пунктах.
6. Исходящий интерфейс, в нашем случае — это rl1.

Теперь теория:

В точке 1, обработчик (input) 2, получает пакет от драйвера сетевой карты rl0. Обработчик записывает соответствующую информацию у себя и пакет получает дополнительную метку «входящий» а также «входящий интерфейс rl0».

После этого, обработчик 2, передаёт пакет далее на узел 3 или 4, в зависимости от того под какое правило он попадает, и в этот момент пакет получает атрибут «in» (входящий), via rl0 (прошедший через интерфейс rl0) и recv rl0 (полученый через rl0).

После чего идёт обработка правил 3,4 и если пакет который зашёл к нам предназначен машинке на которой он уже, то ему назначается атрибут (локальный) 3 и он передаётся на обработчик более высокого уровня и достигает цели.

А если пакет предназначен другому узлу 4, находящегося за интерфейсом rl1, то в этот момент пакет получает атрибут (исходящий на интерфейс) и пакет передается на растерзание обработчику 5.

Попавший пакет в данный обработчик 5, теряет атрибут «in» и дописывает пакету атрибут «out», но при этом все остальные данные, включая входящий интерфейс всё ещё сохраняются. При этом пакет имеет такой вид: recv rl0, xmit rl1, via rl0, via rl1.

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

Также, пакеты которые выходят с этой машинки и не заходящие через интерфейс rl0, сразу попадают в 5 и имеет только исходящие атрибуты.
Исходя из вышесказанного, понятно что пакеты предназначенные данной машине, не имеют исходящих атрибутов, именно поэтому при написании правил для IPFW нельзя использовать одновременно recv и xmit в одном правиле. А для более высокой надёжности необходимо комбинировать условия in и recv, out и xmit.

Теперь немного практики:
Представим сеть из 2х ПК и одного сервера с FreeBSD через который проходят все пакеты в одну сторону. Например это smtp трафик на 25м порту. Сервер имеет две карточки rl0, rl1 и туннель tun0 для интернета. Smtp трафик должен войти в интерфейс rl0 и выйти в карточку rl1, не глядя на то — что маршрут по умолчанию через tun0.
Подсеть на интерфейсе rl0 — 10.10.1.0/24, на интерфейсе rl1 — 192.15.46.0/24 и на туннеле tun0 всё время динамический IP-адрес.
Наша задача, завернуть пакет с портом 25, входящий в rl0 интерфейс на подсеть, а точнее на шлюз 192.15.46.1/32, что бы тот уже решал что с ним делать дальше.

Реализуется это несколькими вариациями ipfw правил, парочку из которых я и приведу здесь.

ipfw add 1 allow tcp from any 25 to any recv rl0 out via rl1
ipfw add 2 fwd 192.15.46.1 tcp from 10.10.1.0/24 25 to any recv rl0
ipfw add 3 fwd 192.15.46.1 tcp from any 25 to any in via rl0
ipfw add 4 fwd 192.15.46.1 tcp from any 25 to any recv rl0
ipfw add 5 deny tcp from any 25 to any xmit tun0 in via rl0

Этим набором правил, мы решили нашу задачу. Обратите внимание на 2,3 и 4тое правило, в принципе достаточно одного из них, я специально написал их три, всё зависит от конкретно поставленной задачи.
2е правило звучит так, перенаправить все пакеты с подсети 10.10.1.0/24 и 25 портом на узел 192.15.46.1 прошедшие через интерфейс rl0.
3е правило звучит так, перенаправить все пакеты с 25 портом на узел 192.15.46.1 вошедшие через интерфейс rl0.
4е правило, по сути такое же как и второе, только не для подсети, а для любых пакетов.
5м правилом мы запрещаем выходить в туннель tun0 всем пакетам с 25м портом и вошедшим через интерфейс rl0.

Также хотел отметить практическое применение правил для ipfw.

Движение пакетов в интерфейсах:

in и out - отношение к направлению движения пакета в операционной системе с ipfw.
recv, xmit, via - а это отношение к интерфейсу в ipfw.

Теперь немного подробнее:

1) recv - интерфейс получил пакет;
2) xmit - интерфейс передал пакет;
3) via - прошел через интерфейс неважно в какую сторону.

Попробуем сообразить несколько правил для пакета:

out recv re0 - исходящий пакет, полученный re0 интерфейсом 
out xmit re0 - исходящий пакет, отправленный re0 интерфейсом 
in recv re0 - входящий пакет, полученный с интерфейса re0
Утверждение: in xmit rl0 - входящий пакет, отправленный rl0 интерфейсом - неверное.
При его использовании ipfw вызовет ошибку.

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

out recv re0 xmit rl0 - исходящий пакет, полученный через re0 и отправленный через rl0.

Также при написании правил, можно использовать «псевдонимы», то есть по разному написанные правила, но имеющие один результат при выполнении:

out via = out xmit  
in via = in recv

Надеюсь что материал изложен понятно.. Пользуйтесь.

Напоминаю всем копирующим мой контент о существовании закона "Об авторском праве".
В связи с этим, прошу во избежании конфликтов при копировании данного материала, ставить на него ссылку:

http://noted.org.ua/?p=804


Также, вы можете отблагодарить меня переслав любую сумму на любой кошелек WebMoney, для поддержания данного ресурса. Или просто админу на пиво ;)

Кошельки для получения благодарности:
R386985788805
U234140473141
Z147712360455

На данной странице нет комментариев, возможно они закрыты. Если Вы хотите оставить свой комментарий, перейдите на специально созданный раздел

Add your comment now

You must be logged in to post a comment.