Ipfw в Freebsd не режет исходящий торрент траффик

[alex_o 1 194]

И по поводу SQUID - я согласен, что скорость таки режется на внутреннем ИФ, но ежели SQUID получил запрос на доступ к Инет-страничке и ему попался большой файл, который он должен кешировать - как происходит заливка этого файла: она полностью контролируется SQUID или трафик льётся через наше правило PIPE (обмен данными вида: прислал пакет-получи подтверждение), прежде чем SQUID полностью зальёт в кеш этот файл или же он успеет скачать и кешировать файл самостоятельно, если внешний канал значительно превышает запрос через PIPE? Вы это хотели подчеркнуть?

Вы как-то все в одну кучу валите...

PIPE - это механизм ipfw, с помощью правил которого можно в этот PIPE загнать любые пакеты (трафик/поток) из любых (и даже из всех сразу) интерфейсов. SQUID - это приложение, слушающее назначенный ему сокет (обычно 3128 или 8080) и кэширующее все принимаемые из внешнего мира HTTP-данные. Эти объекты не зависят друг от друга. Если Вы повесите правило с PIPE на внешний интерфейс и правильно укажите адреса в правиле, то кэшируемый сквидом поток попадет в него. Если же PIPE только на внутренних и-фейсах, то сквид будет заливать в свой кэш данные на полной скорости внешнего канала, а отдавать их в локалку уже через PIPE (опять же если в нем правила заданы верно).

 

Получается, что если у нас стоит NAT, а в правилах мы не указали интерфейс для PIPE - скорость будет резаться всё равно на внутреннем ИФ, потому что после НАТа (исходящий на внешний ИФ) и до него (входящий с внешнего ИФ) - указанных в PIPE внутренних адресов не существует?

Скорость будет резаться для тех пакетов, которые попадают под правило, указанное в PIPE. Если интерфейс не задан явно, то правило с PIPE будет проверяться для ВСЕХ интерфейсов.

 

Т.е. в какой-то момент юзер с пайпом 128Кбит - может занять, скажем, 5-ти мегабитный канал? О_о

А если в конце правил ставим IN и OUT? Интерфейсы не указываем.

Пример:

ipfw add 100 pipe 1 all from 1.1.1.1 to any in - тут в пайп 1 будет направлены все ВХОДЯЩИЕ со ВСЕХ интерфейсов пакеты с АДРЕСОМ ОТПРАВИТЕЛЯ 1.1.1.1

[alex_o 1 194]

Автор частично в чем-то прав. В dummynet файло (на самом деле на файло, а все пакеты) льется на максимальной скорости в очереди (queue). Но очереди настолько малы, что составляют буквально несколько килобайт (а могут быть еще и меньше).

Параметры очередей там полностью настраиваемые. А маленькие они по-умолчанию стоят с одной простой целью - дабы не создавать задержек по нескольку секунд на прохождении пакетов.

[masters 126]

Параметры очередей там полностью настраиваемые. А маленькие они по-умолчанию стоят с одной простой целью - дабы не создавать задержек по нескольку секунд на прохождении пакетов.

 

Я в курсе

[lava 23]

Freebsd Р2Р траф ріже без проблем, так що не потрібно тут людині рекомендувати переходити на другу ось. В самого все через таблиці зробленно і ріжеться, що на зовнішньому, що внутреному інтерфейсі без проблем.

[prototip 284]

Прокладку между клавой и монитором купил , спасибо - пользую , нравится . Насчет фаеров - не надо тут так ГРОМКО ругаться , у чела проблема с шейпингом и следует признать что IPFW c dummynet - которому сто лет в обед для этого не особо подходит . На PF есть ALTQ - это уже другой подход к обесчению киосов . Ну а почему используют фришный стандартный фаер , так это прежде всего то что у него нельзя отнять - скорость работы , речь идет о действительно больших потоках а как прососать десятка два три мегабит .... А плеваться в сторону Линуксов - это н стоит , религия наверное кое у кого не позволяет попробовать чтото другое . Лично к гуру , посоветовавшего мне купить такую классную вещь как "прокладку" , анука зарисуйте мне вариант с классами и приоритетами очередей на IPFW+думминет , очень жду !

[prototip 284]

Можно почитать немного http://www.opennet.ru/base/sec/pf_openbsd_altq.txt.html - помогает осмыслить шейпинг .

[alex_o 1 194]

Прототип, сорри, если обидел. Я человек темный, необразованный, поэтому линукс не люблю (так исторически сложилось). PF+ALTQ пробовал, но не увидел принципиальной разницы с ipfw+dummynet в тех решениях, которые использую. Зато увидел разницу с ng_car, который шейпит 1500 он-лайн тунелей pptp с шифрованием с полосами 1-8 Мбит/сек на каждый. При этом машина молотит 120 000 pps с загрузкой проца всего на 40%. Так что еще раз сорри, после этого нам линукс не потребен. Впрочем как и приоритезация в очередях. Мы ведь люди скромные...

Пора завязывать пустой треп, топикстартер ведь свою проблему порешал. И, кстати, вовсе без линукса...

[prototip 284]

120000 pps это уже серьезные загрузы нана конкретную железяку даже без учета какая ось стоит . А вообще это дело вкуса и кого какие задачи . Для нас скромных локальщиков , это я про себя такой трафик лопатить не приходится , а вот позаботится о том чтобы все работало как часики , мониторилось и было доступным это серьезный вопрос .

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