Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
UXG Запрос функции - Сейчас (по состоянию на 3 июля 2024 года) в основном закрыт, wifiman
 
Не уверен, что это правильный раздел форума для запросов на функции, но начну с этого... @UI_Glenn? UXG ЗАПРОСЫ НА ФУНКЦИИ: 1. СЕТЕВЫЕ ПОРТЫ: Возможность вручную установить любые/все 4 сетевых порта на: Скорость и дуплекс 1.0Gbps/Полный дуплекс Скорость и дуплекс 1.0Gbps/Полудуплекс только для портов SPF+ Скорость и дуплекс 10Gbps/Полный дуплекс Скорость и дуплекс 10Gbps/Полудуплекс ЗАМЕТКА 2: этот запрос добавляется к уже существующим настройкам скорости и дуплекса, доступным на UNA для UXG. ЗАМЕТКА: Вот это да. Запрос #1 уже существует в последней версии GA UNA.... Я это пропустил. Найдено в разделе Порты UNA. Для GBE портов; чтобы 1Gbps FDX отобразился, сетевой кабель должен был быть подключен, иначе отображались только 100 и 10 FDX. Для портов SFP+ указаны как 1, так и 10Gbps FDX. Клянусь, этого не было в списке, когда я смотрел... ну что ж, рад, что это есть. 2. РЕДАКТИРОВАНИЕ IP-НАСТРОЕК: Возможность изменить IP-настройки LAN и WAN портов ПОСЛЕ того, как UXG принят на сайте. ЗАМЕТКА: Это можно было сделать раньше, используя отдельный WebGUI USG. ОБНОВЛЕНИЕ: Можно изменить WAN IP (найдено в UNA -> Интернет).... только LAN IP нельзя изменить нигде, где я мог найти после принятия UXG. ОБНОВЛЕНИЕ 2 3 июля 2024: Похоже, что GW LAN IP можно изменить, используя UNA Настройки -> Сети -> LAN (стандартный Mgmt LAN) при использовании стандартной подсети LAN 192.168.1.0/24, используя UNA Настройки -> Сети -> LAN (стандартный Mgmt LAN), НО в моей среде с подсетью CIDR 172.16.0/16, это не срабатывает. Вероятно, это случайный баг, и эту функцию можно обойти, используя повторное принятие UXG. Поскольку это редкий случай, я считаю, что проблема решена и закрыта. Моя благодарность @khtadmin и @_Space за их усилия и отзывы. 3. СЕРВЕР ВРЕМЕНИ: Предоставить NTP сервер, как это было на USG-Pro. Я понимаю, что это запрашивалось множество раз за последние 4 года с момента первоначального выпуска UXG-Pro, но все равно попрошу. Понятия не имею, почему UI не стремится предоставить продаваемую функцию, которую хотят их клиенты.
 
@khtadmin Спасибо еще раз за ваши дополнительные усилия в тестировании на 172.16.0.0/16 CIDR (повторяя мой выбор подсети). Очевидно, что в моем окружении что-то отличается, что блокирует это. Для меня это не проблема, так как повторное принятие UXG работает без проблем.
 
@_SpaceThanks за ваш отзыв. Никаких проблем, и я понимаю, почему вы написали то, что написали. У меня только возникают проблемы с ложными утверждениями, когда я пытаюсь разобраться в ситуации, и вы знаете, кто это делает довольно часто, что портит репутацию UI и этого форума. Очевидно, что он ссылается на какие-то "внутренние" документы или записки, к которым у меня, как у пользователя, нет доступа. По поводу проблемы с изменением LAN IP, мне пришлось делать это только один раз для UXG, когда я следовал неправильному руководству по внедрению UXG, найденному в интернете (поскольку в тот момент я не мог найти официальный документ UI), хотя функция изменения IP была бы полезной и сейчас, похоже, работает с использованием стандартной подсети. Я понимаю, что это далеко не первоочередная задача, так как влияние низкое, а появление багов тоже очень низкое, поскольку просто повторное внедрение UXG является обходным решением в этих случаях. Сомневаюсь, что я когда-либо снова изменю GW IP для этого устройства. Итог: разработчики UI имеют задачи с гораздо более высоким приоритетом, чем эта редкая проблема. Я не заинтересован и не пытаюсь отвлекать важную работу разработчиков UI и всегда стараюсь быть разумным, когда другие тоже.
 
Это объясняет причину изменения процесса усыновления и почему вы, скорее всего, не увидите никаких изменений в том, что вы воспринимаете как ошибку или недостающую функцию. Как я уже говорил, я вижу, что ваша настройка работает не так, как моя или у @khtadmin, и изменения в шлюзе, сделанные с помощью сетевого приложения, по-видимому, не работают. Я все равно рекомендую вам создать заявке на это.
 
