## Shorewall и подключение к Internet по нескольким каналам

### Tom Eastep

Copyright © 2005, 2006, 2007 Thomas M. Eastep

Copyright © 2007 Russian Translation: Grigory Mokhin

Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке “GNU Free Documentation License”.

2026/01/29

### Warning

Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. Если вы проигнорируете этот совет, то не рассчитывайте, что кто-либо сможет вам помочь..

### Warning

Чтение только документации 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`, включая в него имена таблиц и их номера.

### Caution

При этом используются функции маркировки пакетов для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле `/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

  Имя интерфейса канала связи с провайдером.

  ### Caution

  В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу.

GATEWAY

  IP-адрес шлюза провайдера.

  Здесь можно указать detect для автоматического определения IP-адреса шлюза.

  Совет: "detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP.

OPTIONS

  Список параметров через запятую, описанных ниже:

  track

    Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс.

    Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. Вместе с 'track' всегда следует указывать опцию 'balance'.

    Для работы с этой функцией ядро и iptables должны поддерживать цель CONNMARK и сравнение connmark. Расширение цели ROUTE не требуется.

    ### Warning

    В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда shorewall restore может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу http://shorewall.org/pub/shorewall/contrib/iptables/CONNMARK.diff.

    ### Important

    Если используется файл `/etc/shorewall/providers` для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика.

  balance

    Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера.

    По умолчанию всем провайдерам присваивается одинаковый вес (1). Вес конкретного провайдера можно изменить опцией balance с "=" и весом (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса.

    ### Important

    Если файл `/etc/shorewall/providers` используется для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. Для направления всего трафика через какого-либо определенного провайдера можно использовать файл `/etc/shorewall/tcrules`.

    ### Note

    Если вы проигнорируете этот совет, то прочитайте FAQ 57 и FAQ 58.

    ### Important

    Если указана опция '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-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с balance.

  optional (начиная с Shorewall 3.2.2)

    Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен.

    ### Note

    Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс.

  Для тех, кто окончательно запутался в том, что такое track и balance:

  - track управляет входящими соединениями.

  - balance управляет исходящими соединениями.

COPY

  Если в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.

### Какие функции выполняет запись в файле providers

Добавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. Помимо этого:

1. Если не указана опция loose, то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации.

2. Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле `/etc/shorewall/tcrules`. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений.

3. Если указана опция balance, то Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция balance включена. Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы.

Больше эти записи не делают ничего. Вспомните основной принцип, описанный в документации по маршрутизации Shorewall:

1. Маршрутизация отвечает за то, куда направляются пакеты.

2. После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту.

Итак, если вы хотите направить трафик через определённого провайдера, то необходимо пометить этот трафик значением MARK провайдера в файле `/etc/shorewall/tcrules` и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле `/etc/shorewall/rtrules`.

### Warning

В 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
      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 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 .

### Марсианские пакеты

В конфигурации с несколькими провайдерами часто возникает типичная неполадка с "марсианскими пакетами". Если для сетевых интерфейсов задана опция 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-адреса пришедшего пакета.

Эти неполадки могут возникать по следующим причинам:

1. Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок.

2. В файле providers указаны вместе опции loose и balance. Это приводит к тому, что отдельные соединения будут перескакивать между интерфейсами, и будут возникать ошибки.

3. Локальный трафик направляется через один из интерфейсов с помощью маркировки пакетов записью из файла `/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
    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/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-адресом, соответствующим интерфейсу, через который они направляются.

### Note

Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. Например, если `eth0` имеет динамический IP-адрес:

`/etc/shorewall/params`:

    ETH0_IP=$(find_first_interface_address 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

### Warning

Записи в файле `/etc/shorewall/masq` никак не влияют на то, через какого провайдера пройдёт конкретное соединение. Для этого применяются правила в файле `/etc/shorewall/tcrules` или `/etc/shorewall/rtrules`.

Предположим, что требуется направить весь исходящий трафик 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

Для более чем двух провайдеров требуется внести соответствующие дополнения:

1. Для каждого внешнего адреса в файл `/etc/shorewall/masq` необходимо добавить записи для случаев, когда соединение, использующее этот адрес как SOURCE, направляется через интерфейс с отличным адресом.

2. Для каждого внешнего интерфейса в файл `/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.

- Для OpenVPN задайте опцию local(--local в командной строке с IP-адресом, на котором должен принимать соединения сервер.

### /etc/shorewall/rtrules

Файл `/etc/shorewall/rtrules` добавлен в Shorewall в версии 3.2.0. Файл `rtrules` позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла `tcrules` . Разница между этими двумя файлами состоит в том что записи в `rtrules` никак не связаны с Netfilter.

### Warning

В Shorewall версий ниже 3.4.0 записи из файла `/etc/shorewall/rtrules` необратимо изменяют маршрутизацию в системе, то есть эти изменения не отменяются при вызове команды 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              <=== Эта таблица обычно пуста
    gateway:~ #

В этом примере настроены два провайдера: Blarg и Comcast, с метками MARK 1 и 2 соответственно.

#### Файл rtrules

Далее описаны столбцы файла:

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