"Oskar Andreasson. Iptables Tutorial 1.1.19 " - читать интересную книгу автора

Проблема решается довольно просто с помощью SNAT. Ниже приводится
правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер
передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.
iptables -t nat -A POSTROUTING -p tcp -dst $HTTP_IP -dport 80 -j SNAT
\ -to-source $LAN_IP
Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому
моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий
строится на базе адреса назначения $HTTP_IP.
Если вы думаете, что на этом можно остановиться, то вы ошибаетесь!
Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр.
Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80
самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему,
добавим правило:
iptables -t nat -A OUTPUT -dst $INET_IP -p tcp -dport 80 -j DNAT
\ -to-destination $HTTP_IP
Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно
возникать.

ПРИМЕЧАНИЕ: Каждый должен понять, что эти правила предназначены только
лишь для корректной обработки адресации пакетов. В дополнение к этим
правилам вам может потребоваться написать дополнительные правила для цепочки
FORWARD таблицы filter. Не забудьте при этом, что пакеты уже прошли цепочку
PREROUTING и поэтому их адреса назначения уже изменены действием DNAT.

6.5.3. Действие DROP

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

6.5.4. Действие LOG

LOG - действие, которое служит для журналирования отдельных пакетов и
событий. В журнал могут заноситься заголовки IP пакетов и другая
интересующая вас информация. Информация из журнала может быть затем
прочитана с помощью dmesg или syslogd либо с помощью других программ.
Превосходное средство для отладки ваших правил. Неплохо было бы на период
отладки правил вместо действия DROP использовать действие LOG, чтобы до
конца убедиться, что ваш брандмауэр работает безупречно. Обратите ваше
внимание так же на действие ULOG, которое наверняка заинтересует вас своими
возможностями, поскольку позволяет выполнять запись журналируемой информации
не в системный журнал, а в базу данных MySQL и т.п..

ПРИМЕЧАНИЕ: Обратите внимание - если у вас имеются проблемы с записью в
системный журнал, то это проблемы не iptables или netfilter, а syslogd. За