Tom Eastep 2005 2006 2007 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

Начиная с версии 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 приведены примеры.

Далее описаны поля этого файла. Как и везде в файлах конфигурации 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 Имя интерфейса канала связи с провайдером. В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу. 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.org/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-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с balance. optional (начиная с Shorewall 3.2.2) Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен. Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс. Для тех, кто окончательно запутался в том, что такое track и balance: track управляет входящими соединениями. balance управляет исходящими соединениями. COPY Если в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.

Добавление записи в файле 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/rtrules. В 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 Этот код удаляет все правила маршрутов, за исключением маршрута по умолчанию.

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-адреса пришедшего пакета. Эти неполадки могут возникать по следующим причинам: Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок. В файле 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 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-адресом, соответствующим интерфейсу, через который они направляются. Если какой-либо из интерфейсов имеет динамический 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 Записи в файле /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

Для более чем двух провайдеров требуется внести соответствующие дополнения: Для каждого внешнего адреса в файл /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. Для OpenVPN задайте опцию local(--local в командной строке с IP-адресом, на котором должен принимать соединения сервер.

Файл /etc/shorewall/rtrules добавлен в Shorewall в версии 3.2.0. Файл rtrules позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла tcrules . Разница между этими двумя файлами состоит в том что записи в rtrules никак не связаны с Netfilter. В 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 соответственно.

Далее описаны столбцы файла: 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