res2001

Отдельный VLAN для принтеров - это лишний гемор себе устраиваете. Вы их сначала загоните в отдельный ВЛАН (не понятно для чего), а потом будете искать возможность обходить ограничения ВЛАНа. "КПД этих двух действий - 0" :-)
Для телефонов отдельный ВЛАН вполне оправдан.
Если уж очень хочется расплодить ВЛАНы, заведите шлюз, который будет сидеть во всех ВЛАНах и через него сможете ходить с любого места в нужный ВЛАН, после настройки маршрутизации на раб. месте.

Адрес, начинающийся на 77 - белый. Список серых адресов фиксированный, официально задокументированный в RFC и вовсе не тайна. По ссылке смотрите адреса в таблице п.3 с пометкой "Private-Use Networks".
Увидеть реально выданный адрес вы можете только на роутере, т.к. если роутер получает серый адрес, значит для выхода в инет трафик должен проходить через NAT провайдера, где адрес подменяется и в инете вы уже с белым адресом в любом случае.
Обычно роутеры поддерживают не только веб управление, но и SSH и возможно telnet. Используя их вы можете скриптом получать адрес, проверять его и если он серый, то другим скриптом ребутить роутер (или даже не ребутить, а сбрасывать соединение и устанавливать снова). То же самое можно сделать и через веб интерфейс, но формировать свои HTTP запросы и парсить HTTP ответы роутера более утомительная задача, чем вариант с ssh/telnet.

Добавлю свои пять копеек:
Мало собрать и отправить пакет. Пакет должен кто-нибудь получить на принимающей стороне. Если принимающая сторона неготова принять ваш пакет, то он будет просто отброшен.
Чтобы принять пакет на принимающей стороне должен работать "сервер" и слушать "порт". Например в вебе браузер это клиент (сторона отправляющая запросы), когда вы вводите в адресную строку браузера имя сайта, то на этот сайт отправляется запрос. Сайт в простейшем случае - это компьютер, расположенный где-то в интернете. На нем запущен веб-сервер, который принимает запросы от клиентов. Если веб-сервер остановить, то сайт перестанет отвечать на запросы даже если сам компьютер будет работать.
Команда ping не требует для своей работы сервера, т.к. функционал сервера встроен непосредственно в стек протоколов tcp/ip и система сама отвечает (если трафик pingа не блокируется фаерволом).

Не понятно, почему вы зациклились на отправке пакетов роутеру? Когда отправляете пакет, то указываете адрес назначения пакета, а протокол сам решает как конкретно будет отправлен ваш пакет. Даже если это адрес yandex.ru и вы не знаете где он фактически находится, то TCP/IP + DNS разберутся с этим сами.

Обычно роутеры поддерживают управление через web, ssh, telnet (что-то из списка может быть выключено или не поддерживаться на данной модели). Используя клиенты для этих протоколов вы можете отправлять команды роутеру. Например ssh - это удаленная командная строка, выполняться команды будут на роутере, а вы будете видеть результат выполнения. Для web клиентом может быть не только браузер, но и curl или wget или ваша собственная программа.

Для адреса сети 192.168.1.0 обычно используется маска 24 (т.е. 255.255.255.0), хотя было бы не плохо, чтоб в условии задачи была явно задана маска.
Что бы поделить эту подсеть на 20 подсетей нужно увеличить маску на несколько бит. Число 20 может быть представлено минимум 5 битами. Поэтому увеличиваем маску на 5 бит. Получаем маску 29 (24+5) (т.е. 255.255.255.248). Количество хостов в каждой из 32, поучившихся подсетей максимум 8 (но т.к. 0 и последний адрес являются широковещательными, то на самом деле их 6).
Примеры получившихся подсетей:
192.168.1.0/29 - адреса хостов: 192.168.1.0 - 192.168.1.7
192.168.1.128/29 - адреса хостов: 192.168.1.128 - 192.168.1.135
192.168.1.168/29 - адреса хостов: 192.168.1.168 - 192.168.1.175
192.168.1.248/29 - адреса хостов: 192.168.1.248 - 192.168.1.255

Подсетей получилось 32, а не 20, т.е. 12 подсетей будет не использовано. На практике обычно бывает, что есть дополнительные условия. Например некоторые из 20 подсетей имеют больше 6 хостов, но в большинстве подсетей 2-3 хоста. В этом случае можно оптимизировать деление на подсети - использовать не равномерное разделение (одна маска), а разную длину маски для разных подсетей в зависимости от дополнительных условий.

