Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

На маршрутизаторе A :

# ip addr add dev eth1 10.0.0.0/31

# ip addr add dev eth2 10.0.0.2/31

# ip addr add dev teql0 10.0.0.4/31

На маршрутизаторе B :

# ip addr add dev eth1 10.0.0.1/31

# ip addr add dev eth2 10.0.0.3/31

# ip addr add dev teql0 10.0.0.5/31

Теперь маршрутизатор A должен "пинговать" адреса 10.0.0.1, 10.0.0.3 и 10.0.0.5 по двум реальным каналом и одному компенсаторному устройству. Аналогично, маршрутизатор B должен пинговать 10.0.0.0, 10.0.0.2 и 10.0.0.4.

Если все работает, на маршрутизаторе A маршрут к сети 2 должен проходить через 10.0.0.5, а маршрутизатор B должен иметь адрес 10.0.0.4 в качестве маршрута к сети 1. Для отдельного случая, когда сеть 1 это ваша домашняя сеть, а сеть 2 — Internet, маршрутизатор A должен иметь шлюз по умолчанию 10.0.0.5.

Не все так просто как кажется. На интерфейсах eth1 и eth2, маршрутизаторов A и B , необходимо отключить фильтрацию по адресу возврата (return path filtering), иначе будут фильтроваться пакеты, предназначеные для другого интерфейса:

# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

# echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

Следующая проблема — это порядок пакетов. Допустим нужно передать 6 пакетов от A к B. По интерфейсу eth1 могут пройти пакеты 1, 3 и 5. Соответственно по eth2 пройдут 2, 4 и 6. В идеальном мире, маршрутизатор B получил бы эти пакеты в порядке 1, 2, 3, 4, 5, 6. Но в нашем мире вероятность того, что порядок изменится, очень велика. Например, порядок может быть таким: 2, 1, 4, 3, 6, 5. И это может запутать стек TCP/IP. Хотя эта проблема не так важна, для каналов с большим количеством разных сеансов TCP/IP, тем не менее вы не сможете ощутить значительный прирост скорости при передаче одного файла по ftp, разве только отправляющая или получающая ОС — не Linux, которую весьма не просто шокировать простым изменением порядка пакетов.

Однако, для многих приложений балансировка нагрузки является хорошим решением.

Уильям Стирнс (William Stearns) использовал сложную конфигурацию тоннелей для достижения эффективного использования нескольких несвязанных подключений к сети Internet. Информацию об этом можно найти здесь.

В дальнейшем данный документ, вероятно, будет содержать больше информации по этому вопросу.

До сих пор мы детально разбирались с работой iprouteи лишь вскользь упомянули netfilter. Теперь настало самое время поговорить о нем. Для начала рекомендую вам прочитать Remarkably Unreliable Guides.

Netfilter позволяет выполнять фильтрацию трафика и вносить изменения в заголовки пакетов. Одна из замечательных особенностей netfilter — это возможность устанавливать числовые метки на пакеты.

Например, следующее правило пометит все пакеты, отправляемые на порт 25:

# iptables –A PREROUTING –i eth0 –t mangle –p tcp –dport 25 \

–j MARK –set-mark 1

Допустим, что у нас имеется два подключения к Интернет — одно быстрое, но дорогое, другое медленное, зато дешевое. Естественно, что мы предпочтем отправлять почту по дешевому маршруту. Командой выше, мы уже пометили все пакеты исходящей почты числовой меткой — 1, теперь попробуем направить эти пакеты по дешевому маршруту:

# echo 201 mail.out >> /etc/iproute2/rt_tables

# ip rule add fwmark 1 table mail.out

# ip rule ls

0: from all lookup local

32764: from all fwmark 1 lookup mail.out

32766: from all lookup main

32767: from all lookup default

и зададим пусть и медленный, зато недорогой маршрут в таблице mail.out:

# /sbin/ip route add default via 195.96.98.253 dev ppp0 table mail.out

Это собственно все, что нам пришлось сделать! Если нужно сделать исключения для отдельных хостов, то можно несколько модифицировать набор правил для netfilter, пропуская пакеты с отдельных хостов без метки, или можно добавить правило с более низким приоритетом, которое отправляет отдельные хосты через таблицу main.

Можно так же использовать поле TOS, в заголовке пакета, задавая различный тип обслуживания для трафика различного рода, и создавая правила, которые реагируют на это поле.

Само собой разумеется, все это прекрасно работает и на хостах, под NAT ('masquerading').

Warning

Некоторые наши читатели отмечают, что как минимум MASQ и SNAT конфликтуют с механизмом маркировки пакетов. Расти Рассел (Rusty Russell) описал эту проблему ( http://lists.samba.org/pipermail/netfilter/2000-November/006089.html). Просто, отключите фильтр проверки обратного адреса (см. главу Параметры настройки сети в ядре) и все должно заработать.

Note

Чтобы иметь возможность маркировать пакеты, вы должны собрать ядро с рядом включенных опций: I

IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?]

IP: policy routing (CONFIG_IP_MULTIPLE_TABLES) [Y/n/?]

IP: use netfilter MARK value as routing key (CONFIG_IP_ROUTE_FWMARK) [Y/n/?]

См. так же раздел Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid.

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

Ниже приводится неполный список доступных классификаторов:

fw

Решение принимается на основе маркера пакета, установленного брандмауэром (например — iptables). Наиболее простой классификатор, который можно рекомендовать в том случае, если вам не хочется изучать синтаксис tc. За дополнительной информацией обращайтесь к главе 9.

u32

Решение принимается на основе значений полей в заголовке пакета (например, исходящий IP-адрес и т.п.).

route

Решение принимается на основе маршрута, по которому движется пакет.

rsvp, rsvp6

Маршрутизация пакетов производится на базе RSVP. Применимо только в том случае, если управление сетью полностью находится в ваших руках. В Интернет RSVP не поддерживается.

tcindex

Используется в DSMARKqdisc, см. соответствующий раздел.

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

Классификаторы, как правило, принимают некоторое количество аргументов. Перечислим их здесь, для удобства.

protocol

Протокол, принимаемый классификатором. Как правило вы будете принимать только IP-трафик.

parent

Существующий класс, к которому должен быть присоединен данный классификатор.

prio

Приоритет классификатора. Чем меньше число — тем выше приоритет.

handle

Назначение и смысл аргумента зависит от контекста использования.

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