2 канала интернет в linux работали одновременно

Обновлено: 07.07.2024

C появлением высокоскоростных каналов, предоставляемых провайдерами Internet (Internet Service Provider, ISP), пользователям стало намного проще размещать различные службы на своих домашних компьютерах. Но что если связь прервется? Очевидное решение в такой ситуации — использовать резервное соединение с Internet от другого провайдера. В данной статье рассказывается о наиболее важных моментах, которые следует учитывать при настройке хоста Linux с избыточными соединениями Internet:

о конфигурации хоста таким образом, чтобы он корректно поддерживал входящие сетевые соединения от нескольких провайдеров Internet;
о балансировке трафика между исходящими сетевыми соединениями;
o конфигурации различных служб для поддержания избыточности;
о настройке защиты межсетевого экрана с помощью сценариев ipchains или iptables.

На Рисунке 1 приведена конфигурация домашней компьютерной сети, на которую мы будем ссылаться по мере повествования. Хост Linux действует как межсетевой экран между Internet и внутренней локальной сетью. Интерфейс Ethernet eth1 использует DSL, а интерфейс Ethernet eth2 — кабельный модем. Хост Linux выполняет балансировку нагрузки между исходящими сетевыми соединениями с двумя провайдерами Internet. Такой подход не ограничивается только высокоскоростными сетевыми каналами — подобные методы могут применяться и для распределения нагрузки между двумя коммутируемыми соединениями.

Хост в тестовой конфигурации представлял собой компьютер с двумя процессорами Intel Celeron с тактовой частотой 533 МГц, на котором работала операционная система Red Hat 6.2 с ядром Linux 2.2.18. Испытания проводились также с версией Red Hat 7.1 и ядром Linux 2.4.13. Представленная конфигурация не требует наличия ни двухпроцессорной системы, ни процессоров с тактовой частотой 533 МГц. В качестве межсетевого экрана можно приспособить старую систему с процессором Pentium/100 МГц и оперативной памятью емкостью 32 Мбайт. Некоторые примеры, приведенные в статье, рассчитаны на Red Hat, но их можно легко изменить таким образом, чтобы они будут приложимы к другим распространенным вариантам Linux.

КОНФИГУРИРОВАНИЕ ЯДРА

Ядро Linux 2.2 и более поздних версий поддерживает усовершенствованные методы маршрутизации, которые необходимы для выполнения балансировки нагрузки и предоставления нескольких маршрутов по умолчанию на хосте Linux. Для поддержки нескольких соединений с Internet при компиляции ядра следует задать следующие сетевые опции:

МАРШРУТИЗАЦИЯ IP ПО ИСТОЧНИКУ

По умолчанию, маршрутизация пакетов TCP/IP выполняется путем анализа IP-адресов назначения и поиска маршрута к указанной сети в таблице маршрутизации, просмотреть которую можно с помощью команды netstat -r. Если маршрут найден, пакет передается на этот сетевой интерфейс, в противном случае пересылается на шлюз, заданный по умолчанию. Для большинства систем, напрямую подключенных к Internet, по умолчанию в качестве шлюза выступает провайдер Internet. В нашем случае это означает, что все исходящие соединения Internet выходят из интерфейса DSL — не очень желательное явление в среде с избыточными соединениями. При добавлении в систему кабельного модема совсем не хочется, чтобы его соединения при ответе переходили на DSL.

Для решения этой проблемы с помощью команды ip создается несколько таблиц маршрутизации, а конкретная таблица выбирается в зависимости от IP-адреса отправителя исходящего пакета. Конфигурирование осуществляется посредством следующих команд.

Если исходящий пакет передается с адреса источника 63.89.102.157 (DSL), то поиск маршрута выполняется в Таблице маршрутизации 1, где имеются две записи:

С помощью первой строки локальный трафик маршрутизируется во внутреннюю сеть, а благодаря второй все оставшиеся пакеты пересылаются провайдеру Internet через интерфейс DSL. Таблица маршрутизации 2 для интерфейса кабельного модема используется таким же образом.

БАЛАНСИРОВКА НАГРУЗКИ

