Настройка правил firewall на резервном канале
-
Доброе утро,господа.
Ситуация : есть физический хост с pfsense 2.2.2 , установлены 3 сетевых адаптера -WAN , LAN , OPT1.Есть два канала от провайдеров - на WAN - основной,на OPT - резервный.Пока WAN работает-OPT1 не используется. LAN смотрит в локальную сеть.Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.
Проблема вот в чём: необходимо,чтобы через резервный канал OPT1 из локальной сети был разрешён только VOIP трафик (порты 5060 и т.п.),а весь остальной трафик был запрещён-ума не приложу,как это сделать. Ситуация наверняка не уни кальная,возможно кто-то решал подобные задачи с помощью pfsens'a.Прошу поделиться мыслями по этому поводу.
-
Это нужно только при падении WAN или всегда?
Если навсегда - создать на LAN 2 правила - одно запрещающее VOIP с явным указанием шлюза WAN, 2-е разрешающее, с явным указанием шлюза OPT.
Нужные порты можно завести как алиас, этот алиас затем задействовать в правиле(ах).Шлюз указывается Advanced features-Gateway.
В принципе любые правила можно задавать, указывая вместо default конкретный gateway.
-
Это нужно только при падении WAN или всегда?
Если навсегда - создать на LAN 2 правила - одно запрещающее VOIP с явным указанием шлюза WAN, 2-е разрешающее, с явным указанием шлюза OPT.Шлюз указывается Advanced features-Gateway
Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль
-
Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль
Так если WAN падает, VOIP и так пойдет через OPT.
-
Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль
Так если WAN падает, VOIP и так пойдет через OPT.
И всё остальное тоже,а этого нужно избежать.По резервному каналу должен идти только VOIP ,и ничего больше.Как бы разрулить это правилами?
-
В принципе любые правила можно задавать, указывая вместо default конкретный gateway.
Примерно так:
1.Разрешение всего трафика через WAN 1
2.Разрешение VOIP через OPT1
3.Запрет всего через OPT1?
-
И всё остальное тоже,а этого нужно избежать.По резервному каналу должен идти только VOIP ,и ничего больше.Как бы разрулить это правилами?
Еще раз. Создать создать на LAN 1-е правило, запрещающее VOIP с явным указанием шлюза WAN.
Создать на LAN 2-е правило, запрещающее все, кроме DNS и VOIP с явным указанием шлюза OPT.
-
И всё остальное тоже,а этого нужно избежать.По резервному каналу должен идти только VOIP ,и ничего больше.Как бы разрулить это правилами?
Еще раз. Создать создать на LAN 1-е правило, запрещающее VOIP с явным указанием шлюза WAN.
Создать на LAN 2-е правило, запрещающее все, кроме DNS и VOIP с явным указанием шлюза OPT.Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)
-
Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)
Так на то и правильные указания tier в failover.
Для гарантии дайте WAN максимальный Weight в System: Gateways: Edit gateway->adwanced, а OPT - минимальный.
Но незначительный служебный трафик по OPT все равно будет идти, будет ли его считать провайдер - не знаю.
Если OPT - PPPOE, например, и задержка на поднятие интерфейса не критична, можно включить Dial on demand в настройках OPT.
-
Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)
Так на то и правильные указания tier в failover.
Для гарантии дайте WAN максимальный Weight в System: Gateways: Edit gateway->adwanced, а OPT - минимальный.
Но незначительный служебный трафик по OPT все равно будет идти, будет ли его считать провайдер - не знаю.
Если OPT - PPPOE, например, и задержка на поднятие интерфейса не критична, можно включить Dial on demand в настройках OPT.Большое спасибо за подробные рекомендации ) OPT как раз PPPOE .
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
-
У Вас сейчас весь трафик идет через WAN_DHCP6. Далее, sip чаще всего исп. UDP - у Вас же стоит TCP во 2-м правиле сверху.
-
-
У Вас сейчас весь трафик идет через WAN_DHCP6.
Но физически WAN_DHCP6 выключен,и весь трафик идёт через OPT1.
Поле Gateway вообще за что отвечает и на что влияет?
-
sip чаще всего исп. UDP - у Вас же стоит TCP во 2-м правиле сверху.
-
Но физически WAN_DHCP6 выключен,и весь трафик идёт через OPT1.
Reset states сделайте.
Поле Gateway вообще за что отвечает и на что влияет?
Еще и как. Если только правильно настроено.
-
У Вас сейчас весь трафик идет через WAN_DHCP6.
Т.е. порядок правил не корректен.
А если поменять порядок правил,и поставить allow VOIP для OPT1 то весь трафик будет идти через OPT1(резервный канал) всегда независимо от того,работает ли WAN..
Задача в том,чтобы тем или иным образом
а) Заставить ВЕСЬ трафик в штатном режиме(это когда WAN работает) ходить через WAN -и VOIP в том числе.OPT при этом поднят,но трафик через него должен быть запрещён-даже VOIP (канал этот резервный,трафик на нём тарифицируется довольно дорого)
б)При переключении на резервный канал OPT через него разрешается только хождение VOIP (SIP ,RTP ну и DNS).
Возможно ли такое сотворить с помощью Pfsense? Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.
-
Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
Поставьте Default allow LAN to any rule последним, а свои правила - выше него.WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.
Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.
Указание поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.
-
Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
Поставьте Default allow LAN to any rule последним, а свои правила - выше него.WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.
В реальности 4 версия IP,название просто осталось.Спасибо,сейчас попробую поменять правила местами.
-
Спасибо,сейчас попробую поменять правила местами.
В принципе правильно расположенное разрешающее правило с dst-портом 5060 с указанием шлюза OPT одновременно запретит такому трафику ходить через шлюз WAN
Не забывать reset states или reboot.
-
Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.
Указание поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.
Увы,это иллюзия и нативными средствами pfsense 2.2.2 эту задачу решить не получится.Загвоздка в том,что правило разрешающее только VOIP через определённый интерфейс должно работать только при условии , что другой интерфейс лежит . Остаётся только организовать кластер pfsens'ов,или писать скрипты.
-
Не знаю что вы там городите, лично у меня последовательность
allow IPv4 TCP 192.168.1.244 * * Ports80443 GW_MARK none (Vahta) allow IPv4 TCP LocalNet * * Ports80443 prio_mark none (MAIN ALLOW)запрещает компьютеру 192.168.1.244 переходить на резервный канал. Где GW_MARK основной шлюз, prio_mark - фаловер.
С VoIP, конечно немного сложнее…
-
только при условии , что другой интерфейс лежит.
Да, в правилах нет возможности привязки к состоянию шлюза\интерфейса.
А не поможет ли Allow default gateway switching?
-
1. allow IPv4 UDP LAN subnet * 5060 (SIP) OPT1 none
2. block IPv4 UDP LAN subnet * **!**5060 (SIP) OPT1 none
3. allow IPv4 * LAN subnet * * * WAN_GW none
А не поможет ли Allow default gateway switching?
Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.
-
Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен\может блокировать.
_1. allow IPv4 UDP LAN subnet * 5060 (SIP) OPT1 none
2. block IPv4 UDP LAN subnet * !5060 (SIP) OPT1 none_
А эти правила не дублируют друг друга?
-
Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен блокировать.
Верно. Пускай ТС пробует.
-
1. allow IPv4 UDP LAN subnet * 5060 (SIP) OPT1 none
2. block IPv4 UDP LAN subnet * **!**5060 (SIP) OPT1 none
3. allow IPv4 * LAN subnet * * * WAN_GW none
А не поможет ли Allow default gateway switching?
Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.Если я верно понимаю,то первая строчка этого правила направит весь трафик SIP на OPT1 .Даже когда будет работать основной интерфейс. Это не совсем то,что нужно.
-
В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.Тему можно закрывать.
-
В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.
Так чтоб по типу надо смотреть в сторону L7, что кстати в 2.2.2 недоступно.
Доступно по номеру+типу порта, адресу источника запроса и адресу назначения.Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.
Верно, поэтому есть резервирование.
Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.
В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.
Тему можно закрывать.
DO IT)))
-
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :
Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
так пробовали?
-
В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.
Дело в том,что вкупе с SIP трафиком телефония использует непосредственно для передачи голоса rtp трафик.
-
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :
Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
так пробовали?
По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.
-
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :
Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
так пробовали?
Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.
-
По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что
интерфейсшлюз будет другой. Всё зависит только от Вас.А первые два правила защищают от ошибок конфигурирования fw
Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.
ааа??? Ну что ж. Найдёте лучшее решение, добро пожаловать.
-
По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что
интерфейсшлюз будет другой. Всё зависит только от Вас.Я интерпретировал Ваш пример применительно к своим условиям.В целом Ваш посыл понятен.
Вы ведь не упускаете из виду,что моя задача состоит в том,чтобы через резервный OPT1 шёл только трафик voip и только когда лежит основной интерфейс?Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
Если у Вас есть решение как сделать это pfsens'ом , сделайте милость,избавьте от необходимости искать лучшее решение. :)
-
Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.
Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.
Кстати, на каких кодеках работаете?
-
Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.
Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.
Кстати, на каких кодеках работаете?
Телефонией занимаются другие,поэтому не знаю :)
Проглядел возможность указания в правилах фаервола группы шлюзов. Это выглядит как возможное решение.Буду пробовать.
-
Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.
Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.
Кстати, на каких кодеках работаете?
Телефонией занимаются другие,поэтому не знаю :)
Проглядел возможность указания в правилах фаервола группы шлюзов. Это выглядит как возможное решение.Буду пробовать.Если есть возможность, то настоятельно рекомендую перейти на IAX2. Намного упрощает жизнь. Хотя бы тем , что открывать прийдется всего лишь один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).
-
один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).
Отличная рекомендация,спасибо!
-
Присоединяюсь к благодарности за рекомендацию. Вот только полно железа, которое про IAX2 не слышало и не услышит.
Как решение представляется некий прокси IAX2->SIP
https://groups.google.com/forum/#!topic/taug-archive/SR_VJK9tRko
-
2 pigbrother
https://github.com/primuslabs/iaxproxy
When an IAX2 end point connects to IAXProxy the endpoint information is looked up in Redis and assuming the IAX2 device passes authentication then a SIP Peer and SIP Registrar are created on the users behalf
Мне кажется или оно для другого предназначено ? Т.е. у меня изначально есть iax2-уст-во и мне его надо подключить к только-sip-АТС ? Так asterisk и так iax2 прекрасно поддерживает.
P.s. Сейчас даже недорогое железо поддерживает IAX2. Из ip-phone посмотрите в сторону ATCOM 610\620.