Gateway Monitoring при Multi-WAN

[nockdown]

Попытка диагностики во время потери соединения с интернетом по проблемному WAN1:

Пинг шлюза провайдера:

PING 176.99.160.1 (176.99.160.1) from MYIP: 56 data bytes
64 bytes from 176.99.160.1: icmp_seq=0 ttl=255 time=0.324 ms
64 bytes from 176.99.160.1: icmp_seq=1 ttl=255 time=0.283 ms
64 bytes from 176.99.160.1: icmp_seq=2 ttl=255 time=0.283 ms
--- 176.99.160.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.283/0.296/0.324/0.019 ms

Трассировка до шлюза провайдера:

tracert 176.99.160.1
Tracing route to 176.99.160.1
over a maximum of 7 hops:
1 10.204.46.1 2.135 ms * 0.419 ms

Пинг сайта провайдера:

PING 194.187.205.230 (194.187.205.230) from MYIP: 56 data bytes
--- 194.187.205.230 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Трассировка до сайта провайдера:

tracert 194.187.205.230
Tracing route to 194.187.205.230
over a maximum of 7 hops:
1 10.204.46.1 0.302 ms 0.272 ms 0.269 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *

Пинг DNS yandex:

PING 77.88.8.7 (77.88.8.7) from MYIP: 56 data bytes
--- 77.88.8.7 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Трассировка до DNS yandex:

tracert 77.88.8.7
Tracing route to 77.88.8.7
over a maximum of 7 hops:
1 10.204.46.1 0.303 ms 0.264 ms 0.249 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *

Диагностика извне с IP 5.61.X.X:
Пинг своего IP из глобальной сети:

ping MYIP
Pinging MYIP with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for MYIP:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Трассировка своего IP из глобальной сети:

tracert MYIP
Tracing route to MYIP.inetcom.ru [MYIP]
over a maximum of 20 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms 5.61.8.113
3 <1 ms 8 ms 7 ms 172.30.1.17
4 1 ms 1 ms 1 ms 172.30.1.13
5 35 ms 3 ms 1 ms 198.18.9.94
6 1 ms 1 ms 1 ms 10.0.92.41
7 1 ms 6 ms 1 ms 10.0.91.9
8 1 ms <1 ms 1 ms 169.254.0.25
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.

[werter]

@nockdown
Покажите General с вашего пф.

[nockdown]

@werter , пожалуйста:

Jun 4 04:26:30	rc.gateway_alarm	16939	>>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:1 RTT:7.033ms RTTsd:.041ms Loss:22%)
Jun 4 04:26:30	check_reload_status	524	updating dyndns WAN1INETCOM_DHCP
Jun 4 04:26:30	check_reload_status	524	Restarting ipsec tunnels
Jun 4 04:26:30	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 04:26:30	check_reload_status	524	Reloading filter
Jun 4 04:26:31	php-fpm	13563	/rc.openvpn: MONITOR: WAN1INETCOM_DHCP has packet loss, omitting from routing group WANLoadBalancing
Jun 4 04:26:31	php-fpm	13563	77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.032ms|0.111ms|23%|down|highloss
Jun 4 04:26:31	php-fpm	91403	/rc.filter_configure_sync: Gateway, switch to: WAN0WIFIRE_DHCP
Jun 4 04:26:31	php-fpm	91403	/rc.filter_configure_sync: Default gateway setting Interface WAN0WIFIRE_DHCP Gateway as default.
Jun 4 04:26:33	php	39413	notify_monitor.php: Message sent to X@X.X(myEmail) OK
Jun 4 04:28:03	rc.gateway_alarm	11997	>>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:0 RTT:5.355ms RTTsd:1.678ms Loss:5%)
Jun 4 04:28:03	check_reload_status	524	updating dyndns WAN1INETCOM_DHCP
Jun 4 04:28:03	check_reload_status	524	Restarting ipsec tunnels
Jun 4 04:28:03	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 04:28:03	check_reload_status	524	Reloading filter
Jun 4 04:28:04	php-fpm	13563	/rc.openvpn: MONITOR: WAN1INETCOM_DHCP is available now, adding to routing group WANLoadBalancing
Jun 4 04:28:04	php-fpm	13563	77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|5.385ms|1.676ms|3%|online|none
Jun 4 04:28:05	php	37030	notify_monitor.php: Message sent to X@X.X(myEmail) OK
Jun 4 05:47:05	rc.gateway_alarm	90656	>>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:1 RTT:7.039ms RTTsd:.059ms Loss:22%)
Jun 4 05:47:05	check_reload_status	524	updating dyndns WAN1INETCOM_DHCP
Jun 4 05:47:05	check_reload_status	524	Restarting ipsec tunnels
Jun 4 05:47:05	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 05:47:05	check_reload_status	524	Reloading filter
Jun 4 05:47:06	php-fpm	686	/rc.openvpn: MONITOR: WAN1INETCOM_DHCP has packet loss, omitting from routing group WANLoadBalancing
Jun 4 05:47:06	php-fpm	686	77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.039ms|0.08ms|24%|down|highloss
Jun 4 05:47:07	php	14060	notify_monitor.php: Message sent to X@X.X(myEmail) OK
Jun 4 07:06:42	php-fpm	18070	/index.php: Successful login for user 'XXX(myLogin)' from: 192.168.100.5 (Local Database)
Jun 4 10:15:36	rc.gateway_alarm	98839	>>> Gateway alarm: WAN0WIFIRE_DHCP (Addr:77.88.8.3 Alarm:1 RTT:8.637ms RTTsd:.370ms Loss:21%)
Jun 4 10:15:36	check_reload_status	524	updating dyndns WAN0WIFIRE_DHCP
Jun 4 10:15:36	check_reload_status	524	Restarting ipsec tunnels
Jun 4 10:15:36	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 10:15:36	check_reload_status	524	Reloading filter
Jun 4 10:15:37	php-fpm	91403	/rc.openvpn: MONITOR: WAN0WIFIRE_DHCP has packet loss, omitting from routing group WANLoadBalancing
Jun 4 10:15:37	php-fpm	91403	77.88.8.3|X.X.X.X(myIP0)|WAN0WIFIRE_DHCP|8.639ms|0.379ms|23%|down|highloss
Jun 4 10:15:37	php-fpm	32823	/rc.filter_configure_sync: An error occurred while trying to find the interface got 95.220.0.1 . The rule has not been added.
Jun 4 10:15:37	php-fpm	32823	/rc.filter_configure_sync: An error occurred while trying to find the interface got 176.99.160.1 . The rule has not been added.
Jun 4 10:16:01	php	21320	notify_monitor.php: Could not send the message to X@X.X(myEmail) -- Error: Failed to connect to ssl://smtp.gmail.com:465 [SMTP: Failed to connect socket: No route to host (code: -1, response: )]
Jun 4 10:16:07	php-fpm	91403	/rc.openvpn: API to Telegram did not return data in expected format!
Jun 4 10:17:00	rc.gateway_alarm	66265	>>> Gateway alarm: WAN0WIFIRE_DHCP (Addr:77.88.8.3 Alarm:0 RTT:8.720ms RTTsd:.875ms Loss:5%)
Jun 4 10:17:00	check_reload_status	524	updating dyndns WAN0WIFIRE_DHCP
Jun 4 10:17:00	check_reload_status	524	Restarting ipsec tunnels
Jun 4 10:17:00	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 10:17:00	check_reload_status	524	Reloading filter
Jun 4 10:17:01	php-fpm	91403	/rc.openvpn: MONITOR: WAN0WIFIRE_DHCP is available now, adding to routing group WANLoadBalancing
Jun 4 10:17:01	php-fpm	91403	77.88.8.3|X.X.X.X(myIP0)|WAN0WIFIRE_DHCP|8.717ms|0.864ms|4%|online|none
Jun 4 10:17:12	php	21320	notify_monitor.php: Message sent to X@X.X(myEmail) OK
Jun 4 20:12:48	rc.gateway_alarm	45630	>>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:0 RTT:7.169ms RTTsd:.943ms Loss:5%)
Jun 4 20:12:48	check_reload_status	524	updating dyndns WAN1INETCOM_DHCP
Jun 4 20:12:48	check_reload_status	524	Restarting ipsec tunnels
Jun 4 20:12:48	check_reload_status	524	Restarting OpenVPN tunnels/interfaces
Jun 4 20:12:48	check_reload_status	524	Reloading filter
Jun 4 20:12:49	php-fpm	18070	/rc.openvpn: MONITOR: WAN1INETCOM_DHCP is available now, adding to routing group WANLoadBalancing
Jun 4 20:12:49	php-fpm	18070	77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.166ms|0.941ms|3%|online|none
Jun 4 20:12:50	php	68275	notify_monitor.php: Message sent to X@X.X(myEmail) OK
Jun 4 21:27:34	php-fpm	686	/index.php: Successful login for user 'XXX(myLogin)' from: 192.168.100.5 (Local Database)

[werter]

@nockdown

General - раздел настроек пф в ГУИ.
И Advanced тоже.

[nockdown]

This post is deleted!

[nockdown]

@werter , извиняюсь. Пожалуйста:

System - General Setup
System - Advanced - Admin Access
System - Advanced - Firewall & NAT
System - Advanced - Networking
System - Advanced - Miscellaneous
System - Advanced - System Tunables
System - Advanced - Notifications

[werter]

Добрый.
@nockdown

1-й же скрин (General setup) - настройки ДНС.
У вас по 2 днс на каждый линк - это правильно. Но надо по два РАЗНЫХ днс на каждый линк, т.е. всего 4 НЕПОВТОРЯЮЩИХСЯ ip для ваших 2-х ВАНов.
И НЕ провайдерские ДНС как у вас на скрине.

Пример.
ВАН1 - ДНС 8.8.8.8, 8.8.4.4, ВАН2 - ДНС 1.1.1.1, 1.0.0.1
Любые приличные на ваш выбор, но ВСЕ разные. Приличные - google dns, opendns etc. Можно и dnssec пользовать.

У вас один из ВАН - это wi-fi-линк? Не самое стабильное решение. Может в этом проблема?

Зы. Если ipv6 вам не нужен, то откл его. Иначе прийдется правила Fw и для него рисовать.

Зы2. Цепляйте скрины прямо здесь. Не надо их на сторонние ресурсы выкладывать.

[nockdown]

@werter , спасибо!
Поменял настройки System - General Setup - DNS Server Settings

"Можно и dnssec пользовать."
Если я правильно понимаю, то DNSSEC только для DNS Resolver, у которого проблемы с Multi-WAN. Я использую DNS Forwarder, который полностью совместим с Multi-WAN.
DNS Resolver and Multi-WAN
With the default settings, the DNS Resolver will have issues in a Multi-WAN environment. The main issue is that the DNS Resolver wants to query the root DNS servers directly. These queries will only be sent out using the default gateway. If the WAN containing the default gateway fails then DNS queries will also likely fail. There are ways to work around this limitation, however:

1. Forwarding Mode
   Enable DNS Query Forwarding and configure at least one DNS server per WAN gateway under System > General Setup. DNSSEC may also need to be disabled, depending on upstream DNS server support.
2. Default Gateway Switching
   Enable Default Gateway Switching under System > Advanced, Miscellaneous tab. This will move the default gateway to the next available gateway if the preferred default fails. However, this option is still considered experimental and may have problems in certain cases.

DNS Forwarder and Multi-WAN
The DNS Forwarder is fully compatible with Multi-WAN. Configure at least one DNS server per WAN gateway under System > General Setup.

"У вас один из ВАН - это wi-fi-линк? Не самое стабильное решение. Может в этом проблема?"
Нет, оба WANа по проводу по меди - WAN0 300Мбит/с и WAN1 200Мбит/с.

"Зы. Если ipv6 вам не нужен, то откл его. Иначе прийдется правила Fw и для него рисовать."
К сожалению, не знаю такой опции. У меня такие настройки, надеюсь, этого достаточно:

[werter]

@nockdown said in Gateway Monitoring при Multi-WAN:

Я использую DNS Forwarder, который полностью совместим с Multi-WAN.

У DNS Forwarder НЕТ проблем с мультиВАНом при правильной настройке.
Сами же и процитировали КАК его настроить:

There are ways to work around this limitation, however:

DNS Forwarder испол-ся по умолчанию самими разработчиками пф.

Выкл. Форвардер, вкл. Резольвер. Нет у него проблем с неск-ми ВАНами.
Подтверждено собственным опытом и 20+ установками пф за 1.5 года )

[nockdown]

@werter , спасибо за рекомендации.

1. Я не думаю, что выбор DNS Resolver или DNS Forwarder может повлиять на мониторинг состояния соединения по WAN1 с помощью Gateway Monitoring.
2. Ранее длительно время на данном pfSense я уже использовал DNS Resolver, падения WAN1 случались не реже.
3. "У DNS Forwarder НЕТ проблем с мультиВАНом при правильной настройке." - Тут, я так понимаю, вы описались и имели в виду DNS Resolver.
4. А вы каким из 2 способов обходите проблемы для DNS Resolver при Multi-WAN? Forwarding Mode или Default Gateway Switching?

[werter]

@nockdown

1. Вероятно, вы правы. Но это как мыть или не мыть руки. Лучше мыть.
2. Ок
3. Верно. Резольвер, конечно.
4. Галка на Forwarding Mode.

Может сетевую\патчкорд сменить?
Или Шейпер настроить на проблемном линке с высоким приоритетом для ICMP? Только скорость указывайте для Трубы РЕАЛЬНУЮ - не 100500 Терабит\с ) Берите 80-90%% от РЕАЛЬНОЙ.

[GarryTom]

@werter
У меня такая же проблема, постоянно отваливается один Gate в MultiWAN (WAN+OPT1+OPT2).

Ошибок в статусе интерфейса - 0, многодневный PING по этому интерфейсу - без потерь, IP для мониторинга менял. Такое поведение появилось в последних версиях 2.4, до этого не было.
Самое интересное: если сократить число внешних интерфейсов с 3 до 2 или даже до 1 (оставить только OPT1), то проблемный Gate работает как часы. Не меняя никаких других настроек.
Такое впечатление, что монитор начинает путаться в интерфейсах при их количестве больше 2.

[nockdown]

@garrytom ,

"Такое впечатление, что монитор начинает путаться в интерфейсах при их количестве больше 2." - У меня как раз всего два WAN. Не 3 (WAN+OPT1+OPT2) как у вас.

Провайдер предложил сменить подключение с DHCP на PPPoE. После этого Uptime проблемного интерфейса 6d 19:35:38, потери пакетов (packet loss) укладываются в дефолтные настройки Gateway Monitoring, проблемный WAN1 ни разу не исключается из группы Load Balancing. Наблюдаю, предварительно напрашивается вывод, что проблема была на стороне провайдера.

Насколько я понимаю, при смене DHCP на PPPoE скорость чуть ниже в теории, так как при PPPoE - больший размер служебных заголовков, как следствие, меньше полезной нагрузки можно передать. Хотя speedtest в норме.

[werter]

@nockdown

https://ru.wikipedia.org/wiki/DHCP - прикладной протокол (7-й уровень модели OSI)
pppoe - канальный (2-й уровень)

Нет там потерь. Может 0-целых и хрен-десятых )

Сам активно пользую https://linkmeup.ru/blog/11.html

[werter]

@garrytom
Вы там чего мониторите-то? Зачем замазали?
Не мониторьте ШЛЮЗ провайдера.

Зы. Ого! Это ж кто сейчас pptp пользует? Что ж за провайдер такой?

[GarryTom]

@nockdown
То, что у вас линк изменился на PPPoE, принципиально изменило вашу конфигурацию. Не думаю, что у провайдера глюки при разных видах соединения, ну если, конечно, уровень этого провайдера не ниже плинтуса. А вот на вашей стороне другие драйверы, другие механизмы. Ну и мои эксперименты с простым уменьшением числа интерфейсов и "волшебном" восстановлении проблемного гейта наводят на мысль, что ошибка где-то в pfsense.

@werter
Там общедоступные Яндексовские сервера. pptp - это не провайдер, это линк в одну очень старую сеть, другого там нет.

[nockdown]

@garrytom , как вы думаете, а если я:

1. верну проблемного провайдера на DHCP,
2. физически переподключу кабеля провайдеров в pfsense. Сейчас igb0 - WAN0, igb1 - WAN1, а подключу igb0 - WAN1, igb1 - WAN0. Даже MAC Address для Interfaces подменять не буду. То если предполагать, что "ошибка где-то в pfsense", то проблемным должен стать другой провайдер (вместо WAN1, WAN0)? Ведь WAN0 и WAN1 ничем не отличаются в настройках моего pfsense друг от друга кроме Network port и Monitor IP. А для Monitor IP для WAN1 я перепробовал уже и DNS провайдера, и общедоступные узлы - DNS от Яндекса, Google, OpenDNS, Cloudflare, это никак не влияет на потерю пакетов (packet loss).

[GarryTom]

@nockdown
Нет, не должен, хотя и не возможен. 50/50. В сложных системах, которой, безусловно, является pfsense, не все зависимости настроек линейны.
Я, к сожалению, не могу повторить ваш эксперимент и просто переткнуть кабель в сетевухах: привязка к провайдеру идет по мак-адресу, а его смена - целое мероприятие.
Да, настройки WAN0 и WAN1 не отличаются. Но отличаются сами линии (те же RTT и RTTsd, соответственно реакция монитора на это), отличаются Tier, вес интерфейса и порядок следования. У нас уравнение с несколькими переменными и разными коэффициентами перед ними. :)
Про IP монитора согласен - никак не влияет.

Ого! Сейчас посмотрел в монитор. После сегодняшних манипуляций с настройками, которые рекомендуют в этой теме, ошиба переползла на OPT2. И при чем тут провайдер?

Мне кажется, или ошибка опять на следующем после Default гейте?

[nockdown]

@garrytom ,
"привязка к провайдеру идет по мак-адресу" - у меня тоже, но я готов это стойко перенести ради эксперимента.
"Мне кажется, или ошибка опять на следующем после Default гейте?" - У меня проблемный Gateway сейчас (Uptime: 7d 00:08:14) - default. За это время на втором Gateway (WAN0) потери пакетов (packet loss) укладываются в дефолтные настройки Gateway Monitoring, и этот не проблемный WAN0 ни разу не исключается из группы Load Balancing.
До этого: 1) мой проблемный Gateway не был default, 2) подключение было по DHCP, а не PPPoE.

[GarryTom]

@nockdown
А вот еще один факт в копилку моей уверенности, что проблема в pfsense. Обычно в сутки я получаю 50-100 уведомлений о выпадении/включении гейта. Чуть меньше суток назад, после моих экспериментов с настройками (в итоге я вернул старые настройки), OPT1 стал шлюзом по умолчанию. И с тех пор ни одного падения этого гейта. Был по OPT2, но по OPT1 - ни разу! Изменился режим работы pfsense и - вуаля! - гейт работает как часы.