forum.opennet.ru - "PF: Два канала и ограничение трафика" (19)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"PF: Два канала и ограничение трафика"

Форум Открытые системы на сервере (Маршрутизация, NAT / FreeBSD)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"PF: Два канала и ограничение трафика"	+/–
Сообщение от yurybx (ok) on 12-Июн-12, 16:54
Имеется два интернет-канала: основной и резервный. На FreeBSD-сервере накручены скрипты, которые пингуют корневые DNS с обоих каналов и на основе ответов определяют дохлый канал и в случает такового переключают основной маршрут на другой канал. Чтобы это работало в pf.conf прописаны правила: pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) pass out inet from { ($ext_if) $ext3_if } to (self:network) Средствами ALTQ для некоторых пользователей ограничивается входящий трафик. Теперь же нужно ограничить исходящий трафик некоторым пользователям (которые обнаглели и стали его забивать). Но я не знаю, как это сделать, сохранив маршрутизацию пакетов через оба канала. Если бы был один активный канал, то проблем нету: pass out on $ext_if from 192.168.1.0/24 to any queue q_out pass out on $ext3_if from 192.168.1.0/24 to any queue q_out Прошу помощи в поиске нужного синтаксиса.
Ответить \| Правка \| Cообщить модератору

Оглавление

PF: Два канала и ограничение трафика, user, 18:33 , 12-Июн-12, (1)

PF: Два канала и ограничение трафика, yurybx, 11:45 , 14-Июн-12, (12)

PF: Два канала и ограничение трафика, PavelR, 08:06 , 13-Июн-12, (2)

PF: Два канала и ограничение трафика, yurybx, 10:15 , 13-Июн-12, (3)

PF: Два канала и ограничение трафика, user, 10:29 , 13-Июн-12, (4)

PF: Два канала и ограничение трафика, yurybx, 10:48 , 13-Июн-12, (5)

PF: Два канала и ограничение трафика, yurybx, 10:51 , 13-Июн-12, (6)

PF: Два канала и ограничение трафика, user, 16:46 , 13-Июн-12, (7)

PF: Два канала и ограничение трафика, a2l, 09:41 , 15-Июн-12, (15)

PF: Два канала и ограничение трафика, yurybx, 09:46 , 15-Июн-12, (16)

PF: Два канала и ограничение трафика, LSTemp, 17:35 , 13-Июн-12, (8)

PF: Два канала и ограничение трафика, yurybx, 10:25 , 14-Июн-12, (9)

PF: Два канала и ограничение трафика, user, 10:45 , 14-Июн-12, (10)

PF: Два канала и ограничение трафика, yurybx, 11:05 , 14-Июн-12, (11)

PF: Два канала и ограничение трафика, rush_alex, 12:25 , 14-Июн-12, (13)

PF: Два канала и ограничение трафика, yurybx, 12:50 , 14-Июн-12, (14)

PF: Два канала и ограничение трафика, rush_alex, 10:48 , 15-Июн-12, (17)

PF: Два канала и ограничение трафика, LSTemp, 14:05 , 15-Июн-12, (18)

PF: Два канала и ограничение трафика, yurybx, 14:20 , 15-Июн-12, (19)

Сообщения по теме [Сортировка по времени | RSS]

1. "PF: Два канала и ограничение трафика" +/–

Сообщение от user (??) on 12-Июн-12, 18:33

>[оверквотинг удален]
> pass out route-to ($ext_if <ext_gw>) inet from ($ext_if)
> pass out inet from { ($ext_if) $ext3_if } to (self:network)
> Средствами ALTQ для некоторых пользователей ограничивается входящий трафик. Теперь же
> нужно ограничить исходящий трафик некоторым пользователям (которые обнаглели и стали его
> забивать). Но я не знаю, как это сделать, сохранив маршрутизацию пакетов
> через оба канала.
> Если бы был один активный канал, то проблем нету:
> pass out on $ext_if from 192.168.1.0/24 to any queue q_out
> pass out on $ext3_if from 192.168.1.0/24 to any queue q_out
> Прошу помощи в поиске нужного синтаксиса.
Сразу скажу, что шейпить исходящий на 2х каналах не приходилось, но я бы копал в такую сторону.
  Если у вас НАТ, то приведенные правила не будут работать.

pass in quick on $int_if from 192.168.1.0/24 to any tag LAN1 #назначаем тег
pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if to any queue q_out tagged LAN1 #это будет ограничение от клиенту в мир
pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) to any queue q_out tagged LAN1 # тоже
а потом уже теже правила, но без тега.
И да. Рутовую очередь нужно настроить на обеих внешних.
Вроде все.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 14-Июн-12, 11:45

>[оверквотинг удален]
>   Если у вас НАТ, то приведенные правила не будут работать.
>  pass in quick on $int_if from 192.168.1.0/24 to any tag LAN1
> #назначаем тег
> pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if to any queue q_out
> tagged LAN1 #это будет ограничение от клиенту в мир
> pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) to any queue q_out
> tagged LAN1 # тоже
>  а потом уже теже правила, но без тега.
>  И да. Рутовую очередь нужно настроить на обеих внешних.
>  Вроде все.
Не нашел информации о том, как ведёт себя тегированный пакет после НАТ. Насколько я понял из Ваших слов, тег удаляется после трансляции, и его нельзя использовать в правилах pass out on ext_if?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "PF: Два канала и ограничение трафика" +/–

Сообщение от PavelR (ok) on 13-Июн-12, 08:06

> Имеется два интернет-канала: основной и резервный.
...
> определяют дохлый канал и в случает такового переключают основной маршрут на
> другой канал.
...
> Если бы был один активный канал, то проблем нету:
Исходя из вашего описания, в один момент времени у вас один активный канал.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 13-Июн-12, 10:15

У меня именно NAT.
В один момент времени один канал используется для раздачи интернета. НО! Сервер с помощью скрипта делает пинги по корневым DNS через ОБА канала, чтобы определять, какой из них живой, а какой - мёртвый.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "PF: Два канала и ограничение трафика" +/–

Сообщение от user (??) on 13-Июн-12, 10:29

> У меня именно NAT.
> В один момент времени один канал используется для раздачи интернета. НО! Сервер
> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
> чтобы определять, какой из них живой, а какой - мёртвый.
Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на сайте PF User's guide.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 13-Июн-12, 10:48

