rionnagel

Вы что хотите в итоге? 1 ip адрес и если идёте на jopa.ru - то попадаете туда, а на jora.ru - сюда? Тогда вам надо гуглить virtual hosting. Это Вы можете сделать с использованием реверс прокси на nginx например (apache, haproxy и так далее).

Хосты, которые вы хотите засунуть в разные вланы перемешаны между свитчами или нет? Если нет, то использование вланов принципиально? Свитчи у вас управляемые или нет? Вы просто написали в 2х разных комментариях противоположное. Vlan это управление фрэймами, т.е. L2.

Да разберите разетку и посмотрите порядок цветов, это не сложно.

Это гадание на кофейной гуще. Я конечно ловил плохо обжатый коннектор по признакам tx есть, rx нет, а тестор показывает, что всё ок... но лучше так не делать. Хотя бы дешый лан тестор, который стоит как пару пачек сигарет, либо свой скрутить - это уже гораздо лучше, чем гадание по косвенным признакам. Время своего больше потратите больше по деньгам в итоге, особенно если кабель и прочие расходники паршивого качества.
По хорошему зависит от проекта... если это мальнький офис и требований мало - купите дешевый тестор, как расходник. Если чёт побольше - хотяб пару сотен долларов потратьте на повышение надежности.

BGP

Для создания дополнительного периметра это раз. Целей и реализаций может быть масса, не думаю, что тут обязательно приводить кейс.
Для "моногамности" оборудования это два. Предположим у вас колокейнш стоек в разных датацентрах и несколько виртуальных инфраструктур. Вам надо поднять bgp между этим всем и построить звездой связь gre туннелями через ipsec. Ни один вменяемый специалист не сможет гарантировать работоспособность в среде зоопарка, когда можно внезапно ловить ад по mtu, по размерам tcp окна, частыми флапами туннелей и прочего, что может появиться после обновления прошивки того или иного устройства разных вендоров.

vpn ipsec тунель например
также можно поругаться с провайдером

Базу и популярные утилиты как минимум и сетевые инструменты. Да, в случае чего на какой-нибудь gaia os вам придется тюнить tcp/ip стэк и пересобирать ядро с нужными параметрами. Тюнить стэк вам и на винде придётся ключами реестра. Определять в чём затык, как бороться с tcp перегрузками на разных этапах. Иметь представление обо всём надо, не обязательно слишком детализированно, вам не обязательно знать принципиальные отличия zfs от xfs, но что такое айноды знать надо.

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

Вдруг от линукса вам надо будет только умение поднимать strong swan и iperf'ом скорость мерять хз.

Сначала определиться с бюджетом, временем и что у вас есть, прикинуть возможные риски.
Я бы начал с того, что поднял hyper-v (как я понял лицензия у вас есть), одна лицензия это хост + 2 виртуалки, сделал бы план бэкапов и восстоновлений. Поднял бы active directory, посоздовал бы учётки и ввел бы это всю хрень в домен. Из трат - ваше время, время специалистов, пока вы им настраиваете учётки из AD. Если это возможно операционки ставьте новые. Под серверную крайне желательно выделить отдельное помещение с 1-2 кондиционерами и хотя бы ибп, не говорю уже про резервную линию питания.
С сетью очевидно прямых трат больше. Надо прикинуть возможно ли поставить всё в одну коммутационную стойку, или надо несколько стоек по предприятию. Считаем траты на кабель, коммутациюнные шкафы, сколько метров до самых удаленных точек, разетки, маркировка, кабель-каналы и прочий строительный храм + время простоя во время ременота + пространство (КРАЙНЕ ЖЕЛАТЕЛЬНО ЗАКРЫТОЕ, та же серверная) в котором всё это будет находиться. Обсудить с начальством целесообразно ли покупать управляемые свитчи (с тем же storm control и прочими протоколами), либо конторка без проблем денек подождёт, пока вы будете носится как угарелый искать какой такой нехороший сотрудник решил подключить неподключенный кабель в разетку и куда именно, денек до этого выясняя, что это всё-таки именно broadcast storm. Схему рисовать обязательно. Всё должно быть понятно и подписано. В качестве шлюза микротик более, чем норм. И РАЗУМЕЕТСЯ вы на каждую комнату закладываете больше разеток, чем там находится пользователей процентов на 20-80 в зависимости от ситуации.
В описанном не вижу необходимости нарезать vlan'ы и как-то сегментировать сеть, но возможно вы что-то не договариваете, либо я недооцениваю. Разве, видеокамеры в отдельную подсеть и отдельный vlan (хотя и второе не обязательно в зависимости от схемы подключения).
Для принтетов можно подумать принт-сервер. Для удаленки pptp сервер на микротике.