Балансировка нагрузки между исходящими из внутренней сети соединениями осуществляется с помощью опции ядра CONFIG_IP_ROUTE_MULTIPATH, которая позволяет определить несколько шлюзов по умолчанию. Для этого необходимо удалить шлюз по умолчанию из файла /etc/sysconfig/network и задать шлюз по умолчанию с помощью расширенных функций маршрутизации посредством следующей команды:

Следующая команда позволяет просмотреть усовершенствованную таблицу маршрутизации:

Опция ядра CONFIG_IP_ROUTE_MULTIPATH заставляет Linux, как сказано в документации /usr/src/linux/Documentation/ Configure.help, «рассматривать все эти пути (маршруты, заданные по умолчанию) как имеющие равную «стоимость» и выбирать один из них произвольным образом». Опция equalize в команде ip route указывает ядру Linux на необходимость балансировки нагрузки между исходящими соединениями на основе IP-адреса. Для конкретного IP-адреса ядро выбирает интерфейс, куда будут передаваться исходящие пакеты; затем ядро сохраняет это решение как запись в кэше маршрутизации для данного IP-адреса. Последующие соединения с указанным IP-адресом будут осуществляться через тот же самый интерфейс до тех пор, пока не истечет срок действия записи в кэше маршрутизации, просмотреть который можно с помощью команды ip route list cache.

КОНФИГУРАЦИЯ СЕРвисОВ

Проверить конфигурацию DNS можно с помощью команды dig (модификация команды nslookup):

позволяют организовать несколько именованных виртуальных хостов для Apache.

СЦЕНАРИИ НАЧАЛЬНОЙ ЗАГРУЗКИ

Для поддержки нашей сетевой конфигурации необходимо изменить несколько сценариев начальной загрузки. Они созданы для Red Hat, но легко модифицируются для любого другого варианта Linux. Команды ip rule нужно выполнять только после загрузки системы. Для этого в раздел начальной загрузки сценария /etc/rc.d/init.d/network следует добавить следующие строки:

Файл /etc/sysconfig/static-rules содержит:

Команды ip route должны выполняться каждый раз, когда инициируется ifup для соответствующего интерфейса. Добавьте следующие строки в /etc/sysconfig/ network-scripts/ifup-routes:

Файл /etc/sysconfig/static-routes содержит:

МЕЖСЕТЕВЫЕ ЭКРАНЫ

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

Большинство сценариев межсетевого экрана рассчитано только на одно внешнее сетевое соединение. Поддержку множества внешних сетевых интерфейсов можно реализовать с помощью нескольких специально разработанных сценариев. Первый использует поставляемый вместе с ядрами Linux 2.2 межсетевой экран под названием ipchains. Второй — поставляемый вместе с ядрами Linux 2.4 межсетевой экран под названием iptables. (Ядро Linux 2.4 позволяет установить межсетевой экран ipchains, но одновременная работа ipchains и iptables невозможна.)

По существу, iptables — это преемник ipchains, только более мощный, поскольку поддерживает контроль соединений, благодаря чему Linux получает межсетевой экран с контекстной проверкой. Кроме того, iptables является расширяемым, т. е. к нему можно добавлять новые функции (например, поиск соответствия строк), не изменяя при этом базовый исходный текст для iptables. Новые функции iptables описаны во врезке «Новые функции сценария межсетевого экрана iptables». И ipchains, и iptables разделяют трафик на несколько различных цепочек правил, которые определяют, нужно ли принять или отвергнуть пакет. В iptables для фильтрации пакетов применяются три таблицы цепочек, называемые filter, nat и mangle. При передаче пакета по цепочке последовательно проверяется каждое правило, пока не будет найдено соответствие.

Три стандартные цепочки в ipchains получили название INPUT, FORWARD и OUTPUT. Эти цепочки представлены в iptables в таблице фильтров: INPUT анализирует пакеты сразу же, как только они поступают на сетевой интерфейс; FORWARD исследует замаскированные пакеты; OUTPUT проверяет их до передачи на сетевой интерфейс. На Рисунке 2 представлен путь, который пакеты проходят при разделении на различные цепочки на межсетевом экране ipchains.

У межсетевого экрана iptables в таблице nat имеются две дополнительные цепочки — PREROUTING и POSTROUTING. Они служат для выполнения маскировки пакетов, или, иначе, преобразования сетевых адресов. После поступления на сетевой интерфейс все пакеты проходят эти цепочки перед дальнейшей отправкой.

