lubezniy

Посмотрел на схему.
Если малинки из разных подсетей не пингуют друг дружку, то нужно сперва настроить маршрутизацию. Как вариант, на главном роутере (который интернетовский) прописать по статическому маршруту в каждую подсеть. В каждом маршруте указываются IP-пространство сети (например, для маски подсети 255.255.255.0 это могут быть 192.168.0.0, 192.168.1.0, 192.168.2.0 и т. д.), маска подсети и в качестве шлюза IP-адрес роутера (в роутерной сети), на котором висит описываемая подсеть. NAT на роутерах, кроме главного, должен быть выключен.
После того, как обеспечена "видимость" малинок между собой, их также будет видеть и управляющая машина, и можно приступать к решению основной задачи. Здесь уже возможно огромное множество разных вариантов. Например, малинки периодически сами стучатся на управляющий web-сервер, куда каким-то образом кладутся команды, которые надо выполнить, берут эти команды и выполняют. Или управляющая машина по очереди пинает каждую малинку и говорит, что ей нужно сделать. Если речь только о воспроизведении видео, я бы, пожалуй, попытался поставить в сеть маленький сервер раздачи видеопотока и настроить на автозагрузку малинок подключение к этому серверу (например, браузером) и показ того, что он выдаёт.

Сначала нужно точно знать, где именно будет находиться офисное оборудование (рабочие места, оргтехника, камеры, телефоны и т. д). Дальше можно продумывать вопросы внутренних коммуникаций в деталях; в идеале все точки подключения к сети в здании нужно выводить в одно помещение, в котором размещается коммутационное (и, возможно, серверное) оборудование, но для больших зданий так не получится, ибо банально не хватит лимита длины витой пары в 100м от абонента до коммутатора; приходится использовать несколько помещений или вешать шкафы со свитчами в коридорах. Разумеется, точки присутствия оборудования сети и серверов потребуется обеспечить достаточным электропитанием и при необходимости охлаждением. А дальше уже в зависимости от количества приходящих кабелей в том или ином помещении можно выбирать коммутационное оборудование, составлять схему его подключения и заниматься реализацией. По возможности стоит не разводить зоопарк из разных типов, чтобы потом было проще администрировать.
Также, если речь о нескольких зданиях, нужно сразу продумать возможности по их соединению в общую сеть.
По серверным - их по возможности стоит размещать в разных зданиях и соединять прямыми каналами связи. ПО расставлять на них так, чтобы сервер в одном здании резервировал "коллегу" в другом.
Дальше. Одному поднять большую сеть не получится; слишком много ручной работы по монтажу, соединению и настройкам. Нужно подключать коллег-помощников.
По серверам - сначала определитесь с ПО под задачи всех отделов Вашей компании. Потом уже прикинете распределение программ по серверам с учётом вышеописанного и сможете понять, сколько серверов нужно и для чего, где каждый из них будет находиться, сколько туда нужно электричества и охлаждения.
Для чего-либо более конкретного данных недостаточно. По мере составления (и далее реализации) проекта будут появляться конкретные вопросы, которые уже будете решать.

Проблемы могут возникнуть, если карты с одинаковыми MAC-адресами находятся в одном сегменте сети (не ограждены друг от друга маршрутизатором). На L2 будут коллизии по ARP, и свитч вряд ли сможет правильно понять, на какой порт отсылать трафик для конкретного mac-адреса. Ну и, в частности, по dhcp будут проблемы (одному маку выделится один IP-адрес).

Есть вариант.
1. Придумывается третья подсеть, в которую соединяются роутеры портами WAN (каждому, естественно, нужно назначить свой IP).
2. На обоих роутерах отключается NAT;
3. На каждом роутере добавляется статический маршрут для чужой подсети; в качестве шлюза указывается IP-адрес соответствующего роутера в третьей подсети;
4. Хождение пакетов проверяется с помощью tracert/traceroute.

Я бы выделил виртуалку с nginx-ом, на которую через firewall пробросил 443 порт с внешнего IP. На nginx делаем wildcard-сертификат от Let's Encrypt и настраиваем в его конфигах виртуальные хосты с приёмом ssl по этому сертификату и проксированием на заданные машины - может быть, даже по http.

По-видимому, Ваш роутер должен самостоятельно обрабатывать запросы из локалки на второй IP, а не роутить их на шлюз по умолчанию. Проверить, так ли это, можно с помощью traceroute из локальной сети на второй IP-адрес. А дальше смотреть уже на маршруты.

Просто начните работать. Изучать вопрос будете по ходу дела, шишек набьёте, фидбэк получите, зато и научитесь, и проект будет живой.

Проверять состояние подключения и настройки. А заодно, например, состояние работы службы DNS-клиент.

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

Технически способов подключиться к соседу полно — или витуху кинуть, или по Wi-Fi. Но провайдер, наиболее вероятно, не позволит так сделать. Основная причина — невозможность в должной степени контролировать работоспособность и ремонтировать/менять оборудование и кабели на территории, на которую монтажников могут просто не пустить (мол, у нас всё работает, идите лесом). Самодеятельность в этом вопросе также не приветствуется: стандартно по условиям договора абоненту запрещается предоставлять доступ к услуге третьим лицам.

В Alt и ASP используется запись в /etc/sysconfig/iptables; восстановление по дефолту прописано при подъёме службы network.

Не в тему, но в таких конторах руководство самостоятельно электронную почту читает крайне редко — на всё есть секретари, отсеивающие всевозможные деловые предложения на раз. Для предметного разговора есть смысл искать подходы к вышестоящему руководству.

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

Проверьте системные настройки прокси-сервера. Посмотрите, не блокирует ли какой-то файрволл 80 порт (можно проверить из командной строки — telnet mail.ru 80). Проверьтесь таки на вирусы (одного avz не всегда достаточно).

Возможно, решить проблему Вам поможет DynDNS. Но это строго при условии, если все входящие соединения на 83.149.8.x пробрасываются провайдером на Ваш IP.

Powerline не рассматривали?