B.4. Поставщики услуг Internet, использующие зарезервированные IP-адреса
Я добавил этот раздел чтобы предупредить вас о туповатых провайдерах (Internet Service Providers), которые назначают IP адреса, отведенные IANA для локальных сетей. Например, Swedish Internet Service Provider и телефонная монополия Telia используют такие адреса для своих серверов DNS (диапазон 10.x.x.x). Проблема, с которой вы будете наиболее вероятно сталкиваться, состоит в том, что мы, в своих сценариях, блокируем подключения с любых IP в диапазоне 10.x.x.x, из-за возможности фальсификации пакетов. Если вы столкнетесь с такой ситуацией, то наверное вам придется снять часть правил. Или установить правила, пропускающие траффик с этих серверов, ранее цепочки INPUT, например так:
/usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s \ 10.0.0.1/32 -j ACCEPT
Хотелось бы напомнить подобным провайдерам, что эти диапазоны адресов не предназначены для использования в Интернет. Для корпоративных сетей – пожалуйста, для ваших собственных домашних сетей – прекрасно! Но вы не должны вынуждать нас «открываться» по вашей прихоти.
B.5. Как разрешить прохождение DHCP запросов через iptables
В действительности, эта задача достаточно проста, если вам известны принципы работы протокола DHCP. Прежде всего необходимо знать, что DHCP работает по протоколу UDP. Следовательно, протокол является первым критерием. Далее, необходимо уточнить интерфейс, например, если DHCP запросы идут через $LAN_IFACE, то движение запросов DHCP следует разрешить только через этот интерфейс. И наконец, чтобы сделать правило более определенным, следует уточнить порты. DHCP использует порты 67 и 68. Таким образом, искомое правило может выглядеть следующим образом:
$IPTABLES -I INPUT -i $LAN_IFACE -p udp –dport 67:68 –sport \ 67:68 -j ACCEPT
Обратите внимание, это правило пропускает весь трафик по протоколу UDP через порты 67 и 68, однако это не должно вас особенно смущать, поскольку оно разрешает лишь движение запросов от узлов сети, пытающихся установить соединение с портами 67 и 68. Этого правила вполне достаточно, чтобы позволить выполнение DHCP запросов и при этом не слишком широко «открыть ворота». Если вас очень беспокоит проблема безопасности, то вы вполне можете ужесточить это правило.
B.6. Проблемы mIRC DCC
mIRC использует специфичные настройки, которые позволяют соединяться через брандмауэр и обрабатывать DCC соединения должным образом. Если эти настройки используются совместно с iptables, точнее с модулями ip_conntrack_irc и ip_nat_irc, то эта связка просто не будет работать. Проблема заключается в том, что mIRC автоматически выполняет трансляцию сетевых адресов (NAT) внутри пакетов. В результате, когда пакет попадает в iptables, она просто не знает, что с ним делать. mIRC не ожидает, что брандмауэр будет настолько «умным», чтобы корректно обрабатывать IRC, и поэтому самостоятельно запрашивает свой IP у сервера и затем подставляет его, при передаче DCC запроса.
Включение опции «I am behind a firewall» («Я за брандмауэром») и использование модулей ip_conntrack_irc и ip_nat_irc приводит к тому, что netfilter пишет в системный журнал сообщение «Forged DCC send packet».
У этой проблемы есть простое решение – отключите эту опцию в mIRC и позвольте iptables выполнять всю работу.
Приложение C. Типы ICMP
Это полный список типов ICMP сообщений:
Таблица C-1. ICMP types
(Тип – Код – Описание – Запрос – Ошибка)
Тип: 0
Код: 0
Описание : Echo Reply
Запрос: x
Ошибка: -
Тип: 3
Код: 0
Описание : Network Unreachable
Запрос: -
Ошибка: x
Тип: 3
Код: 1
Описание : Host Unreachable
Запрос: -
Ошибка: x
Тип: 3
Код: 2
Описание : Protocol Unreachable
Запрос: -
Ошибка: x
Тип: 3
Код: 3
Описание : Port Unreachable
Запрос: -
Ошибка: x
Тип: 3
Код: 4
Описание : Fragmentation needed but no frag. bit set
Запрос: -
Ошибка: x
Тип: 3
Код: 5
Описание : Source routing failed
Запрос: -
Ошибка: x
Тип: 3