Настройка правил firewall на резервном канале
-
В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.
Так чтоб по типу надо смотреть в сторону L7, что кстати в 2.2.2 недоступно.
Доступно по номеру+типу порта, адресу источника запроса и адресу назначения.Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.
Верно, поэтому есть резервирование.
Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.
В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.
Тему можно закрывать.
DO IT)))
-
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :
Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
так пробовали?
 -
В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.
Дело в том,что вкупе с SIP трафиком телефония использует непосредственно для передачи голоса rtp трафик.
-
Теперь далее- не работают почему-то вот эти правила (на скриншоте) :
Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?
так пробовали?
По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно. -
-
По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что
интерфейсшлюз будет другой. Всё зависит только от Вас.А первые два правила защищают от ошибок конфигурирования 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.
-
Софт по ссылке, как я понял, позволяет использовать IAX2-оборудование с провайдером, поддерживающим только SIP, без необходимости разворачивать для этого отдельный\промежуточный Asterisk.
Проект, похоже, заброшен:
23 Nov 2012 — Initial Public Release (version 0.2.1.3, Blue Moon release) - первый и единственный релиз.P.s. Сейчас даже недорогое железо поддерживает IAX2.
То, что у меня уже работает, о IAX2 ничего не знает. Теперь, при покупке нового, на поддержку IAX2 обращать внимание буду обязательно. Спасибо. -
Указание поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.
А это значение этого поля является условием,на соответствие которому проверяется очередной пакет трафика,или же указанием,на какой интерфейс должен идти трафик соответствующий всем остальным полям данного правила?
-
Вероятно - не является.
В самом пакете нет упоминания о том, через какой шлюз он должен уйти. -
Спасибо.
-
Был несколько невнимателен, дополню. Назначение шлюза - не условие выполнения правила, а именно его указание, если соблюдаются заданные в правиле условия.
Т.е. если пакет соответствует набору условий то ему назначается шлюз.