В iptables цепочки INPUT и OUTPUT обрабатывают пакеты, предназначенные для межсетевого экрана, а цепочка FORWARD обрабатывает только замаскированные пакеты. На Рисунке 3 представлен путь, по которому следуют пакеты, проходя по различным цепочкам в межсетевом экране iptables.

Таблица mangle в iptables использует цепочки PREROUTING и OUTPUT для того, чтобы можно было изменять в пакетах такие флаги IP, как TTL (срок действия) и TOS (тип обслуживания).

КОНФИГУРАЦИЯ ЯДРА МЕЖСЕТЕВОГО ЭКРАНА

Чтобы создать межсетевой экран ipchains в ядре Linux 2.2, необходимо указать ниже перечисленные опции в файле конфигурации ядра:

Межсетевой экран iptables в ядре Linux 2.2 создается с помощью следующих опций в файле конфигурации ядра:

Добавить к своему ядру экспериментальные заплаты iptables можно, выполнив указанные инструкции.

Ответьте yes («да») на вопрос об установке следующих заплат:

Поскольку не все заплаты совместимы, выбирайте только те из них, которые намереваетесь использовать.

Укажите в качестве ответа m для опций CONFIG_IP_NF_ MATCH, которые вы добавили к ядру.

Обратите внимание, что приведенные команды написаны именно для ядра Linux 2.4.13 и заплат iptables 1.2.4. Предполагается, что эти экспериментальные функции войдут в состав основного ядра уже в ближайшем будущем.

СЦЕНАРИИ МЕЖСЕТЕВОГО ЭКРАНА

Чтобы установить сценарий межсетевого экрана в своей системе Red Hat 7.1, его следует поместить в /etc/init.d/firewall и выполнить команду:

Для конфигурации сценария межсетевого экрана в своей системе нужно отредактировать следующие две строки, чтобы определить имеющиеся внутренний и внешний интерфейсы:

Цепочка INPUT также допускает любые ответы (возвраты), инициированные локально для соединений в соответствии со следующими правилами в сценарии межсетевого экрана ipchains.

Это единственный способ разрешить обратный трафик TCP, поскольку ipchains не является межсетевым экраном с контекстной проверкой. iptables значительно улучшает защиту за счет поддержки работы межсетевого экрана с такой функциональностью. Он называется также «контроль соединения», т. е. пакет принимается только при соответствии активному соединению, инициатор которого находится во внутренней сети. Эта обработка оформляется в сценарии межсетевого экрана iptables соответствующим образом:

UDP — это протокол, не сохраняющий состояние, но контроль соединений iptables поддерживает таблицу состояний и допускает через порты UDP ответы для трафика, инициатор которого находится во внутренней сети.

Сценарий межсетевого экрана iptables принимает входящие соединения и размещает информацию о новых в базе данных контроля соединений в соответствии со следующими правилами:

Базу данных контроля соединений можно посмотреть, открыв файл /proc/net/ip_conntrack.

Приводимое ниже правило для iptables разрешает входящие активные соединения ftp на межсетевом экране с порта TCP 20 только для уже открытого сеанса ftp.

Следующее правило разрешает входящие запросы DNS к BIND:

Перечисленные ниже правила разрешают входящий трафик NTP из военно-морской обсерватории Соединенных Штатов:

Цепочка FORWARD просто маскирует соединения для систем во внутренней сети, используя преобразование сетевых адресов (Network Addresss Translation, NAT). Большинство протоколов работает с NAT, но некоторым необходима небольшая помощь со стороны специального модуля, который переписывает IP-адреса. Активным соединениям ftp требуется программа-помощник для преодоления межсетевого экрана; их можно замаскировать, загружая модули ip_masq_ftp (ipchains) или ip_nat_ftp (iptables) с командой modprobe (если они уже не скомпилированы в ядре). Удаленная машина на другой стороне активного соединения ftp пытается подключиться обратно к локальной машине через межсетевой экран для передачи данных. Модуль ip_masq_ftp перезаписывает пакеты соединения ftp так, что внутренняя машина кажется подключенной напрямую к Internet. В пассивном режиме ftp эта проблема решается за счет передачи всех данных через порт TCP 21. Если вы решите поддерживать ftp, помните, что он передает пароли по сети в виде обычного текста и не считается защищенным. Защищенная альтернатива ftp — это sftp; метод организации соединений он использует в качестве защищенного сокета. Сейчас sftp предлагается вместе с клиентскими инструментальными средствами OpenSSH.

