athacker

Влан -- это всего лишь идентификатор в ethernet фрейме. Который может принимать значения от 1 до 4094. Вланы не бывают тегированными или не-тегированными, они по определению тегированные. Бывает тегированным или не-тегированным трафик. Тегированный -- это тот, в ethernet фреймах которого соответствующее поле реально содержит VID -- VLAN ID, т. е. номер влана. Не-тегированный -- соответственно, такой фрейм, где номера влана нет.

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

Порт, настроенный для приёма не-тегированного трафика, всё равно осознаёт себя в каком-то влане. Т. е. коммутатор внутри себя считает, что в этот порт ему прилетает нетегированный трафик, но этот трафик нужно относить к такому-то влану. Какому конкретно влану -- задаётся сетевым администратором при настройке и включении порта. Не-тегированный трафик может улететь в тегированный (транковый) порт, например, и в этом случае на выходе из транкового порта коммутатор в трафике явным образом проставит тег.

Может быть и обратная ситуация -- прилетит тегированный трафик в транковый порт (допустим, в 5-ом влане). Коммутатор определит, что получатель трафика находится на таком-то порту, и этот порт настроен для отправки не-тегированного трафика. Тогда коммутатор перед передачей пакета в этот порт уберёт трафик из фрейма и только потом отдаст фрейм в порт.

В транковые порты может прилетать любое количество вланов (ну, до 4096, понятное дело). В не-тегированные -- только один какой-то влан, как вы понимаете, так как тега-то в трафике нет, и единственный способ отнести этот трафик к какому-то влану -- это явным образом прописать в настройках коммутатора, что вот этот вот порт относится к такому-то влану.

Обычные компы могут принимать тегированный трафик только в случае дополнительных действий. На винде это должен поддерживать драйвер, и ещё он иметь средства управления вланами на интерфейсе. На линуксе тоже нужно создавать отдельным образом саб-интерфейсы с указанием тегов.

Что касается микрота -- добейтесь сначала связи между роутером и компом в сети 192.168.1.0, без DHCP и тем более натов.

IP 192.168.1.1 пингуется из сети 192.168.0.1 -- это понятно, так как адрес принадлежит вашему маршрутизатору. Вы можете ему на интерфейс 8.8.8.8 повесить, и он тоже будет пинговаться, даже при отсутствии интернета -- если между роутером и компом связь есть.

Service tag ставить не надо -- это уже из области Q-in-Q, вложенных вланов (если на пальцах).

Vlan1 -- какой vlad ID имеет?

Сертификату до фонаря ваши IP. Сертификат выдаётся на доменное имя.

Поставьте nginx на VDS#1, прикрутите там летсенкриптовский сертификат, и в конфиге пропишите что-нибудь в духе:

location / {
proxy_pass https://;
}

Можно делать прокси_пасс по HTTP, но тогда поднимайте шифрованный тунель между VDS-ками и проксируйте на VDS#2_tunnel_IP.

Предполагаю, что это кривые руки индусских технописателей, которые криво скопипастили кусок текста откуда-то. После подключения к консоли нажмите Enter -- некоторые железки в консоль по факту подключения ничего не отдают, надо им туда что-то отправить, и тогда выдают приглашение.

Если вам провайдер отдаёт интернет через прокси, и больше никаких вариантов -- то забудьте про любые другие схемы раздачи интернета пользователям в локалке. Убрать запрос аутентификации можно -- поставьте прокси на своей стороне, настройте его каскадом для провайдерского прокси и сделайте аутентификацию по NTLM. Тогда пользователи будут логиниться на ваш прокси с помощью тех кредсов, с которыми они в систему зашли. Например, вот методичка: wiki.525.su/doku.php?id=squid_ad Каскадов прокси там нет, но есть про настройку в связке с AD. А каскады особой проблемой не являются.

Умные люди говорят: "Если есть возможность проложить провод -- тяните провод, не надейтесь на WiFi". WiFi в рабочей сети, да ещё там, где "Большинство пользователей имеют дело с графикой и видео, объемы большие" -- это источник постоянной головной боли.

Одного сервера всегда мало. Потому что будут проблемы с его обслуживанием -- нужно будет тормозить производственный процесс, либо работать во внеурочное время. И если сервер сбойнёт, то вся работа встанет колом.

А поскольку вы упоминаете гипервизор, то с гипервизорами всё ещё хуже -- нужно минимум три сервера в кластере, для обеспечения отказоустойчивости. Если это винда, то ещё потребуется Micrisift Storage Spaces Direct для организации распределённого отказоустойчивого хранилища. Либо другие технологии, типа DataCore, vSAN, ScaleIO, Ceph -- любые распределённые софтверные системы хранения.

Насчёт выбора железок -- будет зависеть от бюджета. Брэндовое железо стоит дороже, но меньше гемора в эксплуатации, и есть вменяемая поддержка. Не-брэндовое стоит дешевле, но больше вероятность сбоев, и поддержка попроще. Из вменяемых брендов вне "большой четвёрки" могу порекомендовать STSS. Собирают сервера на платформе SuperMicro, и достаточно вменяемы по части общения. Поддержка, есть, но для разборок придётся везти железку к ним в офис.

Какой выбирать гипервизор -- также зависит от бюджета. Есть деньги -- выбирайте VMware или Hyper-V с обвязкой (vCenter или SC VMM). Нет денег -- ставьте KVM, ProxMox CE или Nutanix CE.

HelpDesk системы -- тысячи их. iTop, vsDesk, GPLI, OTRS, YouTrack (он не совсем для этого, но легко заточить).

А начинать нужно с базовых вещей -- с организации сети, электропитания на рабочих местах, выделения помещения под серверную. Качественный монтаж и планирование сети, тщательный выбор и тестирование оборудования -- избавляет впоследствии от множества проблем в процессе эксплуатации.

В идеале, вам нужно монтаж сети переделать, так как любительские свичи, валяющиеся где попало -- это постоянный источник головной боли. Завести коммутационный шкаф (если выделенного помещения по серверную нет) и протянуть от него по 2-4 провода до каждого рабочего места, всё обжать в розетки. Там, где 1-3 метра между рабочими местами -- тоже можно розетки воткнуть, так как 100% рано или поздно там образуется ещё одно рабочее место или сетевой принтер/сканер/МФУ. И все приходящие в коммутационный шкаф/стойку провода -- в патч-панель с последующим подключением в коммутаторы короткими патчкордами. Коммутаторы -- только управляемые, с вланами.

Изоляция -- только вланами. Делать это несколькими физическими портами маршрутизатора -- это трэш, так как такое решение плохо масштабируется. Закончатся порты на маршрутизаторе -- и что будете делать? Покупать ещё один? А если надо будет "вот этого и этого" сотрудников перевести в другой отдел, и как следствие -- пересадить в другую сеть? Будете перетягивать провода, так как коммутатор этой комнаты у вас в 15 влане, а новый отдел -- в 30-ом, но там нет свободных рабочих столов, поэтому пересадить сотрудников туда нельзя, а доступ в сеть нового отдела им нужен? А так -- переключил порты, к которым подключены розетки этих сотрудников, в нужный влан, настройки сети по DHCP они получили новые, и погнали.