В зависимости от того, что вы готовы настроить, вы *можете* это сделать… вам нужно будет перенаправить ряд портов на ваш Cloud Key через брандмауэр/шлюз в интернете, который вы используете. В этом обсуждении объясняется, как работает официально поддерживаемое решение IPv6 link-local (в определенной степени детализации): https://community.ui.com/questions/UCI-How-does-it-adopt-when-its-on-the-WAN-side/8f539cb3-32b3-4812-9a8f-5a3ca33fa37d. Вероятно, это *можно* имитировать, если этого хочется. Я не знаю, какой шлюз и брандмауэр вы используете, у меня UXG-Pro. Проще использовать принятие IPv4, которое также использует UCI (избегая слова «поддерживает», потому что это явно работает намеренно, но не является решением, которое Unifi публикует).

Общие детали были рассмотрены другими примерно год назад: https://community.ui.com/questions/UCI-management-via-Unifi-controller-in-docker-potential-workaround/af2c147b-c24e-4361-b22a-1ddb0e02c834?page=1. Более конкретно, вы *должны* использовать 192.168.100.2 в качестве внешнего IP-адреса, к которому UCI будет подключаться, поскольку UCI отправляет ARP-запросы для обнаружения этого адреса и затем начинает процесс принятия на стандартных портах.

Хотя эти сообщения были сосредоточены на самостоятельно размещенном контроллере Unifi, работающем на сервере/виртуальной машине, который можно было напрямую подключить к VLAN WAN; я добился эквивалентного результата для моего Cloud Key, не трогая ОС, на которой работает Cloud Key.

Я использовал Raspberry Pi, подключенный к одному порту сетевого концентратора, который имел доступ к моей внутренней сети и VLAN, подключенной к моему UCI. Я выбрал OpenWRT для обеспечения легкого доступа к необходимым функциям вторичного шлюза+NAT (PFSense был бы моим первым выбором, но он работает только на x86, и я не хотел зависеть от виртуальной машины на более сложном сервере или покупать оборудование SBC x86).

В идеале я бы хотел использовать свой UXG-Pro *самостоятельно* для этого решения; но, думаю, единственный способ сделать это — пожертвовать функциональностью WAN2 (так как я не уверен, что можно настроить необходимый вторичный IP-адрес 192.168.100.2 *и* одновременно получать обычный, маршрутизируемый IP-адрес из внешнего источника… Unifi действительно должна добавить прямую поддержку решения IPv6-based link-local для UXG-Pro).

Скриншоты ниже показывают рабочую конфигурацию OpenWRT. У моего Cloud Key внутренний IP-адрес сети 192.168.1.236.

Перенаправление портов и правила NAT ниже обобщены для подсети 192.168.100/24 и двух MAC-адресов (замаскированы на скриншоте ниже), поскольку я тестировал подключение с помощью виртуальной машины, подключенной к тому же VLAN, но правила работают отлично даже с более строгими ограничениями, позволяя только 192.168.100.1 и MAC-адрес UCI. Я также был готов перенаправлять широкий диапазон портов, даже если мне нужно было перенаправить только 8080 (или, может быть, это плюс 10001).

Это довольно близко имитирует безопасность решения IPv6, если вы готовы к тому, что ничего не маршрутизируется и/или не подделывается подсеть RFC 1918 192.168.100/24 в сети, к которой подключен ваш UCI (и делает это успешно из внешней сети).

Вот моя рабочая конфигурация OpenWRT в качестве справочной точки.

Перенаправление портов (DNAT) так, чтобы трафик от UCI к WAN IP-адресу этого шлюза 192.168.100.2 достигал Cloud Key в моей внутренней сети: Два интерфейса через один порт сетевого концентратора, подключенный к одно NIC Raspberry Pi, один на сеть LAN по умолчанию; WAN модем на VLAN, настроенный на моем UXG-Pro… любой коммутатор, поддерживающий VLAN, может настроить что-то подобное. (Игнорируйте "eth1" ниже; мой Raspberry Pi имеет два NIC, но второй не подключен к чему-либо и не нужен для этого решения, так как более чистым является подключение одного порта концентратора + VLAN.) Конфигурация NAT для переписывания IP-адреса источника (SNAT) 192.168.100.1 на внутренний IP-адрес 192.168.1.2 этого шлюза (так как ничего в моей настройке не позволяет подсети 192.168.100/24 быть маршрутизируемой из моей внутренней сети и машин на VLAN WAN, настроенный… только этот шлюз настроен на возможность связывания (в обоих направлениях)). UCI «немедленно» появилась как принимаемая, как только я включил эту конфигурацию, и успешно обновила свою прошивку после принятия.

Благодарю @briefrelief, @Aethernex и других участников оригинального обсуждения за то, что они задокументировали так много, что облегчило воспроизведение их успеха (вместе с некоторой паузой в прослушивании и т. д., чтобы подтвердить, например, что работает только 192.168.100.2 и т. д.). Я не уверен, столкнусь ли я с периодическими проблемами, как сообщалось некоторыми, но я не вижу никаких проблем даже с самым новым программным обеспечением контроллера Unifi, прошивкой UCI и т. д. на данный момент.

Проверьте последнее предложение в разделе «Требования к заявке».

Требования к заявке
UniFi Network
Версия 8.0.7 и более поздняя с использованием UniFi Cloud Gateway

**После активации у кабельного провайдера UCI по-прежнему может функционировать как незащищенный кабельный модем для предоставления доступа в интернет для сайтов без Cloud Gateway.**
https://techspecs.ui.com/unifi/integrations/uci

К сожалению, они прячут эту информацию очень глубоко! Это в самом низу, в последнем пункте, в разделе "Технические характеристики". Наверное, 99,9% людей не доходят до этого, когда выбирают что-то купить. Им нужно, чтобы это было прямо вверху страницы, в основном списке функций.