Приложение Unifi Protect для мобильных устройств не поддерживает прямое подключение между VLAN.

Приложение Unifi Protect для мобильных устройств не поддерживает прямое подключение между VLAN., UniFi Protect

DigiMasTer

Guest

10.06.2021 16:58:00

Уважаемая команда Ubiquiti @UI-Team, недавно вы выпустили обновление для мобильного приложения Unifi Protect, которое добавило функцию «прямого подключения», позволяющую мобильному устройству напрямую подключаться к UNVR по локальной сети. Однако, если UNVR и мобильное устройство находятся в разных VLAN с разными IP-диапазонами, но с маршрутизацией между VLAN, приложение не подключается напрямую к UNVR, а использует старое подключение через Интернет. Это работает только когда и UNVR, и мобильный клиент находятся в одном IP-диапазоне. В вашем мобильном приложении Unifi Network ситуация иная: даже при настройке, описанной выше, мобильное приложение напрямую подключается к контроллеру. Пожалуйста, обеспечьте такую же согласованность, какую вы демонстрируете в других своих продуктах. Спасибо.

javaman Guest	#2 08.07.2024 11:45:00 Перепутанный ответ? Мой вопрос вообще не связан с этим постом.

ThatCreole

Guest

07.07.2024 02:38:00

Привет, @UI-Team (или любой, кто в курсе) — почему в приложении Protect такое ограничение по VLAN, если в приложении Console такого нет? Вся эта огромная ветка переписки полна раздражения и нестандартных решений, но при этом нет официального объяснения, почему вообще было принято такое решение по дизайну.

ThatCreole

Guest

07.07.2024 18:43:00

По поводу того, почему у людей возникают такие проблемы с удалённым доступом, нужно помнить, что у разных клиентов разные модели угроз. Хотя я и согласен, что включение удалённого доступа для большинства клиентов — это отличный вариант, есть определённые клиенты, которым приходится осторожно балансировать между конфиденциальностью и безопасностью с одной стороны и удобством — с другой, в зависимости от того, какие ресурсы они пытаются защитить.

Вот пример того, чего пытаются избежать клиенты с более детализированной моделью угроз: https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-says-ring-employees-illegally-surveilled-customers-failed-stop-hackers-taking-control-users

И даже ближе к дому, к этому форуму, пример, который мог бы закончиться гораздо хуже: https://community.ui.com/questions/Update-to-January-2021-Account-Notification/3813e6f4-b023-4d62-9e10-1035dc51ad2e

Когда удалённый доступ включён, например, ваш UNVR в рамках использования STUN/TURN сервисов с удовольствием отправляет данные в Twilio. А что если Twilio — это сервис, которому клиент не хочет доверять? Как сказал @UI-Marcus в этой теме, решение простое — просто отключить удалённый доступ: https://community.ui.com/questions/Anomalous-upload-to-EC2-from-NVR/464d755a-3258-4062-a8e5-bf68018de7f6

Но возвращаясь к моему изначальному вопросу — мне интересно, почему (по крайней мере с точки зрения клиента) дизайн именно такой. Я просто не могу понять, как именно через iOS-приложение установить прямое соединение, вне зависимости от состояния удалённого доступа. Мой текущий план — подсоединить консоль UNVR в доверенную локальную сеть клиента и использовать правила фаервола, чтобы разрешать подключение только конкретным устройствам.

idscomm Guest	#5 07.07.2024 18:33:00 Как я уже говорил в этом посте, я использовал приложение в другой VLAN и подключился напрямую. Я следовал этой статье, и всё заработало с OPNSense и Unifi Gateway: https://idscomm.ca/blog/unifi-nvr-direct-connection-from-separate-network

southerndoc

Guest

07.07.2024 16:17:00

Это работает при включённом удалённом доступе, но устанавливается прямая связь. Я не пробовал без включённого удалённого доступа. Однако, если ваши мобильные устройства находятся в гостевой сети (то есть вы указали именно это, а не просто отдельный VLAN), учтите, что по умолчанию клиенты не могут между собой общаться. Не понимаю, почему у людей такие проблемы с удалённым доступом.

javaman

Guest

07.07.2024 15:57:00

Кто-нибудь здесь умеет использовать прямое подключение, оставаясь при этом в аккаунте UI в приложении? На iOS я сделал всё по инструкции: полностью вышел из аккаунта, затем настроил консоль через локальное прямое подключение. Сеть абсолютно простая, без VLAN. Когда я вышел из UI.com, приложение отображает локальный Protect. Но как только я вхожу в аккаунт UI.com в приложении, в списке появляются мои консоли с облачным подключением, а локальная консоль остаётся с пометкой DIRECT. Но если я пытаюсь к ней подключиться, экран быстро моргает и возвращается обратно к списку консолей. Все остальные облачные консоли работают нормально.

ThatCreole

Guest

07.07.2024 04:11:00

Привет, @southerndoc! Спасибо, что откликнулся. Чтобы уточнить, ты хочешь сказать, что следующий сценарий должен работать (если не блокирует настройки фаервола): UNVR в сети 10.0.0.0/24, мобильные устройства в 10.0.10.0/24, удалённый доступ на UNVR выключен, а приложение Protect на мобильном должно подключаться напрямую к UNVR, примерно так же, как это делает Unifi Console? Если да, то, к сожалению, у меня это всё ещё не работает. Я явно разрешил трафик между этими двумя VLAN и пытался включить SSDP-реле, как советуют в этой ветке, но без успеха. Пока что рабочим получается только вариант, когда включён удалённый доступ.

southerndoc Guest	#9 07.07.2024 03:49:00 Это было решено еще давно. Проверь свои правила в файрволе.

idscomm

Guest

#10

10.05.2024 19:02:00

Спасибо большое за то, что поделились этими знаниями, это решило мои проблемы (медленное соединение с моим NVR в отдельной сети — подключение к Unifi Cloud). Для тех, кто, как и я, использует OPNSense, этот процесс работает без проблем.

SwissSteph

Guest

#11

13.03.2024 09:45:00

Спасибо! Спасибо! Спасибо за ваше очень понятное сообщение и информацию. Благодаря вам у меня наконец-то снова заработал "Protect". Всё работало идеально до конца 2023 года, а потом обновления приложений "Protect" всё сломали. Невозможно было пройти через мой VPN (на Pfsense, как уже несколько лет), а затем запустить "Protect" на моём Android. Поддержка Unifi никакая, просто позор. Хотя я объяснял, что раньше всё работало, а теперь нет, они даже слушать не хотели и задавали глупые вопросы. Потом отправили меня на форум (хотя я им сказал, что уже там писал). В общем, отвратительный сервис.

Ваша же идея идеальна и отлично работает с моим "OpenVPN", так что для меня это просто замечательно (только маленький нюанс — не работает с Wireguard. Это объясняется в ссылке на пакет "UDP Broadcast Relay", которую вы упомянули). Если выбрать "LAN" + "Wireguard", сервис "UDP Broadcast Relay" не запускается. А вот при выборе "LAN" + "OpenVPN" — запускается.

Я искал решение больше трёх месяцев, СПАСИБО за вашу помощь и сообщение!!!!!!!!!

P.S. Ой... Я тестировал через Wi-Fi с OpenVPN и без — всё было нормально... Но увы, если я далеко от дома — не работает :-(

P.P.S. После нескольких тестов работает наполовину.
Дома на моём Wi-Fi, приложение "Protect" — работает (это нормально).
Дома на моём Wi-Fi + OpenVPN, приложение "Protect" — работает.
На работе, в Wi-Fi работодателя + OpenVPN — работает (я очень рад).
Но вот что:
На мобильном операторе + OpenVPN, приложение "Protect" — НЕ РАБОТАЕТ.

Я не могу понять, в чём тут разница.

rickatnight11

Guest

#12

30.01.2024 18:08:00

@gaming09, полагаю, тебе нужно добавить это правило для файрвола (или поднять его выше правила по умолчанию с запретом) на интерфейсе wireguard, поскольку именно через него придут широковещательные пакеты твоего приложения:
* Протокол: IPv4 UDP
* Источник: сеть WG (любое устройство в сети wireguard)
* Адрес назначения: 255.255.255.255 (широковещательный адрес, чтобы пакеты прошли через файрвол pfSense и сервис UDP Broadcast Relay их «увидел»)
* Порт назначения: 10001

asdfasdf99 Guest	#13 29.01.2024 18:35:00 Просто напомню, так как в эти выходные настроил свой G4 Doorbell и был удивлён, что не могу получить доступ к записям через разные VLAN...

gaming09

Guest

#14

14.12.2023 23:03:00

Я пытаюсь зайти через свой VPN-адрес по WireGuard, сделал всё, как ты сказал, но у меня вот что получается. 1.6 — это мой CloudKey.

Dec 14 15:01:19 bridge0 Default deny rule IPv4 (1000000103) 192.168.1.6:60909 255.255.255.255:10001 UDP
Dec 14 15:01:19 bridge0 Default deny rule IPv4 (1000000103) 192.168.1.6:60909 255.255.255.255:10001 UDP
Dec 14 15:01:19 bridge0 Default deny rule IPv4 (1000000103) 192.168.1.6:60909 233.89.188.1:10001 UDP
Dec 14 15:01:19 bridge0 Default deny rule IPv4 (1000000103) 192.168.1.6:60909 233.89.188.1:10001 UDP

Sojeph8

Guest

#15

29.10.2023 11:39:00

У меня такая же проблема, которая только что появилась — установленная и настроенная система работала почти год, а два дня назад эта проблема возникла на моём телефоне, Apple TV и у моего соседа с его Android. Как я уже говорил, я ничего не менял, сеть у меня маленькая и простая, даже без нескольких VLAN! Так что мне теперь делать, чтобы всё снова заработало? Очень раздражает, когда исправно работающее оборудование ломают обновления от самого производителя. И почему я здесь не вижу ни одного ответа от техподдержки? Разве им не выгодно сразу выложить решение, чтобы каждому участнику темы не приходилось обращаться в техподдержку по отдельности? Очень странные методы для компании такого «уровня».

holbra

Guest

#16

20.08.2023 11:30:00

@rickatnight11, спасибо за инструкции, они сработали у меня. Мой VLAN и CK находятся в разных сетях, но если выполнить шаги в обратном порядке, всё отлично работает. Однако я хотел бы иметь возможность обращаться к Protect на iOS через Tailscale, когда я не дома (через 4G/5G). У меня уже настроен Tailscale на Pfsense и iOS. По умолчанию, при настройке Tailscale на Pfsense не нужно создавать новые интерфейсы для работы Tailscale, но нужно указать интерфейсы для службы UDP Broadband Relay. Я пробовал создать новый интерфейс Tailscale с единственным IP-адресом Pfsense Tailscale и повторно использовать описанные выше правила, но это не сработало. Не будет ли у вас каких-нибудь советов? Большое спасибо!

tuanccs Guest	#17 27.07.2023 23:53:00 Спасибо, @rickatnight11, использовал твоё руководство и https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-FortiGate-forward-broadcast/ta-p/197533 — и мне удалось настроить это на Fortigate.

rickatnight11

Guest

#18

27.06.2023 19:39:00

Я здесь, но ты прав, что пакет пока не «официальный». На самом деле я взял последнюю версию pkg с https://redmine.pfsense.org/issues/10818#change-67754, где ведётся разработка, но вижу, что его убрали из задачи (видимо, потому что скоро он станет официальным пакетом). Интересно, не мог бы ты установить его вручную через командную строку?

RipStop

Guest

#19

26.06.2023 03:22:00

Спасибо, @rickatnight11. Очень ценю твой подробный ответ. Похоже, ты пользуешься pfSense Plus. Я же на pfSense CE 2.6, и пакет UDP Broadcast Relay не значится в списке доступных по умолчанию. Похоже, что он появится в CE 2.7, который уже близок к выходу. Я ждал целых полгода с тех пор, как настроил Protect, так что еще пару недель пройдут незаметно. Держу кулаки...

rickatnight11 Guest	#20 24.06.2023 16:27:00 Конечно! У меня есть такие VLANы: `10.0.0.0/24` (Management): здесь находятся основные сетевые устройства, включая мой Unify Cloud Key Gen2 Plus с запущенным Protect `10.1.0.0/24` (LAN): доверенные личные устройства, например телефоны и ноутбуки (с которых я обращаюсь к Protect) `10.2.0.0/24` (Cameras): здесь расположены все камеры Protect Мой роутер pfSense, конечно, имеет интерфейс на каждом VLAN и отвечает за маршрутизацию между VLANами и в Интернет (WAN). Устройства в VLAN LAN не видят Protect на Management VLAN, поэтому приложение думает, что оно в другой сети (технически — так и есть) и подключается через облачный сервис, что работает медленно. Чтобы решить эту проблему, я установил пакет UDP Broadcast Relay, включил его и создал один экземпляр с такими настройками: - Сетевые интерфейсы: Management и LAN (камеры добавлять не нужно, Protect общается только с сервером Protect, а не напрямую с камерами) - Подмена источника (Spoof Source): Keep Original (по умолчанию) — нам важно, чтобы приложение и сервис общались напрямую, без NAT - Уникальный номер: 1 (не важно) - Целевой UDP порт: 10001 (UDP-порт эфира, который использует Unifi Protect для обнаружения локальных серверов) - Мультикаст-группа: не используется Затем я добавил такое правило в файрвол на сети LAN, чтобы пропускать широковещательные пакеты к службе UDP Broadcast Relay на pfSense: - Протокол: IPv4 UDP - Источник: сеть LAN (любое устройство из LAN) - Адрес назначения: 255.255.255.255 (широковещательный адрес, чтобы пакеты прошли через фаервол pfSense и UDP Broadcast Relay их увидел) - Порт назначения: 10001 Дальше правило на Management-сети для пропуска UDP-пакетов, отвечающих на запросы обнаружения клиента: - Протокол: IPv4 UDP - Источник: 10.0.0.20 (IP Cloud Key) - Адрес назначения: сеть LAN (любое устройство LAN, откуда мог прийти запрос) - Порт назначения: * (Protect отвечает с рандомного высокого порта) Также я добавил два правила, чтобы разрешить трафик с LAN на порты 443 и 7443 моего Cloud Key (к этим портам приложение подключается после обнаружения устройства): - Протокол: IPv4 TCP - Источник: сеть LAN - Адрес назначения: 10.0.0.20 (IP Cloud Key) - Порт назначения: 443 и 7443 В итоге получаем следующую схему: - Приложение Protect на устройстве в LAN отправляет широковещательный пакет обнаружения на 255.255.255.255:10001 - Фаервол pfSense пропускает этот пакет на интерфейсе LAN - Служба UDP Broadcast Relay на pfSense принимает пакет и пересылает его в сеть Management (с оригинальным IP источника) - Сервис Protect на Cloud Key в Management слушает этот порт, получает пакет, извлекает оригинальный IP источника и отправляет ответ с собственного IP и случайного высокого порта - Фаервол pfSense пропускает ответный пакет на интерфейсе Management и маршрутизирует его в LAN - Приложение Protect получает ответ, теперь знает IP «локального» сервиса Protect и подключается к нему по TCP на порты 443 и 7443 - Фаервол pfSense пропускает этот трафик на интерфейсе LAN и маршрутизирует в Management Поскольку трафик TCP, pfSense автоматически отслеживает соединение и позволяет проходить ответным пакетам без дополнительных правил. Вуаля!

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