Linux Advanced Routing & Traffic Control HOWTO

 ___/ \_ +------+-------+ +------------+ |
 _/ \__ | if1 | /
/ \ | Linux | |
| Локальная сеть-----+ маршрутизатор| | Internet
\_ __/ | | |
 \__ __/ | if2 | \
 \___/ +------+-------+ +------------+ |
 | | | \
 +-------------+ Провайдер 2+-------
 | | |
 +------------+ \_______

В этом случае обычно возникает два вопроса.

4.2.1. Раздельный доступ

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

Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос.

Warning

Заметка читателя Рода Роака (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

Итак, мы рассмотрели очень простой пример. Он будет работать для всех процессов, выполняющихся на маршрутизаторе и для локальной сети, если настроено преобразование адресов (NAT/masquerading). В противном случае, вам будет необходим диапазон IP адресов обоих провайдеров, или выполнять маскирование для одного из провайдеров. В любом случае, вы можете задать правила выбора провайдера для каждого конкретного адреса вашей локальной сети.

4.2.2. Распределение нагрузки.

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

Вместо выбора одного из провайдеров в качестве маршрута по-умолчанию, вы настраиваете т.н. многолучевой (multipath) маршрут. В стандартном ядре это обеспечит балансировку нагрузки между двумя провайдерами. Делается это следующим образом (повторюсь, мы основываемся на примере из раздела Раздельный доступ):

ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
 nexthop via $P2 dev $IF2 weight 1

Результатом команды будет попеременный выбор маршрута по-умолчанию. Вы можете изменить параметр weight, так чтобы один из провайдеров получал большую нагрузку.

Обратите внимание, что балансировка не будет идеальной, так как она основывается на маршрутах, а маршруты кэшируются. Это означает, что маршруты к часто посещаемым сайтам не будут проходить через разных провайдеров.

Если вы действительно интересуетесь этим, вам стоит посмотреть на патчи Юлиана Анастасова (Julian Anastasov), расположеные по адресуОни могут вам помочь.

Глава 5. GRE и другие тоннели.

В ОС Linux поддерживаются 3 типа тоннелей. Это тоннелирование IP в IP, GRE тоннелирование и тоннели не-ядерного уровня (как, например, PPTP).

5.1. Несколько общих замечаний о тоннелях:

Тоннели могут использоваться для очень необычных и интересных вещей. Также они могут усугубить ситуацию, если они сконфигурированы неправильно. Не задавайте маршрут по умолчанию через тоннель, если только вы ТОЧНО не уверены в том, что делаете :-). Далее, тоннелирование увеличивает нагрузку на систему и сеть, потому что добовляются дополнительные IP-заголовки. Обычно, это 20 байт на пакет. Таким образом, если обычный размер пакета (MTU) в сети равен 1500 байтам, то при пересылке по тоннелю, пакет может содержать только 1480 байт. Это не обязательно становится проблемой, но помните о необходимости правильной настройки фрагментации пакетов, если вы соединяете большие сети. Ах да, и конечно самый быстрый способ "прорыть" тоннель — это "рыть" с обоих сторон.

5.2. Тоннелирование IP в IP.

Этот тип тоннелирования доступен в Linux уже давно. Для его работы требуются два модуля ядра: ipip.o и new_tunnel.o.

Допустим у вас есть три сети: внутренние сети A и B, и промежуточная сеть C (например, Internet). Итак, сеть A:

сеть 10.0.1.0
маска 255.255.255.0
маршрутизатор 10.0.1.1

Адрес маршрутизатора в сети С — 172.16.17.18.