какое в среднем количество правил у вас в фаерволе? Сколько правил у вас проходит пакет в любую сторону?
Если там ограничевается 3 правилами - то да, все нормально... А так...
будете экстенсивно наращивать производительность интернет-маршрутизатора? Начнет дохнуть под нагрузкой - будете апгрейдить железо? Или таки подумаете над оптимизацией?
pipe
У меня несколько pipe, настроенных на фиксированную скорость и плодящихся автоматом по мере надобности. Число правил в своем фаере не считал, оно большое, но фиксированное. Все управление делается через таблицы. И нормально бегает это дело на обычном P4 2,6 GHz. Пакет проходит в каждую сторону от 50 до 100 правил, не больше.
Тот вариант мне тоже не понравился. Я не доверяю этому биллингу работу с большой кучей правил, все сложные комбинации выполняются скриптом на месте. В биллинге только две строчки - open UIP и close UIP, плюс еще один параметр - номер скорости безлимита, если его нет, то нет и нарезки. Просто когда строил, подумал - а что будет если билл решит остановиться на середине прописанных ему правил и помереть, не прописав нарезку скорости? И сделал так, чтобы совершенно лишить его такого удовольствия.
Тот вариант мне тоже не понравился. Я не доверяю этому биллингу работу с большой кучей правил, все сложные комбинации выполняются скриптом на месте. В биллинге только две строчки - open UIP и close UIP, плюс еще один параметр - номер скорости безлимита, если его нет, то нет и нарезки. Просто когда строил, подумал - а что будет если билл решит остановиться на середине прописанных ему правил и помереть, не прописав нарезку скорости? И сделал так, чтобы совершенно лишить его такого удовольствия.
ну расчетно один роутер на 150-200 абонентовmikkey finn писал(а):какое в среднем количество правил у вас в фаерволе? Сколько правил у вас проходит пакет в любую сторону?
Если там ограничевается 3 правилами - то да, все нормально... А так...
будете экстенсивно наращивать производительность интернет-маршрутизатора? Начнет дохнуть под нагрузкой - будете апгрейдить железо? Или таки подумаете над оптимизацией?
Intel Pentium Dual-Core E2200 2,2GHz + 1Гиг мозгов
3 сетевухи - одна наружу две на подсети......
что вы имеете ввиду под оптимизацией?
чем проще схема тем надежнее.... имхо....
вот мне нравится такая логика.......JAO писал(а): Тот вариант мне тоже не понравился. Я не доверяю этому биллингу работу с большой кучей правил, все сложные комбинации выполняются скриптом на месте. В биллинге только две строчки - open UIP и close UIP, плюс еще один параметр - номер скорости безлимита, если его нет, то нет и нарезки. Просто когда строил, подумал - а что будет если билл решит остановиться на середине прописанных ему правил и помереть, не прописав нарезку скорости? И сделал так, чтобы совершенно лишить его такого удовольствия.
такое впечатление что компьютер у вас сам себе думает как ему роутить..... конечно как известно каждый делает как считает нужным, но мне в данном случае так удобней и проще чем лазить в терминал и кривить конфиги БЗДи писать костыли и т.д. ..... тем более что администрированием утма(пользователи тарифы етс) и бсд занимаются разные люди......
#Доступ в интернет для пользователей UNLIM64
${fwcmd} add pipe 64 all from table\($TABLE_UNLIM64\) to any out
${fwcmd} add pipe 64 all from any to table\($TABLE_UNLIM64\) in
${fwcmd} pipe 64 config bw 64Kbit/s
${fwcmd} add pass all from table\($TABLE_UNLIM64\) to any
${fwcmd} add pass all from any to table\($TABLE_UNLIM64\)
Так резали - проблем небыло. Хотя пока не запускали в реальную работу.
${fwcmd} add pipe 64 all from table\($TABLE_UNLIM64\) to any out
${fwcmd} add pipe 64 all from any to table\($TABLE_UNLIM64\) in
${fwcmd} pipe 64 config bw 64Kbit/s
${fwcmd} add pass all from table\($TABLE_UNLIM64\) to any
${fwcmd} add pass all from any to table\($TABLE_UNLIM64\)
Так резали - проблем небыло. Хотя пока не запускали в реальную работу.
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
64К на таблицу адресов - это жестко. Вы не любите своих абонентов?
Вы попробуйте такой тариф паре юзеров поставить и пусть они одновременно покачают. Они будут делить между собой 64К, так что все будет плохо, все будут недовольны.
Решение:
Два пайпа - pipe mask dst-ip и pipe mask src-ip
Вести две таблицы, в каждую заносить адрес абонента, после чего по признаку "входящий/исходящий" раскидывать по пайпам.
Вы попробуйте такой тариф паре юзеров поставить и пусть они одновременно покачают. Они будут делить между собой 64К, так что все будет плохо, все будут недовольны.
Решение:
Два пайпа - pipe mask dst-ip и pipe mask src-ip
Вести две таблицы, в каждую заносить адрес абонента, после чего по признаку "входящий/исходящий" раскидывать по пайпам.
Dimasik, ну да, я костыли пишу и скривил на BSD все что только можно скривить. У меня даже DNS, который изначально не приспособлен к этому, умеет различать, у кого инет открыт, а у кого закрыт. И весь этот бред четко выполняет поставленную начальством задачу. Скрипт управления доступом в сеть, который запускается стоящим на шлюзе RFW, я костылем не считаю.
Подскажите, что делаю не правильно?Oleg_121 писал(а):У нас работает такой скрипт на основе table
В правилах фаревола в UTM на включение
table 1 add UIP (скорость) => например: table 1 add UIP 2048 для скорости 2048
на выключение
table 1 delete UIP 2048
(FreeBSD 6.3 ipfw)
#!/bin/sh
/sbin/ipfw -f flush
/sbin/ipfw -f pipe flush
/sbin/ipfw pipe 64 config bw 64Kbit/s queue 20 mask dst-ip 0xffffffff
/sbin/ipfw pipe 128 config bw 128Kbit/s queue 20 mask dst-ip 0xffffffff
/sbin/ipfw pipe 256 config bw 256Kbit/s queue 20 mask dst-ip 0xffffffff
/sbin/ipfw pipe 512 config bw 512Kbit/s queue 30 mask dst-ip 0xffffffff
/sbin/ipfw pipe 1024 config bw 1024Kbit/s queue 50 mask dst-ip 0xffffffff
/sbin/ipfw pipe 2048 config bw 2048Kbit/s queue 80 mask dst-ip 0xffffffff
/sbin/ipfw pipe 4096 config bw 4096Kbit/s queue 80 mask dst-ip 0xffffffff
/sbin/ipfw -q add pipe tablearg ip from any to table\(1\)
/sbin/ipfw -q add 4900 fwd x.x.x.x ip from any to table\(1\) out via ng*
/sbin/ipfw -q add 4910 fwd x.x.x.x ip from any to table\(1\) via gif*
/sbin/ipfw -q add 00100 allow ip from any to any via lo0
/sbin/ipfw -q add 00150 deny ip from any to 127.0.0.0/8
/sbin/ipfw -q add 00150 deny ip from 127.0.0.0/8 to any
/sbin/ipfw -q add 65000 reject all from any to any out via ng*
/sbin/ipfw -q add 65001 reject all from any to any out via gif*
Здесь ng интерфейсы созданные mpd5 для PPTP
gif - интерфейс IP-IP тунель.
Все работает на реальном биллинге.
Необходимо запихать 172.16.0.6/32 в трубу 128Кбит/с:
00099 62396068 24446965166 allow ip from any to any via lo0
04900 61284 4934451 fwd tablearg ip from any to table(1) out via ng*
51100 0 0 pipe tablearg ip from any to table(1)
65000 0 0 reject ip from any to any out via ng*
[root@accounter2 ~]# ipfw table 1 list
172.16.0.6/32 128
[root@accounter2 ~]# ipfw show | grep 172.16.0.6
15002 24392641 10620808514 allow ip from 172.16.0.6 to any
15002 21982854 15365946601 allow ip from any to 172.16.0.6
Как только убираю 172.16.0.6/32 128 из таблицы 1 - всё работает.
P.S.
/sbin/ipfw -q add 4900 fwd x.x.x.x ip from any to table\(1\) out via ng*
что вместо x.x.x.x надо? или ничего?
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
ман читать надо, а потом уже в чужих конфигах разбираться.
fwd 127.0.0.1 ip from table(1) to any out via ng*
обозначает, что пакету ставится next-hop(следующий маршрутизатор) c адресом 127.0.0.1
Под это правило попадут все пакеты, которые удовлетворяют следующим условиям:
пакет отправлен с адреса из таблицы 1.
Адрес доставки пакета - любой
пакет является исходящим для данной системы
пакет должен пройти через интерфейс семейства ng(via).
Для лучшей читаемости лучше вместо via использовать соответствующие recv и xmit.
За подробностями - в ман.
fwd 127.0.0.1 ip from table(1) to any out via ng*
обозначает, что пакету ставится next-hop(следующий маршрутизатор) c адресом 127.0.0.1
Под это правило попадут все пакеты, которые удовлетворяют следующим условиям:
пакет отправлен с адреса из таблицы 1.
Адрес доставки пакета - любой
пакет является исходящим для данной системы
пакет должен пройти через интерфейс семейства ng(via).
Для лучшей читаемости лучше вместо via использовать соответствующие recv и xmit.
За подробностями - в ман.
Исправил, но если я правильно понимаю то:
надо:
fwd 127.0.0.1 ip from table(1) to any out via ng*
fwd 127.0.0.1 ip from any to table(1) out via ng*
Для того чтобы резать и входящий и исходящий.
имеем следующее:
Необходимо запихать 172.16.0.6/32 в трубу 128Кбит/с:
ng10: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1396
inet 172.16.0.1 --> 172.16.0.6 netmask 0xffffffff
00099 62396068 24446965166 allow ip from any to any via lo0
01010 0 0 deny ip from any to 127.0.0.0/8
01010 0 0 deny ip from 127.0.0.0/8 to any
04900 14 768 fwd 127.0.0.1 ip from any to table(1) out via ng*
51100 112 5352 pipe tablearg ip from any to table(1)
65000 0 0 reject ip from any to any out via ng*
После добавления ipfw table 1 add 172.16.0.6 128
прохождение пакетов от 172.16.0.6 останавливается.
надо:
fwd 127.0.0.1 ip from table(1) to any out via ng*
fwd 127.0.0.1 ip from any to table(1) out via ng*
Для того чтобы резать и входящий и исходящий.
имеем следующее:
Необходимо запихать 172.16.0.6/32 в трубу 128Кбит/с:
ng10: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1396
inet 172.16.0.1 --> 172.16.0.6 netmask 0xffffffff
00099 62396068 24446965166 allow ip from any to any via lo0
01010 0 0 deny ip from any to 127.0.0.0/8
01010 0 0 deny ip from 127.0.0.0/8 to any
04900 14 768 fwd 127.0.0.1 ip from any to table(1) out via ng*
51100 112 5352 pipe tablearg ip from any to table(1)
65000 0 0 reject ip from any to any out via ng*
После добавления ipfw table 1 add 172.16.0.6 128
прохождение пакетов от 172.16.0.6 останавливается.
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
Уважаемый если не сложно обрисуйте на пальцах:mikkey finn писал(а):ман читать надо, а потом уже в чужих конфигах разбираться.
fwd 127.0.0.1 ip from table(1) to any out via ng*
обозначает, что пакету ставится next-hop(следующий маршрутизатор) c адресом 127.0.0.1
Под это правило попадут все пакеты, которые удовлетворяют следующим условиям:
пакет отправлен с адреса из таблицы 1.
Адрес доставки пакета - любой
пакет является исходящим для данной системы
пакет должен пройти через интерфейс семейства ng(via).
Для лучшей читаемости лучше вместо via использовать соответствующие recv и xmit.
За подробностями - в ман.
[root@accounter2 ~]# ipfw pipe list 128
00128: 128.000 Kbit/s 0 ms 20 sl. 1 queues (64 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
38 ip 0.0.0.0/0 172.16.0.6/0 112 5352 0 0 0
На сколько я понимаю sourc'ом в моём случае должен быть 172.16.0.6?
fwd 127.0.0.1 ip from table(1) to any out via ng*
вместо 127.0.0.1 должен быть следующий хоп идущий за моей машиной? Те адрес шлюза машины?
Т.е. правится заголовок пакета, в котором указывается куда деваться пакету который вышел из table(1)?
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
обрисовываю.
В логике Ipfw правило, делающее fwd является синонимом для allow.
То есть, все, что попадет под правило с fwd дальше по фаерволу не идет.
fwd предназначен для того, чтоб реализовать policy-based routing. С ограничениями скорости никак не связано.
Если PBR не нужен(используется один канал, два канала но не важна нагрузка на каналах, есть БГП или другой протокол, который выберет правильный маршрут), то забудьте про fwd, вы себе геморроя больше этим создадите.
Для ограничения скорости, если его(ограничение) надо применить к ng-интерфейсам и при этом это ограничение НЕ НАДО менять с течением времени, лучше использовать ng_car. Примеры есть на этом форуме в ветке "Документация".
Если хочется решить все на Dummynet/IPFW, то конструкция правил с таблицами должна быть примерно такой:
ipfw pipe 1 config bw=128kbit/s mask src-ip 0xffffffff # труба для исходящих пакетов (от пользователя -> в интернет)
ipfw pipe 2 config bw=128kbit/s mask dst-ip 0xffffffff # труба для входящих пакетов ( из интернет -> к пользователю)
ipfw add 100 pipe tablearg ip from table(1) to any in recv ng*
ipfw add 200 pipe tablearg ip from any to table(2) out xmit ng*
При этом в обеих таблицах должен содержаться адрес клиента с соотв номером пайпа.
ipfw table 1 add 172.16.0.6 1
ipfw table 2 add 172.16.0.6 2
Если требуется натить средствами natd/применять для ната фаервол, то правила усложняются. А именно - надо настроить параметр one_pass в sysctl и после этого уже добавлять правила для aliasing/dealiasing
Однако, если использовать набор правил с разделением интерфейсов, то все становится попроще
В логике Ipfw правило, делающее fwd является синонимом для allow.
То есть, все, что попадет под правило с fwd дальше по фаерволу не идет.
fwd предназначен для того, чтоб реализовать policy-based routing. С ограничениями скорости никак не связано.
Если PBR не нужен(используется один канал, два канала но не важна нагрузка на каналах, есть БГП или другой протокол, который выберет правильный маршрут), то забудьте про fwd, вы себе геморроя больше этим создадите.
Для ограничения скорости, если его(ограничение) надо применить к ng-интерфейсам и при этом это ограничение НЕ НАДО менять с течением времени, лучше использовать ng_car. Примеры есть на этом форуме в ветке "Документация".
Если хочется решить все на Dummynet/IPFW, то конструкция правил с таблицами должна быть примерно такой:
ipfw pipe 1 config bw=128kbit/s mask src-ip 0xffffffff # труба для исходящих пакетов (от пользователя -> в интернет)
ipfw pipe 2 config bw=128kbit/s mask dst-ip 0xffffffff # труба для входящих пакетов ( из интернет -> к пользователю)
ipfw add 100 pipe tablearg ip from table(1) to any in recv ng*
ipfw add 200 pipe tablearg ip from any to table(2) out xmit ng*
При этом в обеих таблицах должен содержаться адрес клиента с соотв номером пайпа.
ipfw table 1 add 172.16.0.6 1
ipfw table 2 add 172.16.0.6 2
Если требуется натить средствами natd/применять для ната фаервол, то правила усложняются. А именно - надо настроить параметр one_pass в sysctl и после этого уже добавлять правила для aliasing/dealiasing
Однако, если использовать набор правил с разделением интерфейсов, то все становится попроще
Спасибо теперь всё понятно. Вот это я понимаю объяснили....с уважением....
Создаём тунель:
[root@accounter2 ~]# ipfw pipe 64 config bw 64Kbit/s mask src-ip 0xffffffff
[root@accounter2 ~]# ipfw pipe 641 config bw 64Kbit/s mask dst-ip 0xffffffff
[root@accounter2 ~]# ipfw add 4000 pipe tablearg ip from table\(64\) to any in recv ng*
04000 pipe tablearg ip from table(64) to any in recv ng*
[root@accounter2 ~]# ipfw add 4001 pipe tablearg ip from any to table\(641\) out xmit ng*
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Синтаксис вроде правильный ;(
Похоже не нравится 641.
Удалил и начал с единицы - всё ок.
Создаём тунель:
[root@accounter2 ~]# ipfw pipe 64 config bw 64Kbit/s mask src-ip 0xffffffff
[root@accounter2 ~]# ipfw pipe 641 config bw 64Kbit/s mask dst-ip 0xffffffff
[root@accounter2 ~]# ipfw add 4000 pipe tablearg ip from table\(64\) to any in recv ng*
04000 pipe tablearg ip from table(64) to any in recv ng*
[root@accounter2 ~]# ipfw add 4001 pipe tablearg ip from any to table\(641\) out xmit ng*
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Синтаксис вроде правильный ;(
Похоже не нравится 641.
Удалил и начал с единицы - всё ок.