>> У меня именно NAT.
>> В один момент времени один канал используется для раздачи интернета. НО! Сервер
>> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
>> чтобы определять, какой из них живой, а какой - мёртвый.
> Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на
> сайте PF User's guide.
Это плохо для меня: стабильность интеренета в том офисе - больная тема, а скрипты отлажены и долгое время исправно работают. Они выполняют следующие функции:
1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и переключают на другой канал
2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала и в таком случае переключают маршрутизацию обратно на него (перед этим делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
3) При переключении маршрутизации переключается также relay-host в postfix
4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 13-Июн-12, 10:51

Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и ограничение исходящего трафика?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "PF: Два канала и ограничение трафика" +/–

Сообщение от user (??) on 13-Июн-12, 16:46

> Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и
> ограничение исходящего трафика?
Почему не выходит. Боюсь вам нужно ставть виртуалбокс, имитировать вашу реальную ситуацию и пробовать, пробовать и еще раз пробовать выполнить поставленную задачу. А потом в продакшен. Ничего особенного, все как обычно :-)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

15. "PF: Два канала и ограничение трафика" +/–

Сообщение от a2l on 15-Июн-12, 09:41

>[оверквотинг удален]
> Это плохо для меня: стабильность интеренета в том офисе - больная тема,
> а скрипты отлажены и долгое время исправно работают. Они выполняют следующие
> функции:
> 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и
> переключают на другой канал
> 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала
> и в таком случае переключают маршрутизацию обратно на него (перед этим
> делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
> 3) При переключении маршрутизации переключается также relay-host в postfix
> 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.
Кто мешает иметь два конфига pf и переключать их тем же скриптом?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

16. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 15-Июн-12, 09:46

>[оверквотинг удален]
>> а скрипты отлажены и долгое время исправно работают. Они выполняют следующие
>> функции:
>> 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и
>> переключают на другой канал
>> 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала
>> и в таком случае переключают маршрутизацию обратно на него (перед этим
>> делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
>> 3) При переключении маршрутизации переключается также relay-host в postfix
>> 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.
> Кто мешает иметь два конфига pf и переключать их тем же скриптом?
Проблема не с переключением, а с тем, чтобы совместить две функции одновременно:
1) Возможность пинговать через оба канала одновременно
2) Нарезка исходящего трафика на активном канале

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

8. "PF: Два канала и ограничение трафика" +/–

Сообщение от LSTemp (ok) on 13-Июн-12, 17:35

> У меня именно NAT.
> В один момент времени один канал используется для раздачи интернета. НО! Сервер
> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
> чтобы определять, какой из них живой, а какой - мёртвый.
не спец во Фре, но:
- если юзеры одномоментно ч/з один из двух каналов идут в инет, то почему бы просто не поставить одинаковые ограничение исходящего трафика на обоих каналах для этих юзеров? для нормальных все останется по прежнему, а "исходяки" пусть плачут при переключении - их проблема
- давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но не думаю, что будут проблемы в реализации для данной ОС.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 14-Июн-12, 10:25

Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко):
pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if
pass out route-to ($ext_if <ext_gw>) inet from ($ext_if)
pass out inet from { ($ext_if) $ext3_if } to (self:network)
pass out on $ext3_if from 192.168.1.0/24 to any queue q_out
pass out on $ext_if from 192.168.1.0/24 to any queue q_out
По-идее, должно было работать: PF сканит весь список правил и выбирает последнее подходящее. В этом случае пакеты от ограничиваемых пользователей должны попадать строго в последние два правила, и только пакеты от самого сервера будут идти через первые три правила. Или я не прав?
Кстати, когда я игрался с ограничением входящего трафика (исходящего на внутренних интерфейсах), то пришёл к выводу, что ALTQ не работает с keep state. А в последних двух правилах как раз стоит keep state по-умолчанию. Можно, конечно, написать no state, но тогда NAT не будет работать.
Есть ли какой-то способ подружить ALTQ и keep state?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "PF: Два канала и ограничение трафика" +/–

Сообщение от user (??) on 14-Июн-12, 10:45

> Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко):
> pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if
> pass out route-to ($ext_if <ext_gw>) inet from ($ext_if)
> pass out inet from { ($ext_if) $ext3_if } to (self:network)
> pass out on $ext3_if from 192.168.1.0/24 to any queue q_out
> pass out on $ext_if from 192.168.1.0/24 to any queue q_out
> По-идее, должно было работать: PF сканит весь список правил и выбирает последнее
> подходящее. В этом случае пакеты от ограничиваемых пользователей должны попадать строго
> в последние два правила, и только пакеты от самого сервера будут
> идти через первые три правила. Или я не прав?
Вы делаете неправильно. Я же вам писал, что после ната на внешнем вы уже не оперируете 192.168.1.0/24, там есть только адрес вашей внешней сетевой. Вам нужно тегировать.
> Кстати, когда я игрался с ограничением входящего трафика (исходящего на внутренних интерфейсах),
> то пришёл к выводу, что ALTQ не работает с keep state.
> А в последних двух правилах как раз стоит keep state по-умолчанию.
> Можно, конечно, написать no state, но тогда NAT не будет работать.
> Есть ли какой-то способ подружить ALTQ и keep state?
Все прекрасно работает с keep-state. Почитайте статью
http://www.opennet.dev/tips/2680_freebsd_router_pf_altq_traff...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 14-Июн-12, 11:05

>[оверквотинг удален]
>> чтобы определять, какой из них живой, а какой - мёртвый.
> не спец во Фре, но:
> - если юзеры одномоментно ч/з один из двух каналов идут в инет,
> то почему бы просто не поставить одинаковые ограничение исходящего трафика на
> обоих каналах для этих юзеров? для нормальных все останется по прежнему,
> а "исходяки" пусть плачут при переключении - их проблема
> - давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для
> централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать
> для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но
> не думаю, что будут проблемы в реализации для данной ОС.
А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из реального внешнего интерфейса. Или я чего-то не понимаю?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "PF: Два канала и ограничение трафика" +/–

Сообщение от rush_alex (??) on 14-Июн-12, 12:25

