diff --git a/docs/MultiISP_ru.xml b/docs/MultiISP_ru.xml new file mode 100644 index 000000000..d5e1d9761 --- /dev/null +++ b/docs/MultiISP_ru.xml @@ -0,0 +1,749 @@ + + +
+ + + + Shorewall и подключение к Internet по нескольким каналам + + + + Tom + + Eastep + + + + + + + 2005 + + 2006 + + Thomas M. Eastep + + + + 2007 + + Russian Translation: Grigory Mokhin + + + + Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии +1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке +GNU Free Documentation + License. + + + + + Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. +Если вы проигнорируете этот совет, то +не рассчитывайте, что кто-либо сможет вам помочь. +. + + + + Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). +Скорее всего вам потребуется обратиться к следующим дополнительным источникам: + + + + LARTC HOWTO: http://www.lartc.org + + + + Вывод команды man ip + + + + Вывод команд ip route help и ip rule + help + + + + +
+ Поддержка нескольких соединений с Internet + + Начиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. +Ниже описаны существующие ограничения: + + + + + Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером. + + + + + Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске +и при перезапуске Shorewall (если не указана опция "-n" для + shorewall restart). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию. + + + + + В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд +shorewall + stop, shorewall clear или shorewall restart. + + + +
+ Обзор + + Предположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам ethernet, как показано на рисунке. + + + + + + + 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. + + + + eth2 подключен к локальной сети. У него может быть любой IP-адрес. + + + + + Все эти провайдеры должны быть перечислены в файле /etc/shorewall/providers. + + В записях в файле /etc/shorewall/providers можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. +В записях в файле /etc/shorewall/tcrules можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. + Правила в файле /etc/shorewall/tcrules необязательны для того, чтобы настройка +/etc/shorewall/providers работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки. + + + Если задать опцию track в файле +/etc/shorewall/providers, то соединения из +Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. +Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола. + + + Shorewall настраивает маршрутизацию и обновляет файл +/etc/iproute2/rt_tables , включая в него имена таблиц и их номера. + + + + При этом используются функции маркировки пакетов + для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле +/etc/shorewall/tcrules: + + + + Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее). + + + + Нельзя использовать опции SAVE или RESTORE. + + + + Нельзя использовать маркировку соединений. + + + + + Файл /etc/shorewall/providers может также использоваться в других сценариях маршрутизации. +В документации по работе с Squid приведены примеры. + +
+ +
+ Файл /etc/shorewall/providers + + Далее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение. + + + + + NAME + + + Имя провайдера. Должно начинаться с буквы и состоять из букв и цифр. +Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера. + + + + + + NUMBER + + + Число от 1 до 252. Оно будет номером таблицы маршрутизации для сгенерированной таблицы для этого провайдера. + + + + + + MARK + + + Метка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. +Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. + Метка должна быть целым числом от 1 до 255. + + Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле +/etc/shorewall/shorewall.conf. Это позволяет решить следующие задачи: + + + + + Использовать метки пакетов для управления трафиком, при условии что эти метки присваиваются в цепочке FORWARD. + + + + Использовать значения меток > 255 для меток провайдера. +Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами). + + + + + + + + DUPLICATE + + + Имя или номер таблицы маршрутизации, которая будет продублирована. +Можно указать 'main' или имя или номер ранее объявленного провайдера. +Для большинства приложений здесь достаточно будет указать 'main'. + + + + + + INTERFACE + + + Имя интерфейса канала связи с провайдером. + + + + + GATEWAY + + + IP-адрес шлюза провайдера. + + Здесь можно указать detect для автоматического определения IP-адреса шлюза. + + + Совет: "detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP. + + + + + OPTIONS + + + Список параметров через запятую, описанных ниже: + + + + track + + + Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс. + + + Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. +Вместе с 'track' всегда следует указывать опцию 'balance'. + + Для работы с этой функцией ядро и + 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. + + + + Если используется файл +/etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика. + + + + + + + balance + + + Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. +Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. +При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера. + + + По умолчанию всем провайдерам присваивается одинаковый вес (1). +Вес конкретного провайдера можно изменить опцией +balance с "=" и весом + (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. + + + + Если используется файл + /etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. С помощью записей в файле +/etc/shorewall/tcrules +можно принудительно направить трафик через конкретного провайдера. + Если вы проигнорируете этот совет, то прочитайте FAQ 57 и + FAQ 58. + + + + + Если указана опция '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. + + + + + + loose + + + Не включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. +Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. + + + + + + optional (начиная с Shorewall 3.2.2) + + + Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. +Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен. + + + + Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс. + + + + + + + Для тех, кто окончательно запутался в том, что такое track и balance: + + + + track управляет входящими соединениями. + + + + + balance управляет исходящими соединениями. + + + + + + + COPY + + + Если в поле DUPLICATE указана существующая таблица, + то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла. + + + + +
+ +
+ Какие функции выполняет запись в файле providers + + Добавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. +Помимо этого: + + + + Если не указана опция loose , то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации. + + + + + Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле /etc/shorewall/tcrules. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений. + + + + + Если указана опция balance, то + Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации + 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция +balance включена. +Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы. + + + + + Больше ничего эти записи не делают. +По-прежнему работает основной принцип, упомянутый в документации по маршрутизации Shorewall +: + + + + Маршрутизация отвечает за то, куда направляются пакеты. + + + + После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту. + + + + + Итак, если вы хотите направить трафик через определённого провайдера, то +необходимо пометить этот трафик значением 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 в таблицу маршрутизации, можно уменьшить, указав параметр +metric для каждого настраиваемого маршрута по умолчанию. +Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция +balance включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля. + + + + + Опция -n команд shorewall + restart и shorewall restore позволяет предотвратить изменение маршрутизации. + + + + + Файл /etc/shorewall/stopped можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом: + + + ip route ls > routes + + Ниже приведен пример файла routes для моей системы: + + + 192.168.1.1 dev eth3 scope link +206.124.146.177 dev eth1 scope link +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.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 +206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176 +169.254.0.0/16 dev eth0 scope link +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 + + Сохраните этот файл как +/etc/shorewall/stopped. + + В этот файл можно также добавить следующее: + + + ip rule ls | while read priority rule; do + case ${priority%:} in + 0|3276[67]) + ;; + *) + ip rule del $rule + ;; + esac +done + + Этот код удаляет все правила маршрутов, за исключением маршрута по умолчанию. + + + + +
+ +
+ Какие функции НЕ выполняет запись в файле providers + + Shorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers +не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet . +
+ +
+ Пример + + Конфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле +/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 + + Прочие файлы конфигурации будут иметь следующий вид: + + /etc/shorewall/interfaces: + + #ZONE INTERFACE BROADCAST OPTIONS +net eth0 detect … +net eth1 detect … + + /etc/shorewall/policy: + + #SOURCE DESTINATION POLICY LIMIT:BURST +net net DROP + + Независимо от того, есть ли маскируемые хосты, или нет, ДОБАВЬТЕ ДВЕ ЗАПИСИ В ФАЙЛ +/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-адрес, то указанные правила можно создать с помощью переменных оболочки. +Например, если +eth0 имеет динамический IP-адрес: + + + /etc/shorewall/params: + + ETH0_IP=$(получить-адрес-интерфейса eth0) + + /etc/shorewall/masq: + + #INTERFACE SUBNET ADDRESS +eth0 130.252.99.27 $ETH0_IP +eth1 $ETH0_IP 130.252.99.27 + + + Если есть маскируемые хосты, настройте в файле +/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. + + + Предположим, что требуется направить весь исходящий трафик 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 +
+ +
+ Приложения, работающие в системе файрвола + + Опыт показал, что иногда возникают неполадки с приложениями, работающими в системе файрвола. +Если это имеет место, то свяжите приложение с определенным локальным IP-адресом вместо 0. + + + Примеры: + + + + Squid: В файле squid.conf задайте tcp_outgoing_address равным IP-адресу интерфейса, на котором будет работать Squid. + + + + Для 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 stop + или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. + + Также обратите внимание на предупреждение в разделе +Какие функции выполняет запись в файле providers. + + +
+ Правила маршрутизации + + Правила маршрутизации управляются ядром Linux. Их можно просмотреть командой +ip rule ls . При маршрутизации пакета правила обрабатываются поочередно, пока не будет найден маршрут пакета. + + + gateway:~ # ip rule ls +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 <=== Это и следующее правило не генерируются, если +20256: from 24.12.22.33 lookup Comcast указана опция 'loose'; они основаны на выводе 'ip addr ls' +32766: from all lookup main <=== Это таблица маршрутизации, показанная в выводе 'iproute -n' +32767: from all lookup default <=== Эта таблица обычно пуста + + + В этом примере есть два провайдера, Blarg и Comcast, с метками MARK 1 и 2 соответственно. +
+ +
+ Файл route_rules + + Далее описаны столбцы файла: + + + + SOURCE (Необязательный) + + + IP-адрес (сеть или хост), с которыми совпадает исходный IP-адрес пакета. +Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходит из системы файрвола. + + + + + + DEST (Необязательный) + + + IP-адрес (сеть или хост), с которыми совпадает целевой IP-адрес пакета. + + Если опущен SOURCE или DEST, то в укажите в одном из этих полей "-". +Необходимо задать хотя бы одно из полей SOURCE или + DEST. + + + + + PROVIDER + + + Провайдер, через которого должен проходить трафик. Может быть задан как имя провайдера или его номер. + + + + + + PRIORITY + + + Приоритет правила, определяющий порядок обработки правил. + + + 1000-1999: перед правилами Shorewall, генерируемыми на основе меток 'MARK' + + 11000- 11999: после правил 'MARK', но перед правилами + Shorewall, генерируемыми для интерфейсов провайдеров. + + 26000-26999: после интерфейсов провайдеров, но перед правилом 'default'. + + + Правила с одинаковым приоритетом обрабатываются в том порядке, как они указаны в файле. + + + + + + Пример 1: направить весь трафик, приходящий на eth1, через Comcast. + + #SOURCE DEST PROVIDER PRIORITY +eth1 - Comcast 1000 + + С этим правилом вывод ip rule ls +будет следующим. + + gateway:~ # ip rule ls +0: from all lookup local +1000: from all iif eth1 lookup Comcast +10001: from all fwmark 0x1 lookup Blarg +10002: from all fwmark 0x2 lookup Comcast +20000: from 206.124.146.176 lookup Blarg +20256: from 24.12.22.33 lookup Comcast +32766: from all lookup main +32767: from all lookup default +gateway:~ #Обратите внимание, что приоритет 1000 приводит к тому, что проверка на +eth1 осуществляется перед проверкой fwmark. + + Пример 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 +
+
+
+