nApoBo3

У microsoft есть программа для использования одной клавиатуры и мыши с несколькими ПК. Если компьютеры стоят рядом это вполне вариант. Она так же реализует нужный вам функционал общего буфера обмена.
https://www.microsoft.com/en-us/download/details.a...

Версионость api. Обеспечивается может разными методами. Если старое api будет поддерживаться не ограниченное время, а анализ должен быть сквозным, то данные на слое ниже нужно сводить в один формат.

Qos. Тема обширная с не слишком простая. Начните с теории, на habr есть вполне неплохие статьи на этот счёт. Если не хотите изучать лучше обратитесь к оутсорсерам, тема qos с наскока без понимания процесса не решается.

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

Значит маскарадинг настроен не корректно.
Используете srcnat вместо mascarade.

Вероятно вы не корректно настроили local forwarding и data path. Возможно не до конца разобрались в смысле этих настроек.
Если укрупнено, трафиком беспроводного клиента может управлять или сама точка( local forwarding ) или контроллер( data path ).

Плюс, иногда бывает, что на точке не корректно собран bridge.
Если сложно разобраться, лучше сбросить точку без сохранения конфигурации и перенастроить.

Собственно говоря изоляция зависимостей одна из причин упаковки приложений в образ.
Если вам это мешает, значит просто вам не следует использовать докер.

Azure AD. Там есть все необходимые мануалы. Но надо понимать, что это не совсем тоже самое, что локальный AD.

В сетях есть только пакет, на l2 пакет идёт от одного мака к другому, на l3 от одного ip к другому. Нарисуйте для своего случая где и как происходит инкапсуляция пакетов в упрощенном виде и все встанет на свои места. Т.е. вот есть компьютер он отправляет пакет на микротик, и расписать что будет с этим пакетом далее и какие где будут адреса.

Проц слабый, памяти мало. 14FHD только с хорошим зрением.
Но если нет более мощных вариантов, то работать возможно, в принципе даже вполне комфортно.
Желательно все же ram нарастить до 16гб.

Для начала поменять стэк. Go + php это не тот стэк который легко продать на региональном рынке.
Подумайте где данные языки массово востребованы на данный момент в Ярославле? Думаю практически нигде.
Рынок под ваш стэк в вашем городе маленький.

Другой вариант переезд. Но стэк в любом случае сильно ослабит ваши конкурентные возможности. Про go модно писать, но объем работы на рынке для него не сравним с той же java.

У вас какая-то каша. Если вы хотите объеденить их l2 туннелем( тоннель в бридж ), то у вас не две подсети, а одна географически распределённая.
Если же у вас реально две одинаковые подсети, то ваша идея корректна. В каждой подсети вы маскирует( подменяет ) другу сеть, меняя в ней адреса, подставляя вместо нее виртуальную сеть, маршрутизируете эту сеть на другой роутер и там делаете обратное преобразование. Сделать это надо на двух концах туннеля, поскольку иначе у вас не будут проходить ответы.

Использовать промежуточную модель. Из нее генерировать локальные объекты.

Для wifi 2.4 в многоквартирном доме вполне нормальная скорость. По поводу от это железки вы тоже 500мбит не получите, он столько не прокачает.

Я бы предположил или петлю( но поскольку по mak доступен, то это не она ) или конфликт адресов.
Попробуйте следующее:
1. Повесить еще один адрес в другой сети на тот же интерфейс и проверить доступность по данному адресу в тот момент когда возникают проблемы.
2. Повесить еще один адрес в другой сети на другой интерфейс и проверить доступность по данному адресу в тот момент когда возникают проблемы.
3. В момент возникновения проблем снять дамп на mikrotik и на рабочей станции. Вообще в любых непонятных ситуациях с сеть снимай дамп, там можно много чего интересного найти.

Вы можете загружать адресную книгу любым удобным вам способом. Эмулировать МФУ в данном случае бессмысленно, поскольку у каждого вендора на подобную настройку свой специфичный взгляд.

Настроить spf и dkim, это будет достаточно чтобы такие письма на "приличных" почтовых серверах попадали как минимум в спам, а возможно вообще не принимались.
При жалобах от ваших клиентов рекомендовать им использовать указанные технологии.