Как лучше орган-ть шлюз на PFS
-
Гуру, подскажите, плиз, как лучше организовать шлюз PFSense (прокси, шейпер) для такой сети:
Есть 1 WAN.
Есть одна локальная LAN (основная сеть), в которой и находится PFSense. 172.15.0.0
Есть несколько удаленных офисов, подключенных через VPN провайдера (DSL-модемы) к основной LAN.
Основная сеть - 172.15.0.0 (2000 Кбит)
ОФис 1 - 172.15.1.0 (512 Кбит)
ОФис 2 - 172.15.2.0 (512 Кбит)
ОФис 3 - 172.15.3.0 (256 Кбит)
ОФис 4 - 192.168.0.0 (128 Кбит)
Я сделал так на PFSense. IP PFSense 172.15.0.250, 1 WAN, 1 LAN, создал шлюз для удаленных сетей (один на всех - GW1 - 172.15.0.10).
Прописал для каждой сети маршрут через GW1. Создал правила для всех сетей в Firewall:Rules:Lan и в Firewall:NAT:Outbound.
Был поднят и настроен squid для всех сетей и настроены соответсвтующие правила.
Перешел к настройке Шейпера для каждой из сетей. И тут возникла проблема. Нужно резать канал для каждой сети и причем ширина канала у разных офисов разная (у кого 512 Кбит, у кого 256 и 128). Поэтому создание общих очередей для всех сетей не подходит. В виду разной ширины канала нужно создавать очереди для каждой из сетей. Но тут-то и проблема, что суммарная ширина канала всех очередей не должна превышать общую ширину канала LAN. Выхода тут 2 либо создавать новые LAN интерфейсы и привязывать каждой сети свой LAN, переписывать все правила и настривать спокойно шейпер для каждой LAN. Либо 2 вариант - просто задать общую пропускную способность единственного LAN как сумму всех созданных очередей для каждой сети, а для каждой очереди создать дочерние очереди для конкретной резки по протоколам и портам. Т.е. получается что-то так:
LAN (общая ширина 5Мбит)
…Other_traffic (128 Кбит default) - дефолтная очередь с низким приоритетом, равная пропускной способности
...Osnovnoi (2000 Кбит)
...ack
...low
...high
...Office1 (512 Кбит)
...ack
...low
...high
...Office2 (512 Кбит)
...ack
...low
...high
...Office3 (256 Kбит)
...ack
...low
...high
...Office4 (128 Кбит)
...ack
...low
...highOther_traffic (128 Кбит default) - дефолтная очередь с низким приоритетом, равная или меньше пропускной способности самого узкого канала из всех сетей. Сюда попадают те пакеты, которые не попадут в другие последющие очереди.
Затем прописать в Floating Rules правила (не буду указывать правила для дочерних очередей -смысл и так ясен)
ID Proto Source Port Destination Port Gateway Queue-
- * * * * Other_traffic
- 172.15.0.0/24 * * * * Osnovnoi
- 172.15.1.0/24 * * * * Office1
- 172.15.1.1/24 * * * * Office2
- 172.15.1.2/24 * * * * Office3
- 192.168.0.0/24 * * * * Office4
В моем понимании логика такая: Сначала все пакеты попадают по самому верхнему правилу (режется по минималке - 30% от 128Кбит), затем по мере следования сверху вниз, если пакет попадает под какое-то из следующих правил, допустим, пакет попал под правило c очередью Office2 (более приоритетное), то он уже режется 512Кбит, а там попадает в следующее правило с дочерней очередью и т.д.
Как вы сами поняли, я пошел по 2 пути (что, как я думаю, не является правильным и удобным вариантом). В виду того, что я виду работу по переходу c другого шлюза на PFSense, то пока нет возможности проверить работу данной схему вживую. Пока только создал кроме основной сети тестовую сеть (192.168.25.0/24) и создал подобные правила для неё. Отличие тестовой сети от реальных состоит в том, что она не находится за VPN прова и не проходит через шлюзы DSL модемов. Данная схема с тестовой сетью полностью работает.Из всего вышеизложенного хочу спросить:
1. Как будет более правильным - создание дополнительных LAN для каждой сети со всеми вытекающими изменениями в правилах или есть какой-нибудь другой вариант?
2. Если же переделывать всю структуру по 1 варианту, то как создать дополнительные LAN, если он физически всего один (только через WLAN получается только?) и как вообще построить всю сеть со всеми офисами и их доп. сетями LAN на PFSense, если все доп. сети ходят через один шлюз??А вообще, все эти манипуляции сделаны с целью построения нормально работающего шейпера для каждой из сети с разной шириной канала. Во всем остальном меня вполне данная структура устраивала. НО так как я построил шейпер является не правильным да и к тому не удобным, то у меня и возникли вопросы.
P.S. Сорри, если что-то не понятно в моих изречениях - прошу особо не критиковать (головняков на работе много) :-)
-
-
В вашем случае смысла создавать новые интерфейсы нет. Интерфейсы пришлось бы создать если все устройства бы были в одной физической сети на втором уровне и широкой маской IP (/16)
Дочерние очереди есть только в планировщике HFSC. Там сумма дочерних очередей вроде должна быть 70% от родительской.
@sundoom:В моем понимании логика такая: Сначала все пакеты попадают по самому верхнему правилу (режется по минималке - 30% от 128Кбит), затем по мере следования сверху вниз, если пакет попадает под какое-то из следующих правил, допустим, пакет попал под правило c очередью Office2 (более приоритетное), то он уже режется 512Кбит, а там попадает в следующее правило с дочерней очередью и т.д.
Логика тут проще - применяется последнее совпавшее правило.
-
Кстати, здесь небольшая опечатка, кто не догадался:
ID Proto Source Port Destination Port Gateway Queue
* * * * * * Other_traffic
* 172.15.0.0/24 * * * * Osnovnoi
* 172.15.1.0/24 * * * * Office1
* 172.15.2.0/24 * * * * Office2
* 172.15.3.0/24 * * * * Office3
* 192.168.0.0/24 * * * * Office4В общем вопрос поставлю проще. Как пустить разные подсети (удаленные офисы) через Trafic Shaper на PFSense, у которого 1 LAN (шлюз для DSL-модемов в удаленных офисах)? Выше я описал способ через задание дочерних очередей (подсетей) для LAN. Но такой способ очень громозкий для администрирования и описание правил. Может есть способ проще, например, создание вирт. сетей.
P.S. PFSense крутится на виртуалке. -
А каков смысл этого действия с шейпером? Если в удаленных офисах лимит скорости на уровне канала, то при Ваших 5 мегабитах они физически не смогут ничего сверх своей нормы получить. Какой смысл в шейпере?
-
Смысл таков. Если организовать в качестве дочерних очередей для LAN, то создается допустим дочерняя очередь с шириной канала, например, 512Кбит, а в ней другие дочерние очереди по протоколам, портам (как мне надо). Правилами привязывается подсеть к своей дочерней очереди. А LAN в этом случае должна быть равна или больше суммы всех дочерних очередей (подсетей со своими каналами). ТОлько тут ограничение на семь дочерних очередей (значит всего 7 подсетей) согласно наличию всего 7 приоритетов для HFSC.
Я думаю должно быть более простое и удобное решение. -
А причем здесь приоритеты для HFSC к количеству подсетей? Мне кажется, или вы чего-то не понимаете?
Зачем Вам иерархия по подсетям? Общие скорости на канал уже ограничены физически.
Если хотите регулировать какой-то вид трафика Интернет - Удаленный офис, просто создайте отдельные очередь и правила для этого трафика.ACK_common
Hi_1
Lo_1
Hi_2
Lo_2
… -
Наверно я не совсем доходчиво объяснил. В принципе у меня так и сделано как вы написали, но более усложненно. Насчет приоритетов - я не знаю есть ли возможность назначать один и тот же приоритет на несколько очередей. Как PFSense это понимает? Если же нельзя, то получается, что нельзя создавать более 7 (т.к. всего 7 приоритетов HFSC) очередей одного уровня. Но так как я создаю для каждой подсети свою очередь, то и получается, что сколько приоритетов, то столько и очередей для подсетей я могу прописать, т.е. не более 7. Но у меня 9 подсетей. Поэтому и задаю такие вопросы.
В итоге, у меня 2 вопроса:
1. Можно ли назначать один и тот же приоритет нескольким очередям?
2. КАК можно создать, например, вирт.интерфейс в PFSense и привязать его к определенной подсети, чтобы уже потом писать очереди шейпера для этого вирт.интерфейса? -
1. Да можно без ограничений.
2. Не понятно что значит привязать и виртуальные интерфейсы ? Есть VLAN, есть Virtual IP. -
Я приведу аналогию.
Шейпер в пф, это ведро в которое льется трафик входящего канала. Ваши правила - это дырки в ведре, через которые трафик выливается. Как только ведро заполнено, пакеты начинают отбрасываться (дропаются). Размер ведра обычно меньше скорости входящего канала (для эффективной работы).
Задача шейпера - не давать ведру переполняться. Но если ведро переполнилось, то правилами задаются приоритетные дырки, через которые трафик надо выпускать в первую очередь (и доля трафика вливающегося в ведро для этих дырок постепенно будет расти, а для остальных уменьшаться). Но правила, повторяю еще раз, делаются для дырок - исходящих каналов.
Если сделаете много интерфейсов, то вместо одного ведра получите несколько, которые наполняются независимыми входящими каналами.
Но как тут уже раньше писали, у вас есть физическое ограничение канала и канал этот только один. И независимых входящих каналов нет. Резать его еще самому на куски дополнительными интерфейсами особо смысла нет (но можно если хотите).
Все что вы можете, это правилами регулировать дырки в ведре (ваши подсети) чтобы оно не переполнялось.
Все это делается только если есть четкий план приоритета, если его нет - то шейпер в вашем случае не нужен. -
Nomeron, спасибо за доходчивое разъяснение. Как вы написали, в принципе, так я и полагал и сделал с некоторыми оговорками.
Но для интереса, а как можно было бы разделить один физический канал на несколько кроме использования VLAN и подключения дополнительных сетевых карт? -
Nomeron, спасибо за доходчивое разъяснение. Как вы написали, в принципе, так я и полагал и сделал с некоторыми оговорками.
Но для интереса, а как можно было бы разделить один физический канал на несколько кроме использования VLAN и подключения дополнительных сетевых карт?Alias-ми для подсетей (диапазонов адресов).