У меня в архиве валялось
# Включить трансляцию адресов на внешних интерфейсах.#
#nat on $ext_if_a inet from !(self) -> $ext_if_a
#nat on $ext_if_b inet from !(self) -> $ext_if_b
nat on $ext_if_a inet from !(self) tag TR !tagged TR -> $ext_if_a
nat on $ext_if_b inet from !(self) tag TR !tagged TR -> $ext_if_b
# FTP-PROXY
#no rdr on lo0 from any to any
rdr proto tcp from { $int_if:network, 192.168.4.0/24 } to !(self) port ftp -> lo0 port 8021
#rdr pass on $int_if proto tcp from  192.168.0.129 to any port {ftp} -> 192.168.0.4 port 2121
#HTTP всех на переадресовываем на Squid
#rdr pass on $int_if proto tcp from  any to any port http -> $int_if port 3128
rdr on $int_if proto tcp from  any to !<nosquid-list> port http -> $int_if port 3128
rdr on $int_if proto tcp from  !<white-list> to any port $ext_proxy -> $int_if port 3128
#rdr pass on $int_if proto tcp from  !<nosquid-list> to any port http -> $int_if port http
#rdr on $int_if proto tcp from any to any port $ext_proxy -> $int_if port 3128
# Переадресовать TCP сессии для сервисов, обслуживаемых локальным сервером.
# Правила rdr здесь НЕ должны содержать слова pass.
rdr on $ext_if_a inet proto tcp to $ext_if_a port { $int_server2_port } tag EXT_IF_A -> $int_server2
rdr on $ext_if_b inet proto tcp to $ext_if_b port { $int_server2_port } tag EXT_IF_B -> $int_server2
rdr on $ext_if_a inet proto tcp to $ext_if_a port { $ftp2ports } tag EXT_IF_A -> $ftp_lan_server
rdr on $ext_if_b inet proto tcp to $ext_if_b port { $ftp2ports } tag EXT_IF_B -> $ftp_lan_server
rdr on $ext_if_a inet proto tcp to $ext_if_a port { $ftp_ext_ports } tag EXT_IF_A -> $ftp_lan_server
rdr on $ext_if_b inet proto tcp to $ext_if_b port { $ftp_ext_ports } tag EXT_IF_B -> $ftp_lan_server
rdr on $ext_if_a inet proto tcp to $ext_if_a port { $videoports } tag EXT_IF_A -> $video_lan_server
rdr on $ext_if_b inet proto tcp to $ext_if_b port { $videoports } tag EXT_IF_B -> $video_lan_server
rdr on $ext_if_a inet proto tcp to $ext_if_a port { ssh } tag EXT_IF_A -> lo0 port ssh
rdr on $ext_if_b inet proto tcp to $ext_if_b port { ssh } tag EXT_IF_B -> lo0 port ssh
#rdr on $ext_if_b inet proto tcp to $ext_if_b port { ssh } tag EXT_IF_B -> lo0 port ssh
## SMTP-SPAM
##rdr on $ext_if_a inet proto tcp to $ext_if_a port { smtp } tag EXT_IF_A -> lo0 port smtp
rdr on $ext_if_a inet proto tcp from <spamd-whitelist> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port smtp
rdr on $ext_if_a inet proto tcp from <spamd> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port spamd
rdr on $ext_if_a inet proto tcp from !<spamd-white> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a  port spamd
rdr on $ext_if_a inet proto tcp from <spamd-white> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port smtp
#rdr on $ext_if_b inet proto tcp to $ext_if_b port { smtp } tag EXT_IF_B -> lo0 port smtp
rdr on $ext_if_b inet proto tcp from <spamd-whitelist> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port smtp
rdr on $ext_if_b inet proto tcp from <spamd> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port spamd
rdr on $ext_if_b inet proto tcp from !<spamd-white> to $ext_if_b port { smtp } tag EXT_IF_B ->  $ext_if_b port spamd
rdr on $ext_if_b inet proto tcp from <spamd-white> to $ext_if_b port { smtp } tag EXT_IF_B ->  $ext_if_b port smtp
# Разрешить подключение к переадресованным сервисам из локальной сети по
# внешним адресам.
#
rdr pass on $int_if inet proto tcp to { $ext_if_a $ext_if_b } port { $int_server2_port } tag INT_IF_RDR -> $int_server2
rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $ftp2ports } tag INT_IF_RDR -> $ftp_lan_server
rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $ftp_ext_ports } tag INT_IF_RDR -> $ftp_lan_server
rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $videoports } tag INT_IF_RDR -> $video_lan_server
nat on $int_if tagged INT_IF_RDR -> $int_if:0

