Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32
match ip protocol 41 0xff
match u8 0x05 0x0f at 0
match u8 0x20 0xff at 28
match u8 0x01 0xff at 29
flowid 10:13
Глава 13. Параметры настройки сети в ядре.
В ядре имеется масса параметров, которые могут быть изменены под различные нужды. Хотя, заданные по-умолчанию параметры удовлетворяют потребности в 99% случаев, но не зря же мы назвали это руководство Advanced HOWTO!
Очень интересные настройки вы найдете в /proc/sys/net , загляните туда. Конечно же, изначально не все тонкости будут описаны здесь, но мы работаем над этим.
Между прочим, значительная часть настроек описана в файле Documentation/filesystems/proc.txt, в дереве каталогов с исходными текстами ядра.
13.1. Reverse Path Filtering.
Reverse Path Filtering — Проверка Обратного Адреса, хотя это слишком вольный перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев.
По-умолчанию, маршрутизаторы перенаправляют все подряд, даже пакеты, которые не принадлежат вашей сети. В качестве примера можно привести утечку локального трафика в Интернет. Если у вас имеется интерфейс с маршрутом к нему 195.96.96.0/24, то вы наверняка не ожидаете получить на него пакеты от 212.64.94.1.
В файловой системе /proc лежит файл, изменив который вы сможете отключить или включить эту проверку. Смысл этого параметра достаточно прост – все, что поступает к нам, проходит проверку на соответствие исходящего адреса с нашей таблицей маршрутизации и такая проверка считается успешной, если принятый пакет предполагает передачу ответа через тот же самый интерфейс.
Следующий фрагмент включит проверку исходящего адреса для всех существующих интерфейсов:
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
> echo 2 > $i
> done
Возвращаясь к примеру выше: пусть имеется маршрутизатор, построенный на базе Linux, который обслуживает две подсети — net1 и net2, причем net1 подключена к интерфейсу eth0, а net2 — к интерфейсу eth1. Теперь, если на eth0, придет пакет с обратным адресом net2, то он будет сброшен. Аналогичным образом будет отвергнут пакет, с обратным адресом net1, пришедший на интерфейс eth1.
Это есть полная проверка обратного адреса. Но такая фильтрация возможна только на основе анализа IP-адресов сетей связанных напрямую маршрутизатором. Это потому, что полная фильтрация становится невозможной в случае асимметричной маршрутизации (когда пакеты приходят через один интерфейс, а ответный трафик через другой), например через спутник (или в случае динамической маршрутизации (bgp, ospf, rip) в вашей сети), когда данные поступают со спутниковой антенны, а ответы отправляются по обычной наземной линии связи.
Если у вас как раз такой случай (вы наверняка точно знаете об этом), то можете просто выключить rp_filter на интерфейсе, куда приходят данные со спутника. Если вам интересно узнать — сбрасываются ли какие-нибудь пакеты, файл log_martians, в том же самом каталоге, сообщит ядру о необходимости журналирования таких пакетов.
# echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians
FIXME: достаточно ли настроек в файлах conf/[default,all]/* ? — martijn
13.2. Малоизвестные настройки.
Итак, имеется целый ряд дополнительных настроек, которые вы можете изменить. Попробуем их перечислить. Кроме того, они частично описаны в файле Documentation/ip-sysctl.txt.
Некоторым из этих параметров присвоены такие значения по умолчанию, которые напрямую зависят от того как вы сконфигурировали свое ядро.
Оскар Андриссон (Oskar Andreasson) написал руководство, в котором значительно лучше нас описал все эти настройки, так что не поленитесь — загляните на http://ipsysctl-tutorial.frozentux.net/. (Русский перевод руководства "ipsysctl tutorial", о котором идет речь, вы найдете по адресу: http://gazette.linux.ru.net/rus/article/index-ipsysctl-tutorial.html, тарболл с исходными текстами документа (на русском языке) — http://gazette.linux.ru.net/archive/ipsysctl-tutorial.1.0.4.tar.gz.
13.2.1. Параметры настройки IPv4.
Небольшое примечание: в большинстве своем, приводимые здесь временные параметры не воздействуют на локальный (loopback) интерфейс, так что вы не сможете проверить их, не имея реального сетевого интерфейса. Кроме того, указываемые пределы измеряются в 'тиках', и предполагают использование ранее упомянутого Token Bucket Filter.
Некоторые пункты, из приводимого ниже списка, мы просто скопировали из /usr/src/linux/Documentation/networking/ip-sysctl.txt, написанного Алексеем Кузнецовым < [email protected]> и Энди Клином (Andi Kleen) < [email protected]>.
От переводчика (А.К.): Я взял на себя смелость привести описание части параметров из "ipsysctl tutorial" , поскольку они более точные и полные.
/proc/sys/net/ipv4/icmp_destunreach_rate
Если ядро решит, что оно не в состоянии доставить пакет, то пакет будет сброшен, а отправителю будет послано соответствующее ICMP-сообщение.
/proc/sys/net/ipv4/icmp_echo_ignore_all
Параметр может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 0 (выключено). Если записана 1, то ядро просто игнорирует все ICMP Echo Request запросы и тогда никто не сможет ping-ануть вашу машину, чтобы проверить ее наличие в сети, что само по себе не есть хорошо. Однако, у каждого из нас может быть свое собственное мнение по поводу этой опции. С одной стороны — окружающие лишены возможности проверить ваше присутствие в сети, с другой — существует масса приложений, которые используют ICMP Echo Request запросы далеко не в благовидных целях. Вобщем все как всегда — что-то плохо, а что-то хорошо.
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Эта переменная очень близка по смыслу к icmp_echo_ignore_all, только в данном случае будут игнорироваться ICMP-сообщения, отправленные на широковещательный или групповой адрес. Вполне очевидно, почему полезно включить этот параметр — защита от smurf атак.
/proc/sys/net/ipv4/icmp_echoreply_rate
Частота генерации эхо-ответов, посылаемых по любому адресу.
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
Отдельные маршрутизаторы, вопреки стандартам, описанным в RFC 1122, отправляют фиктивные ответы в широковещательном диапазоне. Обычно эти ошибки заносятся в системный журнал. Если вы не желаете регистрировать их, то включите этот параметр и тем самым сбережете некоторый объем дискового пространства в своей системе. Параметр может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 0 (выключено)
/proc/sys/net/ipv4/icmp_paramprob_rate
Относительно малоизвестное ICMP-сообщение, которое посылается в ответ на неправильные пакеты с искаженными IP или TCP заголовками. Этот параметр регулирует частоту генерации подобных сообщений.
/proc/sys/net/ipv4/icmp_timeexceed_rate
Ограничивает частоту генерации сообщений ICMP Time Exceeded.
От переводчика (А.К.): По поводу двух предыдущих параметров (icmp_paramprob_rate и icmp_timeexceed_rate) у меня есть большие сомнения в том, что они присутствуют в файловой системе /proc. Вероятно в более ранних версиях ядра (до 2.4) эти параметры присутствовали, но у себя я их не нашел, зато имеются два других параметра, которые обеспечивают данную функциональность.
icmp_ratelimit
Максимальная частота генерации ICMP-пакетов с типом, указанным в icmp_ratemask (см. ниже). Это значение задается в "тиках" и устанавливает временной интервал между ICMP-посылками. Таким образом, значение 0 означает отсутствие ограничений. Обычно 1 "тик" равен 0.01 секунды, так значение 1 в этой переменной ограничивает скорость передачи не более 100 посылок в секунду, а значение 100 – не более 1 посылки в секунду. Значение по-умолчанию – 100 (зависит от конфигурации ядра), что означает не более 1 ICMP посылки за интервал в 100 "тиков".
icmp_ratemask
Маска ICMP типов, на которые накладывается ограничение по частоте генерации переменной icmp_ratelimit. Каждый из ICMP типов маскируется своим битом.
icmp_ratemask – это битовая маска, где каждый ICMP тип представлен своим битом. Соответствие между символическим названием ICMP типа и его порядковым номером вы найдете в заголовочном файле netinet/ip_icmp.h (обычно это /usr/include/netinet/ip_icmp.h). За дополнительной информацией обращайтесь к RFC 792 — Internet Control Message Protocol. Математически маска определяется так:
ratemask = SUM 2^n
где n принимает значения всех типов ICMP, которые должны быть ограничены.
Например: Ограничим передачу сообщений ICMP Destination Unreachable. В /usr/include/netinet/ip_icmp.h этому типу соответствует число 3. Подсчитаем значение 2**3, это будет число 8. Теперь нужно прибавить это число к имеющейся битовой маске. Допустим, что маска уже равна числу 6160 (в двоичном виде 0001100000010000), тогда результирующая маска получится: 6160 + 8 = 6168 (в двоичном виде 0001100000011000).
