Имеется два интернет-канала: основной и резервный. На 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Прошу помощи в поиске нужного синтаксиса.
>[оверквотинг удален]
> 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 # тоже
а потом уже теже правила, но без тега.
И да. Рутовую очередь нужно настроить на обеих внешних.
Вроде все.
>[оверквотинг удален]
> Если у вас НАТ, то приведенные правила не будут работать.
> 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?
> Имеется два интернет-канала: основной и резервный....
> определяют дохлый канал и в случает такового переключают основной маршрут на
> другой канал....
> Если бы был один активный канал, то проблем нету:
Исходя из вашего описания, в один момент времени у вас один активный канал.
У меня именно NAT.
В один момент времени один канал используется для раздачи интернета. НО! Сервер с помощью скрипта делает пинги по корневым DNS через ОБА канала, чтобы определять, какой из них живой, а какой - мёртвый.
> У меня именно NAT.
> В один момент времени один канал используется для раздачи интернета. НО! Сервер
> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
> чтобы определять, какой из них живой, а какой - мёртвый.Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на сайте PF User's guide.
>> У меня именно NAT.
>> В один момент времени один канал используется для раздачи интернета. НО! Сервер
>> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
>> чтобы определять, какой из них живой, а какой - мёртвый.
> Зачем скрипты. Вы можете делать балансировку самим PF. Почитайте у них на
> сайте PF User's guide.Это плохо для меня: стабильность интеренета в том офисе - больная тема, а скрипты отлажены и долгое время исправно работают. Они выполняют следующие функции:
1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и переключают на другой канал
2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала и в таком случае переключают маршрутизацию обратно на него (перед этим делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
3) При переключении маршрутизации переключается также relay-host в postfix
4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.
Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и ограничение исходящего трафика?
> Интересно, выходит, в PF несовместимы такие вещи, как два работающих канала и
> ограничение исходящего трафика?Почему не выходит. Боюсь вам нужно ставть виртуалбокс, имитировать вашу реальную ситуацию и пробовать, пробовать и еще раз пробовать выполнить поставленную задачу. А потом в продакшен. Ничего особенного, все как обычно :-)
>[оверквотинг удален]
> Это плохо для меня: стабильность интеренета в том офисе - больная тема,
> а скрипты отлажены и долгое время исправно работают. Они выполняют следующие
> функции:
> 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и
> переключают на другой канал
> 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала
> и в таком случае переключают маршрутизацию обратно на него (перед этим
> делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
> 3) При переключении маршрутизации переключается также relay-host в postfix
> 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.Кто мешает иметь два конфига pf и переключать их тем же скриптом?
>[оверквотинг удален]
>> а скрипты отлажены и долгое время исправно работают. Они выполняют следующие
>> функции:
>> 1) Быстро (в течении 15-30 секунд) реагируют на падение активного канала и
>> переключают на другой канал
>> 2) Резервный канал - платный, по-этому скрипты отслеживают восстановление основного канала
>> и в таком случае переключают маршрутизацию обратно на него (перед этим
>> делая выдержку 15 минут, чтобы маршрутизация не прыгала туда-сюда)
>> 3) При переключении маршрутизации переключается также relay-host в postfix
>> 4) Пишут логи о недоступности каждого из каналов, переключениях и т.д.
> Кто мешает иметь два конфига pf и переключать их тем же скриптом?Проблема не с переключением, а с тем, чтобы совместить две функции одновременно:
1) Возможность пинговать через оба канала одновременно
2) Нарезка исходящего трафика на активном канале
> У меня именно NAT.
> В один момент времени один канал используется для раздачи интернета. НО! Сервер
> с помощью скрипта делает пинги по корневым DNS через ОБА канала,
> чтобы определять, какой из них живой, а какой - мёртвый.не спец во Фре, но:
- если юзеры одномоментно ч/з один из двух каналов идут в инет, то почему бы просто не поставить одинаковые ограничение исходящего трафика на обоих каналах для этих юзеров? для нормальных все останется по прежнему, а "исходяки" пусть плачут при переключении - их проблема
- давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но не думаю, что будут проблемы в реализации для данной ОС.
Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко):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?
> Кстати, вроде пробовал так (перепроверить нет возможности - офис далеко):
> 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.me/tips/2680_freebsd_router_pf_altq_traff...
>[оверквотинг удален]
>> чтобы определять, какой из них живой, а какой - мёртвый.
> не спец во Фре, но:
> - если юзеры одномоментно ч/з один из двух каналов идут в инет,
> то почему бы просто не поставить одинаковые ограничение исходящего трафика на
> обоих каналах для этих юзеров? для нормальных все останется по прежнему,
> а "исходяки" пусть плачут при переключении - их проблема
> - давно отработанный подход: фигачить весь нужный трафик на виртуальный интерфейс (для
> централизованной обработки), рулить там им по своему усмотрению (урезать, оттегировать
> для дальнейшей обработки, итд) и выплевывать дальше. механизмы OS depended, но
> не думаю, что будут проблемы в реализации для данной ОС.А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из реального внешнего интерфейса. Или я чего-то не понимаю?
У меня в архиве валялось# Включить трансляцию адресов на внешних интерфейсах.#
#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_server2rdr 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_serverrdr 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_serverrdr 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_server2rdr 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_servernat 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_soundpass 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_httppass 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_apass 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
В Вашем примере нарезка исходящего трафика по портам, а мне нужно по ай-пи адресам локальной сети.
Однако крайне заинтересовали строки:
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_ifpass 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По-идее должно работать. Или нет?
>[оверквотинг удален]
> 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
> По-идее должно работать. Или нет?По внешнему виду должно...
>>[оверквотинг удален]
> А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю
> схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем
> виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из
> реального внешнего интерфейса. Или я чего-то не понимаю?IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс. там трафик режется тем же tc например и после обработки опять попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил.
наверняка подобные механизмы и во Free есть.
>>>[оверквотинг удален]
>> А можно подробней про направление трафика через виртуальный интерфейс? Не совсем понимаю
>> схему. Ведь получается, что мне нужно шейпить исходящий трафик на некоем
>> виртуальном интерфейсе, тогда эти пакеты потом должны каким-то образом выходить из
>> реального внешнего интерфейса. Или я чего-то не понимаю?
> IMQ для Linux например. пакеты прямо из сетевого фильтра специальным правилом заворачиваются
> на псевдо-девайс, который для системы выглядит, как обычный физический сетевой интерфейс.
> там трафик режется тем же tc например и после обработки опять
> попадает в сетевой фильтр и продолжает свое путешествие по цепочкам правил.
> наверняка подобные механизмы и во Free есть.Интересно. Да, я уже нарисовал схему, действительно интересный способ. Спасибо за информацию к размышлению!