Другие маскирующие модули для различных приложений можно найти в каталогах /lib/modules/?uname -r?/ipv4 (ipchains) или /lib/modules/?uname -r?/kernel/net/ipv4/netfilter/ (iptables).

Цепочка FORWARD использует следующие правила iptables при прохождении замаскированных пакетов через межсетевой экран:

Цепочка OUTPUT допускает только сетевой трафик (если он направляется через корректный интерфейс), а также выявляет приоритеты для определенного трафика, устанавливая флаги TOS. Так, с помощью флагов TOS можно указать, что интерактивный (SSH) трафик имеет приоритет перед трафиком ftp. К флагам TOS относятся минимизация задержки (Minimize-Delay), максимизация пропускной способности (Maximize-Throughput), максимизация надежности (Maximize-Reliability) и минимизация затрат (Minimize-Cost).

Многие провайдеры Internet игнорируют флаги TOS в пакетах, но их полезность очевидна, поскольку именно благодаря им опция ядра CONFIG_IP_ROUTE_TOS определяет приоритеты исходящего трафика. Это значит, что приложения с высокими требованиями к пропускной способности (например, крупный сервер ftp) могут выполняться с флагом «максимальная пропускная способность», а интерактивные приложения (такие, как SSH) — «с минимальной задержкой». Таким образом, ftp не будет негативно влиять на производительность вашего соединения SSH.

Флаги TOS устанавливаются в сценарии межсетевого экрана iptables в цепочках PREROUTING и OUTPUT таблицы mangle. Цепочка PREROUTING определяет приоритеты входящих, а OUTPUT — исходящих пакетов. Для минимизации задержки пакетов SSH используются следующие правила:

ПОДДЕРЖКА МЕЖСЕТЕВОГО ЭКРАНА

Чтобы проверить эффективность правил межсетевого экрана, сценарий межсетевого экрана следует выполнить, применив следующую команду:

Проанализируйте данные в первых двух столбцах полученного результата. Нули свидетельствуют о том, что ни один пакет не соответствует данному правилу. Это не всегда плохо — нули в поле правил DENY или DROP свидетельствуют, что никто не пытался проникнуть на ваш хост с помощью указанного правила. Нули в поле правила ACCEPT означают, что соответствующий трафик не был принят, однако трафик может соответствовать к правилу, находящемуся раньше в цепочке.

Эти сценарии межсетевого экрана разрешают обратный трафик только через непривилегированные порты, поэтому, чтобы разрешить обслуживание непривилегированных портов, конфигурацию SSH придется обновить, отредактировав файл ssh_config и добавив строку:

ВЫВОДЫ

Я использовал эту конфигурацию почти целый год и остался доволен ее производительностью. Однако исходящие соединения ставят несколько вопросов в тех случаях, когда канал перестает функционировать. Если один канал станет недоступен, то на этот случай избыточность для исходящих соединений обеспечивается с помощью второго канала на уровне приложений. Исходящие соединения, инициируемые локально, будут поддерживаться в единичных случаях до тех пор, пока не будет выполнена команда ifdown для интерфейса с провайдером Internet, на котором возник сбой. Если перерыв в работе окажется достаточно долгим, вы можете обновить DNS. Проблема возникает, когда выполняется ifup для интерфейса, поскольку во вторичную таблицу необходимо добавить записи о маршрутизации (например, ip route add 0/0 via 63.89.102.1 table 1). Сценарий ifup-routes был изменен для того, чтобы эти нетривиальные маршруты добавлялись автоматически. Если команда ifdown запускается на обоих интерфейсах, необходимо снова добавить маршрут по умолчанию в основную таблицу маршрутизации (например, ip route add default equalize nexthop via. ). Сценарии для выполнения различных алгоритмов восстановления после сбоя читателю предлагается написать самостоятельно в качестве упражнения.

Ресурсы Internet

Новые функции сценария межсетевого экрана iptables

