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

Все что не было явно пропущено в цепочке INPUT будет подвергнуто действию DROP, поскольку именно это действие назначено в качестве политики по-умолчанию. Политики по-умолчанию были описаны чуть выше в разделе Установка политик по-умолчанию.

Цепочка FORWARD содержит очень небольшое количество правил. Первое правило напрвляет все TCP пакеты на проверку в цепочку bad_tcp_packets, которая используется так же и в цепочке INPUT. Цепочка bad_tcp_packets сконструирована таким образом, что может вызываться из других цепочек, невзирая на то, куда направляется пакет. После проверки TCP пакетов, как обычно, мы разрешем движение пакетов из локальной сети без ограничений.

Далее, пропускается весь трафик из локальной сети без ограничений. Естественно, нужно пропустить ответные пакеты в локальную сеть, поэтому следующим правилом мы пропускаем все, что имеет признак ESTABLISHED или RELATED, т.е. мы пропускаем пакеты по соединению установленному ИЗ локальной сети.

И в заключение заносим в системный журнал информацию о сброшенных пакетах, предваряя их префиксом "IPT FORWARD packet died: ", чтобы потом, в случае поиска ошибок, не перепутать их с пакетами, сброшенными в цепочке INPUT.

Как я уже упоминал ранее, в моем случае компьютер используется как брандмауэр и одновременно как рабочая станция. Поэтому я позволяю покидать мой хост всему, что имеет исходный адрес $LOCALHOST_IP, $LAN_IP или $STATIC_IP. Сделано это для защиты от трафика, который может сфальсицировас моего компьютера, несмотря на то, что я совершенно уверен во всех, кто имеет к нему доступ. И в довершение ко всему, я журналирую «сброшенные» пакеты, на случай поиска ошибок или в целях выявления сфальсифицированных пакетов. Ко всем пакетам, не прошедшим ни одно из правил, применяется политика по-умолчанию – DROP.

В данном сценарии эта цепочка не имеет ни одного правила и единственно, почему я привожу ее описание здесь, это еще раз напомнить, что в данной цепочке выполняется преобразование сетевых адресов (DNAT) перед тем как пакеты попадут в цепочку INPUT или FORWARD.

ОСТОРОЖНО: Еще раз хочу напомнить, что эта цепочка не предназначена ни для какого вида фильтрации, а только для преобразования адресов, поскольку в эту цепочку попадает только первый пакет из потока.

И заключительный раздел – настройка SNAT. По крайней мере для меня. Прежде всего мы добавляем правило в таблицу nat, в цепочку POSTROUTING, которое производит преобразование исходных адресов всех пакетов, исходящих с интерфейса, подключенного к Internet. В сценарии определен ряд переменных, с помощью которых можно использовать для автоматической настройки сценария. Кроме того, использование переменных повышает удобочитаемость скриптов. Ключом -t задается имя таблицы, в данном случае nat. Команда -A добавляет (Add) новое правило в цепочку POSTROUTING, критерий -o $INET_IFACE задает исходящий интерфейс, и в конце правила задаем действие над пакетом – SNAT. Таким образом, все пакеты, подошедшие под заданный критерий будут «замаскированы», т.е. будут выглядеть так, как будто они отправлены с нашего узла. Не забудьте указать ключ –to-source с соответствующим IP адресом для исходящих пакетов

В этом сценарие я использую SNAT вместо MASQUERADE по ряду причин. Первая – предполагается, что этот сценарий должен работать на сетевом узле, который имеет постоянный IP адрес. Следующая состоит в том, что SNAT работает быстрее и более эффективно. Конечно, если вы не имеете постоянного IP адреса, то вы должны использовать действие MASQUERADE, которое предоставляет более простой способ трансляции адресов, поскольку оно автоматически определяет IP адрес, присвоенный заданному интерфейсу. Однако, по сравнению с SNAT это действие требует несколько больших вычислительных ресурсов, хотя и не значительно. Пример работы с MASQUERADE, вы найдете в сценарии rc.DHCP.firewall.txt.

Цель этой главы состоит в том, чтобы дать краткое описание каждого сценария, в этом руководстве. Эти сценарии не совершенны, и они не могут полностью соответствовать вашим нуждам. Это означает, что вы должны сами «подогнать» эти сценарии под себя. Последующая часть руководства призвана облегчить вам эту подгонку.

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

ПРИМЕЧАНИЕ: Обратите внимание на то, что эта структура может оказаться далеко неоптимальной для ваших сценариев. Эта структура выбрана лишь для лучшего объяснения хода моих мыслей.

Это – структура, которой следуют все сценарии в этом руководстве. Если вы обнаружите, что это не так, то скорее всего это моя ошибка, если конечно я не объяснил, почему я нарушил эту структуру.

1. Configuration – Прежде всего мы должны задать параметры конфигурации, для сценария. Параметры Конфигурации, в большинстве случаев, должны быть описаны первыми в любом сценарии.

1.1 Internet – Это раздел конфигурации, описывающей подключение к Internet. Этот раздел может быть опущен, если вы не подключены к Интернет. Обратите внимание, что может иметься большее количество подразделов чем, здесь перечислено, но только те, которые описывают наше подключение к Internet.

1.1.1 DHCP – Если имеются специфичные для DHCP настройки, то они добавляются здесь.

1.1.2 PPPoE – Описываются параметры настройки PPPoE подключения.

1.2 LAN – Если имеется любая ЛОКАЛЬНАЯ СЕТЬ за брандмауэром, то здесь указываются параметры, имеющие отношение к ней. Наиболее вероятно, что этот раздел будет присутствовать почти всегда.

1.3 DMZ – Здесь добавляется конфигурация зоны DMZ. В большинстве сценариев этого раздела не будет, т.к. любая нормальная домашняя сеть, или маленькая локальная сеть, не будет иметь ее. (DMZ – de-militarized zone. Скорее всего под это понятие автор подвел небольшую подсеть, в которой расположены серверы, например: DNS, MAIL, WEB и т.п, и нет ни одной пользовательской машины. прим. перев.)

1.4 Localhost – Эти параметры принадлежат нашему брандмауэру (localhost). В вашем случае эти переменные вряд ли изменятся, но, тем не менее, я создал эти переменные.Хотелось бы надеяться, что у вас не будет причин изменять эти переменные.

1.5 iptables – Этот раздел содержит информацию об iptables. В большинстве сценариев достаточно будет только одной переменной, которая указывает путь к iptables.