Диапазоны обоих подсетей пересекаются. Оба адреса находятся в той части диапазона, которая принадлежит обеим подсетям. Поэтому хосты друг друга видят.
Вообще маска нужна только для того, чтобы локальный стек TCP/IP мог определить куда отправлять исходящий пакет. Если хост получателя находится в той же подсети, что и локальный хост, то пакет отправляется напрямую получателю, если подсети разные, то, обычно, пакет отправляется на шлюз по умолчанию.

- Если вы вдруг захотите разработать свой собственный протокол на уровне ниже прикладного.
- Если задумаете писать пакетный сниффер
- Если захотите в приложении использовать какой-либо протокол отличный от TCP или UDP, например ICMP.

Точнее пригодится не знание самой модели OSI, а знание модели TCP/IP - это упрощенная модель OSI, которая реально используется. Но принципы передачи кадров от одного уровня к другому точно такие же, просто в модели TCP/IP отсутствуют некоторые уровни OSI, точнее они совмещены с соседними уровнями.

У вас уже и так все объединено в локальную сеть. Например вы спокойно можете настроить сетевой доступ к ресурсам компа по сети средствами ОС и использовать их с другого компа (например дисковые шары или общий сетевой принтер). Правда из интернета доступа не будет, но внутри сети - пожалуйста.
Для чего-то другого нужно установить соответствующее ПО.

Из вашего вопроса не ясно, что вы понимаете под "показывало текущий проект" - где показывать, в каком виде, какое ПО хотите использовать для просмотра проекта, что представляет собой проект и т.п.?

Поднимите второй DHCP во втором офисе, раздавайте на нем адреса из той же подсети, сделайте не пересекающиеся диапазоны на обоих DHCP. Второй DHCP пусть так же выдает и другой шлюз для своих клиентов.
Т.к. второй DHCP находится ближе к своим клиентам, то он и будет первым на отвечать на их запросы. Хотя, конечно, есть шанс, что ответит и первый.
Можно на микротиках в фаерволе заблокировать прохождение DHCP трафика в удаленную сеть, тогда точно не будет путаницы. С другой стороны, можно рассматривать DHCP другого офиса как резервный.

И FTP и POP3, а так же SMTP, IMAP и многие другие являются текстовыми протоколами, там так же можно определить протокол по содержимому пакета.
В двоичных протоколах такой метод то же может работать, только анализировать нужно уже двоичную информацию, а не текстовую.
В любом случае для анализа нужно знать сам протокол хоть текстовый, хоть двоичный.
Но, конечно, не все так можно определить. Например, если любой из протоколов спрятан за SSL, то снаружи вы увидите шифрованный трафик, а что внутри без расшифровки понять уже не возможно.

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

Судя по тому, что указываете номера портов, обмен с весами идет по Ethernet.
Соответственно могут быть типичные проблемы с сетью.
Для теста запустите пинг на весы, посмотрите есть ли потери пакетов, какое время ответа.
Если есть потери, то нужно проверять весь путь от весов до компа: кабели, розетки, разъемы, маршрутизаторы.
Хорошо бы, чтоб проверкой сети занялся специалист по сети.

Проверьте версию драйвера, сравните ее с той, что стоит на работающей машине.
Если весы разные, то проверьте версию прошивки весов.

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

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

3.Если узлы в интернете, куда ходят 5 пользователей все разные, то можно разрулить таблицей маршрутизации, отправляя трафик на конкретный узел через конкретный микротик.

Два шлюза по умолчанию с разными метриками на клиентах.

PS: Было бы интереснее в вашем случае замутить балансировку каналов с обеспечением отказоустойчивости. Это уже более сложный вопрос - либо покупать железку, которая это умеет; либо самому разбираться с вопросом.

Что делаете, что бы восстановить гигабит?

Проблемы могут быть на любом участке между компом и свичем:
1. дохнет или глючит свич/порт в свиче;
2. сетевой адаптер компа (но вы уже меняли на другой, так что это видимо не оно)
3. плохой контакт в одном из патчкордов, разъемов, розеток
4. кривые драйвера сетевого адаптера.

Что можно предпринять:
1.Найдите свежие драйвера для сетевого адаптера и переустановите
2.Замените патчкорды, которые сможете.
3.Переткните в другой порт на свиче, а лучше - в другой свич.
4. Для подключения компа используйте другую розетку

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

Найдите в сети книгу: У.Р. Ственс. Unix. Разработка сетевых приложений.
Одна из лучших книг по теме, хоть уже и старовата.
Не смотря на то что там UNIX, но подход один и тот же практически для всех ОС.