Следует отметить, что iptables не только обеспечивает полноценную работу межсетевого экрана с контекстной проверкой, но и способен к расширению. Кроме того, iptables поддерживает более совершенные функции межсетевого экрана, чем ipchains. Некоторые из них требуют поддержки ядра, как описано выше в разделе «Конфигурация ядра межсетевого экрана».

iptables можно использовать для установки ограничений на новые входящие пакеты TCP, чтобы предотвратить атаки по типу «отказ в обслуживании». Это достигается с помощью следующих правил:

Эти правила ограничивают количество новых входящих соединений TCP (пакеты с установленным битом SYN) до 12 соединений в секунду после того, как окажется достигнут предел в 24 соединения в секунду.

Теперь можно установить соответствие любым флагам TCP, т. е. блокировать дерево XMAS (все флаги установлены) и пакеты NULL по следующим правилам:

Благодаря экспериментальной заплате netfilter psd межсетевой экран iptables может выявлять и блокировать сканирование входящих портов с помощью другого правила:

Экспериментальная заплата netfilter iplimit позволит межсетевому экрану iptables ограничить число соединений с конкретного IP-адреса посредством следующего правила:

Одна из наиболее мощных заплат netfilter предназначена для определения соответствия пакетов на основе их информационного наполнения. Экспериментальная заплата соответствия строк позволяет отфильтровать пакеты, если они относятся к определенной строке. Она дает возможность выявлять вирусы CodeRed или Nimda до их проникновения на сервер Web. Это можно сделать с помощью нескольких правил.

Вы можете также перенаправлять с порта пакеты UDP. Если трафик перенаправляется на конкретный порт, то для разрешения входящих соединений соответствующее правило в цепочке INPUT указывать не нужно.

Новые функции iptables появляются регулярно. Один из таких экспериментальных модулей — ip_nat_h323. Он позволит перенаправлять с порта входящие соединения NetMeeting через межсетевой экран. В момент написания данной статьи это решение находилось на стадии разработки.

Решено: Два интернет канала (Как бы их объеденить в один?)

Модератор: SLEDopit

Решено: Два интернет канала

Суть проблемы такова: есть подключение к интернет через локальную сеть (первый канал) и с недавних пор появилось второе подключение по выделенной линии (второй канал). дома две персоналки, два ноутбука и КПК. Роутер (Zyxel p-330w ee) подключен к первому каналу и раздает интернет на все это хозяйство.
Собственно чего я хочу: а хочу я использовать оба интернет соединения одновременно, дабы увеличить ширину канала и до кучи повысить надежность, чтобы в случае падения одного канала второй продолжал работать как ни в чем не бывало.

Собственно зачем обращаюсь на форум:
1) Возможно ли такое? В смысле не просто "подключение по двум интернетам", а именно чтобы они работали как один. Вариант с разделением трафика по двум каналам не интересен, хочется именно оба вместе. Возможно ли?
2) Если 1 возможно, то нужен будет девайс (по видимому интернет шлюз), порекомендуйте что-нибудь самое простенькое и недорогое. (Имеющийся роутер с этой задачей не справится).

Linux Advanced Routing & Traffic Control HOWTO
4.2.2. Распределение нагрузки.

Ну, какбы, то и значит (как я это представляю): стоит шлюз, в него приходят два шнурка из внешнего мира, к шлюзу подключен роутер, с настроенными LAN'ом и Wi-Fi, с которого интернет расходится по домашним компам. В случае каких-то неполадок на одном канале (упал сервер авторизации, обрыв кабеля иль еще какая зараза) второй канал работает и интернет соединение не обрывается, закачки с торрентов не обрываются, продолжаем работать в интернете как ни в чем не бывало, разве что скорость упадет. Ну и соотвественно если скорость одного канало 600кб/с, а скорость второго канала 1,5Мб/с - то на выходе хочется иметь общий канал 2.1Мб/с.

Подключил я себе дома помимо стандартного ADSL канала еще один канал интернет через витую пару. За ADSL канал абонентская плата для меня незначительна, поэтому решил оставить этот канал как запасной. Воткнул оба канала интернет в свой сервер-роутер на антресоле (для этого пришлось перевести ADSL роутер в режим bridge) и стал думать как сделать, чтобы оба канала работали одновременно.
Все нижеприведенные конфиги подходят для ОС Linux.
Мысль была такая,