Если вы хотите там как-то резать доступ по отделам, делать несколько ad, сегментировать сеть и т.д. это уже другой вопрос.

Это я так, сходу прикинул. Вообще всё зависит от финансирования.

Прокси... а вообще можно по разному... например pfsense, mikrotik, kerio control, административный приказ.
В ситуации, если это обычные работники сделаете только хуже для себя.

Экономия на семечках... На 500 пк есть деньги, на контроллер домена нет? Вы объясните начальству, что чтобы это всё поддерживать нужно нанять больше людей. А что дешевле? Каждый месяц платить специалисту (может даже не одному), который будет заниматься мартышкиным трудом и бегать по всем пк или автоматизировать, поставить сервера для ad, sccm и прочее?

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

Я бы предпочел раздавать локальные адреса машинкам и использовать виртуальный роутер, чтобы открывать на нужных внешних адресах нужные порты машинок. Как-то голой попой виртуалок светить в мир такое-себе, как и потом траблшутить.
Что вы имеете в виду под выделенным сервером? Колокейшн? Своя стойка? Голое железа арендуете и сами его настраиваете или что?

От взлома защититься нельзя. Можно только снизить риски. Безопасность можно грейдить бесконечно, вплоть до изолированного острова с пулеметчиками по периметру и оружием массового поражения. Затраты на безопасность не должны превышать ценность защищаемого.
Надо разобраться что защищаем и каков бюджет. Может проще будет не иметь вообще защищаемых данных и/или не пользоваться ничем сложнее микроволновки? Или подойдет отдельный комп без подключения к интернету и сети с зашифрованной файловой системой?

У динамических правил fasttrack есть такая штука, что даже если вы отключили правила firewall, которые fasttrack включают, то они никуда не пропадут, пока вы не перезагрузите роутер.

Найдите работу получше. Увольняйтесь. Я без шуток и без издевок. На этом месте вы ничего не узнаете и ничего интересного делать не будите. Я исхожу из описанной вами цели "А так хочется набраться опыта".

Zabbix, elk stack + elastiflow, PRTG Network Monitor, netflow analizer и прочее, что умеет жрать netflow. Так вы увидите с какого ip на какой человек лезет. Но вы же понимаете, что с коробки ничего вам не покажет, что человек сидит на youtube, а не гуглит (это можно определить лишь по косвенным признакам и неоднозначно), особенно если адреса принадлежат одной компании. Если заголовок зашифрован - вам надо mitm фигачить, сертификаты всем подменять, возможно покупать весьма дорогое ПО, а в некоторых случаях и железки и пр. Сейчас не 2000 года, когда трафик был преимущественно http и можно было без проблем видеть заголовки через прокси.
Если бюджетом не располагаете, то лучше эту идею не реализовывать. А то придёте к тому, что везде надо будет ставить kerio control, покупать лицензии, подменять сертификаты и переворачивать сетевую инфраструктуру так, чтобы потратить меньше денег. Это потянет более жосткие проблемы за собой и на поддержание этого придётся нанимать специалиста.

Да простят меня все мыслимые и немыслимые специалисты... Но вашу задачу решает вполне себе тот же Kerio Control из коробки с красивыми отчетами и графиками... только денег стоит.

Про стрельбу из пушки по мухам можно упомянуть ELK stack, который жрёт логи... например сквида.

По вашей изначальной проблеме, либо порт не открыт, либо сервис не установлен, либо висит на другом порту, либо ещё что, не знаю -v покажет или нет, как вариант можете wireshark'ом посмотреть содержание почему именно connection refused. По проблеме которой вы поделились в комментариях - не указан алгоритм ключа в конфиге.
Попробуйте ssh -v юзер@сервер и напишите вывод.