1) Не нужно быть грубым. Ты можешь игнорировать людей и не обращать внимания на их комментарии. 2) Я знаю, что ты знаешь следующую часть, так что нет смысла реагировать так раздражённо.. USG и UXG совсем не одно и то же устройство, они работают по-разному, управляются по-разному, у них разные кодовые базы... поэтому ожидать одинаковых результатов от них — это не лучшее предположение с твоей стороны. Если честно, это глупо. (Простой пример: редактирование json файлов... ты можешь сделать это с одним, но не можешь с другим.) Я протестировал то, что, как я думаю, ты пытаешься сделать, и у меня всё работает.. но, возможно, я не совсем всё понимаю... Честно говоря, у меня не так много желания тестировать или играть сегодня, так что возможно, это просто я. Поскольку ты недоволен комментариями, которые получаешь, как уже было предложено, открой тикет, и ты получишь официальный ответ от UI инженеров.
 
Большое спасибо за тестирование. Я полностью с тобой согласен: мне тоже страшно и противно вносить такие изменения. Очень ценю, что ты нашел время, принял риск и протестировал это. Я owe тебе пиво! Хм... Итак, это работает, когда используется стандартная локальная сеть 192.168.1.0/24, но когда я проверял это снова прошлой ночью в своей управляемой сети 172.30.2.0/24 (очевидно, что моя сеть не является стандартной управляемой сетью UXG прямо из коробки), она ведет себя так же... UXG-Pro становится изолированным в сети и отключается. Изменение настроек > Сеть > IP-адрес шлюза LAN обратно на оригинальный IP-адрес шлюза LAN не восстанавливает доступ к сети UXG. Только повторное принятие UXG работает для меня. ПРИМЕЧАНИЕ: У меня UXG-Pro на последней версии прошивки v4.0.6. Моя единственная догадка на данный момент - использование стандартной подсети 162.168.1.0/24 работает. Однако использование другой частной подсети CIDR в пределах 172.16.0.0/16 не срабатывает, так что не получится. ПРИМЕЧЕНИЕ2: Протестировать мой UXG-Pro в подсети 192.168.1.0/24 - это ОЧЕНЬ... слишком много работы, так как я уже использую 192.168.1.0/24 в другой не управляемой, но критической сети. Изменения, которые мне нужно будет внести, потребуют огромной работы и сломают много всего по пути. Если бы это не было так масштабно, я бы определенно сделал это в рамках сбора тестовой информации, которая могла бы помочь разработчикам интерфейсов и, соответственно, нам в конечном итоге.
 
Что за чертовщина?!.... в этом вообще ничего не упоминается о обсуждении или предупреждении об изменениях LAN IP на принятом USG. Так что, очевидно, у вас нет ссылки на поддержку UI, чтобы подтвердить ваше заявление. Это чушь и ничего больше. Факт: Каждый раз, когда я вносил это изменение LAN IP на своем принятом USG-Pro, все проходило как по маслу, и абсолютно НИЯКИХ проблем.
 
E.g. вот пост от Криса
 
Вы должны подать заявку или проверить брандмауэр вашего собственного сетевого сервера. Никаких проблем с Cloud Key G2 Plus, все настраивается и работает за секунды.
 
@khtadmin Я уже понял, о чем ты говорил. Однако, если IP-адрес GW LAN изменить здесь через UNA > Networks после привязки, и он будет отличаться от IP-адреса, который был назначен изначально через UXG WebGUI до привязки, то UXG станет недоступен, а базовый IP-адрес GW LAN на устройстве не изменится сам по себе... поэтому оно не будет работать. UXG станет изолированным от сети. ПРОВЕРЬ ЭТО САМ: Попробуй изменить IP-адрес GW LAN сам на своем принятом UXG-Lite через Настройки > Сеть, как ты предлагаешь (так как это домашняя система... не будет работать так, как твой Pro). Попробуй изменить его на что-то вроде 172.27.0.254/24 (оставь его в той же подсети, которую ты сейчас используешь - я никогда не пробовал менять UXG на другую подсеть таким образом), ты увидишь, о чем я говорю. Это нарушит доступ к UXG, и UXG уйдет в офлайн в UNA. Будь готов забыть, сбросить и заново привязать свой UXG (и немного испытать отключение). Именно так мне пришлось поступить, поскольку я уже пробовал этот метод, когда впервые настраивал свой UXG. Ах да... дополнительно, тебе следует временно приостановить правила фаервола, иначе этот тестовый запуск, скорее всего, нарушит доступ к твоему UXG после изменения IP-адреса GW LAN.
 
Вам нужно предоставить официальные доказательства от UI для своих утверждений, иначе это просто бред и не более того. Я тщательно искал подтверждение вашим словам и ничего, нигде, что поддерживало бы или даже упоминало ваши заявления, не нашел. Я нашел только два отдельных потока обсуждения людей, пытавшихся изменить LAN IP на USG после усыновления (эта информация была на форуме сообщества UI и никаких официальных документов/белых книг я нигде не нашел), и там нет никакого упоминания о том, что вы сказали. Пользователи на самом деле получили указания от других о том, как изменить LAN IP после усыновления, и это сработало как надо. Вы не предоставили никаких официальных доказательств от UI в поддержку своей точки зрения. Так что я вам не верю, пока вы не докажете это (т.е. поддерживающие документы).
 