Пустить мой основной рабочий комп через новый интернет канал (этот комп больше всего потребляет трафика)
Сам сервер-роутер (обновления ОС) и все остальные мобильные WiFi устройства пустить через ADSL канал.

Настройка заключается в том, чтобы роутить мой компьютер через один интерфейс интернета, а всех остальных клиентов, включая сам сервер-роутер через другой интерфейс и в этом нам поможет программа iproute и iptables.

В конфиг /etc/iproute2/rt_tables добавляем идентификаторы наших двух провайдеров. Я добавил в файл 2 строки

Числа и названия идентификаторов можно задавать произвольные, но потом в скрипте роутинга надо обязательно ссылаться на эти же названия.

Пример скрипта роутинга, который ставим в автозагрузку компьютера

А теперь в iptables вместо правил Nat занесем эти строки

Дефолтным маршрутом сервер-роутера я сделал gateway adsl провайдера. Т.е. если выходить в интернет с самого сервера, то инет пойдет через adsl соединение.
Добавляя нужные ip адреса для меток 1 или 2 в конфиг iptables можно управлять нагрузкой каналов. Для этого надо перезапускать только правила iptables. Скрипт роутинга трогать не нужно.

20 комментариев Работа с двумя провайдерами интернет одновременно

Господа, продолжая вышеизложенную тему можно проще. Берется роутер Asus PX3042H с двумя WAN портами, оба канала суммируюся в процентном отношении и все. У меня ADSL-3Mbit и выделенка-6Mbit в итоге на 1 LAN порту 9Mbit.

Есть намерения в PC установить три сетевые карты(одна встроенная) и ClearOs с режимом MultiWAN (может для iPTV другой режим нужен). В две Internet(2) и IPTV, соответственно, третью соединить с одним из LAN портом ASUS. В другой соединить со Свич, в Порт WAN ASUS подключить Internet(1).
Вопрос в том как все это настроить. Мои знания в *NIX близкие к нулю.

я так понял, что будет подключен asus через lan порт, а еще фактичести также к серверу будет и свич подключен.
4 же сетевые на сервере вы планировали? 1 встроенная + 3 pci..

нет мне хотелось бы ограничится 3 сетевыми (2+1 встроенная). Схема сети точно такая как у Вас на рисунке и задачи б! Почему я и заинтересовался данной темой.
Вместо ADSL модема ASUS wl500gpv2(WAN-ethernet c PPPoE), сервер подключен двумя картами на два выхода ONT (Optical Network Terminal) -интернет(2) и IPTV, а вместо компьютера на вашей схеме свичи 10 портов. Свичи находится в другом помещении. Покупка новых switch или роутеров и перепрокладка сетей не планируется. IPTV рассматривается как бонус, т.е. хотелось, но не обязательно.

Ну так если почти все как у меня, то думаю проблем не должно быть если все по этой инструкции делать 🙂
Вот только с выбором linux дистрибутива надо определиться. ClearOS может и хорошо для новичка, но как подсказывает опят не все можно проделать через web интерфейс, возможно придется ковыряться внутри командной строки.
Давайте так. Начните с чего-нибудь, чтобы приступить к решению задачи. Самое простое на мой взгляд это сделать доступ в инет через провайдера без pppoe. Для новичка все может быть трудно, даже прописать ip на интерфейсе.
Как будут появляться конкретные вопросы пишите здесь, постараюсь ответить.

У меня приведен случай когда ip адреса провайдеров всегда одни и теже. Если они меняются, то тут не подскажу правильный конфиг.
Определить всё достаточно просто, надо провод провайдера к себе в компьютер воткнуть и получить адрес который выдал провайдер. В зависимости от операционной системы посмотреть нужными командами какой адрес сейчас у компьютера и маршрут по умолчанию.
Ну с адресом все итак понятно, а P1_NET будет шлюз по умолчанию, только на конце 0/24, а первые три цифры оставить как есть.

Т.к. я подключаюсь через dhclient, приходится изучать файл dhclient.leases. Первые три цифры тоже меняются, вот к примеру два подключения и данные каждый раз меняются:

fixed-address 100.68.229.190;
option subnet-mask 255.255.255.252;
option dhcp-lease-time 518400;
option routers 100.68.229.189;
option dhcp-message-type 5;
option dhcp-server-identifier 100.68.229.189;

