Записки старого админа

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

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

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

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

Теперь описываю по пунктам:
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

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