Для довольно большого числа людей это действительно было так. Если я правильно помню, было предупреждение не вносить изменения после принятия, что иногда игнорировалось. В результате у людей возникали проблемы с их USG, и они в конечном итоге возвращались к скреплению бумаг, повторно принимали его и выражали недовольство. Тот самый процесс принятия USG, который у некоторых был проблемой, на самом деле дал толчок подходу UniFi Cloud Gateway, чтобы сделать настройку и управление более удобным. Я не ожидаю, что интерфейс вернется к тому, что они, скорее всего, назвали бы улучшениями.
 
На самом деле нет. Изменение LAN IP не было проблемой с линейкой USG от UI. Можно было напрямую войти в WebUI USG и внести эти изменения за несколько секунд. С любым другим шлюзом, с которым я сталкивался раньше, таким как Cisco, HPE, Juniper, Checkpoint, pfSense и т.д., я мог легко изменить LAN IP. Мне странно, что UI не позволяет это на их премиум шлюзе, было бы проще для пользователя внести любые необходимые изменения LAN IP... лучше, чем использовать подход "забудь и переосознай" на мой взгляд. Поэтому и запрос на эту функцию. UI добавил это для любых изменений WAN IP через настройки UNA > Интернет - выберите WAN порт... просто не для LAN порта.
 
Это вполне ожидаемо для устройства, управляемого программным обеспечением для сетевого администрирования, не так ли?
 
Вы пропустили проблему, о которой я говорил. Проблема не в том, чтобы поменять GW в настройках сети UNA (это, черт возьми, очень просто), а в том, чтобы изменить IP физического LAN-адаптера GW на самом шлюзе, что и составляет проблему (после подключения IP LAN-адаптера заблокирован).
 
Не вижу, чтобы это отметили, сработал ли у вас параметр IP шлюза в интерфейсе? Ваша идея не решает основную проблему — проблема в изменении фиксированного IP внутреннего LAN NIC шлюза на самом интерфейсе шлюза. Дело не в изменении Настройки > Сеть > LAN > IP шлюза: я могу это делать в любое время и с любым устройством... Проблема в том, что изменить физический IP LAN GW NIC на самом UXG нельзя после его адаптации. Для WAN NIC UXG я могу менять IP, но с LAN NIC это не получится. Это все еще проблема. Мое решение заключалось в добавлении собственного NTP Stratum 3, размещенного в внутренней сети, и настройке всех устройств на его использование через DHCP. Теперь никаких проблем. ЗАМЕТКА: "сценарии, когда обычный NTP сервер на шлюзе нежелателен"... именно поэтому производители предоставляют это как опцию включения/выключения. Большинство шлюзов уровня бизнеса предлагают NTP, но не все. Это давно уже запрашивалось многими пользователями до меня, и реализовать это в коде UXG невероятно просто. Ясно, что интерфейс это не сделает, но запрос остается.
 
Это не ты. Это работа @khtadmin натолкнула меня на это. Последовательная правда = доверие и являются ключом к раскрытию ситуации. Рад видеть, что Маркони снова тут.
 
Рад, что смог помочь, навестив тебя проверить настройки брандмауэра на сервере.
 
Ошибка между сиденьем и клавиатурой... была nftables на моем собственном контроллере UNA. Они были активны во время моего тестирования. Я всегда отключал файрвол контроллера перед тем, как заняться адаптацией или повторной адаптацией устройства Unifi, такого как UXG (следуя небольшому руководству, которое я написал, чтобы помнить все необходимые шаги, так как у меня усиленная безопасность), НО забыл сделать это, когда вносил изменения в сети в консоли UNA. Как только файрвол был отключен, все прошло гладко, когда я изменил шлюз LAN. После успешного изменения я снова включил nftables, и все продолжало работать отлично.
 
@khtadmin Я понимаю, что ты имел в виду выше 172.16.x.x из твоего скриншота... Спасибо еще раз за дополнительные тесты. Я считаю все твои тесты вне стандартной сети 192.168.1.0/24 актуальными и корректными. Я доверяю твоей работе, так как ты не давал мне повода сомневаться. Поскольку я упорен в решении любых технических вопросов, я нашёл корень своей проблемы, и изменение IP-адреса GW LAN теперь работает отлично в моем окружении. ОБНОВЛЕНИЕ: Дополнительно: Я только что понял из твоей работы, что ты, кстати, отлично это показал, что подсеть LAN шлюза UXG может быть изменена в UNA без необходимости повторного принятия UXG... это очень полезно знать.
Страницы: 1 2 След.
Читают тему (гостей: 1)