вот у меня статика, и можно сделать так. подсети мне не нужны, нужна доступность хоста по 2м адресам. для динамических ip скрипт пишется в папку ifup.d
Первый вопрос заключается в том, как организовать маршрутизацию таким образом, чтобы ответы на запросы, приходящие через определенного провайдера, скажем ровайдера 1, уходили через того же провайдера.
Давайте определим некоторые переменные. Пусть $IF1 будет именем первого интерфейса (if1 на рисунке), а $IF2 — именем второго. Тогда $IP1 будет IP адресом $IF1 , а $IP2 — IP адресом $IF2 . Далее, $P1 это IP-адрес шлюза провайдера 1, а $P2 — IP адрес шлюза провайдера 2. Наконец, $P1_NET это IP сеть, к которой принадлежит $P1 , а $P2_NET — сеть, к которой принадлежит $P2 .
Создадим две дополнительные таблицы маршрутизации, скажем T1 и T2 . Добавим их в файл /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
Ничего особо эффектного, маршрут к шлюзу и маршрут по-умолчанию через этот шлюз. Точно так же, как и в случае одного провайдера, но по таблице на каждого провайдера. Заметьте, что маршрута к сети, в которой находится шлюз достаточно, потому что он определяет как найти все хосты в этой сети, включая сам шлюз.
Теперь нужно настроить главную таблицу маршрутизации. Хорошо бы маршрутизировать пакеты для сетей провайдеров через соответствующие интерфейсы. Обратите внимание на аргумент `src’, который обеспечивает правильный выбор исходного IP-адреса.
ip route add $P1_NET dev $IF1 src $IP1 ip route add $P2_NET dev $IF2 src $IP2
Теперь задаем маршрут по умолчанию:
ip route add default via $P1
Зададим правила маршрутизации. Они будут отвечать за то, какая таблица будет использоваться при маршрутизации. Вы хотите, чтобы пакет с определенным адресом источника маршрутизировался через соответствующий интерфейс:
ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос.
Заметка читателя Рода Роака (Rod Roark): ‘ если $P0_NET это локальная сеть, а $IF0 — соответствующий ей интерфейс, желательно задать следующие команды:
ip route add $P0_NET dev $IF0 table T1 ip route add $P2_NET dev $IF2 table T1 ip route add 127.0.0.0/8 dev lo table T1 ip route add $P0_NET dev $IF0 table T2 ip route add $P1_NET dev $IF1 table T2 ip route add 127.0.0.0/8 dev lo table T2
Второй вопрос заключается в балансировке нагрузки между двумя провайдерами. Это не сложно, если у вас уже настроен раздельный доступ, описанный в предыдущем разделе.
Вместо выбора одного из провайдеров в качестве маршрута по-умолчанию, вы настраиваете т.н. многолучевой (multipath) маршрут. В стандартном ядре это обеспечит балансировку нагрузки между двумя провайдерами. Делается это следующим образом (повторюсь, мы основываемся на примере из раздела Раздельный доступ ):
ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \ nexthop via $P2 dev $IF2 weight 1
Результатом команды будет попеременный выбор маршрута по-умолчанию. Вы можете изменить параметр weight , так чтобы один из провайдеров получал большую нагрузку.
Обратите внимание, что балансировка не будет идеальной, так как она основывается на маршрутах, а маршруты кэшируются. Это означает, что маршруты к часто посещаемым сайтам не будут проходить через разных провайдеров.
Источник
Linux + 2 ISP. И доступность внутреннего сервера через обоих провайдеров
Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.
Описание проблемы
Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.
Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.
Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.
Как должно быть
А нельзя ли как-то поменять порядок — сначала отслеживать, какой нужен провайдер, а потом уже на основании этого выбирать next hop?
Можно. Для этого в Linux есть интерфейс к его отслеживателю соединений — conntrack match и CONNTRACK target. Первый из них — это условие соответствия пакета правилу, согласно которому будут обработаны только те пакеты, в которых специальная метка — метка соединения — имеет определённое значение. Второй — это средство управления меткой соединения.
Метки соединений отличаются от обычных меток пакетов (MARK) тем, что дополнительно обслуживаются и поддерживаются модулем conntrack. Если мы назначаем пакету метку соединения, то в дальнейшем эта метка будет обнаружена на всех пакетах, относящихся к этому же соединению. Отслеживание соединений и восстановление метки происходит после завершения обработки таблицы raw (цепочка PREROUTING или OUPTUT), перед обработкой этих же цепочек таблицы mangle, а запоминание метки соединения в conntrack — в цепочке POSTROUTING после обработки таблицы nat.
Мы можем с самого начала, ещё даже до того, как произошёл наш DNAT на внутренний сервер, назначить соединению метку, например, в зависимости от интерфейса, через который попал этот пакет на маршрутизатор. После этого, все последующие пакеты и ответы мы будем видеть с этой же меткой — т.е. в любой момент времени для любого ответа знать, через какой интерфейс он должен выйти.
В Linux есть RPDB — Routing Policy DataBase — это то же самое, что в Cisco называется route-map — база данных политик маршрутизации. При этом, мы создаём несколько разных таблиц маршрутизации, а выбор, по какой из них будет происходить обработка пакета, будет делаться на основании политик. Критериями выбора таблицы могут быть: интерфейс, через который вошёл наш пакет; метка netfilter (nfmark); адрес отправителя; адрес назначения и другие.
Метка netfilter (nfmark) — подходящий для этого случая критерий. Это не то же самое, что метка соединения (ctmark), но что нам мешает установить nfmark на основании ctmark? Напротив, в CONNTRACK target есть специальная команда как раз для этого.
Настройка
Для начала, настроим RPDB. Я не буду назначать таблицам имён — это выходит за рамки темы, тем более, что в данном случае нагляднее будут именно номера. Правила условной маршрутизации добавляются задаются при поднятии соответствующих интерфейсов, убиваются при останове.
ip rule add fwmark — это как раз те самые правила: если стоит метка 1, маршрутизируй через 201, если 2 — через 202. Другие два правила — это обычный split-access (как описано в LARTC). Если ни один из критериев не совпадёт, маршрутизация пойдёт по таблице по умолчанию (это справедливо для начальных пакетов соединений, инициированных из локальной сети или на маршрутизаторе).
В таблицы маршрутизации мы (также динамически, при поднятии интерфейсов) добавляем правила:
(если у нас не ppp, то правила будут такими: default via table 20N или metric 2000) Это, собственно, тоже по LARTC. Метрика задаёт приоритет провайдера (будет выбран маршрут с минимальной метрикой), но для помеченых пакетов будут обрабатываться таблицы 201 и 202 соответственно, в каждой из которых по одному провайдеру.
Осталось начать метить пакеты.
Нужно обратить внимание на три момента.
Во-первых, вся обработка происходит в цепочке PREROUTING таблицы mangle. Это потому, что мы хотим метить пакеты (поэтому mangle) до того, как произойдёт обработка этих меток при маршрутизации (поэтому PREROUTING).
Во-вторых, задание метки соединения происходит только для головных пакетов (-ctstate NEW) — остальные и так её имеют. Если новый пакет не имеет метки соединения, то его вообще никак обслуживать не надо — он пойдёт по таблице по умолчанию. Это справедливо для всех соединений, инициированных из локалки.
Под «номера провайдеров» задействовано 2 бита, т.е. мы таким способом мы можем сделать 3 аплинка (0 всегда остаётся под «неопределённый провайдер», для таких пакетов будет использоваться маршрут по умолчанию). Поэтому везде метки написаны с маской /0x3 — наши команды никак не будут влиять на все остальные биты меток, и их можно задействовать под другие цели. У меня, например, другие биты задействованы под шейпинг трафика.
А можно и по-другому
Назначаем внутреннему серверу второй адрес. Для этого адреса в rpdb назначаем выход через второго провайдера, и DNAT для пакетов, попавших к нам через второго провайдера, делаем на этот второй адрес.
Проще? В каком-то смысле да. Зато придётся обслуживать по N адресов на внутреннем сервере (по число провайдеров) и N правил DNAT.
Источник
«Щадящая» балансировка между несколькими провайдерами на офисном шлюзе
Эта статья описывает конфигурацию шлюза под управлением Linux для балансировки трафика между каналами разных провайдеров.
Результат, достигаемый в этом руководстве, отличается от результата подобных руководств: для каждого клиента используется один и тот же внешний IP-адрес, что избавляет от проблем с интернет-сервисами, которые не готовы к смене IP-адреса клиента в рамках одной сессии.
Проблемы
Для рядового потребителя, не обладающего ни одним собственным блоком адресов и не участвующего в обмене маршрутами на уровне операторов связи, доступ к интернету возможен только с тех адресов, которые предоставляет ему каждый интернет-провайдер для каждого канала. Это означает, что любое подключение нескольких каналов от «бытовых» интернет-провайдеров к одному узлу требует не только выбора между разными вышестоящими шлюзами, но ещё и выбора правильного исходящего адреса для общения с ними.
Такое положение дел идёт вразрез с тем, как работает стандартный механизм маршрутизации. В общем случае маршрут в таблице маршрутизации зависит только от адреса назначения и не меняет адрес отправителя. Поэтому первая задача, которую требуется решить — организовать соответствие интерфейса отправки, шлюза и исходящего адреса при пересылке пакетов от клиентов.
Вторая задача, которую нужно решить, состоит в том, как разумно распределить нагрузку от клиентов.
Балансировка с использованием многолучевых маршрутов (как по ссылке в начале статьи) осуществляется по адресу назначения и не всегда выглядит привлекательным решением. Там, где стоило бы иметь одинаковый внешний адрес, у клиента в одной сессии может получиться разный и наоборот — при обращении к популярным ресурсам, все клиенты будут использовать один общий канал.
Балансировка по адресу отправителя может послужить компромиссом между совместимостью и гранулярностью распределения. У каждого компьютера в локальной сети будет всегда один и тот же внешний адрес и при немалом числе компьютеров в сети мы получим сносное распределение нагрузки по каналам. Такого деления можно добиться, если образовать от локальных адресов хэши, поделить всё пространство хэшей пропорционально весам каналов и использовать значение этого хэша для выбора канала.
Инструменты
В ядре Linux есть возможность использовать одновременно несколько разных таблиц в зависимости от того, каким критериям соответствует пакет. Часто этот механизм называют policy based routing (PBR). Управление этим механизмом осуществляется через набор утилит iproute2.
Несколько упрощая постановку задачи, можно сказать: всё, что от нас требуется для разграничения маршрутов, интерфейсов и исходящих адресов — это создать для каждого провайдера дополнительную таблицу маршрутизации, имеющую вид, как если бы этот канал этого провайдера был единственным. Затем нужно добавить правила (те самые политики маршрутизации), пускающие в ход подходящую таблицу маршрутизации для соответствующего ей трафика.
Что же касается балансировки по отправителю, то для этого можно воспользоваться сетевым фильтром ядра — netfilter (iptables). С помощью действия HMARK мы промаркируем пакет хэшом от адреса. По критерию fwmark в правилах маршрутизации (команда ip rule) мы направим пакет в нужную таблицу маршрутизации. iproute2 и iptables здесь неплохо играют в паре.
Пример
В качестве примера возьму шлюз на базе Debian, который предоставляет доступ к интернету через три канала от двух разных провайдеров. Такой пример выбран специально, так как он рассматривает щекотливую ситуацию, когда один и тот же вышестоящий шлюз одного провайдера доступен через 2 разных провода. Описываемая конфигурация будет иметь схожий вид и во всех других debian-подобных операционных системах, включая Ubuntu.
Шлюз имеет 4 рабочих интерфейса:
Инт.
Описание
Ёмкость
Адрес
Шлюз
eth0
локальная сеть
10.0.0.1/16
—
eth1
первый канал первого провайдера
100 Мбит/с
100.1.1.92/24
100.1.1.1
eth2
единственный канал от второго провайдера
80 Мбит/с
200.2.2.22/24
200.2.2.1
eth3
второй канал первого провайдера
100 Мбит/с
100.1.1.93/24
100.1.1.1
Каждый канал подключен через обычный ethernet со статическим адресом.
Начальное состояние
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
# The loopback network interface auto lo iface lo inet loopback
auto eth0 iface eth0 inet static address 10.0.0.1 netmask 255.255.0.0
auto eth2 iface eth2 inet static address 200.2.2.22 # gateway 200.2.2.1 #correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0
auto eth3 iface eth3 inet dhcp address 100.1.1.93 # gateway 100.1.1.1 # correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0
Как видите, только на одном из интерфейсов обозначен маршрут по умолчанию.
В /etc/sysctl.conf значение net.ipv4.ip_forward установлено равным 1. Пакет iptables-persistent установлен и содержимое файла /etc/iptables/rules.v4 таково:
Только три правила для трансляции адресов у пакетов, исходящих через три внешних интерфейса. Не принципиально использовать именно маскарад, но я остановился на нём. Поскольку в данный момент шлюз настроен только на одном интерфейсе, на деле работает только первое правило.
Правила маршрутизации
# # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
# The loopback network interface auto lo iface lo inet loopback up ip route add 127.0.0.0/8 dev lo table Provider1_Cable1 up ip route add 127.0.0.0/8 dev lo table Provider2 up ip route add 127.0.0.0/8 dev lo table Provider1_Cable2
auto eth0 iface eth0 inet static address 10.0.0.1 netmask 255.255.0.0 up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable1 up ip route add 10.0.0.0/16 dev eth0 table Provider2 up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable2
auto eth1 iface eth1 inet static address 100.1.1.92 gateway 100.1.1.1 netmask 255.255.255.0 up ip route add 100.1.1.0/24 dev eth1 table Provider1_Cable1 up ip route add default dev eth1 via 100.1.1.1 table Provider1_Cable1 up ip rule add from 100.1.1.92 table Provider1_Cable1
auto eth2 iface eth2 inet static address 200.2.2.22 # gateway 200.2.2.1 #correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0 up ip route add 200.2.2.22/24 dev eth2 table Provider2 up ip route add default dev eth2 via 200.2.2.1 table Provider2 up ip rule add from 200.2.2.22 table Provider2
auto eth3 iface eth3 inet dhcp address 100.1.1.93 # gateway 100.1.1.1 # correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0 up ip route add 100.1.1.0/24 dev eth3 table Provider1_Cable2 up ip route add default dev eth3 via 100.1.1.1 table Provider1_Cable2 up ip rule add from 100.1.1.93 table Provider1_Cable2
Обратите внимание: в основную таблицу маршрутизации всё равно попадает только один gateway — все директивы gateway, кроме одной, закомментированы. Здесь дополнительные маршруты и правила оформлены директивами up, которые просто выполняют команду при поднятии интерфейса. Команды добавления маршрутов и правил сгруппированы под интерфейсами, через которые они могут быть реализованы — яснее всего это видно на примере интерфейса lo.
Перезагрузив сеть, мы можем заметить, как изменился вывод списка правил в команде ip rule list:
Соответствующую таблицу можно просмотреть командой «ip ro li table XXX».
Уже в таком положении сервер готов использовать все интерфейсы сразу. Проверим это, попробовав воспользоваться всеми интерфейсами по очереди и сверяя наблюдаемый внешней стороной адрес:
Если на внешних интерфейсах реальные «белые» адреса, то можно попробовать присоединиться к серверу, используя любой адрес — сервер будет общаться через каждый из них через правильный канал и правильного провайдера. Если всё так, то самое сложное позади.
Балансировка
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
# The loopback network interface auto lo iface lo inet loopback up ip route add 127.0.0.0/8 dev lo table Provider1_Cable1 up ip route add 127.0.0.0/8 dev lo table Provider2 up ip route add 127.0.0.0/8 dev lo table Provider1_Cable2
auto eth0 iface eth0 inet static address 10.0.0.1 netmask 255.255.0.0 up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable1 up ip route add 10.0.0.0/16 dev eth0 table Provider2 up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable2
auto eth1 iface eth1 inet static address 100.1.1.92 gateway 100.1.1.1 netmask 255.255.255.0 up ip route add 100.1.1.0/24 dev eth1 table Provider1_Cable1 up ip route add default dev eth1 via 100.1.1.1 table Provider1_Cable1 up ip rule add from 100.1.1.92 table Provider1_Cable1 up ip rule add from 10.0.0.0/8 fwmark 10000 table Provider1_Cable1 up ip rule add from 10.0.0.0/8 fwmark 10003 table Provider1_Cable1 up ip rule add from 10.0.0.0/8 fwmark 10006 table Provider1_Cable1 up ip rule add from 10.0.0.0/8 fwmark 10009 table Provider1_Cable1 up ip rule add from 10.0.0.0/8 fwmark 10012 table Provider1_Cable1
auto eth2 iface eth2 inet static address 200.2.2.22 # gateway 200.2.2.1 #correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0 up ip route add 200.2.2.22/24 dev eth2 table Provider2 up ip route add default dev eth2 via 200.2.2.1 table Provider2 up ip rule add from 200.2.2.22 table Provider2 up ip rule add from 10.0.0.0/8 fwmark 10002 table Provider2 up ip rule add from 10.0.0.0/8 fwmark 10005 table Provider2 up ip rule add from 10.0.0.0/8 fwmark 10008 table Provider2 up ip rule add from 10.0.0.0/8 fwmark 10011 table Provider2
auto eth3 iface eth3 inet dhcp address 100.1.1.93 # gateway 100.1.1.1 # correct gateway value, but commented out to avoid routing conflicts netmask 255.255.255.0 up ip route add 100.1.1.0/24 dev eth3 table Provider1_Cable2 up ip route add default dev eth3 via 100.1.1.1 table Provider1_Cable2 up ip rule add from 100.1.1.93 table Provider1_Cable2 up ip rule add from 10.0.0.0/8 fwmark 10001 table Provider1_Cable2 up ip rule add from 10.0.0.0/8 fwmark 10004 table Provider1_Cable2 up ip rule add from 10.0.0.0/8 fwmark 10007 table Provider1_Cable2 up ip rule add from 10.0.0.0/8 fwmark 10010 table Provider1_Cable2 up ip rule add from 10.0.0.0/8 fwmark 10013 table Provider1_Cable2
Для каждого интерфейса добавились строчки вида «up ip rule add from 10.0.0.0/8 fwmark MARK table TABLE». Каждая из них отправляет пакеты с соответсвующей маркировкой на маршрутизацию в указанную таблицу. В моём примере числа перемешаны между интерфейсами ради равномерности.
Тема «разжёвана» просто на все 100%, если бы наши преподаватели так материал могли доносить до студентов, то Билли работал бы на нас. 🙂 
Судя по всему, вместо 
всё очень круто описано, но нельзя ли выложить полный скрипт без размышлений вслух? 
пример бы реализации, когда одно соединение ppp 
Внесу поправку, автор немного не верно написал.. 
