Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

• Название: Linux Advanced Routing & Traffic Control HOWTO
• Автор: Bert Hubert
• Жанр: Программное обеспечение

Оригинальную версию документа вы найдете по адресу http://lartc.org/.

Практическое руководство по применению iproute2 (и в меньшей степени netfilter) для управления трафиком.

---

# 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).