From 746e60a6d31dc245995e0657d62fc2ede2d69c09 Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 7 Aug 2007 19:17:40 +0000 Subject: [PATCH] Updated Russian translations git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7080 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- docs/MultiISP_ru.xml | 528 +++++++++++++------------------ docs/blacklisting_support_ru.xml | 130 +++----- 2 files changed, 259 insertions(+), 399 deletions(-) diff --git a/docs/MultiISP_ru.xml b/docs/MultiISP_ru.xml index d5e1d9761..5bc6294da 100644 --- a/docs/MultiISP_ru.xml +++ b/docs/MultiISP_ru.xml @@ -1,18 +1,15 @@ - +
- Shorewall и подключение к Internet по нескольким каналам + Shorewall и подключение к Internet по нескольким каналам - - Tom + Tom - Eastep - + Eastep @@ -22,38 +19,34 @@ 2006 + 2007 + Thomas M. Eastep + 2007 Russian Translation: Grigory Mokhin + - Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии -1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке -GNU Free Documentation - License. + Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License. - Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. -Если вы проигнорируете этот совет, то -не рассчитывайте, что кто-либо сможет вам помочь. -. + Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. Если вы проигнорируете этот совет, то не рассчитывайте, что кто-либо сможет вам помочь.. - Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). -Скорее всего вам потребуется обратиться к следующим дополнительным источникам: + Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). Скорее всего вам потребуется обратиться к следующим дополнительным источникам: - LARTC HOWTO: http://www.lartc.org + LARTC HOWTO: http://www.lartc.org @@ -61,124 +54,91 @@ - Вывод команд ip route help и ip rule - help + Вывод команд ip route help и ip rule help -
- Поддержка нескольких соединений с Internet +
+ Поддержка нескольких соединений с Internet - Начиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. -Ниже описаны существующие ограничения: - + Начиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. Ниже описаны существующие ограничения: - Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером. - + Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером. - Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске -и при перезапуске Shorewall (если не указана опция "-n" для - shorewall restart). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию. - + Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске и при перезапуске Shorewall (если не указана опция "-n" для shorewall restart). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию. - В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд -shorewall - stop, shorewall clear или shorewall restart. + В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд shorewall stop, shorewall clear или shorewall restart. -
- Обзор +
+ Обзор - Предположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам ethernet, как показано на рисунке. - + Предположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам Ethernet, как показано на рисунке. - + - eth0 подключен к ISP1. IP-адрес eth0 - это - 206.124.146.176, и шлюз провайдера имеет IP-адрес - 206.124.146.254. + eth0 подключен к ISP1. IP-адрес eth0 - это 206.124.146.176, и шлюз провайдера имеет IP-адрес 206.124.146.254. - eth1 подключен к ISP2. IP-адрес eth1 - это - 130.252.99.27, и шлюз провайдера имеет IP-адрес - 130.252.99.254. + eth1 подключен к ISP2. IP-адрес eth1 - это 130.252.99.27, и шлюз провайдера имеет IP-адрес 130.252.99.254. - eth2 подключен к локальной сети. У него может быть любой IP-адрес. - + eth2 подключен к локальной сети. У него может быть любой IP-адрес. Все эти провайдеры должны быть перечислены в файле /etc/shorewall/providers. - В записях в файле /etc/shorewall/providers можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. -В записях в файле /etc/shorewall/tcrules можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. - Правила в файле /etc/shorewall/tcrules необязательны для того, чтобы настройка -/etc/shorewall/providers работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки. - + В записях в файле /etc/shorewall/providers можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. В записях в файле /etc/shorewall/tcrules можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. Правила в файле /etc/shorewall/tcrules необязательны для того, чтобы настройка /etc/shorewall/providers работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки. - Если задать опцию track в файле -/etc/shorewall/providers, то соединения из -Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. -Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола. - + Если задать опцию track в файле /etc/shorewall/providers, то соединения из Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола. - Shorewall настраивает маршрутизацию и обновляет файл -/etc/iproute2/rt_tables , включая в него имена таблиц и их номера. - + Shorewall настраивает маршрутизацию и обновляет файл /etc/iproute2/rt_tables, включая в него имена таблиц и их номера. - При этом используются функции маркировки пакетов - для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле -/etc/shorewall/tcrules: + При этом используются функции маркировки пакетов для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле /etc/shorewall/tcrules: - Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее). + Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее). - Нельзя использовать опции SAVE или RESTORE. + Нельзя использовать опции SAVE или RESTORE. - Нельзя использовать маркировку соединений. + Нельзя использовать маркировку соединений. - Файл /etc/shorewall/providers может также использоваться в других сценариях маршрутизации. -В документации по работе с Squid приведены примеры. - + Файл /etc/shorewall/providers может также использоваться в других сценариях маршрутизации. В документации по работе с Squid приведены примеры.
-
- Файл /etc/shorewall/providers +
+ Файл /etc/shorewall/providers - Далее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение. - + Далее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение. NAME - Имя провайдера. Должно начинаться с буквы и состоять из букв и цифр. -Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера. - + Имя провайдера. Должно начинаться с буквы и состоять из букв и цифр. Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера. @@ -186,8 +146,7 @@ Internet будут автоматически маршрутизировать NUMBER - Число от 1 до 252. Оно будет номером таблицы маршрутизации для сгенерированной таблицы для этого провайдера. - + Число от 1 до 252. Оно будет номером таблицы маршрутизации для сгенерированной таблицы для этого провайдера. @@ -195,23 +154,17 @@ Internet будут автоматически маршрутизировать MARK - Метка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. -Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. - Метка должна быть целым числом от 1 до 255. + Метка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. Метка должна быть целым числом от 1 до 255. - Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле -/etc/shorewall/shorewall.conf. Это позволяет решить следующие задачи: - + Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле /etc/shorewall/shorewall.conf. Это позволяет решить следующие задачи: - Использовать метки пакетов для управления трафиком, при условии что эти метки присваиваются в цепочке FORWARD. + Использовать метки пакетов для управления трафиком, при условии что эти метки присваиваются в цепочке FORWARD. - Использовать значения меток > 255 для меток провайдера. -Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами). - + Использовать значения меток > 255 для меток провайдера. Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами). @@ -221,10 +174,7 @@ Shorewall также помечает этой меткой соединения DUPLICATE - Имя или номер таблицы маршрутизации, которая будет продублирована. -Можно указать 'main' или имя или номер ранее объявленного провайдера. -Для большинства приложений здесь достаточно будет указать 'main'. - + Имя или номер таблицы маршрутизации, которая будет продублирована. Можно указать 'main' или имя или номер ранее объявленного провайдера. Для большинства приложений здесь достаточно будет указать 'main'. @@ -232,7 +182,11 @@ Shorewall также помечает этой меткой соединения INTERFACE - Имя интерфейса канала связи с провайдером. + Имя интерфейса канала связи с провайдером. + + + В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу. + @@ -240,13 +194,11 @@ Shorewall также помечает этой меткой соединения GATEWAY - IP-адрес шлюза провайдера. + IP-адрес шлюза провайдера. - Здесь можно указать detect для автоматического определения IP-адреса шлюза. - + Здесь можно указать detect для автоматического определения IP-адреса шлюза. - Совет: "detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP. + Совет: "detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP. @@ -254,34 +206,25 @@ Shorewall также помечает этой меткой соединения OPTIONS - Список параметров через запятую, описанных ниже: + Список параметров через запятую, описанных ниже: track - Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс. - + Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс. - Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. -Вместе с 'track' всегда следует указывать опцию 'balance'. + Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. Вместе с 'track' всегда следует указывать опцию 'balance'. - Для работы с этой функцией ядро и - iptables должны поддерживать цель CONNMARK и сравнение connmark. - Расширение цели ROUTE не требуется. + Для работы с этой функцией ядро и iptables должны поддерживать цель CONNMARK и сравнение connmark. Расширение цели ROUTE не требуется. - В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда -shorewall - restore может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff. + В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда shorewall restore может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff. - Если используется файл -/etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика. - + Если используется файл /etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика. @@ -290,41 +233,20 @@ Shorewall также помечает этой меткой соединения balance - Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. -Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. -При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера. - + Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера. - По умолчанию всем провайдерам присваивается одинаковый вес (1). -Вес конкретного провайдера можно изменить опцией -balance с "=" и весом - (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. - + По умолчанию всем провайдерам присваивается одинаковый вес (1). Вес конкретного провайдера можно изменить опцией balance с "=" и весом (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. - Если используется файл - /etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. С помощью записей в файле -/etc/shorewall/tcrules -можно принудительно направить трафик через конкретного провайдера. - Если вы проигнорируете этот совет, то прочитайте FAQ 57 и - FAQ 58. + Если файл /etc/shorewall/providers используется для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. Для направления всего трафика через какого-либо определенного провайдера можно использовать файл /etc/shorewall/tcrules. + Если вы проигнорируете этот совет, то прочитайте FAQ 57 и FAQ 58. - Если указана опция 'balance', но весь трафик по-прежнему идёт через одного провайдера, то причина этого может состоять в том, что ядро не собрано с опцией - CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. У некоторых пользователей пересборка ядра с этой опцией помогла устранить неполадку. - + Если указана опция 'balance', но весь трафик по-прежнему идёт через одного провайдера, то причина этого может состоять в том, что ядро не собрано с опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. У некоторых пользователей пересборка ядра с этой опцией помогла устранить неполадку. - Эта неполадка присутствует в ядре SuSE 10.0, и согласно - - в этом случае может возникать критическая ошибка ядра. - В SUSE 10.1 и SLES 10 опция - CONFIG_IP_ROUTE_MULTIPATH_CACHED=n включена по умолчанию. Источник неполадки описан здесь: -несовместимость между исправлениями от LARTC и опцией - CONFIG_IP_ROUTE_MULTIPATH_CACHED. + Эта неполадка присутствует в ядре SuSE 10.0, и согласно в этом случае может возникать критическая ошибка ядра. В SUSE 10.1 и SLES 10 опция CONFIG_IP_ROUTE_MULTIPATH_CACHED=n включена по умолчанию. Источник неполадки описан здесь: несовместимость между исправлениями от LARTC и опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED. @@ -333,9 +255,7 @@ Shorewall также помечает этой меткой соединения loose - Не включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. -Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. - + Не включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с balance. @@ -343,26 +263,20 @@ Shorewall также помечает этой меткой соединения optional (начиная с Shorewall 3.2.2) - Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. -Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен. - + Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен. - Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс. - + Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс. - Для тех, кто окончательно запутался в том, что такое track и balance: + Для тех, кто окончательно запутался в том, что такое track и balance: - track управляет входящими соединениями. - + track управляет входящими соединениями. @@ -376,95 +290,65 @@ Shorewall также помечает этой меткой соединения COPY - Если в поле DUPLICATE указана существующая таблица, - то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла. - + Если в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.
-
- Какие функции выполняет запись в файле providers +
+ Какие функции выполняет запись в файле providers - Добавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. -Помимо этого: + Добавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. Помимо этого: - Если не указана опция loose , то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации. - + Если не указана опция loose, то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации. - Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле /etc/shorewall/tcrules. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений. - + Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле /etc/shorewall/tcrules. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений. - Если указана опция balance, то - Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации - 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция -balance включена. -Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы. - + Если указана опция balance, то Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция balance включена. Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы. - Больше ничего эти записи не делают. -По-прежнему работает основной принцип, упомянутый в документации по маршрутизации Shorewall -: + Больше эти записи не делают ничего. Вспомните основной принцип, описанный в документации по маршрутизации Shorewall: - Маршрутизация отвечает за то, куда направляются пакеты. + Маршрутизация отвечает за то, куда направляются пакеты. - После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту. - + После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту. - Итак, если вы хотите направить трафик через определённого провайдера, то -необходимо пометить этот трафик значением MARK провайдера в файле -/etc/shorewall/tcrules и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле -/etc/shorewall/route_rules. + Итак, если вы хотите направить трафик через определённого провайдера, то необходимо пометить этот трафик значением MARK провайдера в файле /etc/shorewall/tcrules и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле /etc/shorewall/route_rules. - В Shorewall версий ниже 3.4.0 записи из файла -/etc/shorewall/providers необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды -shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. -Обычно это делается командой -/etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. - + В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/providers необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. - Дополнительные замечания: + Дополнительные замечания: - Влияние изменений, вносимых Shorewall в таблицу маршрутизации, можно уменьшить, указав параметр -metric для каждого настраиваемого маршрута по умолчанию. -Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция -balance включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля. - + Влияние изменений, вносимых Shorewall в таблицу маршрутизации, можно уменьшить, указав параметр metric для каждого настраиваемого маршрута по умолчанию. Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция balance включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля. - Опция -n команд shorewall - restart и shorewall restore позволяет предотвратить изменение маршрутизации. - + Опция -n команд shorewall restart и shorewall restore позволяет предотвратить изменение маршрутизации. - Файл /etc/shorewall/stopped можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом: - + Файл /etc/shorewall/stopped можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом: - ip route ls > routes + ip route ls > routes - Ниже приведен пример файла routes для моей системы: - + Ниже приведен пример файла routes для моей системы: 192.168.1.1 dev eth3 scope link 206.124.146.177 dev eth1 scope link @@ -476,25 +360,23 @@ Shorewall создаст маршрут по умолчанию с распре 127.0.0.0/8 dev lo scope link default via 206.124.146.254 dev eth3 - Отредактируйте этот файл следующим образом: + Отредактируйте этот файл следующим образом: ip route flush table main ip route add 192.168.1.1 dev eth3 scope link ip route add 206.124.146.177 dev eth1 scope link -ip route add 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 -ip route add 192.168.2.0/24 via 192.168.2.2 dev tun0 -ip route add 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 -ip route add 206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176 -ip route add 169.254.0.0/16 dev eth0 scope link -ip route add 127.0.0.0/8 dev lo scope link -ip route add default via 206.124.146.254 dev eth3 -ip route flush cache +192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 +192.168.2.0/24 via 192.168.2.2 dev tun0 +192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 +192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 +ip route add 206.124.146.177 dev eth1 scope link +ip route add 206.124.146.177 dev eth1 scope link +ip route add 206.124.146.177 dev eth1 scope link +ip route flush table main - Сохраните этот файл как -/etc/shorewall/stopped. + Сохраните этот файл как /etc/shorewall/stopped. - В этот файл можно также добавить следующее: - + В этот файл можно также добавить следующее: ip rule ls | while read priority rule; do case ${priority%:} in @@ -506,26 +388,56 @@ ip route add 192.168.1.1 dev eth3 scope link esac done - Этот код удаляет все правила маршрутов, за исключением маршрута по умолчанию. - + Этот код удаляет все правила маршрутов, за исключением маршрута по умолчанию.
-
+
Какие функции НЕ выполняет запись в файле providers - Shorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers -не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet . + Shorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet .
-
- Пример +
+ Марсианские пакеты - Конфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле -/etc/shorewall/providers следующим образом. - + В конфигурации с несколькими провайдерами часто возникает типичная неполадка с "марсианскими пакетами". Если для сетевых интерфейсов задана опция routefilter в файле /etc/shorewall/interfaces (а вместе с этой опцией должны быть задана опция logmartians), то могут возникать ошибки, и в протоколе будут сообщения следующего вида: + + Feb 9 17:23:45 gw.ilinx kernel: martian source 206.124.146.176 from 64.86.88.116, on dev eth1 +Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00 + + Это сообщение может ввести в заблуждение. Исходным IP входящего пакета является 64.86.88.116, а целевым IP - 206.124.146.176. Следует также учитывать, что целевой IP-адрес входящего пакета мог быть уже изменен, либо в DNAT, либо записью в файле /etc/shorewall/masq (SNAT или Masquerade) для первоначального исходящего соединения. Поэтому целевой IP-адрес (206.124.146.176) может отличаться от исходного целевого IP-адреса пришедшего пакета. + + Эти неполадки могут возникать по следующим причинам: + + + + Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок. + + + + В файле providers указаны вместе опции loose и balance. Это приводит к тому, что отдельные соединения будут перескакивать между интерфейсами, и будут возникать ошибки. + + + + Локальный трафик направляется через один из интерфейсов с помощью маркировки пакетов записью из файла /etc/shorewall/tcrules. Вместо этого следует привязать приложение к соответствующему локальному IP-адресу требуемого интерфейса. См. далее. + + + + Если больше ничего не помогает, удалите опцию routefilter для внешнего интерфейса. При этом можно добавить правила для регистрации и сбрасывания пакетов из Интернета, имеющих адрес источника из вашей локальной сети. Например, если локальная сеть в указанной выше конфигурации имеет адреса 192.168.1.0/24, то добавьте следующее правило: + + #ACTION SOURCE DEST +DROP:info net:192.168.1.0/24 all + + Be sure the above rule is added before any other rules with net in the SOURCE column. +
+ +
+ Пример + + Конфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле /etc/shorewall/providers следующим образом. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 @@ -536,7 +448,7 @@ ISP2 2 2 main eth1 130.252.99.254 track,ba /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS -net eth0 detect … +net eth0 detect … net eth1 detect … /etc/shorewall/policy: @@ -544,26 +456,20 @@ net eth1 detect … #SOURCE DESTINATION POLICY LIMIT:BURST net net DROP - Независимо от того, есть ли маскируемые хосты, или нет, ДОБАВЬТЕ ДВЕ ЗАПИСИ В ФАЙЛ -/etc/shorewall/masq: + Если соединения файрвола будут перенаправляться с помощью правил /etc/shorewall/tcrules, или если для провайдеров указана опция balance, то независимо от того, есть ли маскируемые хосты, в файл /etc/shorewall/masq необходимо добавить следующие записи. #INTERFACE SUBNET ADDRESS eth0 130.252.99.27 206.124.146.176 eth1 206.124.146.176 130.252.99.27 - Эти записи обеспечивают отправку пакетов, созданных в системе файрвола, с правильным исходным IP-адресом, соответствующим интерфейсу, через который они направляются. - + Эти записи обеспечивают отправку пакетов, созданных в системе файрвола, с правильным исходным IP-адресом, соответствующим интерфейсу, через который они направляются. - Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. -Например, если -eth0 имеет динамический IP-адрес: - + Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. Например, если eth0 имеет динамический IP-адрес: /etc/shorewall/params: - ETH0_IP=$(получить-адрес-интерфейса eth0) + ETH0_IP=$(find_first_interface_address eth0) /etc/shorewall/masq: @@ -572,105 +478,115 @@ eth0 130.252.99.27 $ETH0_IP eth1 $ETH0_IP 130.252.99.27 - Если есть маскируемые хосты, настройте в файле -/etc/shorewall/masq маскарадинг для обоих провайдеров. Например, если маскируются хосты, подключенные через -eth2 то: + Если есть маскируемые хосты, то настройте в файле /etc/shorewall/masq маскарадинг для обоих провайдеров. Например, если маскируются хосты, подключенные через eth2 то это делается так: #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth1 eth2 130.252.99.27 - Записи в файле /etc/shorewall/masq никак не влияют на то, через какого провайдера пройдёт конкретное соединение. -Для этого служат записи в файле -/etc/shorewall/tcrules или /etc/shorewall/route_rules. + Записи в файле /etc/shorewall/masq никак не влияют на то, через какого провайдера пройдёт конкретное соединение. Для этого применяются правила в файле /etc/shorewall/tcrules или /etc/shorewall/route_rules. - Предположим, что требуется направить весь исходящий трафик SMTP из локальной сети через провайдера 2. В файле -/etc/shorewall/tcrules укажите следующее (и в версии Shorewall ниже 3.0.0 также задайте - TC_ENABLED=Yes в файле /etc/shorewall/shorewall.conf). + Предположим, что требуется направить весь исходящий трафик SMTP из локальной сети через провайдера 2. В файле /etc/shorewall/tcrules укажите следующее (и в версии Shorewall ниже 3.0.0 также задайте TC_ENABLED=Yes в файле /etc/shorewall/shorewall.conf). #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) -2:P <локальная сеть> 0.0.0.0/0 tcp 25 +2:P <локальная сеть> 0.0.0.0/0 tcp 25
-
- Приложения, работающие в системе файрвола +
+ Если провайдеров больше, чем 2 - Опыт показал, что иногда возникают неполадки с приложениями, работающими в системе файрвола. -Если это имеет место, то свяжите приложение с определенным локальным IP-адресом вместо 0. - + Для более чем двух провайдеров требуется внести соответствующие дополнения: + + + + Для каждого внешнего адреса в файл /etc/shorewall/masq необходимо добавить записи для случаев, когда соединение, использующее этот адрес как SOURCE, направляется через интерфейс с отличным адресом. + + + + Для каждого внешнего интерфейса в файл /etc/shorewall/masq необходимо добавить записи для каждой внутренней подсети, которая будет маскироваться (или для которой применяется SNAT) через этот интерфейс. + + + + Например, для eth3 с IP-адресом 16.105.78.4 и шлюзом 16.105.78.254, необходимо добавить следующее: + + /etc/shorewall/providers:#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY +ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 +ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 +ISP3 3 3 main eth3 16.105.78.254 track,balance eth2 + + /etc/shorewall/masq:#INTERFACE SUBNET ADDRESS +eth0 130.252.99.27 206.124.146.176 +eth3 130.252.99.27 16.105.78.4 +eth1 206.124.146.176 130.252.99.27 +eth3 206.124.146.176 16.105.78.4 +eth0 16.106.78.4 206.124.146.176 +eth1 16.106.78.4 130.252.99.27 +eth0 eth2 206.124.146.176 +eth1 eth2 130.252.99.27 +eth3 eth2 16.105.78.4 +
+ +
+ Приложения, работающие в системе файрвола + + Иногда возникают неполадки с приложениями, работающими в системе файрвола. Это часто имеет место, для для внешних интерфейсов в файле /etc/shorewall/interfaces указана опция routefilter (см. выше). В этом случае рекомендуется связать приложение с определенным локальным IP-адресом вместо 0. Примеры: - Squid: В файле squid.conf задайте tcp_outgoing_address равным IP-адресу интерфейса, на котором будет работать Squid. + Squid: В файле squid.conf задайте tcp_outgoing_address равным IP-адресу интерфейса, на котором будет работать Squid. - Для OpenVPN задайте опцию local - (--local в командной строке с IP-адресом, на котором должен принимать соединения сервер. - + Для OpenVPN задайте опцию local(--local в командной строке с IP-адресом, на котором должен принимать соединения сервер.
-
+
/etc/shorewall/route_rules - Файл /etc/shorewall/route_rules добавлен в -Shorewall в версии 3.2.0. Файл route_rules позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла -tcrules . Разница между этими двумя файлами состоит в том что записи в -route_rules никак не связаны с Netfilter. + Файл /etc/shorewall/route_rules добавлен в Shorewall в версии 3.2.0. Файл route_rules позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла tcrules . Разница между этими двумя файлами состоит в том что записи в route_rules никак не связаны с Netfilter. - Записи в файле /etc/shorewall/route_rules - необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды shorewall stop - или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. + В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/route_rules необратимо изменяют маршрутизацию в системе, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. - Также обратите внимание на предупреждение в разделе -Какие функции выполняет запись в файле providers. + Также обратите внимание на предупреждение в разделе Какие функции выполняет запись в файле providers. -
- Правила маршрутизации +
+ Правила маршрутизации - Правила маршрутизации управляются ядром Linux. Их можно просмотреть командой -ip rule ls . При маршрутизации пакета правила обрабатываются поочередно, пока не будет найден маршрут пакета. - + Правила маршрутизации управляются ядром Linux. Их можно просмотреть командой ip rule ls . При маршрутизации пакета правила обрабатываются в указанном порядке, пока не будет найден маршрут пакета. gateway:~ # ip rule ls -0: from all lookup local <=== Локальные IP-адреса (система файрвола) -10001: from all fwmark 0x1 lookup Blarg <=== Это и следующее правило генерируются +0: from all lookup local <=== Локальные IP-адреса (система файрвола) +10001: from all fwmark 0x1 lookup Blarg <=== Это и следующее правило генерируются 10002: from all fwmark 0x2 lookup Comcast записями 'MARK' из /etc/shorewall/providers. -20000: from 206.124.146.176 lookup Blarg <=== Это и следующее правило не генерируются, если +20000: from 206.124.146.176 lookup Blarg <=== Это и следующее правило не генерируются, если 20256: from 24.12.22.33 lookup Comcast указана опция 'loose'; они основаны на выводе 'ip addr ls' -32766: from all lookup main <=== Это таблица маршрутизации, показанная в выводе 'iproute -n' -32767: from all lookup default <=== Эта таблица обычно пуста - +32766: from all lookup main <=== Это таблица маршрутизации, показанная в выводе 'iproute -n' +32767: from all lookup default <=== Эта таблица обычно пуста +gateway:~ # - В этом примере есть два провайдера, Blarg и Comcast, с метками MARK 1 и 2 соответственно. + В этом примере настроены два провайдера: Blarg и Comcast, с метками MARK 1 и 2 соответственно.
-
- Файл route_rules +
+ Файл route_rules - Далее описаны столбцы файла: + Далее описаны столбцы файла: SOURCE (Необязательный) - IP-адрес (сеть или хост), с которыми совпадает исходный IP-адрес пакета. -Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходит из системы файрвола. - + IP-адрес (подсеть или хост), с которыми совпадает исходный IP-адрес пакета. Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходить из системы файрвола. @@ -678,11 +594,9 @@ Shorewall в версии 3.2.0. Файл route_rules по DEST (Необязательный) - IP-адрес (сеть или хост), с которыми совпадает целевой IP-адрес пакета. + IP-адрес (подсеть или хост), с которыми совпадает целевой IP-адрес пакета. - Если опущен SOURCE или DEST, то в укажите в одном из этих полей "-". -Необходимо задать хотя бы одно из полей SOURCE или - DEST. + Если опущен SOURCE или DEST, то в укажите в одном из этих полей "-". Необходимо задать хотя бы одно из полей SOURCE или DEST. @@ -690,8 +604,7 @@ Shorewall в версии 3.2.0. Файл route_rules по PROVIDER - Провайдер, через которого должен проходить трафик. Может быть задан как имя провайдера или его номер. - + Провайдер, через которого должен проходить трафик. Может быть задан как имя провайдера или его номер. @@ -699,30 +612,25 @@ Shorewall в версии 3.2.0. Файл route_rules по PRIORITY - Приоритет правила, определяющий порядок обработки правил. - + Приоритет правила, определяющий порядок обработки правил. - 1000-1999: перед правилами Shorewall, генерируемыми на основе меток 'MARK' + 1000-1999: перед правилами Shorewall, генерируемыми на основе меток 'MARK' - 11000- 11999: после правил 'MARK', но перед правилами - Shorewall, генерируемыми для интерфейсов провайдеров. + 11000- 11999: после правил 'MARK', но перед правилами Shorewall, генерируемыми для интерфейсов провайдеров. - 26000-26999: после интерфейсов провайдеров, но перед правилом 'default'. - + 26000-26999: после интерфейсов провайдеров, но перед правилом 'default'. - Правила с одинаковым приоритетом обрабатываются в том порядке, как они указаны в файле. - + Правила с одинаковым приоритетом обрабатываются в том порядке, как они указаны в файле. - Пример 1: направить весь трафик, приходящий на eth1, через Comcast. + Пример 1: Направить весь трафик, приходящий на eth1, через Comcast. #SOURCE DEST PROVIDER PRIORITY eth1 - Comcast 1000 - С этим правилом вывод ip rule ls -будет следующим. + С этим правилом вывод ip rule ls будет следующим. gateway:~ # ip rule ls 0: from all lookup local @@ -733,13 +641,9 @@ eth1 - Comcast 1000 20256: from 24.12.22.33 lookup Comcast 32766: from all lookup main 32767: from all lookup default -gateway:~ #Обратите внимание, что приоритет 1000 приводит к тому, что проверка на -eth1 осуществляется перед проверкой fwmark. +gateway:~ #Обратите внимание, что приоритет 1000 приводит к тому, что проверка на eth1 осуществляется перед проверкой fwmark. - Пример 2: используется OpenVPN (маршрутизируемая конфигурация /tunX) в сочетании с несколькими провайдерами. -В этом случае необходимо настроить правило, согласно которому трафик OpenVPN будет направляться обратно через интерфейс tunX, а не через какого-либо из провайдеров. -10.8.0.0/24 - это подсеть, выбранная для OpenVPN (сервер 10.8.0.0 - 255.255.255.0). + Пример 2: Используется OpenVPN (маршрутизируемая конфигурация /tunX) в сочетании с несколькими провайдерами. В этом случае необходимо настроить правило, согласно которому трафик OpenVPN будет направляться обратно через интерфейс tunX, а не через какого-либо из провайдеров. 10.8.0.0/24 - это подсеть, выбранная для OpenVPN (сервер 10.8.0.0 255.255.255.0). #SOURCE DEST PROVIDER PRIORITY - 10.8.0.0/24 main 1000 diff --git a/docs/blacklisting_support_ru.xml b/docs/blacklisting_support_ru.xml index c40ed6b49..06222bf5f 100644 --- a/docs/blacklisting_support_ru.xml +++ b/docs/blacklisting_support_ru.xml @@ -1,18 +1,15 @@ - +
- + - Чёрные списки в Shorewall + Чёрные списки в Shorewall - - Tom + Tom - Eastep - + Eastep @@ -24,98 +21,71 @@ + 2007 Russian Translation: Grigory Mokhin - Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии -1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке - GNU Free Documentation - License. + Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License. -
+
Введение - В Shorewall предусмотрены два вида чёрных списков, статические и динамические. -Опция BLACKLISTNEWONLY в файле /etc/shorewall/shorewall.conf задаёт параметры фильтрации согласно этим спискам: - + В Shorewall предусмотрены два вида чёрных списков, статические и динамические. Опция BLACKLISTNEWONLY в файле /etc/shorewall/shorewall.conf задаёт параметры фильтрации согласно этим спискам: - BLACKLISTNEWONLY=No -- проверка осуществляется для всех входящих пакетов. -Новые записи в чёрном списке позволяют заблокировать уже существующие соединения. - + BLACKLISTNEWONLY=No --  проверка осуществляется для всех входящих пакетов. Новые записи в чёрном списке позволяют прервать уже существующие соединения. - BLACKLISTNEWONLY=Yes -- проверка осуществляется только для новых запросов на установление соединения. -Записи в чёрном списке не влияют на уже существующие соединения. На соответствие чёрному списку проверяется только адрес источника. - + BLACKLISTNEWONLY=Yes -- проверка осуществляется только для новых запросов на установление соединения. Записи в чёрном списке не влияют на уже существующие соединения. На соответствие чёрному списку проверяется только адрес источника. - На соответствие чёрному списку проверяется только адрес источника . Чёрные списки закрывают доступ только хостам, перечисленным в списке, но не закрывают доступ к самим этим хостам. - + На соответствие чёрному списку проверяется только адрес источника . Чёрные списки закрывают доступ только хостам, перечисленным в списке, но не закрывают доступ к самим этим хостам. - Динамические чёрные списки в Shorewall непригодны для случаев, когда список содержит тысячи адресов. -Статические списки могут работать с большим числом адресов, но только при использовании наборов IP (ipset). Без ipset большие чёрные списки будут загружаться слишком долго и заметно снизят производительность файрвола. - + Динамические чёрные списки в Shorewall непригодны для случаев, когда список содержит тысячи адресов. Статические списки могут работать с большим числом адресов, но только при использовании наборов IP (ipset). Без ipset большие чёрные списки будут загружаться слишком долго и заметно снизят производительность файрвола.
-
- Статические чёрные списки +
+ Статические чёрные списки - Далее описаны параметры конфигурации статических чёрных списков в Shorewall: - + Далее описаны параметры конфигурации статических чёрных списков в Shorewall: - Пакеты с хостов из чёрного списка будут отбрасываться без уведомления (drop) или с уведомлением (reject), согласно параметру BLACKLIST_DISPOSITION из файла /etc/shorewall/shorewall.conf. + Пакеты с хостов из чёрного списка будут отбрасываться без уведомления (drop) или с уведомлением (reject), согласно параметру BLACKLIST_DISPOSITION из файла /etc/shorewall/shorewall.conf. - Пакеты с хостов из чёрного списка будут заноситься в протокол с заданным уровнем syslog согласно параметру BLACKLIST_LOGLEVEL из файла /etc/shorewall/shorewall.conf. + Пакеты с хостов из чёрного списка будут заноситься в протокол с заданным уровнем syslog согласно параметру BLACKLIST_LOGLEVEL из файла /etc/shorewall/shorewall.conf. - IP-адреса или подсети, которые требуется занести в чёрный список, указываются в файле /etc/shorewall/blacklist. - В этом файле можно также указать имена протоколов, номеров портов или имён служб. - + IP-адреса или подсети, которые требуется занести в чёрный список, указываются в файле /etc/shorewall/blacklist. В этом файле можно также указать имена протоколов, номера портов или имена служб. - Интерфейсы, для которых входящие пакеты проверяются на соответствие чёрному списку, задаются с помощью опции -blacklist - в файле /etc/shorewall/interfaces. + Интерфейсы, для которых входящие пакеты проверяются на соответствие чёрному списку, задаются с помощью опции blacklist в файле /etc/shorewall/interfaces. - Чёрный список из файла -/etc/shorewall/blacklist можно обновить командой shorewall - refresh . + Чёрный список из файла /etc/shorewall/blacklist можно обновить командой shorewall refresh. - При наличии большого статического чёрного списка можно включить опцию DELAYBLACKLISTLOAD в файле shorewall.conf (начиная с Shorewall версии - 2.2.0). Если DELAYBLACKLISTLOAD=Yes, то Shorewall будет загружать правила чёрного списка после установления соединений. -Хотя при этом соединения с хостов из чёрного списка могут осуществляться в течение времени создания списка, эта опция позволяет существенно снизить время запрета соединений в ходе команд "shorewall [re]start". + При наличии большого статического чёрного списка можно включить опцию DELAYBLACKLISTLOAD в файле shorewall.conf (начиная с Shorewall версии 2.2.0). Если DELAYBLACKLISTLOAD=Yes, то Shorewall будет загружать правила чёрного списка после установления соединений. Хотя при этом соединения с хостов из чёрного списка могут осуществляться в течение времени создания списка, эта опция позволяет существенно снизить время запрета соединений в ходе выполнения команд "shorewall [re]start". - Начиная с Shorewall версии 2.4.0 поддерживаются наборы IP, или ipsets для определения статического чёрного списка. Пример: - + Для определения статического чёрного списка в Shorewall начиная с версии 2.4.0 поддерживаются наборы IP, или ipsets. Пример: #ADDRESS/SUBNET PROTOCOL PORT +Blacklistports[dst] @@ -123,85 +93,71 @@ +Blacklist[src,dst] #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - В этом примере задан ipset набора портов (portmap) - Blacklistports для запрета трафика на целевые порты, указанные в этом ipset. Есть также -Blacklistnets (типа nethash) и -Blacklist (типа iphash), закрывающие доступ с подсетей и отдельных адресов. -Обратите внимание, что указаны - [src,dst], чтобы можно было связать отдельные записи наборов с другими portmap ipset и включить чёрные списки сочетаний ( адрес источника, целевой порт). -Пример: + В этом примере задан ipset набора портов (portmap) Blacklistports для запрета трафика на целевые порты, указанные в этом ipset. Есть также списки сетей - Blacklistnets (типа nethash) и адресов - Blacklist (типа iphash), закрывающие доступ из подсетей и с отдельных адресов. Обратите внимание, что указаны [src,dst], чтобы можно было связать отдельные записи наборов с другими portmap ipset и включить чёрные списки сочетаний ( адрес источника, целевой порт). Пример: ipset -N SMTP portmap --from 1 --to 31 ipset -A SMTP 25 ipset -A Blacklist 206.124.146.177 ipset -B Blacklist 206.124.146.177 -b SMTP - Блокируется трафик SMTP с хоста 206.124.146.177. + При этом блокируется трафик SMTP с хоста 206.124.146.177.
-
- Динамические чёрные списки +
+ Динамические чёрные списки - Динамические списки не имеют никаких параметров конфигурации, но настраиваются следующими командами /sbin/shorewall[-lite]: + Динамические списки не имеют никаких параметров конфигурации, но настраиваются следующими командами /sbin/shorewall[-lite]: - drop <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом без уведомления. - + drop <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом без уведомления. - reject <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом с уведомлением. + reject <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом с уведомлением. - allow <список IP-адресов> - разрешить пакеты с хостов, ранее занесённых в чёрный список командами -drop или reject -. + allow <список IP-адресов> - разрешить пакеты с хостов, ранее занесённых в чёрный список командами drop или reject. - save - сохранить конфигурацию динамического чёрного списка, чтобы она восстановилась автоматически при следующем перезапуске файрвола. - + save - сохранить конфигурацию динамического чёрного списка; она будет восстановлена автоматически при следующем перезапуске файрвола. - show dynamic - показать конфигурацию динамического чёрного списка. - + show dynamic - показать конфигурацию динамического чёрного списка. - Начиная с Shorewall версии 3.2.0 Beta2 доступны следующие дополнительные команды: - + Начиная с Shorewall версии 3.2.0 Beta2 доступны следующие дополнительные команды: - logdrop <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом без уведомления. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). + logdrop <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом без уведомления. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). - logreject <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом с уведомлением. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). + logreject <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом с уведомлением. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). - Динамические чёрные списки не зависят от опции -blacklist в файле - /etc/shorewall/interfaces. + Динамические чёрные списки не зависят от опции blacklist в файле /etc/shorewall/interfaces. - - Игноpиpовать пакеты с двух IP-адресов + + Игноpиpовать пакеты с двух IP-адресов shorewall[-lite] drop 192.0.2.124 192.0.2.125 - Блокирует доступ с хостов 192.0.2.124 и 192.0.2.125 + При этом блокируется доступ с хостов 192.0.2.124 и 192.0.2.125 - - Разрешить пакеты с IP-адреса + + Разрешить пакеты с IP-адреса shorewall[-lite] allow 192.0.2.125 Разрешает трафик с 192.0.2.125.
-
\ No newline at end of file +