# Перенаправляем определенные tcp по определенному каналу
#nat on $ext_if_b inet proto tcp from $ext_if_b to port 25 -> $ext_if_a
#nat on !$int_if  inet proto {tcp udp } to port 53 tag TRANSFER !tagged TRANSFER  -> {($ext_if_a),($ext_if_b)}
#nat on !$int_if  inet proto tcp to port http tag TRANSFER !tagged TRANSFER  -> { ($ext_if_a:0) , ($ext_if_b:0) }
# По умолчанию блокировать весь трафик на всех интерфейсах. Для входящих TCP
# соединений возвращать RST.
block log on { $ext_if_a $ext_if_b $int_if}
block return log on { $ext_if_a $ext_if_b $int_if} inet proto tcp
# Blok by rfc1918
block  in quick on  { $ext_if_a $ext_if_b } from <rfc1918> to any
# Blok by white-list and block-list
block  in quick on $int_if from !<white-list> to <block-list>
#teamviever
block in quick on $int_if inet proto {tcp udp} from any to any port 5938
# pass traffic on the loopback interface in either direction
pass in on lo0 all
#pass quick on lo0 all
pass out on lo0 all
##  pass all outgoing packets on internal interface
#pass out on $int_if from any to $int_if:network
##  pass in quick any packets destined for the gateway itself
#pass in quick on $int_if from $int_if:network to $int_if
#Разрешить доступ через лок интерфейс к терминал серверу
pass out quick on $int_if inet proto tcp from any to $int_server1 port {$int_server1_port} keep state queue iif_sound
pass out quick on $int_if inet proto tcp from any to $int_server2 port {$int_server2_port} keep state queue iif_sound
pass out quick on { $int_if } inet proto tcp from any to { $ftp_lan_server } port { $ftp2ports } keep state queue iif_sound
pass out quick on { $int_if } inet proto tcp from any to { $ftp_lan_server } port { $ftp_ext_ports } keep state queue iif_sound
pass out quick on { $int_if } inet proto tcp from any to { $video_lan_server } port { $videoports } keep state queue iif_sound
# Пропускаем входящие пакеты для переадресованых сервисов. Устанавливаем
# для них симметричную маршрутизацию (если пакет пришел
# из канала A, ответ пойдет через канал A независимо от default route)
pass in quick reply-to ($ext_if_a $ext_gw_a) tagged EXT_IF_A keep state
pass in quick reply-to ($ext_if_b $ext_gw_b) tagged EXT_IF_B keep state
#pass in reply-to ($ext_if_a $ext_gw_a) tagged EXT_IF_A keep state
#pass in reply-to ($ext_if_b $ext_gw_b) tagged EXT_IF_B keep state
# Выпускать исходящие пакеты. Установить маршрутизацию в зависимости от
# адреса источника. Пакеты с адресом интерфейса A уходят в канал A,
# с адресом интерфейса B - в канал B.
pass out route-to ( $ext_if_a $ext_gw_a ) inet from $ext_if_a keep state
pass out log route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {smtp} keep state queue eif_a_smtp
pass out route-to ( $ext_if_a $ext_gw_a ) inet proto udp from $ext_if_a to port {$1ext_ext_serv_udp} keep state queue eif_a_sound
pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$1ext_ext_serv} keep state queue eif_a_sound
pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$2ext_ext_serv} keep state queue eif_a_ftp
pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$3ext_ext_serv} keep state queue eif_a_http
pass out route-to ( $ext_if_b $ext_gw_b ) inet from $ext_if_b keep state
pass out log route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {smtp} keep state queue eif_b_smtp
pass out route-to ( $ext_if_b $ext_gw_b ) inet proto udp from $ext_if_b to port {$1ext_ext_serv_udp} keep state queue eif_b_sound
pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$1ext_ext_serv} keep state queue eif_b_sound
pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$2ext_ext_serv} keep state queue eif_b_ftp
pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$3ext_ext_serv} keep state queue eif_b_http
# Разрешить входящие ICMP PING пакеты.#
pass in on $ext_if_a reply-to ($ext_if_a $ext_gw_a) inet proto icmp to $ext_if_a icmp-type echoreq code 0 keep state queue eif_a_sound
pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto icmp to $ext_if_b icmp-type echoreq code 0 keep state queue eif_b_sound
# Разрешить входящие TCP сессии для обслуживаемых сервисов.#
#pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet to $ext_if_a
pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto udp to $ext_if_a port { $1ext_int_serv_udp } queue eif_a_sound
pass in log on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port smtp keep state queue eif_a_smtp
pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $1ext_int_serv } flags S/SA keep state queue eif_a_sound
pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $2ext_int_serv } flags S/SA keep state queue eif_a_ftp
pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $3ext_int_serv } flags S/SA keep state queue eif_a_http
#pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet to $ext_if_b
pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto udp to $ext_if_b port { $1ext_int_serv_udp } keep state queue eif_b_sound
pass in log on $ext_if_b reply-to ( $ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port smtp keep state queue eif_b_smtp
pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $1ext_int_serv } flags S/SA keep state queue eif_b_sound
pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $2ext_int_serv } flags S/SA keep state queue eif_b_ftp
pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $3ext_int_serv } flags S/SA keep state queue eif_b_http
#pass in on $ext_if_a reply-to ($ext_if_a $ext_gw_a) inet proto tcp from any to $ext_if_a user proxy keep state
#pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp from any to $ext_if_b user proxy keep state
#block in quick on $int_if inet proto tcp from <block-list-in> to any port {3128 80 8080 8081}
#Разрешить в локалку пакеты от внутреннего интерфейса, из локальных сетей
# туннелей
pass out on $int_if inet from { $int_if:0, 192.168.3.0/24, 192.168.4.0/24 } to $int_if:network:0 keep state
pass out on $int_if inet proto tcp from { $int_if:0 } port { $1int_int_serv } to $int_if:network:0 keep state queue iif_sound
pass out on $int_if inet proto tcp from { $int_if:0 } port { $2int_int_serv } to $int_if:network:0 keep state queue iif_ftp
pass out on $int_if inet proto tcp from { $int_if:0 } port { $3int_int_serv } to $int_if:network:0 keep state queue iif_http

#Разрешить из локалки пакеты на внутренний интерфейс, в локальные сети
# туннелей
pass in on $int_if inet from $int_if:network:0 to { 192.168.3.0/24, 192.168.4.0/24 } keep state
pass in on $int_if inet proto udp from $int_if:network:0 to self port { $1int_int_serv_udp } keep state queue iif_sound
pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $1int_int_serv } keep state queue iif_sound
pass in on $int_if inet proto tcp from !<block-list-in> to self port { $2int_int_serv } keep state queue iif_ftp
pass in on $int_if inet proto tcp from !<block-list-in> to self port { $3int_int_serv } keep state queue iif_http
#Разрешить из локалки пинг
pass in on $int_if inet proto icmp from $int_if:network:0 to any icmp-type echoreq code 0 keep state
#Разрешить из локалки ext_ext_serv
pass in on $int_if inet from !<block-list-in> to !(self) keep state
pass in on $int_if inet proto udp from !<block-list-in> to !(self) port { $1ext_ext_serv_udp } keep state queue iif_sound
pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $1ext_ext_serv } flags S/SA keep state queue iif_sound
pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $2ext_ext_serv } flags S/SA keep state queue iif_ftp
pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $3ext_ext_serv } flags S/SA keep state queue iif_http
#Разрешить из локалки int_int_serv
pass in on $int_if inet from any to $int_if keep state
pass in on $int_if inet proto udp from $int_if:network:0 to self port { $1int_int_serv_udp } keep state
pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $1int_int_serv } flags S/SA keep state
pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $2int_int_serv } flags S/SA keep state
pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $3int_int_serv } flags S/SA keep state

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 14-Июн-12, 12:50

В Вашем примере нарезка исходящего трафика по портам, а мне нужно по ай-пи адресам локальной сети.
Однако крайне заинтересовали строки:
nat on $ext_if_a inet from !(self) tag TR !tagged TR -> $ext_if_a
nat on $ext_if_b inet from !(self) tag TR !tagged TR -> $ext_if_b
Возникла мысль назначать тег в правилах трансляции, и потом работать с ним в правилах pass out on ext_if. Например, так:
nat on $ext_if from $lan1 to any -> ($ext_if)
nat on $ext3_if from $lan1 to any -> $ext3_if
nat on $ext_if from $lan2 to any tag Limited -> ($ext_if)
nat on $ext3_if from $lan2 to any tag Limited -> $ext3_if
pass out route-to ($ext_if <ext_gw>) inet from ($ext_if)
pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if
pass out inet from { ($ext_if) $ext3_if } to (self:network)
pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) tagged Limited queue q_out
pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if tagged Limited queue q3_out
По-идее должно работать. Или нет?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "PF: Два канала и ограничение трафика" +/–

