Linux Advanced Routing & Traffic Control HOWTO
Шрифт:
13.1. Reverse Path Filtering.
Reverse Path Filtering — Проверка Обратного Адреса, хотя это слишком вольный перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев.
По-умолчанию, маршрутизаторы перенаправляют все подряд, даже пакеты, которые не принадлежат вашей сети. В качестве примера можно привести утечку локального трафика в Интернет. Если у вас имеется интерфейс с маршрутом к нему 195.96.96.0/24, то вы наверняка не ожидаете получить на него пакеты от 212.64.94.1.
В файловой системе /proc лежит файл, изменив который вы сможете отключить или включить эту
Следующий фрагмент включит проверку исходящего адреса для всех существующих интерфейсов:
Возвращаясь к примеру выше: пусть имеется маршрутизатор, построенный на базе Linux, который обслуживает две подсети — net1 и net2, причем net1 подключена к интерфейсу eth0, а net2 — к интерфейсу eth1. Теперь, если на eth0, придет пакет с обратным адресом net2, то он будет сброшен. Аналогичным образом будет отвергнут пакет, с обратным адресом net1, пришедший на интерфейс eth1.
Это есть полная проверка обратного адреса. Но такая фильтрация возможна только на основе анализа IP-адресов сетей связанных напрямую маршрутизатором. Это потому, что полная фильтрация становится невозможной в случае асимметричной маршрутизации (когда пакеты приходят через один интерфейс, а ответный трафик через другой), например через спутник (или в случае динамической маршрутизации (bgp, ospf, rip) в вашей сети), когда данные поступают со спутниковой антенны, а ответы отправляются по обычной наземной линии связи.
Если у вас как раз такой случай (вы наверняка точно знаете об этом), то можете просто выключить rp_filter на интерфейсе, куда приходят данные со спутника. Если вам интересно узнать — сбрасываются ли какие-нибудь пакеты, файл log_martians, в том же самом каталоге, сообщит ядру о необходимости журналирования таких пакетов.
FIXME: достаточно ли настроек в файлах conf/[default,all]/* ? — martijn
13.2. Малоизвестные настройки.
Итак, имеется целый ряд дополнительных настроек, которые вы можете изменить. Попробуем их перечислить. Кроме того, они частично описаны в файле Documentation/ip-sysctl.txt.
Некоторым из этих параметров присвоены такие значения по умолчанию, которые напрямую зависят от того как вы сконфигурировали свое ядро.
Оскар Андриссон (Oskar Andreasson) написал руководство, в котором значительно лучше нас описал все эти настройки, так что не поленитесь — загляните на(Русский перевод руководства "ipsysctl tutorial", о котором идет речь, вы найдете по адресу:тарболл с исходными текстами документа (на русском языке) — 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, написанного Алексеем Кузнецовым <kuznet@ms2.inr.ac.ru> и Энди Клином (Andi Kleen) <ak@muc.de>.
От переводчика (А.К.): Я взял на себя смелость привести описание части параметров из "ipsysctl tutorial" , поскольку они более точные и полные.
Если ядро решит, что оно не в состоянии доставить пакет, то пакет будет сброшен, а отправителю будет послано соответствующее ICMP-сообщение.
Параметр может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 0 (выключено). Если записана 1, то ядро просто игнорирует все ICMP Echo Request запросы и тогда никто не сможет ping– ануть вашу машину, чтобы проверить ее наличие в сети, что само по себе не есть хорошо. Однако, у каждого из нас может быть свое собственное мнение по поводу этой опции. С одной стороны — окружающие лишены возможности проверить ваше присутствие в сети, с другой — существует масса приложений, которые используют ICMP Echo Request запросы далеко не в благовидных целях. Вобщем все как всегда — что-то плохо, а что-то хорошо.
Эта переменная очень близка по смыслу к icmp_echo_ignore_all, только в данном случае будут игнорироваться ICMP-сообщения, отправленные на широковещательный или групповой адрес. Вполне очевидно, почему полезно включить этот параметр — защита от smurf атак.
Частота генерации эхо-ответов, посылаемых по любому адресу.
Отдельные маршрутизаторы, вопреки стандартам, описанным в RFC 1122, отправляют фиктивные ответы в широковещательном диапазоне. Обычно эти ошибки заносятся в системный журнал. Если вы не желаете регистрировать их, то включите этот параметр и тем самым сбережете некоторый объем дискового пространства в своей системе. Параметр может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 0 (выключено)
Относительно малоизвестное ICMP-сообщение, которое посылается в ответ на неправильные пакеты с искаженными IP или TCP заголовками. Этот параметр регулирует частоту генерации подобных сообщений.
Ограничивает частоту генерации сообщений ICMP Time Exceeded.
От переводчика (А.К.): По поводу двух предыдущих параметров (icmp_paramprob_rate и icmp_timeexceed_rate) у меня есть большие сомнения в том, что они присутствуют в файловой системе /proc. Вероятно в более ранних версиях ядра (до 2.4) эти параметры присутствовали, но у себя я их не нашел, зато имеются два других параметра, которые обеспечивают данную функциональность.