К специалистам Linux: деление канала пополам через tc + NAT

[Volodya]

Есть сетевое подключение ppp0 на роутере ASUS WL-500g Premium ver.1, LAN IP = 192.168.1.1, через которое шурует входящий и исходящий трафик. Далее, трафик через NAT (Network Address Translation) раскидывается на 192.168.1.2 и 192.168.1.3.
Задача: делить пополам между 192.168.1.2 и 192.168.1.3 входящий и исходящий трафик идущий через ppp0.

На роутере:

$ uname -a
Linux 2.4.37.6 #9 2009-10-30 20:22:17 MSK mips GNU/Linux

Почитал

"Linux Advanced Routing & Traffic Control HOWTO"
http://gazette.linux.ru.net/rus/article ... index.html

Принцип деления:

Используется синтаксис bash

#/bin/sh

COUNT_USER=2

CEIL_DOWNLOAD=512
RATE_DOWNLOAD=CEIL_DOWNLOAD/COUNT_USER

CEIL_UPLOAD=512
RATE_UPLOAD=CEIL_UPLOAD/COUNT_USER

DEV=ppp0


# корень дерева 1:0, пакеты не удовлетворяющие всем условиям фильтров идут в очередь класса 1:9
tc qdisc add dev $DEV root handle 1:0 htb default 9


# исходящий

# класс 1:1 для 192.168.1.2, потомок корня дерева 1:0
tc class add dev $DEV parent 1:0 classid 1:1 htb rate ${RATE_UPLOAD}mbit ceil ${CEIL_UPLOAD}mbit

# класс 1:2 для 192.168.1.3, потомок корня дерева 1:0
tc class add dev $DEV parent 1:0 classid 1:2 htb rate ${RATE_UPLOAD}mbit ceil ${CEIL_UPLOAD}mbit


# очередь 11:0 для класса 1:1, алгоритм sfq с изменением алгоритма хеширования каждые 10 секунд
tc qdisc add dev $DEV parent 1:1 handle 11:0 sfq perturb 10

# очередь 12:0 для класса 1:2, алгоритм sfq с изменением алгоритма хеширования каждые 10 секунд
tc qdisc add dev $DEV parent 1:2 handle 12:0 sfq perturb 10


# направление пакетов из корня 1:0 в очередь 1:1 по условию "u32 match ip dst 192.168.1.2"
# u32 - 32 бита из заголовка пакета; match ip dst - соответствующие ip приёмника; равны 192.168.1.2
tc filter add dev $DEV parent 1:0 protocol ip prio 20 u32 match ip dst 192.168.1.2 flowid 1:1

# направление пакетов из корня 1:0 в очередь 1:2 по условию "u32 match ip dst 192.168.1.3"
# u32 - 32 бита из заголовка пакета; match ip dst - соответствующие ip приёмника; равны 192.168.1.3
tc filter add dev $DEV parent 1:0 protocol ip prio 20 u32 match ip dst 192.168.1.3 flowid 1:2


# входящий

# класс 2:1 для 192.168.1.2, потомок корня дерева
tc class add dev $DEV parent 1:0 classid 2:1 htb rate ${RATE_DOWNLOAD}mbit ceil ${CEIL_DOWNLOAD}mbit

# класс 2:2 для 192.168.1.3, потомок корня дерева
tc class add dev $DEV parent 1:0 classid 2:2 htb rate ${RATE_DOWNLOAD}mbit ceil ${CEIL_DOWNLOAD}mbit


# очередь 21:0 для класса 2:1, алгоритм sfq с изменением алгоритма хеширования каждые 10 секунд
tc qdisc add dev $DEV parent 2:1 handle 21:0 sfq perturb 10

# очередь 22:0 для класса 2:2, алгоритм sfq с изменением алгоритма хеширования каждые 10 секунд
tc qdisc add dev $DEV parent 2:2 handle 22:0 sfq perturb 10


# направление пакетов из корня 1:0 в очередь 2:1 по условию "u32 match ip src 192.168.1.2"
# u32 - 32 бита из заголовка пакета; match ip src - соответствующие ip источника; равны 192.168.1.2
tc filter add dev $DEV parent 1:0 protocol ip prio 20 u32 match ip src 192.168.1.2 flowid 2:1

# направление пакетов из корня 1:0 в очередь 2:2 по условию "u32 match ip src 192.168.1.3"
# u32 - 32 бита из заголовка пакета; match ip dst - соответствующие ip источника; равны 192.168.1.3
tc filter add dev $DEV parent 1:0 protocol ip prio 20 u32 match ip src 192.168.1.3 flowid 2:2


# пакеты неадресованные 192.168.1.2 или 192.168.1.3
# в условии "default 9" корня дерева направлены в очередь класса 1:9

# класс 1:9 для пакетов неадресованных 192.168.1.2 или 192.168.1.3, потомок корня дерева 1:0
tc class add dev $DEV parent 1:0 classid 1:9 htb

# очередь 19:0 для класса 1:9, алгоритм sfq с изменением алгоритма хеширования каждые 10 секунд
# нет ограничений rate, ceil
tc qdisc add dev $DEV parent 1:9 handle 19:0 sfq perturb 10
Парсинг занял 0.024 сек. Использовалась библиотека GeSHi 1.0.8.4

Но будут ли срабатывать условия для входящих пакетов "u32 match ip dst 192.168.1.2", "u32 match ip dst 192.168.1.3" и исходящих "u32 match ip src 192.168.1.2", "u32 match ip src 192.168.1.3"? Ведь локальные адреса 192.168.1.0/8 подставлены в заголовки пакетов после NAT, а перед NAT в заголовках пакетов подставлены глобальные адреса интернета.

ppp0, ведь, расположен перед NAT... Как сделать аналог ppp0, только после NAT, и заюзать в tc? Какие ещё недочёты в описанном скрипте настройки деления канала пополам? Мегапрофи в Linux, отзовитесь! Заранее большое спасибо!

[ZeroMem]

На самом деле аналог ppp0, только после NAT не используют. Если подобное Вы и сможете сделать, то решение будет нестанадартно.
Трафик при помощи команды tc в линукс шейпется только в исходящую сторону. Для того, чтобы шейпить входящий трафик, применяют промежуточное IMQ устройство. В IMQ, через ipchains или iptables, можно загнать весь входящий трафик с ppp0, повесить на него шейпер, и таким образом обрабатывать входящий трафик. Но IMQ доступно только при помощи неофициальных патчей для ядра ОС. Мне неизвестно, имеет ли Вам роутер ядро с данным патчем.

Второе решение, - это использование VLAN'ов. Если Вам незнакомы они, рекомендую почитать литературу по протоколу 802.11Q. Вам нужно создать 2 VLAN'а, предоставив клиентам 192.168.1.2 и 192.168.1.3 access port (это по терминологии Cisco, она достаточно популярна). На каждый сетевой интерфейс, отвечающий за VLAN, повесить шейпер с HTB дисциплиной на половинной скорости. Таким образом, вы будете контролировать входящий трафик к клиентам.