Сообщение от rush_alex (??) on 15-Июн-12, 10:48

>[оверквотинг удален]
> nat on $ext_if from $lan1 to any -> ($ext_if)
> nat on $ext3_if from $lan1 to any -> $ext3_if
> nat on $ext_if from $lan2 to any tag Limited -> ($ext_if)
> nat on $ext3_if from $lan2 to any tag Limited -> $ext3_if
> pass out route-to ($ext_if <ext_gw>) inet from ($ext_if)
> pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if
> pass out inet from { ($ext_if) $ext3_if } to (self:network)
> pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) tagged Limited queue q_out
> pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if tagged Limited queue q3_out
> По-идее должно работать. Или нет?
По внешнему виду должно...

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "PF: Два канала и ограничение трафика" +/–

Сообщение от LSTemp (ok) on 15-Июн-12, 14:05

>>[оверквотинг удален]
> А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю
> схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем
> виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из
> реального внешнего интерфейса. Или я чего-то не понимаю?
IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс. там трафик режется тем же tc например и после обработки опять попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил.
наверняка подобные механизмы и во Free есть.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

19. "PF: Два канала и ограничение трафика" +/–

Сообщение от yurybx (ok) on 15-Июн-12, 14:20

>>>[оверквотинг удален]
>> А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю
>> схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем
>> виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из
>> реального внешнего интерфейса. Или я чего-то не понимаю?
> IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются
> на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс.
> там трафик режется тем же tc например и после обработки опять
> попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил.
> наверняка подобные механизмы и во Free есть.
Интересно. Да, я уже нарисовал схему, действительно интересный способ. Спасибо за информацию к размышлению!

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "PF: Два канала и ограничение трафика"	+/–
Сообщение от user (??) on 12-Июн-12, 18:33
>[оверквотинг удален] > pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) > pass out inet from { ($ext_if) $ext3_if } to (self:network) > Средствами ALTQ для некоторых пользователей ограничивается входящий трафик. Теперь же > нужно ограничить исходящий трафик некоторым пользователям (которые обнаглели и стали его > забивать). Но я не знаю, как это сделать, сохранив маршрутизацию пакетов > через оба канала. > Если бы был один активный канал, то проблем нету: > pass out on $ext_if from 192.168.1.0/24 to any queue q_out > pass out on $ext3_if from 192.168.1.0/24 to any queue q_out > Прошу помощи в поиске нужного синтаксиса. Сразу скажу, что шейпить исходящий на 2х каналах не приходилось, но я бы копал в такую сторону. Если у вас НАТ, то приведенные правила не будут работать. pass in quick on $int_if from 192.168.1.0/24 to any tag LAN1 #назначаем тег pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if to any queue q_out tagged LAN1 #это будет ограничение от клиенту в мир pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) to any queue q_out tagged LAN1 # тоже а потом уже теже правила, но без тега. И да. Рутовую очередь нужно настроить на обеих внешних. Вроде все.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	12. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 14-Июн-12, 11:45
	>[оверквотинг удален] > Если у вас НАТ, то приведенные правила не будут работать. > pass in quick on $int_if from 192.168.1.0/24 to any tag LAN1 > #назначаем тег > pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if to any queue q_out > tagged LAN1 #это будет ограничение от клиенту в мир > pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) to any queue q_out > tagged LAN1 # тоже > а потом уже теже правила, но без тега. > И да. Рутовую очередь нужно настроить на обеих внешних. > Вроде все. Не нашел информации о том, как ведёт себя тегированный пакет после НАТ. Насколько я понял из Ваших слов, тег удаляется после трансляции, и его нельзя использовать в правилах pass out on ext_if?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

