nApoBo3

Первое, wifi на mikrotik так себе, много проблем, сложная настройка, посредственная скорость. Второе, там есть проблемы с работой одновременно старых и новых устройств. Если в качестве головы берете ax, то и точки лучше брать ax, или изучайте документацию по совместимости пакетов.

Бывают кривые железки которые работают только в пределах одной подсети или l2 домена. Победить можно двойным nat, т.е. одновременно поменяем и адрес назначения и адрес источника.

Трафик между vlan идет по третьему уровню, настройте маршрутизацию и фаервол и все будет работать.

Плюс два момента:
Насколько я помню, в tagged нужно еще и сам birdge добавлять, вроде раньше так было, может быть поправили, но я не уверен.
Не понятно зачем у вас у каждого ПК два ip интерфейса ip: 10.30.0.20/24, ip vlan: 10.30.0.22/24. При этом оба они в одной подсети, в таком сценарии нужно будет руками много чего прописывать.

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

Это зависит то настройки bonding.
https://wiki.mikrotik.com/wiki/Manual:Interface/Bonding
Базовый вариант 802.3ad
"LACP balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. "

Для корректной настройки вам бы почитать немного как этот самый bonding работает, там все не совсем так же как просто обычный интерфейс, устройства в каждый момент времени должны выбрать какой порт использовать.

1. Оптика. Этот же вариант правильный. В данном варианте у вас здания гальванически развязаны.
2. Poe удлинитель, например от mikrotik, у них есть уличный, штука компактная и удобная.

На mikrotik это можно сделать, через маркировку трафика и маршрутизацию по меткам. Но сама идея достаточно странная.

Если вы vlan настраиваете на bridge, вам надо в настройки моста настроить target и untarget порты.

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

Например gns3.

Я в таких "непонятных" случаях начинаю с проверки счётчиков ошибок на портах коммутатора. Если там все ок. Проверяю dns. Если и тут проблем нет. Запускаю несколько параллельных пингов, изнутри, до маршрутизатора, если есть возможность до ещё одного устройства в сети, до шлюза за маршрутизатором, до крупного публичного ресурса, и аналогично снаружи, до маршрутизатора, до коммутатора.
Чаще всего этого достаточно, чтобы понять где именно находится проблема.
Можно даже готовые скрипты для этого написать, которые логи в удобном виде в файл положат.

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

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

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

Если HP J9449 умеет снимите дамп( если не умеет, поставьте в разрез что-нибудь, что умеет ). Посмотрите приходят ли на него icmp запросы и уходят ли ответы.

Первое, нет такого жутко пинговать.
Второе, от mtu может напрямую зависеть потеря пакетов.
Третье базовый размер "ping" пакета очень маленький и на пакетах такого размера потеря может не выявляется, особенно это характерно для радио сред.
Четвертое, некоторые приложения это настолько не точное определение, что оно не позволяет делать хоть какие-то выводы, может у вас просто cpu загрузка уходит в 100%.
Пятое, потеря пакетов до разных узлов может быть разной.

Попробуйте в момент возникновения сетевых проблем использовать ping с пакетами большего размера, если это вообще сетевые проблемы, из вашего описания это не следует.

Есть ещё один вариант на некоторых коммутаторах, mac based vlan.

Должны через роутер. Коммутатор по идее не должен анализировать l3 пакет, если l2 пакет предназначен не ему, но конечно зависит от того как этот самый коммутатор настроен.

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