Да, это сложно, Филиппо. Я согласен с pgrey, что профили портов идеальны по многим причинам, первая из которых — это последовательность, и вам не нужно гадать, в какой VLAN подключено устройство. Другая причина в том, что если UDM выйдет из строя, люди будут подключаться к LAN, связанному с портами, а не к тому, который назначен клиенту, и именно поэтому я стараюсь их избегать.

@Filippo_Fabbrini Да, это кажется огромной тратой времени, если спросить меня. Почему бы просто не разложить все по полочкам и не назначить через порт-профили и SSID? Тогда тебе не придется гадать, работает ли это и почему, из сборки в сборку и с учетом вариаций оборудования. Я использую это только как временный/тестовый механизм, как я уже упоминал несколько раз выше, я просто не думаю, что это предназначено для полного развертывания, и использование его таким образом вызывает проблемы (согласно моему посту несколько дней назад). Думаю, ты можешь с этим справляться, это зависит от того, сколько времени ты хочешь в это вложить (и проверять каждый раз, когда происходит обновление на любом устройстве или программном компоненте), по сравнению с тем, чтобы перенастроить это на более стандартные механизмы назначения... Вопрос с третьими сторонами — это то, о чем я никогда особо не задумывался в этой дискуссии, пока кто-то не поднял его несколько дней назад — в этом сценарии это будет очень проблемно почти в каждом случае.

Если у вас есть адаптер, который поддерживает более одного VLAN, предполагая, что это Win-Server, вы должны иметь возможность настроить тегирование для каждой ВМ. Вот хорошая подсказка: Настройка нескольких интерфейсов VLAN на Windows | Windows OS Hub. Если это другая серверная ОС, у меня нет реального опыта, но я бы предположил, что там есть что-то подобное?

@CartoonNetwork Почему бы вам не пометить порт для VLAN, который вам нужен для сервера с виртуалками? Вам придется вручную назначить неразмеченные, но это позволило бы вам назначать любые VLAN для виртуалок по мере необходимости. Скорее всего, именно это и делает пользовательский интерфейс здесь, за кулисами.

@eltoddo, теперь, когда я понял, чего не стоит делать (использовать переопределение сети на проводном клиенте), у тебя есть мысли о том, как решить исходную задачу? Чтобы не читать заново, у меня есть сервер, который хостит несколько различных виртуальных машин и сценариев использования, но имеет только один сетевой интерфейс. Эти разные сервера должны находиться в разных VLAN, но в данный момент они все в одном. Поскольку это один порт, очевидно, что так быть не может в рамках нашего назначения, именно поэтому я изначально попробовал переопределение сети. Например, я хотел бы, чтобы сам сервер находился в моей надежной сети, в то время как клиенты в основном должны быть в моей IoT-сети (можно было бы утверждать, что в моем конкретном случае они все должны быть IoT, но давайте оставим это в стороне и предположим, что я нахожусь в корпоративной среде и хостю машины для финансов и маркетинга, и мне нужно их разделить, если это поможет примеру). Мне кажется, что переопределение сети используется неправильно, по крайней мере, так я это воспринимаю: если ты хочешь, чтобы Wi-Fi клиент был в другой VLAN, просто let him подключится к другой сети, которая находится в другой VLAN, верно? Это значит, что не нужно переопределение, поскольку ты сам контролировал, как они подключались изначально. Однако эта возможность отсутствует для физических подключений - что-то подключено или нет, и поэтому оно находится в указанной VLAN или нет. В любом случае, я не эксперт в этом, просто пытаюсь больше понять и решить свою задачу, поэтому буду признателен за помощь

Если бы мне пришлось угадать, я бы сказал, что UI использует некую промежуточную таблицу/структуру отображения, отличную от их стандартной реализации VLAN, но с этим связанной (это полгадание, просто у меня опыт в драйверах ОС и тестировании оборудования). Обычно такие единичные разработки хорошо работают, когда кто-то их предлагает и реализует, существуют юнит-тесты и прочее. Но всё меняется (разработчики/тестировщики/менеджеры проектов меняются и т. д.), такие специальные функции часто становятся брошенными или подобными, и функциональность становится менее стабильной и надежной. Я настаиваю на своем предложении, основываясь на этом, что эту функциональность лучше использовать как тестовый механизм, а не как долгосрочную разработку/реализацию, но это основано на вышеупомянутой догадке, так что вот так. Тот факт, что они попросили @CartoonNetwork удалить этого клиента для перенастройки/сброса, подтверждает эту догадку, но не полностью. @Filippo_Fabbrini Что касается коммутаторов Flex, сейчас их довольно много. Коммутаторы 2.5 почти полноценные по стандартам UI (полные возможности VLAN и т. д.), тогда как более старые модели имеют ограниченные возможности в обработке тегов. Я бы поспорил, что именно с этими старыми коммутаторами почти всегда возникают проблемы, в то время как 2.5, несмотря на то что они в той же категории по своей маркировке (и иногда функциональности алгоритмического отображения), решают эти проблемы. Использование единичных функций всегда риск, в любой реализации ОС, вы просто должны понимать и принимать этот риск как таковой и быть готовыми к его устранению, исходя из моего опыта. Проблема с Crowdstrike — отличный пример этого. Некоторые поставщики использовали данные L2/L3 (пользовательский уровень и промежуточный уровень) для изменения функциональности алгоритма на уровне L1 (драйверы антивирусов ядра). Это работало, пока не перестало, и в промежутке это было, по крайней мере, проблемой безопасности DOS. Эти драйверы с тех пор были переведены на полную реализацию L3, полный ремап. Это не первый случай, и, вероятно, не последний, судя по моему опыту, когда это происходило (просто один из более заметных случаев).

та же проблема здесь, настроил больше 40 проводных устройств (все камеры и UNVR) с принудительной сетью в настройках устройства. Я больше не вижу этой опции, все продолжает работать, но клиенты случайным образом теряют конфигурацию и начинают подключаться к родной сети. Недавно я добавил гибкий коммутатор, который, похоже, может быть причиной проблемы. Я прочитал все комментарии, и, похоже, удаление гибкого коммутатора из сети решает проблему, но из других комментариев видно, что возможность использовать принудительную сеть на проводных клиентах "была ошибкой" в предыдущей версии, и в будущем единственный способ заставить проводного клиента вести переговоры по другой VLAN — это тегировать порт (а мне это не нравится, это менее гибко, чем опция непосредственно на клиенте). В мобильном приложении я все еще вижу эту опцию для некоторых клиентов. Может кто-то подтвердить то, что я написал? извините за английский, это не мой язык

Спасибо, @Barward!!!

Г genius - спасибо!!