[Comm] Равное разделение трафика и наблюдение за его скоростью

[Eugine Kosenko <eugine.kosenko@gmail.com>]

Есть типичная ситуация. Два компьютера (станции), соединенных в
скоростную локальную сеть, разделяют общий доступ в Internet по
низкоскоростному EDGE/GPRS. Разделение сделано с помощью простейшего
(в одно правило) маскарадинга через iptables.

Проблема тут, однако, в том, что скорость внешнего соединения не
просто низкая, а непредсказуемо низкая. В зависимости от фаз Луны и
настроения провайдера она может меняться от 8 до 250 кбит/с.

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

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

После быстрого вникания в iproute я понял, что при настройке
предполагается фиксированная и даже гарантированная ширина внешнего
канала. Если это так, то в самом деле достаточно разделить ее с
помощью дисциплины HTB пополам и все. Но беда ведь как раз в том, что
ширина доступного канала на текущий момент неизвестна! Зарезать канал
на какой-то низкий лимит неинтересно, так как не исключено, что именно
в данный момент мне может быть доступно больше. Я использую простую
дисциплину SFQ, которая, вроде бы, в большинстве случаев работает
именно так, как мне нужно. Однако иногда я замечаю, что полосу
начинают делить по принципу слотов. То есть, некоторое время (секунд
15-30) всю полосу захватывает одна станция, потом примерно столько же
--- вторая. И это при относительно постоянной общей скорости на
внешнем соединении. Понятно, что это тоже "поровну", но хотелось бы
именно "мягкого" деления, когда доступная полоса делится одновременно
и поровну между двумя машинами. Я хотел попробовать для решения этой
проблемы ESFQ, но как понял, в нынешних альтах использовать эту
дисциплину не рекомендуется.

Стоит ли для этих целей все же попробовать HTB (указав заведомо
большую ширину внешнего канала)? Стоит ли ради этой же задачи
попытаться освоить CBQ? Вообще говоря, сделал ли я все возможное в
этой ситуации или можно сделать что-то еще? Или может вообще нужно по
все делать по другому?

Второй момент связан со слежением за скоростью. Так как я новичок, то
попытался найти все, что относится к этой теме в Сизифе:

cban darkstat dsniff-X11 etherape flowscan ipband ipcad iptraf jnettop
tcpdump trafshow trickle ulog-acctd vnstat vnstat-server shapercontrol

Начал пробовать с iptraf и остановился пока на нем. Он достаточно
прост для новичка и дает мне именно то, что нужно. Но у него есть
недостатки. Во-первых, он привязан к интерфейсам. Поэтому я могу
видеть скорость трафика через ppp0 только в целом, без деления на
станции. Приходится из него в голове вычитать скорость трафика,
идущего через NAT с eth0, чтобы получить скорость трафика со станции,
подключенной к Internet напрямую. Это не очень удобно.

В теории я могу отделить пакеты с разных станций на уровне iptables,
но что потом делать с этим разделением? Ведь iptraf (как я понял), не
умеет анализировать поле MASK. Является ли правильным решением тут
создание виртуального сетевого устройства (по этой причине я
интересовался IMQ/IBF)? Или правильно делать (прозрачный) прокси и
вести учет на нем? А может, есть более простое решение на основе
другого инструмента?

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