22.10.2011 14:29, Mykola Dzham пишет:
Artyom Viklenko wrote:
21.10.2011 22:03, Mykola Dzham пишет:
Artyom Viklenko wrote:
21.10.2011 19:29, Mykola Dzham пишет:
Victor Sudakov wrote:
Понятно. Хотя странно при этом, что с неожиданным поведением в pf я пока
не столкнулся, а в ipfw таки да.
Это вдвойне странно: нарваться на неожиданное поведение pf элементарно.
Достаточно чтобы конфиг перерос определенный уровень.
А определенный уровень это что? Сколько строк?
Возможно мне ни как не удавалось этого достичь,
но во всех случаях поведение pf было адекватно тому,
что я от него ожидал при написании соответствующего
набора правил...
Ну попробуйте нарисовать набор правил и добиться адекватного поведения
для простой задачи:
cbq 1Mbit для трафика, который пришел через ext1 и уходит в int1
cbq 1Mbit для трафика, который пришел через int1 и уходит в ext1
cdq 10Mbit для трафика, который пришел через ext2 и уходит в int1
cbq 10Mbit для трафика, который пришел через inet1 и уходит в ext2
"cbq 1Mbit" - сферический конь в вакууме, IMHO.
С моей точки зрения задача поставлена не совсем корректно.
С моей точки зрения это придирки чистой воды. Мне нужно сделать
симметричный шейп для трафика через int1, причем ext1<->int1 1Mbit ,
ext2<->int1 10Mbit. Так лучше?
С другой стороны, не вижу большой проблемы создать
две очереди на внутреннем интерфейсе - на 1 мбит и на 10,
по одной очереди на внешних. повесить теги на весь входящий
трафик и с учетом этих меток раскидать исходящий трафик по очередям
и интерфейсам.
И какой адекватности не получается достичь?
А Вы попробуйте. tag требует keep state. Поэтому по нему создастся
Я пытаюсь найти и не вижу утверждения, что tag требует state.
Но точно знаю, что state может быть if-bound, а может и не быть.
Кроме того state, созданный на одном интерфейсе при приеме пакета,
например, не мешает создать второй стейт на исходящем интерфейсе.
queue можно привязать и в "pass in".
Чтобы попробовать нужно время собрать стенд. Пока нет возможности этим
заняться.
Я не утверждаю, что PF универсальный инструмент на все случаи жизни!
Но с Вашим утверждением все же не согласен. Уровень конфига и конкретный
случай не совсем одно и то же. Можно написать 500 правил и все будет
ок. В моем домашнем PF-е, например, как ни сранно их почти 180.
А можно и в десяти запутаться.
Опять же. При наличии динамической маршрутизации, я бы не стал на этом
же тазике пытаться решить "все и вся".
state, под которое "вдруг" начнут попадать исходящие пакеты. А их нам
надо вообще то завернуть в правильный queue. Тут и начнётся "если
соединение устанавливалось со стороны int1, то всё будет так, если со
стороны ext1, то так". Про ситуации когда трафик через некоторое время
Как-то лет 5 назад была ситуация - два прова, по одному ip от каждого.
Ни те BGP, ни те OSPF. В частности, прекрасно получалось отдавать
ответный трафик строго через тот интерфейс (провайдера), через который
приходил входящий. Т.е. если делать icmp echo или ssh через одного
прова, то и reply и обратный трафик ехал через этого же прова. Да
еще и раскидывать трафик по очередям в зависимости от типа трафика.
Например, в очередь с большим приоритетом попадали udp/53, udp/123,
интерактивный ssh, а "пинги" в очередь с наинизшим приоритетом,
остальное в дефолтную очередь.
ввиду изменения роутинга развернется с ext1 в ext2 можно вообще молчать.
Тут не буду голословно утверждать, нужно освежить в памяти, поковырять.
Но, как я уже писал выше, это не совсем гуд с точки зрения statefull
фильтрации. :)
--
Sincerely yours,
Artyom Viklenko.
-------------------------------------------------------
[email protected] | http://www.aws-net.org.ua/~artem
[email protected] | ================================
FreeBSD: The Power to Serve - http://www.freebsd.org
