Извиняюсь, ответить сразу не мог.
Юрий, вы просили максимально простую конфигурацию, ну так держите
:
1. В идеале, асимметричный канал от провайдера, но, возможно, допустимо организовать его искусственно с помощью каналов.
2. За DFL в lannet 2 хоста на одном из которых установлен торрент-клиент, и на этот хост проброшен порт для этого клиента.
3. Минимальный набор каналов и правил, которых, как я считал, должно было хватить для разруливания трафика между этими двумя машинами согласно задачам, изложенным в предыдущем моём посте. Т.е. хосту B, должна гарантироваться полоса пропускания в 300 kbps с приоритетом 2, весь остальной трафик свыше этого значения пойдёт с приоритетом 0, следовательно, у трафика, принадлежащего хосту A, приоритет будет выше (1):
VPN_CLI_Int - интерфейс VPN-клиента
A-host_ip и
B-host_ip - дреса машин в локалке за LAN-интерфейсом DFL между которыми шейпится трафик, торрент-клиен установлен на B-host_ip.
Но каменный цветок не выходит с этими настройками (в левой части графика скорости шейпер неактивен, в правой - шейпер включен):
Консоль по SSH выдаёт аналогичные показатели:
Код:
pipe
DFL-210:/>
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
--------------- --------------- ------ ------ --------
VPN_In None 6.00 M 0 0 7
Current: 3.83 M 638
VPN_Out None 3.00 M 0 0 7
Current: 2.98 M 603
Т.е. часть входящего трафика у меня после применения канальных правил куда-то испаряется и до адресата не доходит.
Далее проводим дополнительный эксперимент. Увеличиваю значение общего ограничения для обоих VPN-каналов, как входящего, так и исходящего до 7000 kbps, для того, чтобы взглянуть, что в этом случае будет твориться с содержимым обоих каналов (график скорости не привожу, т.к. визуально он ничем не отличается от графика при отключенном шейпере):
Код:
pipe
DFL-210:/>
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
--------------- --------------- ------ ------ --------
VPN_In None 7.00 M 0 0 7
Current: 5.32 M 774
VPN_Out None 7.00 M 0 0 7
Current: 2.79 M 720
pipe
DFL-210:/>
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
--------------- --------------- ------ ------ --------
VPN_In None 7.00 M 0 0 7
Current: 5.19 M 782
VPN_Out None 7.00 M 0 0 7
Current: 3.87 M 850
pipe
DFL-210:/>
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
--------------- --------------- ------ ------ --------
VPN_In None 7.00 M 0 0 7
Current: 6.73 M 947
VPN_Out None 7.00 M 0 0 7
Current: 3.03 M 839
По серии из этих 3 замеров видно, что количество трафика в каналах сильно плавает, причём, трафика в исходящем канале обычно ощутимо больше 3 Mbps, заявляемых провайдером, а во входящем канале обычно ощутимо меньше, чем 6 Mbps (но бывают и исключения), хотя в сумме, опять же, обычно получается число близкое к 9 Mbps. Т.е. как минимум в исходящий канал DFL замешивает некоторую часть входящего трафика, видимо, как я понимаю, Сергей об этом и говорит в своих постах.
Sergey Vasiliev писал(а):
дело даже не в этом, вы забыли про такое понятие как staitfull соединение, поэтому ОТДЕЛЬНЫЕ ПРАВИЛА на входящий и исходящий трафик просто не работают и это не ошибка системы или ошибка в шейпере. Просто трафик гонятется по установленному соединению, понимаете?
Ну вообще-то, в разделе мануала по шейпингу это нигде не задокументировано, поэтому, ИМХО, считать это нормой не корректно.
Sergey Vasiliev писал(а):
Для тако чтоб точно ограничить торрент вы можете использовать IPS сигнатуру, не не блокировать трафик, а распознать и зашейпить данная возможность появилась в прошивке 2.26.
Возможно это и поможет, вот только при установке прошивки 2.26 все сигнатуры затираются, что "халявные" (в кавычках потому, что за эти сигнатуры я заплатил, преобретая DFL), идущие в комплекте с умолчательной прошивкой, что триальные, а тратить 80-100$ (или сколько они там теперь стоят) на годовую коммерческую подписку на какие-то одни сигнатуры в домашних условиях, ИМХО, как то не "Айс".
Сергей, хотелось бы у вас уточнить ещё пару вопросов.
На сколько понял, при VPN пакет кроме сырой полезной информации содержит ещё и блок служебной VPN-информации (прошу прощения за возможно ламерские формулировки), в мануале проскакивает значение в 25% от объёма полезных данных. Так вот, я правильно понимаю, что DFL отправляет под шейпер именно ещё не перепакованные (в случае входящего соединения) и уже перепакованные (в случае исходящего соединения) пакеты, содержащие эту служебную информацию?
В прикладном плане этот вопрос меня интересует вот с какой стороны: допустим, провайдер предоставляет по VPN честные, скажем, 3 Mbps в обе стороны полезного трафика, т.е. по факту получается, что входящий и исходящий каналы провайдера ко мне/от меня на самом деле больше на эти ~25%. Если DFL шейпит не сырой полезный трафик, а пакеты содержащие служебную VPN-информацию, то тут, ИМХО, возникает проблема задания ограничения для общих VPN-каналов (исходящего/входящего).
Второй вопрос: если между DFL и внутренней сетью поставить коммутатор L2 с нормальной поддержкой QoS, а не костылей в виде Pipes, удастся ли обойти обсуждаемую тут проблему шейпинга при использовании p2p-софта?
Вход
Регистрация
FAQ
Поиск
