<para>Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке <quote><ulinkurl="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<para>Вы должны <emphasisrole="bold"> установить современный дистрибутив, который обновляется поставщиком</emphasis>, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. Если вы проигнорируете этот совет, <emphasisrole="bold">то <emphasisrole="bold">не </emphasis> рассчитывайте, что кто-либо сможет вам помочь.</emphasis>.</para>
<para>Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). Скорее всего вам потребуется обратиться к следующим дополнительным источникам:</para>
<para>Начиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. Ниже описаны существующие ограничения:</para>
<para>Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером.</para>
<para>Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске <emphasisrole="bold">и при перезапуске Shorewall </emphasis> (если не указана опция "-n" для <command>shorewall restart</command>). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию.</para>
<para>В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд <command>shorewall stop</command>, <command>shorewall clear</command> или <command>shorewall restart</command>.</para>
<para>Предположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам Ethernet, как показано на рисунке.</para>
<para>В записях в файле <filename>/etc/shorewall/providers</filename> можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. В записях в файле <filename>/etc/shorewall/tcrules</filename> можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. Правила в файле <filename>/etc/shorewall/tcrules</filename> необязательны для того, чтобы настройка <filename>/etc/shorewall/providers</filename> работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки.</para>
<para>Если задать опцию <emphasisrole="bold">track</emphasis> в файле <filename>/etc/shorewall/providers</filename>, то соединения из Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола.</para>
<para>Shorewall настраивает маршрутизацию и обновляет файл <filename>/etc/iproute2/rt_tables</filename>, включая в него имена таблиц и их номера.</para>
<para>При этом используются функции <ulinkurl="traffic_shaping.htm">маркировки пакетов</ulink> для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле <filename>/etc/shorewall/tcrules</filename>:</para>
<para>Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее).</para>
<para>Файл <filename>/etc/shorewall/providers</filename> может также использоваться в других сценариях маршрутизации. В<ulinkurl="Shorewall_Squid_Usage.html">документации по работе с Squid </ulink> приведены примеры.</para>
<para>Далее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение.</para>
<para>Имя провайдера. Должно начинаться с буквы и состоять из букв и цифр. Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера.</para>
<para>Метка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. Метка должна быть целым числом от 1 до 255.</para>
<para>Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле <filename>/etc/shorewall/shorewall.conf</filename>. Это позволяет решить следующие задачи:</para>
<para>Использовать значения меток > 255 для меток провайдера. Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами).</para>
<para>Имя или номер таблицы маршрутизации, которая будет продублирована. Можно указать 'main' или имя или номер ранее объявленного провайдера. Для большинства приложений здесь достаточно будет указать 'main'.</para>
<para>Имя интерфейса канала связи с провайдером.</para>
<caution>
<para>В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу.</para>
<para><emphasisrole="bold">Совет:</emphasis><emphasisrole="bold">"detect"</emphasis> следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP.</para>
<para>Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс.</para>
<para>Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. Вместе с'track' всегда следует указывать опцию 'balance'.</para>
<para>В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда <command>shorewall restore</command> может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу <ulinkurl="http://shorewall.org/pub/shorewall/contrib/iptables/CONNMARK.diff">http://shorewall.org/pub/shorewall/contrib/iptables/CONNMARK.diff</ulink>.</para>
<para>Если используется файл <filename>/etc/shorewall/providers</filename> для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика.</para>
<para>Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера.</para>
<para>По умолчанию всем провайдерам присваивается одинаковый вес (1). Вес конкретного провайдера можно изменить опцией <emphasis>balance</emphasis>с"=" и весом (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. </para>
<para>Если файл <filename>/etc/shorewall/providers</filename> используется для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. Для направления всего трафика через какого-либо определенного провайдера можно использовать файл <filename>/etc/shorewall/tcrules</filename>. <note>
<para>Если вы проигнорируете этот совет, то прочитайте <ulinkurl="FAQ.htm#faq57">FAQ 57</ulink> и <ulinkurl="FAQ.htm#faq58">FAQ 58</ulink>.</para>
<para>Если указана опция 'balance', но весь трафик по-прежнему идёт через одного провайдера, то причина этого может состоять в том, что ядро не собрано с опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. У некоторых пользователей пересборка ядра с этой опцией помогла устранить неполадку.</para>
<para>Эта неполадка присутствует в ядре SuSE 10.0, и согласно <ulinkurl="https://bugzilla.novell.com/show_bug.cgi?id=190908">в этом случае может возникать критическая ошибка ядра.</ulink>В SUSE 10.1 и SLES 10 опция CONFIG_IP_ROUTE_MULTIPATH_CACHED=n включена по умолчанию. Источник неполадки описан здесь: <ulinkurl="http://news.gmane.org/find-root.php?message_id=%3c00da01c5b35a%24b12b9860%241b00a8c0%40cruncher%3e">несовместимость между исправлениями от LARTC и опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED.</ulink></para>
<para>Не включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с<emphasisrole="bold">balance</emphasis>.</para>
<para>Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен.</para>
<para>Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды <command>shorewall start</command> или <command>shorewall restart</command> - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс.</para>
<para>Если в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.</para>
<para>Если не указана опция <emphasisrole="bold">loose</emphasis>, то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации.</para>
<para>Если указана опция <emphasisrole="bold">track</emphasis>, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле <filename>/etc/shorewall/tcrules</filename>. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений.</para>
<para>Если указана опция <emphasisrole="bold">balance</emphasis>, то Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция <emphasisrole="bold">balance</emphasis> включена. Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы.</para>
<para>Больше эти записи не делают <emphasisrole="bold">ничего</emphasis>. Вспомните основной принцип, описанный в <ulinkurl="Shorewall_and_Routing.html">документации по маршрутизации Shorewall</ulink>:</para>
<para>Итак, если вы хотите направить трафик через определённого провайдера, то <emphasis>необходимо </emphasis>пометить этот трафик значением MARK провайдера в файле <filename>/etc/shorewall/tcrules</filename> и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле <filename>/etc/shorewall/rtrules</filename>.</para>
<para>В Shorewall версий ниже 3.4.0 записи из файла <filename>/etc/shorewall/providers</filename> необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды <command>shorewall stop</command> или <command>shorewall clear</command>. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда <command>/etc/init.d/network restart</command> или <command>/etc/init.d/networking restart</command>. Обратитесь к документации по сети вашего дистрибутива.</para>
<para>Влияние изменений, вносимых Shorewall в таблицу маршрутизации, можно уменьшить, указав параметр <emphasis>metric</emphasis> для каждого настраиваемого маршрута по умолчанию. Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция <emphasisrole="bold">balance</emphasis> включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля.</para>
<para>Опция <command>-n</command> команд <command>shorewall restart</command> и <command>shorewall restore</command> позволяет предотвратить изменение маршрутизации.</para>
<para>Файл <filename>/etc/shorewall/stopped</filename> можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом:</para>
<para>Shorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers <emphasisrole="bold">не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet </emphasis>.</para>
</section>
<sectionid="Martians">
<title>Марсианские пакеты</title>
<para>В конфигурации с несколькими провайдерами часто возникает типичная неполадка с"марсианскими пакетами". Если для сетевых интерфейсов задана опция <emphasisrole="bold">routefilter</emphasis> в файле <filename>/etc/shorewall/interfaces</filename> (а вместе с этой опцией должны быть задана опция <emphasisrole="bold">logmartians</emphasis>), то могут возникать ошибки, и в протоколе будут сообщения следующего вида: </para>
<programlisting>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</programlisting>
<para>Это сообщение может ввести в заблуждение. Исходным IP входящего пакета является 64.86.88.116, а целевым IP - 206.124.146.176. Следует также учитывать, что целевой IP-адрес входящего пакета мог быть уже изменен, либо в DNAT, либо записью в файле <filename>/etc/shorewall/masq</filename> (SNAT или Masquerade) для первоначального исходящего соединения. Поэтому целевой IP-адрес (206.124.146.176) может отличаться от исходного целевого IP-адреса пришедшего пакета. </para>
<para>Эти неполадки могут возникать по следующим причинам: </para>
<orderedlist>
<listitem>
<para>Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок. </para>
</listitem>
<listitem>
<para>В файле providers указаны вместе опции <emphasisrole="bold">loose</emphasis> и <emphasisrole="bold">balance</emphasis>. Это приводит к тому, что отдельные соединения будут перескакивать между интерфейсами, и будут возникать ошибки. </para>
</listitem>
<listitem>
<para>Локальный трафик направляется через один из интерфейсов с помощью маркировки пакетов записью из файла <filename>/etc/shorewall/tcrules</filename>. Вместо этого следует привязать приложение к соответствующему локальному IP-адресу требуемого интерфейса. См. <linklinkend="Local">далее</link>.</para>
</listitem>
</orderedlist>
<para>Если больше ничего не помогает, удалите опцию <emphasisrole="bold">routefilter</emphasis> для внешнего интерфейса. При этом можно добавить правила для регистрации и сбрасывания пакетов из Интернета, имеющих адрес источника из вашей локальной сети. Например, если локальная сеть в указанной выше конфигурации имеет адреса 192.168.1.0/24, то добавьте следующее правило:</para>
<programlisting>#ACTION SOURCE DEST
DROP:info net:192.168.1.0/24 all</programlisting>
<para>Be sure the above rule is added before any other rules with <emphasis>net</emphasis> in the SOURCE column.</para>
<para>Конфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле <filename>/etc/shorewall/providers</filename> следующим образом.</para>
<para>Если соединения файрвола будут перенаправляться с помощью правил <filename>/etc/shorewall/tcrules</filename>, или если для провайдеров указана опция <emphasisrole="bold">balance</emphasis>, то независимо от того, есть ли маскируемые хосты, в файл <filename>/etc/shorewall/masq</filename> необходимо добавить следующие записи.</para>
<para>Эти записи обеспечивают отправку пакетов, созданных в системе файрвола, с правильным исходным IP-адресом, соответствующим интерфейсу, через который они направляются.</para>
<para>Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. Например, если <filenameclass="devicefile">eth0</filename> имеет динамический IP-адрес:</para>
<para>Если есть маскируемые хосты, то настройте в файле <filename>/etc/shorewall/masq</filename> маскарадинг для обоих провайдеров. Например, если маскируются хосты, подключенные через <filenameclass="devicefile">eth2</filename> то это делается так:</para>
<para>Записи в файле <filename>/etc/shorewall/masq</filename> никак не влияют на то, через какого провайдера пройдёт конкретное соединение. Для этого применяются правила в файле <filename>/etc/shorewall/tcrules</filename> или <filename>/etc/shorewall/rtrules</filename>.</para>
<para>Предположим, что требуется направить весь исходящий трафик SMTP из локальной сети через провайдера 2. В файле <ulinkurl="traffic_shaping.htm">/etc/shorewall/tcrules</ulink> укажите следующее (и в версии Shorewall ниже 3.0.0 также задайте TC_ENABLED=Yes в файле <ulinkurl="???">/etc/shorewall/shorewall.conf</ulink>).</para>
<para>Для более чем двух провайдеров требуется внести соответствующие дополнения: </para>
<orderedlist>
<listitem>
<para>Для каждого внешнего адреса в файл <filename>/etc/shorewall/masq</filename> необходимо добавить записи для случаев, когда соединение, использующее этот адрес как SOURCE, направляется через интерфейс с отличным адресом. </para>
</listitem>
<listitem>
<para>Для каждого внешнего интерфейса в файл <filename>/etc/shorewall/masq</filename> необходимо добавить записи для каждой внутренней подсети, которая будет маскироваться (или для которой применяется SNAT) через этот интерфейс. </para>
</listitem>
</orderedlist>
<para>Например, для eth3 с IP-адресом 16.105.78.4 и шлюзом 16.105.78.254, необходимо добавить следующее:</para>
<para><filename>/etc/shorewall/providers</filename>:<programlisting>#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</programlisting></para>
<para>Иногда возникают неполадки с приложениями, работающими в системе файрвола. Это часто имеет место, для для внешних интерфейсов в файле /etc/shorewall/interfaces указана опция <emphasisrole="bold">routefilter</emphasis> (см. <linklinkend="Martians">выше</link>). В этом случае рекомендуется связать приложение с определенным локальным IP-адресом вместо 0.</para>
<para>Squid: В файле <filename>squid.conf</filename> задайте <emphasisrole="bold">tcp_outgoing_address</emphasis> равным IP-адресу интерфейса, на котором будет работать Squid.</para>
<para>Для OpenVPN задайте опцию <emphasisrole="bold">local</emphasis>(<emphasisrole="bold">--local</emphasis> в командной строке с IP-адресом, на котором должен принимать соединения сервер.</para>
<para>Файл <filename>/etc/shorewall/rtrules</filename> добавлен в Shorewall в версии 3.2.0. Файл <filename>rtrules</filename> позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла <filename>tcrules</filename> . Разница между этими двумя файлами состоит в том что записи в <filename>rtrules</filename> никак не связаны с Netfilter.</para>
<para>В Shorewall версий ниже 3.4.0 записи из файла <filename>/etc/shorewall/rtrules</filename> необратимо изменяют маршрутизацию в системе, то есть эти изменения не отменяются при вызове команды <command>shorewall stop</command> или <command>shorewall clear</command>. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда <command>/etc/init.d/network restart</command> или <command>/etc/init.d/networking restart</command>. Обратитесь к документации по сети вашего дистрибутива.</para>
<para>Также обратите внимание на <linklinkend="Undo">предупреждение в разделе <emphasis>Какие функции выполняет запись в файле providers</emphasis></link>.</para>
<para>Правила маршрутизации управляются ядром Linux. Их можно просмотреть командой <command>ip rule ls</command> . При маршрутизации пакета правила обрабатываются в указанном порядке, пока не будет найден маршрут пакета.</para>
<para>IP-адрес (подсеть или хост), с которыми совпадает исходный IP-адрес пакета. Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходить из системы файрвола.</para>
gateway:~ #</programlisting>Обратите внимание, что приоритет 1000 приводит к тому, что проверка на <filenameclass="devicefile">eth1</filename> осуществляется перед проверкой fwmark.</para>
<para>Пример 2: Используется OpenVPN (маршрутизируемая конфигурация /tunX) в сочетании с несколькими провайдерами. В этом случае необходимо настроить правило, согласно которому трафик OpenVPN будет направляться обратно через интерфейс tunX, а не через какого-либо из провайдеров. 10.8.0.0/24 - это подсеть, выбранная для OpenVPN (сервер 10.8.0.0 255.255.255.0).</para>