fixed-address 100.84.105.213;
option subnet-mask 255.255.255.252;
option dhcp-lease-time 518400;
option routers 100.84.105.214;
option dhcp-message-type 5;
option dhcp-server-identifier 100.84.105.214;

Понятно что у вас с адресами и почему они так меняются. Это частные адреса сети 100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Т.е провайдер выдает не белый адрес, а потом делает NAT на белый. Ну и вы еще свою сеть 192.168.2.0/24 натите. Двойной NAT в этом случает будет. Это нормально работает, но пробросы портов в таком случае уже не будут работать. Просто имейте это ввиду.
как я понял вы уже в качестве переменных все прописали в конфиг роутинга?

А задача ваша очень просто решается, я так у себя делал, чтобы определенные сайты работали только через определенного провайдера.
Вычисляете ip к которому надо делать определенные подключения и добавляете в конфиг iptables 2 строчки

iptables -t mangle -A PREROUTING -s 192.168.2.0/24 ! -d xx.xx.xx.xx/32 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -d xx.xx.xx.xx/32 -j MARK --set-mark 1

соотверсвенно маркируете сами меткой 1 или 2 в зависимости от провайдера. Таким образом первая строчка запрещает сети 192.168.2.0/24 маркировать трафик на ip xx.xx.xx.xx, а вторая строчка маркирует его нужной меткой провайдера. и доступ к этому ip будет именно с нужного провайдера. Соответсвенно можно задавать разные маски адресов и маркировать не только один ip но и целый диапазон.

Тут только один минус, в iptables нельзя задавать fqdn имена. Но вы почитайте возможно есть скрипты, которые сначала по fqdn вычисляют ip сайта и потом уже в iptables можно оперировать ip.

Сейчас я использую как мне кажется более красивое решение. Я ушел от настройки 2 провайдеров на linux машине в сторону RouterOS. (продукция Mikrotik ) Но это не бесплатно, но и не очень дорого. Принцип логики там в двух провайдерах аналогичный, а вот сайты на которые надо ходить через определенный ip просто добавляются в одну таблицу по имени dns и сразу все работает..

Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе "policy routing" (т.е. маршрутизация на основе политик), а не "destination routing" (маршрутизация на основе адреса получателя).
Итак, приступим. Для начала определимся с переменными:

IF- это сетевые интерфейсы, которые смотрят в интернет, через наших провайдеров

IP - это наши внешние IP-адреса, которые нам выдали провайдеры

P - это шлюзы по умолчанию у наших провайдеров
Policy routing позволяет выполнять маршрутизацию на основе адреса источника поэтому перечислим сервера которые будут участвовать:

Здесь SRV11 и SRV12 - это два айпишника одного и того же сервера (это важно!), это позволяет одному серверу обрабатывать входящие соединения с двух провайдеров. Конечно же, существуют и другие варианты реализовать эту возможность, но я буду использовать именно айпишники, мне кажется для начала так будет прошё.
Ну а теперь самое интересное - пишем правило для маршрутизации.
Первое что мы должны сделать это добавить свои таблицы маршрутизации, для этого необходимо отредактировать файл /etc/iproute2/rt_tables , например так:

Заполняем первую таблицу:

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1

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

ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
Затем разберемся с основной таблицей, которая называется "main". Ее мы видим, когда набираем ip route:
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip route add default via $P1 metric 10

Первые две строчки аналогичны предыдущим записям, только опущено " table main ". В третьей строчке задается маршрут по умолчанию с указанием метрики.
На этом с маршрутизацией разобрались, чтобы посмотреть что у нас находится в таблице маршрутизации можно выполнить команду " ip route show table <имя таблицы>". Теперь приступим к правилам. Как раз по правилам и будет приниматься решения какой пакет по какой таблице будет маршрутизироваться.

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

Здесь мы указали, что если адрес источника равен первому внешнему адресу, тогда маршрутизация выполняется по таблице T1. Аналогично вторая запись.
И наконец самое интересное:

ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2

На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов, а SMTP сервер будет выходить наружу через основного провайдера.

export GLOBAL_ETH_PRIM=eth1
export GLOBAL_ETH_SEC=eth2
export GLOBAL_IP_PRIM=10.10.10.10
export GLOBAL_IP_SEC=20.20.20.20
export MARK_PRIM=10
export MARK_SEC=20

