PFsense 2.4.4 не работает DNS в MultiWan

[vladimirlind]

Значит полиси-рутинг правило не матчится по какой-то причине. Но какое-то правило на ЛАНе все же должно выпускать трафик наружу. На ЛАНе дальше после полиси-рутинга правила какие? Трафик точно из LAN сети идет?

Что интересно вот тут:

cat /tmp/rules.debug | grep MultiWan

[wezen]

@vladimirlind said in PFsense 2.4.4 не работает DNS в MultiWan:

Значит полиси-рутинг правило не матчится по какой-то причине. Но какое-то правило на ЛАНе все же должно выпускать трафик наружу. На ЛАНе дальше после полиси-рутинга правила какие? Трафик точно из LAN сети идет?

Что интересно вот тут:

cat /tmp/rules.debug | grep MultiWan
вот что пишет
GWMultiWan = " route-to { ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re0 10y.y.y.y ) ( re0 10y.y.y.y ) } round-robin "
основной трафик с lan идет еще с wi-fi идет трафик

[vladimirlind]

@wezen said in PFsense 2.4.4 не работает DNS в MultiWan:

GWMultiWan = " route-to { ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re0 10y.y.y.y ) ( re0 10y.y.y.y ) } round-robin "

хм, группа из пяти шлюзов? А само правило с GWMultiWan не вывелось в команде? Получается, правила нет...

Надо бы удалить полиси-рутинг правило и группу шлюзов MultiWan и создать все заново. Посмотреть в сислоге, нет ли ошибок pf при создании правила, колокольчик не брякает ли в правом верхнем углу.

[Konstanti]

@wezen Должно быть как минимум 2 строчки
1 строка - алиас
2 правило
алиас есть , правила нет
например , вот так

GWTUN200_TUNNELV4 = " route-to ( gre1 10.10.200.2 ) "
pass  in  quick  on $LAN  $GWTUN200_TUNNELV4 inet from 192.168.1.96 to any tracker 1530287339 keep state  label "USER_RULE"

Попробуйте сделать так , как Вам написали выше

[wezen]

GWMultiWan = " route-to { ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re1 9x.x.x.x ) ( re0 10y.y.y.y ) ( re0 10y.y.y.y ) } round-robin " по ходу нормально, установилна каждом Gateway Weight на сотком 3 и на мтс 2 видимо он так прописывает. пересоздал мульти группу. Пошел трафик.

[wezen]

Поставил 7-5 в весе шлюзов вот такую красоту отображает)))
GWMultiWans = " route-to { ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re1 x.x.x.x ) ( re0 y.y.y.y ) ( re0 y.y.y.y ) ( re0 y.y.y.y ) ( re0 y.y.y.y ) ( re0 y.y.y.y ) } round-robin "
pass in quick on $LAN $GWMultiWans inet from 10.10.10.0/24 to any tracker 1423503327 keep state label "USER_RULE: Default allow LAN to any rule"
pass in quick on $WIFI $GWMultiWans inet proto { tcp udp } from 192.168.2.0/24 to any tracker 1551818363 keep state dnpipe ( 1,2) label "USER_RULE"

[vladimirlind]

Ага, похоже weight просто увеличивает частоту выбора шлюза в round-robin механизме. Если оставить weight 1 , то шлюзы дублироваться не будут в группе. То есть соотношение балансировки WAN1 к WAN2 будет 7 к 5.

Ну, по крайней мере, сейчас правило есть.

[wezen]

да сейчас раскидывает на два провайдера, спасибо за подсказки.

[dvv06]

@wezen, @vladimirlind, @Konstanti Добрый день ребята. Ваша тема с весами на внешних интерфейсах и консольные команды позволяющие это проверить меня натолкнуло проверить тоже самое у меня. И кое-что частично заработало (по крайней мере маршрут по умолчанию в States начал переключаться и по traceroute начало направляться при переключении провайдеров куда нужно), но при попытке разрешить имя (nslookup через консоль на шлюзе или через интерфейс Diagnostics-DNS Lookup) имя не может быть разрешено
У вас в теме шло придметное обсуждение и оно мне частично помогло, может быть что-то в моем случае посоветуете (вот моя бесперспективная тема https://forum.netgate.com/topic/142687/multiwan-usb3g-adsl-optic_fiber-%D0%BF%D0%B5%D1%80%D0%B5%D1%81%D1%82%D0%B0%D0%BB%D0%BE-%D1%81%D1%80%D0%B0%D0%B1%D0%B0%D1%82%D1%8B%D0%B2%D0%B0%D1%82%D1%8C-%D0%BF%D0%B5%D1%80%D0%B5%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D0%BE%D0%B2/9)
помогло изменение весов в "1" на всех WANs, когда-то читал описание этого параметра и сделал сосотношение wan2=30 на основном интерфейсе, а остальные wan1="2" и wan3="1" и получилась ситуация как в моей теме.

[vladimirlind]

@dvv06 said in PFsense 2.4.4 не работает DNS в MultiWan:

при попытке разрешить имя (nslookup через консоль на шлюзе или через интерфейс Diagnostics-DNS Lookup) имя не может быть разрешено

Добрый день. Policy-routing правило работает для трафика, входящего на интерфейс, на котором это правило настроено. Nslookup запросы в консоли фаервола будут маршрутизироваться согласно таблице маршрутов, полиси-рутинг тут уже никаким боком не задействован - так как это трафик, исходящий от самого фаервола. Если у вас Nslookup запросы к каким-то апстрим днм серверам остаются без ответов - смотрите, есть ли дефолтный маршрут, пингуется ли днс сервер.

[dvv06]

@vladimirlind У меня в System- General Setup 4 публичных рабочих днс (на wan2 (основной канал) они пингаются и все успешно разрешают имена как через консоль фаервола, так и через Diagnostics - DNS Lookup), я в консоли делаю ifconfig em1 down (WAN2) и в происходит переключение на opt4 (WAN3 3G Modem) и в мониторе показано что он Online (пингуя внешний ip) в routes показано что шлюзом по умолчанию является шлюз этого интерфейса а не предыдущий (до прочтения вашей ветки по весам этого не было), но этиже днс уже не пингуются и не разрешают имена никак

[2.3-RELEASE][admin@nacyalnika.local]/root: cat /tmp/rules.debug | grep MyMultiWAN
GWMyMultiWAN = "  route-to { ( ue0 192.168.8.1 )  }  "
.........

[werter]

@dvv06

Weight в настройках интерфейсов я бы вообще без особой надобности не трогал. Достаточно корректных Tier в настройках групп интерфейсов.

но этиже днс уже не пингуются

Пинг появляется не сразу при переключении на др. интерфейс.

и не разрешают имена никак

Разрешать имена будет тот ДНС, к-ый указан в настройках конкретного интерфейса.

Для решения проблемы попробовать завернуть ВСЕ днс-запросы клиентов на адрес пф. Затем в настройках DNS Resolver-а (DNS Forwarder на пф НЕ ПОЛЬЗОВАТЬ!) вкл. Форвардинг.

[dvv06]

@werter вроде бы у меня так как вы и говорите было, дополнительно (чтоб наверняка и не возникало путаницы поставил всем интерфейсам Tier1, Tier2, Tier3 )

В поле "Interface" там невидно, но LAN, LAN2, localhist выбрано


заметил, что после переключения на резервный WAN секунд 10 имена разрешаются, а потом ни по имени, ни по ip уже не пингаются (ждал минут 5), но traceroute yahoo.com (например) идет по нужному wan'у.

"Для решения проблемы попробовать завернуть ВСЕ днс-запросы клиентов на адрес пф." - так и есть прописал в настройках сетевой карты на клиенте именно DNS = ip_pfSense

[werter]

@dvv06
Мил человек.

Для решения проблемы попробовать завернуть ВСЕ днс-запросы клиентов на адрес пф. Затем в настройках DNS Resolver-а (DNS Forwarder на пф НЕ ПОЛЬЗОВАТЬ!)

Это для кого написано? Вы между строк читаете?

Честно? Такая откровенная лень и глупость достойны увольнения. Будь я Вашим начальником.

Не еб... себе и др. моСк.
Откл. Форвардер, настраивайте Резольвер, заворачивайте ВСЕ днс-запросы на пф Порт Форвардингом на ЛАН.
Как ЕЩЕ надо объяснять?

Зы. След. совет Вам будет только за $$$.

[dvv06]

@werter
да видомо я спутал resolver s forwarder в pfSense, поэтому решил что у меня так как вы говорите (опустим мою невнимательность и проф.навыки. Если я в поисках ответов еб* вам лично мозг и вы ничем помочь не можете , то просто не отвечайте, может найдется более осведомленный человек я же не к вам лично создавал свою тему). У меня в сети eсть DNS в AD я на него все запросы заворачивал, а уже с него перенаправляют на pfSense. Все так работало до какого-то момента.
Что даст resolver ? Я когда только ставил pfSense resolver шел включенным из коробки, но многие рекомендовали его выключать а использовать forwarder, что я и сделал. Как он будет себя вести совместно с DNS AD на 53 порту...

Причем тут $$$, это же форум где люди обращаются с их ошибками по pfSense расчитывая на помощь сообщества, мы же по сути бэта-тестерами выступаем

[werter]

@dvv06 said in PFsense 2.4.4 не работает DNS в MultiWan:

Я когда только ставил pfSense resolver шел включенным из коробки, но многие рекомендовали его выключать а использовать forwarder, что я и сделал.

Ссылки на то КТО и ГДЕ рекомендовал такое.
Или вы думаете ,что разрабы пф идиоты, если они из коробки Резолвер включают?

Как он будет себя вести совместно с DNS AD на 53 порту...

Замечательно он будет себя вести. Особенно если прислушиваться к советам тех же разработчиков и не создавать себе проблем на пустом месте. У меня самого AD имеется.

Причем тут $$$, это же форум где люди обращаются с их ошибками по pfSense расчитывая на помощь сообщества

Это вы опоздали. Лет на 30. Капитализм на улице.
Никто не прочь здесь подсказать и НАТОЛКНУТЬ на решение, если это отнимет немного времени. Однако в случае, если такая "помощь" требует много времени - я говорю прямо СКОЛЬКО это будет стоить для вопрошающего.
Вы попробуйте попросить НЕЗНАКОМОГО сантехника\электрика\частного (?) врача оказать вам помощь ДАРОМ. И запишите , что он вам ответит.
Отличия в работе IT-ка и электрика НЕ ВИЖУ.

мы же по сути бэта-тестерами выступаем

Ставьте бэту и тестите. Ссылку на redmine, куда писАть про ошибки могу дать. Вот ТОГДА вы будете тестером.

Зы. ЧТО и ГДЕ вам поправить подсказано было. Дерзайте.

[dvv06]

@werter ну ок создам resolver на pfSense, так а почему forwarder перестал работать?
про капитализм все верно, но не стоит к нему стремится и принимать как должное. я считаю что админское сообщество построено на взаимопомощи иначе хана

[dvv06]

В общем тем, кто будет в такойже ситуации как и я с такимим же нежеланием переключаться маршруту по-умолчанию на multiWAN (netstat -r) из группы шлюзов разных провайдеров (проверять по cat /tmp/rules.debug | grep MyMultiWAN) то имейте ввиду, что если у вас в сетевуху не вставлен провод и на этой сетевухе назначен шлюз провайдера по умолчанию (галка в настройках интерфейса), а резервные каналы интернета по другим шлюзам будут "Online" и на них будет инет, то переключение не произойдет, пока вы какой-нибудь провод не воткнете в линк от провайдера по умолчанию (главное чтобы статус линка интерфейса был "Up"). Вот такие косячки у pfSense. На сим откланиваюсь...

[werter]

@dvv06 said in PFsense 2.4.4 не работает DNS в MultiWan:

@werter ну ок создам resolver на pfSense, так а почему forwarder перестал работать?

Потому что ИЛИ Форвдер ИЛИ Резольвер.

@dvv06 said in PFsense 2.4.4 не работает DNS в MultiWan:

В общем тем, кто будет в такойже ситуации как и я с такимим же нежеланием переключаться маршруту по-умолчанию на multiWAN (netstat -r) из группы шлюзов разных провайдеров (проверять по cat /tmp/rules.debug | grep MyMultiWAN) то имейте ввиду, что если у вас в сетевуху не вставлен провод и на этой сетевухе назначен шлюз провайдера по умолчанию (галка в настройках интерфейса), а резервные каналы интернета по другим шлюзам будут "Online" и на них будет инет, то переключение не произойдет, пока вы какой-нибудь провод не воткнете в линк от провайдера по умолчанию (главное чтобы статус линка интерфейса был "Up"). Вот такие косячки у pfSense. На сим откланиваюсь...

1. Для Failover-схемы у вас МИНИМУМ один из шлюзов в Группе должен иметь Tier-приоритет выше (т.е. ЕДИНИЦУ), чем остальные.
2. В ОБЩИХ настройках пф должны быть указаны РАЗНЫЕ DNS для разных WAN-ов.
3. В настройках мониторинга ИСПОЛЬЗОВАТЬ ТОЛЬКО что-то стороннее (8.8.8.8, 1.1.1.1 etc)
4. Использовать РЕЗОЛВЕР, бл.. Форвардер НЕ ВКЛ.

Проверено. Работает. И "косячки" тут у того, кто настраивает. Причем по своей глупости и лени.

[dvv06]

@werter
не хотел отвечать, но вынудили

1. все таки есть, все ваны с разными Tier-Приоритетами по схеме срабатывания member down
2. в общих настройках пф стоят все общие причем не привязанніе ни к одному интерфейсу (года 2 назад ві мне сами так рекомендовали, хотя у меня была привязка), все работает по схеме форвардера - кто первый ответит (но для экперимента пробовал как вы говорите ранее)
3. в мониторинге днс но другие, т.к знаю что маршруты к ним жестко привязываются
4. резолвер, форвардер, обновления пф - это фигня для ленивых, кто не хочет разбираться в сути проблемы

и подобную проблему я читал с ошибках пф (уже непомню решенная или нет, гуглить повторно не буду)
то, что происходит именно так - это факт, ну а остальное ввод в заблуждение и увод от темы