| 1.1, Аноним (-), 17:08, 26/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
| | |
| |
| 2.3, parad (??), 17:28, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для редактирования правил из скриптов и тд, чего нет в pf.
pf больше подходит для простых правил, поэтому и кажется что он проще...
| | |
| |
| 3.13, Осторожный (?), 21:51, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>Упростить настройку ipfw очень просто... достаточно всего лишь заменить его pf %)
>
>сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического
>создания и удаления очередей, фильтрации по маске пакета, удобного интерфейса для
>редактирования правил из скриптов и тд, чего нет в pf.
>pf больше подходит для простых правил, поэтому и кажется что он проще...
Фильтрация по маске пакета - это что ?
Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ?
| | |
| |
| 4.16, parad (??), 22:23, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> Фильтрация по маске пакета - это что ?
Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет.
> Удобный интерфейс для редактирования правил из скриптов - что именно не так в pf ?
Сможете проще для pf придумать?:
#!/usr/bin/perl
system ("ipfw add ...");
или
#!/bin/sh
ipfw add ...
| | |
| |
| 5.20, Осторожный (?), 00:27, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Фильтрация по маске пакета - это что ?
>
>Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно
>перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине.
>В общем диверта в pf нет.
нет
>[оверквотинг удален]
>
>Сможете проще для pf придумать?:
>
>#!/usr/bin/perl
>system ("ipfw add ...");
>
>или
>
>#!/bin/sh
>ipfw add ...
Ха!
А что именно нужно сделать-то ? Какая стоит конкретная задача ?
В pf есть анхоры
1) модифицируем anchor.conf
2) pfctl -a myanchor -f anchor.conf
Или же вообще можно ограничится модификацией таблиц
pfctl -t mytable -T add 1.2.3.4
| | |
| |
| 6.27, parad (??), 09:41, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А что именно нужно сделать-то ? Какая стоит конкретная задача ?
>В pf есть анхоры
>1) модифицируем anchor.conf
>2) pfctl -a myanchor -f anchor.conf
>
>Или же вообще можно ограничится модификацией таблиц
>pfctl -t mytable -T add 1.2.3.4
Я и говорю - pf лучше подойдет для простых правил. )))
В том, что вы написали сразу виден недостаток:
1) Для того, чтобы добавлять правила в якорь - необходимо этот якорь создать, а это править файл руками. Если подцеплять все правила от разных пользователей на один (ранее созданный) якорь - со временем невозможно будет разгребсти этот мусор.
2) Ок, а с шейпером как поступить, для него якорей не насоздаешь?
| | |
| |
| 7.33, Осторожный (?), 23:50, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Ну почему для простых-то ?
Хоть в pf, хоть в ipfw написать можно ЛЮБЫЕ правила !
Вопрос в том, где проще будет скрипт для управления.
Но пока неизвестно какую задачу решает скрипт спорить можно бесконечно.
Вот если будет конкретная задача - там можно предметно говорить.
Я не вижу проблем - скрипт можно сделать для ipfw и для pf.
1)
Якорь создается один раз в файле pf.conf
Потом все нужные правила добавляются в этот один якорь.
Правила записанные в якорь храним в файле myrule.conf
Правим скриптом файл, потом перегружаем якорь.
Можно без якоря - править файл pf.conf
Но скорее все этого не нужно.
Я понимаю, что в ipfw подкупает наличие номеров.
Можно вставлять куда угодно что угодно.
Насчет мусора - а что если в ipfw добавлять правила, то со временем мусор там не образуется ? Следить надо в любом случаа за тем что добавляется и для чего,
а также процедуру удаления предусмотреть.
Какая конкретная задача решается ?
Или это большой секрет ?
2)
С шейпером не знаю как, ибо в pf с ним не работал :)
| | |
|
|
| 5.21, Осторожный (?), 00:34, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а именно перенаправление пакетов в диверт сокет, с последующим анализм в своей софтине. В общем диверта в pf нет.
Вообще divert был придуман в FreeBSD чтобы как-то сделать natd
И является скорее затычкой, чем полезной вещью: например в частности из-за того что пакеты из kernel-space передаются в user-level-space и обратно.
Какой именно анализ выполняется в свой софтине ?
| | |
| |
| 6.26, parad (??), 09:22, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> Какой именно анализ выполняется в свой софтине ?
Защита от рассылки спама из клиентских сетей - проверяет, чтобы все smtp подключения были с авторизацией, иначе - дропает.
| | |
| |
| |
| 8.31, parad (??), 15:08, 27/06/2008 [^] [^^] [^^^] [ответить] | +/– | не секрет при подключении на 25 порт подключения заварачиваются на divert сокет... текст свёрнут, показать | | |
| |
| |
| 10.34, parad (??), 13:38, 28/06/2008 [^] [^^] [^^^] [ответить] | +/– | так сделано у 90 провайдеров START TLS приравнивается к прохождению аутентифик... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| |
| 2.4, trey (?), 17:33, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>А что то поумнее сказать? :-)
к вам это тоже относится...
и ко мне относится...
в общем стена там <----
пошли...
| | |
|
| 1.5, rage (??), 17:56, 26/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
в статье анахронизмы вперемешку с откровенными ошибками.
>Некоторые могут возразить что мол мы не можем контролировать входящий поток.
>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
это вообще шедевр.
>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика.
браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента никак?
Да и использовать natd - бред.
| | |
| |
| 2.38, nuclight (ok), 22:08, 03/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >в статье анахронизмы вперемешку с откровенными ошибками.
>
>>Некоторые могут возразить что мол мы не можем контролировать входящий поток.
>>Я отвечу что можем! Наверное Вы просто ребята не читали работу протокола TCP/IP.
>
>это вообще шедевр.
Криво выражено, но по сути верно. Вешать шейпинг на вход - полностью логически эквивалентно поставить перед входом еще один роутер, на исходе которого к нам шейпить. Да, это никак не повлияет на забитость канала теми пакетами, которые уже пришли (особенно если флуд какой). Но в случае конкнетно tcp, составляющего обычно бОльшую часть трафика - скорость выровняется спустя некоторое время, по подстройке отправителя к скорости возвращаемых ACK'ов.
>>То что можно сделать, так это перенаправлять входящий трафик клиентам по очереди, таким образом разделив канал поровну между ними. Также можно ограничить потребление некоторым клиентом не более K% трафика.
>
>браво. а повесить шейпер исходящего трафика на интерсфейс, смотрящий в сторону клиента
>никак?
Это чисто на того клиента. Пример же приводился и для случая, если софтины-клиенты есть и на самом роутере (а почему бы им не взяться, скажем, на домашнем сервере, выполняющем заодно и роль софт-роутера?), для которых исходящего трафика никакого вовсе не будет.
| | |
|
| 1.8, Sem (ok), 18:57, 26/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Блин, режет глаз слово "ложить". И опечатки. И вообще...
Вся тема про недостаток ALTQ мягко говоря спорная. Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических целях. И фраза про разделение входящего канала поровну - технически не грамотная. Можно создать иллюзию придерживая часть трафика, но к каналу это не имеет отношения.
| | |
| |
| 2.11, Andrew Kolchoogin (?), 20:21, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
> целях.
_Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется (это я в вашу сторону "ping -f" пустил :).
Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям".
:-\
| | |
| |
| 3.12, Sem (ok), 20:42, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
> _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
| | |
| |
| 4.18, Andrew Kolchoogin (?), 22:31, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Под входящим тут имеется в виду не тот трафик, который идет в
> интерфейс, а тот, который пришел, но еще не передан на обработку.
> Почему его "_нельзя_" зашейпить?
Потому что. Его можно только заполисить. Не передать на дальнейшую обработку, если он транзитный. Но _каналам_ твоим от этого ни горячо, ни холодно.
> Можно.
Нельзя.
> Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
Речь о безграмотности автора статьи. :)
| | |
|
| 3.14, Осторожный (?), 21:57, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
> _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку
- например в локальную сеть
>
>
> Это "альфа" и "омега" всего управления трафиком в
>TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да
>пожалуйста, хоть сто раз. Канал у вас по входу как на
>полке был, так на полке и останется (это я в
>вашу сторону "ping -f" пустил :).
тем не менее твои входящие ping можно ограничить по скорости
- с какой скоростью они будут попадать на мой интерфейс
>[оверквотинг удален]
> Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
> И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
> :-\
ха-ха
| | |
| |
| 4.17, Andrew Kolchoogin (?), 22:29, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
> тем не менее твои входящие ping можно ограничить по скорости
> - с какой скоростью они будут попадать на мой интерфейс
Нет. (C) Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой.
Я зуб даю с пломбой, что мои пинги будут попадать на твой интерфейс ровно с той скоростью, с которой я их посылаю. Не быстрее, и не медленнее.
Это они в твой TCP/IP-стек могут не попадать. Но _каналу_ от этого легче не станет. Dixi.
| | |
| |
| 5.23, Осторожный (?), 00:43, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> тем не менее твои входящие ping можно ограничить по скорости
>> - с какой скоростью они будут попадать на мой интерфейс
>
> Нет. (C) Фарид Вагапов, если тут еще хоть
>кто-то помнит, кто это такой.
>
> Я зуб даю с пломбой, что мои пинги
>будут попадать на твой интерфейс ровно с той скоростью, с которой
>я их посылаю. Не быстрее, и не медленнее.
Вот зуб не надо.
По дороге между источником ping-ом и firewall многое может случиться
- например их может drop-нуть или задержать проходящий роутер.
>
> Это они в твой TCP/IP-стек могут не попадать.
>Но _каналу_ от этого легче не станет. Dixi.
Каналу легче не станет, но про канал речи и не было вовсе.
| | |
| |
| 6.28, Andrew Kolchoogin (?), 10:17, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Я зуб даю с пломбой, что мои пинги
>> будут попадать на твой интерфейс ровно с той скоростью, с которой
>> я их посылаю. Не быстрее, и не медленнее.
> Вот зуб не надо.
> По дороге между источником ping-ом и firewall многое может случиться
> - например их может drop-нуть или задержать проходящий роутер.
Угу, или не справиться мой TCP/IP-стек посылать пакеты с такой скоростью, чтобы выложить _мой_ канал на полку. :)
Разумеется, имелся в виду ping flood с directly-connected router'а.
| | |
|
|
| 4.39, mFF (?), 11:49, 04/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>тем не менее твои входящие ping можно ограничить по скорости
>- с какой скоростью они будут попадать на мой интерфейс
>
Бгы гы
Ограничивать можно только то что УЖЕ пришло.
Ограничивать "скорость попадания на твой интерфейс" можно только на вышестоящем роутере.
Почитал бы ты что-нибудь о защите от DDOS-атак что ли.
| | |
|
| 3.15, migosm (?), 22:20, 26/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
> И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
> :-\
Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
| | |
| |
| 4.30, Sem (??), 11:54, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>>
>>
>> И до тех пор, пока такие вот безграмотные
>>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>>по объявлениям".
>>
>> :-\
>
>Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
Ну послал, так послал! :) Но раз не указал, куда идти, то иду куда могу и читаю:
"More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile)."
"Traffic policing is the distinct but related practice of packet dropping and packet marking."
| | |
|
| 3.41, Eugen Konkov (?), 01:46, 09/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
 > управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь.
Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс.
В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера.
т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер.
ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе.
ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера.
На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны.
ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0):
ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00
ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0
ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0
И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше.
Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ.
В догонку:
http://www.nabble.com/altq-td18171872.html#a23453905
| | |
|
|
| 1.10, grayich (??), 19:34, 26/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
все это хорошо, только нарезать четко(плавно) каналы не говоря уже о распределении не получается. Если у когото получилось, то скорее всего человек проверял на искуственном тесте и все, а реально не использовал.
| | |
| 1.19, Myc (??), 22:32, 26/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Например если на интерфейсе висит сеть 192.168.0.0/24, то дропаем всё, что не с этой сети:
>ipfw add 11101 deny all from not 192.168.0.0/24 to any in recv rl0
Мдя, бывает.
У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof.
| | |
| |
| 2.22, Andrew Kolchoogin (?), 00:35, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcreach, antispoof.
Лучший способ убить border router:
router>en
Password:
router#conf t
router(config)#int <имя внешнего интерфейса>
router(config-if)#ip verify unicast reverse-path
:)))
verrevpath -- зло. :)
| | |
| |
| 3.25, Аноним (-), 09:16, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Аргументы и факты? Cisco давно рекомендует использовать эту фичу и выполняется она в CEF.
| | |
|
| 2.24, Осторожный (?), 00:49, 27/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
В результате дропаются DHCP-запросы которые идут с адреса 0.0.0.0 to 255.255.255.255
Еще можно следить за адресами, куда идут пакеты
Скажем пакеты из локальной сети 192.168.0.0/24 на адреса 10.0.0.0/8 тоже можно drop-ать ( если у вас нет локальной сети 10.0.0.0/8 )
| | |
|
|