2. "PF: Два канала и ограничение трафика"	+/–
Сообщение от PavelR (ok) on 13-Июн-12, 08:06
> Имеется два интернет-канала: основной и резервный. ... > определяют дохлый канал и в случает такового переключают основной маршрут на > другой канал. ... > Если бы был один активный канал, то проблем нету: Исходя из вашего описания, в один момент времени у вас один активный канал.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 13-Июн-12, 10:15
	У меня именно NAT. В один момент времени один канал используется для раздачи интернета. НО! Сервер с помощью скрипта делает пинги по корневым DNS через ОБА канала, чтобы определять, какой из них живой, а какой - мёртвый.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от user (??) on 13-Июн-12, 10:29
	> У меня именно NAT. > В один момент времени один канал используется для раздачи интернета. НО! Сервер > с помощью скрипта делает пинги по корневым DNS через ОБА канала, > чтобы определять, какой из них живой, а какой - мёртвый. Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на сайте PF User's guide.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 13-Июн-12, 10:48
	>> У меня именно NAT. >> В один момент времени один канал используется для раздачи интернета. НО! Сервер >> с помощью скрипта делает пинги по корневым DNS через ОБА канала, >> чтобы определять, какой из них живой, а какой - мёртвый. > Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на > сайте PF User's guide. Это плохо для меня: стабильность интеренета в том офисе - больная тема, а скрипты отлажены и долгое время исправно работают. Они выполняют следующие функции: 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и переключают на другой канал 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала и в таком случае переключают маршрутизацию обратно на него (перед этим делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда) 3) При переключении маршрутизации переключается также relay-host в postfix 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 13-Июн-12, 10:51
	Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и ограничение исходящего трафика?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от user (??) on 13-Июн-12, 16:46
	> Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и > ограничение исходящего трафика? Почему не выходит. Боюсь вам нужно ставть виртуалбокс, имитировать вашу реальную ситуацию и пробовать, пробовать и еще раз пробовать выполнить поставленную задачу. А потом в продакшен. Ничего особенного, все как обычно :-)
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	15. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от a2l on 15-Июн-12, 09:41
	>[оверквотинг удален] > Это плохо для меня: стабильность интеренета в том офисе - больная тема, > а скрипты отлажены и долгое время исправно работают. Они выполняют следующие > функции: > 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и > переключают на другой канал > 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала > и в таком случае переключают маршрутизацию обратно на него (перед этим > делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда) > 3) При переключении маршрутизации переключается также relay-host в postfix > 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д. Кто мешает иметь два конфига pf и переключать их тем же скриптом?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	16. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 15-Июн-12, 09:46
	>[оверквотинг удален] >> а скрипты отлажены и долгое время исправно работают. Они выполняют следующие >> функции: >> 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и >> переключают на другой канал >> 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала >> и в таком случае переключают маршрутизацию обратно на него (перед этим >> делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда) >> 3) При переключении маршрутизации переключается также relay-host в postfix >> 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д. > Кто мешает иметь два конфига pf и переключать их тем же скриптом? Проблема не с переключением, а с тем, чтобы совместить две функции одновременно: 1) Возможность пинговать через оба канала одновременно 2) Нарезка исходящего трафика на активном канале
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	8. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от LSTemp (ok) on 13-Июн-12, 17:35
	> У меня именно NAT. > В один момент времени один канал используется для раздачи интернета. НО! Сервер > с помощью скрипта делает пинги по корневым DNS через ОБА канала, > чтобы определять, какой из них живой, а какой - мёртвый. не спец во Фре, но: - если юзеры одномоментно ч/з один из двух каналов идут в инет, то почему бы просто не поставить одинаковые ограничение исходящего трафика на обоих каналах для этих юзеров? для нормальных все останется по прежнему, а "исходяки" пусть плачут при переключении - их проблема - давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но не думаю, что будут проблемы в реализации для данной ОС.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	9. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 14-Июн-12, 10:25
	Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко): pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) pass out inet from { ($ext_if) $ext3_if } to (self:network) pass out on $ext3_if from 192.168.1.0/24 to any queue q_out pass out on $ext_if from 192.168.1.0/24 to any queue q_out По-идее, должно было работать: PF сканит весь список правил и выбирает последнее подходящее. В этом случае пакеты от ограничиваемых пользователей должны попадать строго в последние два правила, и только пакеты от самого сервера будут идти через первые три правила. Или я не прав? Кстати, когда я игрался с ограничением входящего трафика (исходящего на внутренних интерфейсах), то пришёл к выводу, что ALTQ не работает с keep state. А в последних двух правилах как раз стоит keep state по-умолчанию. Можно, конечно, написать no state, но тогда NAT не будет работать. Есть ли какой-то способ подружить ALTQ и keep state?
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от user (??) on 14-Июн-12, 10:45
	> Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко): > pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if > pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) > pass out inet from { ($ext_if) $ext3_if } to (self:network) > pass out on $ext3_if from 192.168.1.0/24 to any queue q_out > pass out on $ext_if from 192.168.1.0/24 to any queue q_out > По-идее, должно было работать: PF сканит весь список правил и выбирает последнее > подходящее. В этом случае пакеты от ограничиваемых пользователей должны попадать строго > в последние два правила, и только пакеты от самого сервера будут > идти через первые три правила. Или я не прав? Вы делаете неправильно. Я же вам писал, что после ната на внешнем вы уже не оперируете 192.168.1.0/24, там есть только адрес вашей внешней сетевой. Вам нужно тегировать. > Кстати, когда я игрался с ограничением входящего трафика (исходящего на внутренних интерфейсах), > то пришёл к выводу, что ALTQ не работает с keep state. > А в последних двух правилах как раз стоит keep state по-умолчанию. > Можно, конечно, написать no state, но тогда NAT не будет работать. > Есть ли какой-то способ подружить ALTQ и keep state? Все прекрасно работает с keep-state. Почитайте статью http://www.opennet.dev/tips/2680_freebsd_router_pf_altq_traff...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 14-Июн-12, 11:05
	>[оверквотинг удален] >> чтобы определять, какой из них живой, а какой - мёртвый. > не спец во Фре, но: > - если юзеры одномоментно ч/з один из двух каналов идут в инет, > то почему бы просто не поставить одинаковые ограничение исходящего трафика на > обоих каналах для этих юзеров? для нормальных все останется по прежнему, > а "исходяки" пусть плачут при переключении - их проблема > - давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для > централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать > для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но > не думаю, что будут проблемы в реализации для данной ОС. А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из реального внешнего интерфейса. Или я чего-то не понимаю?
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	13. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от rush_alex (??) on 14-Июн-12, 12:25
	У меня в архиве валялось # Включить трансляцию адресов на внешних интерфейсах.# #nat on $ext_if_a inet from !(self) -> $ext_if_a #nat on $ext_if_b inet from !(self) -> $ext_if_b nat on $ext_if_a inet from !(self) tag TR !tagged TR -> $ext_if_a nat on $ext_if_b inet from !(self) tag TR !tagged TR -> $ext_if_b # FTP-PROXY #no rdr on lo0 from any to any rdr proto tcp from { $int_if:network, 192.168.4.0/24 } to !(self) port ftp -> lo0 port 8021 #rdr pass on $int_if proto tcp from 192.168.0.129 to any port {ftp} -> 192.168.0.4 port 2121 #HTTP всех на переадресовываем на Squid #rdr pass on $int_if proto tcp from any to any port http -> $int_if port 3128 rdr on $int_if proto tcp from any to !<nosquid-list> port http -> $int_if port 3128 rdr on $int_if proto tcp from !<white-list> to any port $ext_proxy -> $int_if port 3128 #rdr pass on $int_if proto tcp from !<nosquid-list> to any port http -> $int_if port http #rdr on $int_if proto tcp from any to any port $ext_proxy -> $int_if port 3128 # Переадресовать TCP сессии для сервисов, обслуживаемых локальным сервером. # Правила rdr здесь НЕ должны содержать слова pass. rdr on $ext_if_a inet proto tcp to $ext_if_a port { $int_server2_port } tag EXT_IF_A -> $int_server2 rdr on $ext_if_b inet proto tcp to $ext_if_b port { $int_server2_port } tag EXT_IF_B -> $int_server2 rdr on $ext_if_a inet proto tcp to $ext_if_a port { $ftp2ports } tag EXT_IF_A -> $ftp_lan_server rdr on $ext_if_b inet proto tcp to $ext_if_b port { $ftp2ports } tag EXT_IF_B -> $ftp_lan_server rdr on $ext_if_a inet proto tcp to $ext_if_a port { $ftp_ext_ports } tag EXT_IF_A -> $ftp_lan_server rdr on $ext_if_b inet proto tcp to $ext_if_b port { $ftp_ext_ports } tag EXT_IF_B -> $ftp_lan_server rdr on $ext_if_a inet proto tcp to $ext_if_a port { $videoports } tag EXT_IF_A -> $video_lan_server rdr on $ext_if_b inet proto tcp to $ext_if_b port { $videoports } tag EXT_IF_B -> $video_lan_server rdr on $ext_if_a inet proto tcp to $ext_if_a port { ssh } tag EXT_IF_A -> lo0 port ssh rdr on $ext_if_b inet proto tcp to $ext_if_b port { ssh } tag EXT_IF_B -> lo0 port ssh #rdr on $ext_if_b inet proto tcp to $ext_if_b port { ssh } tag EXT_IF_B -> lo0 port ssh ## SMTP-SPAM ##rdr on $ext_if_a inet proto tcp to $ext_if_a port { smtp } tag EXT_IF_A -> lo0 port smtp rdr on $ext_if_a inet proto tcp from <spamd-whitelist> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port smtp rdr on $ext_if_a inet proto tcp from <spamd> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port spamd rdr on $ext_if_a inet proto tcp from !<spamd-white> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port spamd rdr on $ext_if_a inet proto tcp from <spamd-white> to $ext_if_a port { smtp } tag EXT_IF_A -> $ext_if_a port smtp #rdr on $ext_if_b inet proto tcp to $ext_if_b port { smtp } tag EXT_IF_B -> lo0 port smtp rdr on $ext_if_b inet proto tcp from <spamd-whitelist> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port smtp rdr on $ext_if_b inet proto tcp from <spamd> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port spamd rdr on $ext_if_b inet proto tcp from !<spamd-white> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port spamd rdr on $ext_if_b inet proto tcp from <spamd-white> to $ext_if_b port { smtp } tag EXT_IF_B -> $ext_if_b port smtp # Разрешить подключение к переадресованным сервисам из локальной сети по # внешним адресам. # rdr pass on $int_if inet proto tcp to { $ext_if_a $ext_if_b } port { $int_server2_port } tag INT_IF_RDR -> $int_server2 rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $ftp2ports } tag INT_IF_RDR -> $ftp_lan_server rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $ftp_ext_ports } tag INT_IF_RDR -> $ftp_lan_server rdr pass on $int_if inet proto tcp to { $int_if $ext_if_a $ext_if_b } port { $videoports } tag INT_IF_RDR -> $video_lan_server nat on $int_if tagged INT_IF_RDR -> $int_if:0 # Перенаправляем определенные tcp по определенному каналу #nat on $ext_if_b inet proto tcp from $ext_if_b to port 25 -> $ext_if_a #nat on !$int_if inet proto {tcp udp } to port 53 tag TRANSFER !tagged TRANSFER -> {($ext_if_a),($ext_if_b)} #nat on !$int_if inet proto tcp to port http tag TRANSFER !tagged TRANSFER -> { ($ext_if_a:0) , ($ext_if_b:0) } # По умолчанию блокировать весь трафик на всех интерфейсах. Для входящих TCP # соединений возвращать RST. block log on { $ext_if_a $ext_if_b $int_if} block return log on { $ext_if_a $ext_if_b $int_if} inet proto tcp # Blok by rfc1918 block in quick on { $ext_if_a $ext_if_b } from <rfc1918> to any # Blok by white-list and block-list block in quick on $int_if from !<white-list> to <block-list> #teamviever block in quick on $int_if inet proto {tcp udp} from any to any port 5938 # pass traffic on the loopback interface in either direction pass in on lo0 all #pass quick on lo0 all pass out on lo0 all ## pass all outgoing packets on internal interface #pass out on $int_if from any to $int_if:network ## pass in quick any packets destined for the gateway itself #pass in quick on $int_if from $int_if:network to $int_if #Разрешить доступ через лок интерфейс к терминал серверу pass out quick on $int_if inet proto tcp from any to $int_server1 port {$int_server1_port} keep state queue iif_sound pass out quick on $int_if inet proto tcp from any to $int_server2 port {$int_server2_port} keep state queue iif_sound pass out quick on { $int_if } inet proto tcp from any to { $ftp_lan_server } port { $ftp2ports } keep state queue iif_sound pass out quick on { $int_if } inet proto tcp from any to { $ftp_lan_server } port { $ftp_ext_ports } keep state queue iif_sound pass out quick on { $int_if } inet proto tcp from any to { $video_lan_server } port { $videoports } keep state queue iif_sound # Пропускаем входящие пакеты для переадресованых сервисов. Устанавливаем # для них симметричную маршрутизацию (если пакет пришел # из канала A, ответ пойдет через канал A независимо от default route) pass in quick reply-to ($ext_if_a $ext_gw_a) tagged EXT_IF_A keep state pass in quick reply-to ($ext_if_b $ext_gw_b) tagged EXT_IF_B keep state #pass in reply-to ($ext_if_a $ext_gw_a) tagged EXT_IF_A keep state #pass in reply-to ($ext_if_b $ext_gw_b) tagged EXT_IF_B keep state # Выпускать исходящие пакеты. Установить маршрутизацию в зависимости от # адреса источника. Пакеты с адресом интерфейса A уходят в канал A, # с адресом интерфейса B - в канал B. pass out route-to ( $ext_if_a $ext_gw_a ) inet from $ext_if_a keep state pass out log route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {smtp} keep state queue eif_a_smtp pass out route-to ( $ext_if_a $ext_gw_a ) inet proto udp from $ext_if_a to port {$1ext_ext_serv_udp} keep state queue eif_a_sound pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$1ext_ext_serv} keep state queue eif_a_sound pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$2ext_ext_serv} keep state queue eif_a_ftp pass out route-to ( $ext_if_a $ext_gw_a ) inet proto tcp from $ext_if_a to port {$3ext_ext_serv} keep state queue eif_a_http pass out route-to ( $ext_if_b $ext_gw_b ) inet from $ext_if_b keep state pass out log route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {smtp} keep state queue eif_b_smtp pass out route-to ( $ext_if_b $ext_gw_b ) inet proto udp from $ext_if_b to port {$1ext_ext_serv_udp} keep state queue eif_b_sound pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$1ext_ext_serv} keep state queue eif_b_sound pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$2ext_ext_serv} keep state queue eif_b_ftp pass out route-to ( $ext_if_b $ext_gw_b ) inet proto tcp from $ext_if_b to port {$3ext_ext_serv} keep state queue eif_b_http # Разрешить входящие ICMP PING пакеты.# pass in on $ext_if_a reply-to ($ext_if_a $ext_gw_a) inet proto icmp to $ext_if_a icmp-type echoreq code 0 keep state queue eif_a_sound pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto icmp to $ext_if_b icmp-type echoreq code 0 keep state queue eif_b_sound # Разрешить входящие TCP сессии для обслуживаемых сервисов.# #pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet to $ext_if_a pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto udp to $ext_if_a port { $1ext_int_serv_udp } queue eif_a_sound pass in log on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port smtp keep state queue eif_a_smtp pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $1ext_int_serv } flags S/SA keep state queue eif_a_sound pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $2ext_int_serv } flags S/SA keep state queue eif_a_ftp pass in on $ext_if_a reply-to ( $ext_if_a $ext_gw_a) inet proto tcp to $ext_if_a port { $3ext_int_serv } flags S/SA keep state queue eif_a_http #pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet to $ext_if_b pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto udp to $ext_if_b port { $1ext_int_serv_udp } keep state queue eif_b_sound pass in log on $ext_if_b reply-to ( $ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port smtp keep state queue eif_b_smtp pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $1ext_int_serv } flags S/SA keep state queue eif_b_sound pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $2ext_int_serv } flags S/SA keep state queue eif_b_ftp pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp to $ext_if_b port { $3ext_int_serv } flags S/SA keep state queue eif_b_http #pass in on $ext_if_a reply-to ($ext_if_a $ext_gw_a) inet proto tcp from any to $ext_if_a user proxy keep state #pass in on $ext_if_b reply-to ($ext_if_b $ext_gw_b) inet proto tcp from any to $ext_if_b user proxy keep state #block in quick on $int_if inet proto tcp from <block-list-in> to any port {3128 80 8080 8081} #Разрешить в локалку пакеты от внутреннего интерфейса, из локальных сетей # туннелей pass out on $int_if inet from { $int_if:0, 192.168.3.0/24, 192.168.4.0/24 } to $int_if:network:0 keep state pass out on $int_if inet proto tcp from { $int_if:0 } port { $1int_int_serv } to $int_if:network:0 keep state queue iif_sound pass out on $int_if inet proto tcp from { $int_if:0 } port { $2int_int_serv } to $int_if:network:0 keep state queue iif_ftp pass out on $int_if inet proto tcp from { $int_if:0 } port { $3int_int_serv } to $int_if:network:0 keep state queue iif_http #Разрешить из локалки пакеты на внутренний интерфейс, в локальные сети # туннелей pass in on $int_if inet from $int_if:network:0 to { 192.168.3.0/24, 192.168.4.0/24 } keep state pass in on $int_if inet proto udp from $int_if:network:0 to self port { $1int_int_serv_udp } keep state queue iif_sound pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $1int_int_serv } keep state queue iif_sound pass in on $int_if inet proto tcp from !<block-list-in> to self port { $2int_int_serv } keep state queue iif_ftp pass in on $int_if inet proto tcp from !<block-list-in> to self port { $3int_int_serv } keep state queue iif_http #Разрешить из локалки пинг pass in on $int_if inet proto icmp from $int_if:network:0 to any icmp-type echoreq code 0 keep state #Разрешить из локалки ext_ext_serv pass in on $int_if inet from !<block-list-in> to !(self) keep state pass in on $int_if inet proto udp from !<block-list-in> to !(self) port { $1ext_ext_serv_udp } keep state queue iif_sound pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $1ext_ext_serv } flags S/SA keep state queue iif_sound pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $2ext_ext_serv } flags S/SA keep state queue iif_ftp pass in on $int_if inet proto tcp from !<block-list-in> to !(self) port { $3ext_ext_serv } flags S/SA keep state queue iif_http #Разрешить из локалки int_int_serv pass in on $int_if inet from any to $int_if keep state pass in on $int_if inet proto udp from $int_if:network:0 to self port { $1int_int_serv_udp } keep state pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $1int_int_serv } flags S/SA keep state pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $2int_int_serv } flags S/SA keep state pass in on $int_if inet proto tcp from $int_if:network:0 to self port { $3int_int_serv } flags S/SA keep state
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	14. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 14-Июн-12, 12:50
	В Вашем примере нарезка исходящего трафика по портам, а мне нужно по ай-пи адресам локальной сети. Однако крайне заинтересовали строки: nat on $ext_if_a inet from !(self) tag TR !tagged TR -> $ext_if_a nat on $ext_if_b inet from !(self) tag TR !tagged TR -> $ext_if_b Возникла мысль назначать тег в правилах трансляции, и потом работать с ним в правилах pass out on ext_if. Например, так: nat on $ext_if from $lan1 to any -> ($ext_if) nat on $ext3_if from $lan1 to any -> $ext3_if nat on $ext_if from $lan2 to any tag Limited -> ($ext_if) nat on $ext3_if from $lan2 to any tag Limited -> $ext3_if pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if pass out inet from { ($ext_if) $ext3_if } to (self:network) pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) tagged Limited queue q_out pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if tagged Limited queue q3_out По-идее должно работать. Или нет?
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	17. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от rush_alex (??) on 15-Июн-12, 10:48
	>[оверквотинг удален] > nat on $ext_if from $lan1 to any -> ($ext_if) > nat on $ext3_if from $lan1 to any -> $ext3_if > nat on $ext_if from $lan2 to any tag Limited -> ($ext_if) > nat on $ext3_if from $lan2 to any tag Limited -> $ext3_if > pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) > pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if > pass out inet from { ($ext_if) $ext3_if } to (self:network) > pass out route-to ($ext_if <ext_gw>) inet from ($ext_if) tagged Limited queue q_out > pass out route-to ($ext3_if $ext3_gw) inet from $ext3_if tagged Limited queue q3_out > По-идее должно работать. Или нет? По внешнему виду должно...
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	18. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от LSTemp (ok) on 15-Июн-12, 14:05
	>>[оверквотинг удален] > А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю > схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем > виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из > реального внешнего интерфейса. Или я чего-то не понимаю? IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс. там трафик режется тем же tc например и после обработки опять попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил. наверняка подобные механизмы и во Free есть.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	19. "PF: Два канала и ограничение трафика"	+/–
	Сообщение от yurybx (ok) on 15-Июн-12, 14:20
	>>>[оверквотинг удален] >> А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю >> схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем >> виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из >> реального внешнего интерфейса. Или я чего-то не понимаю? > IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются > на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс. > там трафик режется тем же tc например и после обработки опять > попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил. > наверняка подобные механизмы и во Free есть. Интересно. Да, я уже нарисовал схему, действительно интересный способ. Спасибо за информацию к размышлению!
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору