Не обращайте внимания на то, что говорят остальные здесь... они понятия не имеют, особенно про Hitron. Линейка Unifi *очень* слабовата по сравнению с тем, что предлагала серия ER. Поэтому я оставил несколько запасных ER-4/6 для сайтов с WAN < 1Gbps и перевел другие сайты на OpnSense, Mikrotik или Juniper. Но у меня было два первых сайта, которые используют UDMPs, так что я вроде как все равно должен их поддерживать. Я устанавливаю on-boot-utilities от BoostChicken, чтобы они запускались при загрузке и каждый раз, когда UI GUI перезаписывает настройки. Это часть сложного скрипта, чтобы эти Unifi устройства имели функциональность ER. Это в скрипте /data/scripts/on-state-change.sh.

Эти две строки проверяют наличие второго IP-адреса на WAN и добавляют правило маршрутизации postrouting по мере необходимости для CPE. WAN на этих подключены к порту 10 SFP+ (так что eth9); подкорректируйте, если нужно. Вы можете проверить это, просто введя эти две строки непосредственно внутри операторов if в SSH-промпте.

if [ "$(ip addr show eth9 | grep "inet 192.168.100.2/24 scope global eth9")" = '' ]; then
ip addr add 192.168.100.2/24 dev eth9
fi

# -------------------------------------------------------
if [ "$(iptables -t nat -S POSTROUTING | grep -e "POSTROUTING -d 192.168.100.0/24 -o eth9 -j SNAT --to-source 192.168.100.2")" = '' ]; then
iptables -t nat -A POSTROUTING -o eth9 -d 192.168.100.0/24 -j SNAT --to-source 192.168.100.2
fi

Не могу сейчас вспомнить, добавлял ли мне нужно было статический маршрут или нет, возможно, добавлял. И также, не забудьте проверить свой брандмауэр, чтобы разрешить внутренний трафик к CPE (и обратно, если это необходимо!).

Да, не получилось. Этот кабельный модем известен тем, что не предоставляет доступ к своим админ-страницам, кроме того устройству, которому он выдал публичный IP-адрес через DHCP (только одно устройство после перезагрузки).

Хосты, не находящиеся в подсети 192.168.100.x/24, и без явного перенаправления (через псевдоинтерфейс на ER4), не знают, как маршрутизировать ответ обратно от модема, потому что SNAT не ведёт таблицу маршрутизации для ответов, которые перенаправление делает.

Так что SNAT исправно переписывает заголовки, чтобы исходящие пакеты выглядели так, будто они пришли, скажем, с 192.168.100.2/24, но когда маршрутизатор получает ответ на 192.168.100.2/24, он просто отбрасывает его, потому что не имеет представления, куда его отправить.

Заметьте, кабельные модемы от Arris и Netgear так не работают, но Hitron CODA56 – да.

Не работает это, потому что SNAT просто перезаписывает исходящий адрес; поскольку нет маскирования, CGM не знает, как отправить ответ обратно отправителю.

Всё, что я сделал, это убедился, что нет конфликта IP-адресов, используемых на WAN- и LAN-сторонах UXG-PRO. А при настройке порта WAN на UXG-PRO я выбрал опцию "Автоматическое согласование скорости/дуплекса". Как ты физически подключаешь Cloud Gateway Max к кабельному модему?

Делай это из браузера, а не из какой-то там "CGM GUI", что бы это ни значило.

Обратите внимание, как настроен порт WAN

192.168.100.255 – это широковещательный адрес. Что происходит, когда вы напрямую подключаете рабочую станцию к кабельному модему?

Отличная мысль.

Тогда что-то еще мешает кабельному модему распознавать запрос как пришедший с локального адреса. Когда я пытаюсь зайти на страницы администрирования модема по адресу 192.168.100.1, доступ просто висит, пока не появится сообщение об ошибке таймаута. Маскировка IP-адреса позволила ему работать на ER4, но ничего из того, что я пробовал, не заставляет его работать на CGM.