Тонкости организации правил floating
-
Еще раз: (извиняюсь, если непонятно объясняю.)
Как следует составить правила, чтобы определенные алиасы попадали в свои трубки, все остальные попадали в другую, а во вкладке LAN был алиас, с содержимым, включающим в себя весь список разрешенных айпи адресов. (т.е. удаление из этого алиаса означало бы блокирование интернета)Раз при создании лимитера есть фраза Enable limiter and its children, значит есть механизм, позволяющий создавать родительские лимиты на вход\выход и лимиты внутри этих "родителей".
Может Вам в англоветке поинтересоваться? -
…есть фраза Enable limiter and its children, значит есть механизм, позволяющий создавать родительские лимиты на вход\выход и лимиты внутри этих "родителей".
Dymminet позволяет создавать queues с определенным весом(weight) внутри трубок. В этом случае о их создании и идет речь. Дочерних трубок нет =\
-
…есть фраза Enable limiter and its children, значит есть механизм, позволяющий создавать родительские лимиты на вход\выход и лимиты внутри этих "родителей".
Dymminet позволяет создавать queues с определенным весом(weight) внутри трубок. В этом случае о их создании и идет речь. Дочерних трубок нет =\
Насчет dummynet-а - http://freebsd.1045724.n5.nabble.com/PF-dummynet-td4991090.html.
А вот что говорит мануал по Limiter (как пример):Using Limiters for Bandwidth Guarantees
If you want to use limiters to guarantee a certain amount of bandwidth instead of limit, you can do so by making four limiters.
Bandwidth to guarantee upload
Bandwidth to guarantee download
Total bandwidth upload (less guaranteed above)
Total bandwidth download (less guaranteed above)Ensure that you do not set the Mask to anything other than "none". It must be "none" for these to work properly.
So if you have 8Mb down and 2Mb up, and you want to guarantee 512Kb/s for service X, you'd have queues sized like so:
512 Kb/s
512 Kb/s
1536 Kb/s
7680 Kb/sThen direct the guaranteed service traffic into the first two limiters, and everything else into the "total" limiters.
Важно это :
Ensure that you do not set the Mask to anything other than "none". It must be "none" for these to work properly.
Как понял это я:
1. Создаем алиасы для избранных.
2. Создаем лимитеры по каждому алиасу на вход и выход (Mask =none)
3. Создаем лимитеры по ОБЩЕЙ трубе на вход и выход (Mask =none)
4. Рисуем правила в фаере , где первыми будут правила для выбранных алиасов. Ниже будут правила для общей трубы, т.е. для всех остальных.Т.е. все что попадает в алиасы - имеет отдельный заданный канал, все остальное - имеет общую трубу.
-
не совсем так. при маске none будет создаваться общая трубка, которая ограничит своей пропускной способностью все адреса из алиаса.
кроме того не вополняется основное требование-организация удобного менеджмента правилами.
мой главный task- это ограничение группы адресов скоростью одного айпи(что сейчас реализовано оббщим правилом и лимитером с маской(которая разбирает мое общее для всех правило на айпи адреса и каждому выделяет свой пайп)), таким образом я могу создать для каждой группы алиас, создать для каждого трубку без маски и правило для фаервола по количеству алиасов.
но тут кроется проблема: каждый аликс кроме регулировании скорости, как я заметил, требует чтобы правило было pass правилом. таким образом, дабы отключить пользователя с несколькими айпи понадобится отключать его алиас. помимо этого будет существовать алиас со всеми остальными одноадресовыми пользователями. а это очень не удобно, ведь не скрипт не напишешь. и для сквида придется плодить ту же кучу алиасов.
нужен способ, который позволил бы при общем правиле, включающим в себя все айпи, для определеных групп просто регулировать скорость, не затрагивая разрешающие функции.
я все это описал в первом посту.
так что надо думать дальше.
спасибо -
хм.
Получается создать правила для ограничения скорости не типа-pass нельзя?
очень станно. -
хм.
Получается создать правила для ограничения скорости не типа-pass нельзя?
очень станно.А как вы собрались ограничить скорость блокированному трафику?
-
А как вы собрались ограничить скорость блокированному трафику?
я же описал впостах ранее, на мой взгялд, логично было бы иметь такую возможность, по принципу queue. (правила queue, они же match).
Главная задача - возможность держать только один алиас, в который входили бы все разрешенные адреса. Для этой задачи я вижу только 2 пути решения - создания дерева алиасов и организации правил dummynet'a так,чтобы они влияли только на распределение по каналу уже разрешенного траффика.
И, собственно, подтвердите (своим авторитетным мнением) мое заключение о том, что это не возможно и тема будет закрыта
-
FYI,
Все-таки мне удалось реализовать идею удобного редактирования правил.
Осуществил я это путем ограничения доступа в интернет правилами NAT'a (да, может это и выглядит дико, но работает прекрасно). Стандартно все пользователи локальной сети в фаерволе имеют полный доступ в интернет. Правила лишь сортируют определенные ip адреса в трубки для группового ограничения скорости интернета (к примеру, 5 юзеров имеют 5 ip адресов, но используют 1 канал), все остальные пользователи, не учтенные в правилах попадают под общее правило с динамически организующимися трубками под каждый ip своя. Таким образом у всех абсолютно есть инет и все правильно поделены по группам для Limiter'a. Осталось ограничить доступ в интернет тем, кому не нужно его предоставлять. Тут начинаются изобретения.
Все началось с темы Выборочная переадресация v2.
В итоге получилось следующее. Все пользователи стандартно по всем запросам на 80ый порт переадресовываются на 80ый порт веб-сервера, на котором крутится информационная страница о том, что доступа в интернет нет и о том, как его получить. По всем остальным портам работает переадресация на 0.0.0.0 (считайте, доступ заблокирован). Для определенного списка адресов созданы правила No rdr с алиасами типа URL Table. Эти алиасы ссылаются на файлы на удаленном фтп сервере. На машине с pfsense крутится скрипт, который с определенной периодичностью выкачивает эти файлы алиасов с фтп и сравнивает с текущими. При наличии изменений файлы заменяются новыми, создается бекап заменяемых файлов (на всякий случай, хранится только посл версия, чтобы можно было откатиться) и применяются правила фаервола.
Таким образом, чтобы подключить или отключить пользователей достаточно лишь отредактировать текстовый файл на удаленном фтп-сервере! А это тоже могут делать скрипты с заданным алгоритмом ;)
Вот вам и оптимизация процесса подключения-отключения! -
FYI,
Все-таки мне удалось реализовать идею удобного редактирования правил.
Осуществил я это путем ограничения доступа в интернет правилами NAT'a (да, может это и выглядит дико, но работает прекрасно). Стандартно все пользователи локальной сети в фаерволе имеют полный доступ в интернет. Правила лишь сортируют определенные ip адреса в трубки для группового ограничения скорости интернета (к примеру, 5 юзеров имеют 5 ip адресов, но используют 1 канал), все остальные пользователи, не учтенные в правилах попадают под общее правило с динамически организующимися трубками под каждый ip своя. Таким образом у всех абсолютно есть инет и все правильно поделены по группам для Limiter'a. Осталось ограничить доступ в интернет тем, кому не нужно его предоставлять. Тут начинаются изобретения.
Все началось с темы Выборочная переадресация v2.
В итоге получилось следующее. Все пользователи стандартно по всем запросам на 80ый порт переадресовываются на 80ый порт веб-сервера, на котором крутится информационная страница о том, что доступа в интернет нет и о том, как его получить. По всем остальным портам работает переадресация на 0.0.0.0 (считайте, доступ заблокирован). Для определенного списка адресов созданы правила No rdr с алиасами типа URL Table. Эти алиасы ссылаются на файлы на удаленном фтп сервере. На машине с pfsense крутится скрипт, который с определенной периодичностью выкачивает эти файлы алиасов с фтп и сравнивает с текущими. При наличии изменений файлы заменяются новыми, создается бекап заменяемых файлов (на всякий случай, хранится только посл версия, чтобы можно было откатиться) и применяются правила фаервола.
Таким образом, чтобы подключить или отключить пользователей достаточно лишь отредактировать текстовый файл на удаленном фтп-сервере! А это тоже могут делать скрипты с заданным алгоритмом ;)
Вот вам и оптимизация процесса подключения-отключения!Ув. goliy, а можно все то же но со скринами ? Думается, многим пригодится.
Заранее благодарен. -
Ув. goliy, а можно все то же но со скринами ? Думается, многим пригодится.
Статья в процессе…
-
Ув. goliy, а можно все то же но со скринами ? Думается, многим пригодится.
http://thin.kiev.ua/index.php?option=com_content&view=article&id=589:pfsense-20-nat&catid=50:pfsense&Itemid=81