Назовем этот файл ipt_p1.conf . А содержит он данные о том, какой из интерфейсов является главным, а какой запасным (PRIM и SEC соответственно) и значения для маркировки пакетов.
Перейдем к основному файлу конфигурации iptables, назовем его ipt.conf. Запишем переменные

Это для того, чтобы меньше зависеть от дистрибутива - пути к исполняемым файлам.
LOCAL_ETH=eth0
GLOBAL_ETH_P1=eth1
GLOBAL_ETH_P2=eth2
LOCAL_IP=192.168.0.1
LOCAL_NET=192.168.0.0/24
GLOBAL_IP_P1=10.10.10.10
GLOBAL_IP_P2=20.20.20.20

Тут мы описали конфигурацию нашей сети, по порядку: локальный интерфейс, интерфейсы, которые смотрят к провайдерам, локальный айпишник и подсеть, айпишники, которые выданы провайдерами.

Зацепили внешние настройки, в данном случае это будет наш файл ipt_p1.conf .
Хватит о скучном, приступим к настройке, причем попытаемся все сделать красиво:

echo "[+] Flushing existing iptables rules. "
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t raw
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

Очищаем все правила iptables, в первой строке говорим, что делаем, почему по английски, а чтобы не было проблем с кодировками. Последние три строчки устанавливают правила по умолчанию - все пакеты не подходящие под список правил будут просто отброшены.

Загрузили модули ядра, которые будем использовать.
Теперь пройдемся по цепочкам iptables и заполним их необходимыми правилами:

echo "[+] Setting up INPUT chain. "

$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Используя возможности модуля state мы отбрасываем некорректные пакеты и принимаем пакеты относящиеся к уже установленным соединениям либо ко вторичными соединениям (таким как передача данных в ftp).

$IPTABLES -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
Локальный трафик будет ходить без ограничений, хотя это не всегда правильно.

Тоже на localhost .
Продолжаем с цепочкой OUTPUT:

echo "[+] Setting up OUTPUT chain. "

$IPTABLES -A OUTPUT -m state --state INVALID -j DROP
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p udp --dport 53 -j ACCEPT Мы разрешили работать нашему DNS серверу через основного провайдера
$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -o $LOCAL_ETH -d $LOCAL_NET -m state --state NEW -j ACCEPT

Опять же на исходящий локальный трафик ограничений нет.
Переходим к обработке трафика из локальной сети:

echo "[+] Setting up FORWARD chain. "

$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT Так у нас получается, что пакеты приходящие на первого провайдера пропускаются только на первый айпишник сервера, второго - на второй.
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV11 -j ACCEPT
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV12 -j ACCEPT

Разрашаем весь исходящий трафик с нашего сервера, опять же это не совсем правильно.
Далее идут правила NAT:

$IPTABLES -t nat -A POSTROUTING -s $SRV11 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM
$IPTABLES -t nat -A POSTROUTING -s $SRV12 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2

Итак, наши правила:

$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM

Все пакеты уходящие с нашего внутреннего сервера на 25 порт мы маркируем значением $MARK_PRIM. Давайте проследим, что это нам дает: исходящий пакет маркируется значением 10, значит маршрутизироваться он будет по таблице T1, а соответствуя этой таблице пакет должен уйти через первого провайдера, в цепочке FORWARD есть разрешающее правило, поэтому пакет безпрепятственно проходит - все правильно это нам и требовалось.
Теперь нам надо разобраться с соединениями идущими к нам. Сначала, конечно же, должен отработать DNAT:

$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 25 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 3389 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 25 -j DNAT --to-destination $SRV12
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 3389 -j DNAT --to-destination $SRV12

Вроде бы все правильно, проверяем: пакет приходит на внешний интерфейс шлюза, в зависимости от принадлежности интерфейса провайдеру, он перенаправляется на первый или второй айпишник внутреннего сервера, сервер отвечает с того же(!) айпишника, пакет на шлюзе маршрутизируется по основной таблице, проходит через FORWARD и отправляется через основного провайдера, а вот это уже не правильно, ведь пакет мог прийти и через запасного провайдера. Исправляем, добавляя правила:

Читайте также: