Минимизация использования данных на резервном канале UDM Pro (для резервного подключения по сотовой сети)

RSS

Минимизация использования данных на резервном канале UDM Pro (для резервного подключения по сотовой сети), UniFi Network

stiell

Guest

31.05.2025 16:17:00

Наконец-то добавил резервное интернет-соединение к моему UDM Pro. Это сотовая связь с лимитом 10ГБ/мес. Всего за 4 дня и ни одной активации резерва, уже потрачено 1ГБ данных!

Обе линии имеют постоянный трафик, даже неактивная резервная линия.

Как можно ограничить трафик на резервной линии, чтобы сотовая связь использовалась минимально, пока она действительно не понадобится?

athurdent

Guest

01.06.2025 17:08:00

Это роутер, и он работает немного иначе. Он не подключен к интерфейсу WAN. Вы можете просто подключить его куда угодно в своей сети, так как он использует GRE-туннель для подключения к UniFi Gateway. Он довольно легко относится к проверкам пинга, ИМХО, примерно раз в минуту. Он точно не будет потреблять гигабайт в день. В будущих версиях Network (9.2.x) можно будет настроить мониторинг IP SLA для ваших интерфейсов WAN, так что в будущем у вас должна будет появиться возможность немного снижать трафик на вашем мобильном WAN. Если вы готовы к EA-тестированию, то просто зарегистрируйтесь в настройках своего аккаунта, сделайте резервную копию, установите и тестируйте.

stiell

Guest

01.06.2025 16:49:00

Это просто современный [устройство]. Движение контролируется UDM Pro, и я полагаю, что неважно, какой модем подключен. А версия этого продукта в США (которую я попробовал первой) заблокирована под конкретного оператора, у которого, к тому же, плохая связь там, где я живу. Да и ежемесячная стоимость намного выше. Так что это не жизнеспособное решение.

athurdent Guest	#4 01.06.2025 12:40:00 Есть оптимизированный для мобильных устройств продукт, который можно использовать: https://eu.store.ui.com/eu/en/products/u-lte-pro

stiell Guest	#5 31.05.2025 19:04:00 Спасибо @travis.vitek. @UI-Glenn, жду твоих мыслей.

travis.vitek

Guest

31.05.2025 18:27:00

@UI-Glenn - Это баг? Похоже, что к Google отправляется 6 пингов для WAN2. Кажется избыточным. Для WAN1 я вижу только 1 такой пинг.

root@Vitek-UDM-Pro:/etc# ps x | grep "dpinger" | grep "google" | grep "eth8"
4049540 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.138-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.138-google.com.sock 173.194.202.138
4049545 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.113-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.113-google.com.sock 173.194.202.113
4049546 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.100-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.100-google.com.sock 173.194.202.100
4049555 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.139-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.139-google.com.sock 173.194.202.139
4049560 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.102-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.102-google.com.sock 173.194.202.102
4049565 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-173.194.202.101-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon9-173.194.202.101-google.com.sock 173.194.202.101

root@Vitek-UDM-Pro:/etc# ps x | grep "dpinger" | grep "google" | grep "eth9"
4050650 ? S<l 0:00 /usr/bin/dpinger -f -i eth9-mon4-142.251.215.238-google.com -B 98.246.105.5 -I eth9 -m 0x001a0000 -s 10s -d 1 -t 30s -u /run/eth9-mon4-142.251.215.238-google.com.sock 142.251.215.238
Есть ли способ отключить, заблокировать или уменьшить пинги для отображения задержки панели управления?

travis.vitek Guest	#7 31.05.2025 18:21:00 Похоже, нужно найти источник трафика и отключить или заблокировать его. Моя версия в том, что этот трафик генерируется функцией мониторинга WAN шлюза, отображаемой на панели управления. Это пинги microsoft/google/cloudflare, а также обнаружение переключения (failover). Обычно у меня не настроен WAN2, но я временно его сконфигурировал и вижу это… ``` root@Vitek-UDM-Pro:/etc# ps x \| grep "dpinger" \| grep "eth8" 4015030 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon9-XX.XX.XX.XX -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 60s -d 1 -t 86400s -u /run/eth8-mon9-XX.XX.XX.XX.sock XX.XX.XX.XX 4015035 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon12-1.1.1.1 -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon12-1.1.1.1.sock 1.1.1.1 4015328 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon6-8.8.8.8-ping.ui.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 3s -d 1 -t 60s -u /run/eth8-mon6-8.8.8.8-ping.ui.com.sock -L 50 -C /usr/bin/wan-failover-script 8.8.8.8 4015329 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon6-1.1.1.1-ping.ui.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 3s -d 1 -t 60s -u /run/eth8-mon6-1.1.1.1-ping.ui.com.sock -L 50 -C /usr/bin/wan-failover-script 1.1.1.1 4015347 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon10-23.197.102.50-www.microsoft.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon10-23.197.102.50-www.microsoft.com.sock 23.197.102.50 4015352 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.101-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.101-google.com.sock 142.251.188.101 4015357 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.100-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.100-google.com.sock 142.251.188.100 4015362 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.113-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.113-google.com.sock 142.251.188.113 4015365 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.138-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.138-google.com.sock 142.251.188.138 4015372 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.139-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.139-google.com.sock 142.251.188.139 4015373 ? S<l 0:00 /usr/bin/dpinger -f -i eth8-mon11-142.251.188.102-google.com -B 10.255.255.143 -I eth8 -m 0x001c0000 -s 10s -d 1 -t 30s -u /run/eth8-mon11-142.251.188.102-google.com.sock 142.251.188.102 ``` Два экземпляра для ping.ui.com нужны для обнаружения переключения, а все остальное - просто для отображения информации на панели управления. Это работает около 30 минут и уже использовало 5,65 МБ. При такой скорости это может составить около 270 МБ в день, что соответствует тому, что вы видите. К сожалению, я не вижу способа заблокировать или отключить этот исходящий пинг-трафик от шлюза с использованием зона-основанного межсетевого экрана. Это должно быть возможно с использованием старого межсетевого экрана с помощью правила WAN_OUT, но это потенциально может помешать исходящим пинг-запросам от клиентов LAN. В Early Access есть функция, которая позволяет контролировать способ определения переключения, позволяя снизить частоту некоторых из этих пингов, но она не дает вам никакого контроля над пинг-запросами к microsoft/google/cloudflare.

Читают тему (гостей: 1)