Клёвый Админ

Это тоже самое что и ethernet, только без карточных игр и барышень. Основная фишка -это гарантия выделения полосы (по моим знаниям - это очень напоминает организацию SAN на FC).

А коммутатор (если имеется в виду железка) - это свич, с поддержкой этого протокола l2.

если микротик в обоих сетях шлюз по-умолчанию, то достаточно просто не запрещать такой трафик и сделать маршруты доступными для ПК обоих сетей (это исходя из того что у вас есть таблицы маршрутизации или VRF, по умолчанию этого делать не требуется).

Ээммм, прописываем на интерфейсе (пусть зовётся vlan1) адреса и всё. Пакеты отправленные из сети на другом интерфейсе (пусть зовётся Ether4) будут смаршрутизированы в нужные сети.

NAT, DNAT. Проброс портов, port-triggering, port-forward или как там это в вашей железке называется.

Поставьте перед ним nginx в proxy режиме и всё. У последнего иммунитет (в целом) от такого.

Вообще если туннель действительно l2 то, по логике, нужно создавать VLAN на бриджах. Тогда внутри этого единого l2 будут ходить кадры с тегами. Но учитывая все перепетии с crs и транками внутри локальной сети - затруднаюсь ответить конкретнее что и как нужно настроить.

А как вы эти потери пакетов детектируете? Какие симптомы?
Если общение между двумя ПК идёт внутри сети, то действует два правила:
1. Они не используют роутер, а значит Router ОС у вас не при чём.
2. Если вы используете RB как свич, то трафик идёт через свич чип, который работает на скорости сети, и для этой модели его пропускная способность примерно 479 мегабит для размера пакета 512. Потеря будет только при нагрузке выше это (или другим патерном).

Как настроена среда передачи данных на клиенте и интерфейсах МК? Дуплекс, скорость, чётность, MTU?

О боже. Мысли у вас. Ну. В общем. нужно же. И ещё уметь излагать. И что бы понять. А да и понять же ещё нужно что написано.

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

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

Если же у вас за туннелем ещё один маршрутизатор и лишь за ним доступен целевой сервер - то необходимо создать ещё один NAT по аналогии с первым.

Как как? Порассуждать, понять что PPTP это у нас L3 туннель, а значит сделать единый L2 домен с его помощью нельзя, а значит нужно построить EoIP туннель поверх существующего соединения и включить этот EoIP туннель в бриджи с локальной сетью с обоих сторон.

Но немой вопрос "нахрена?" всё же остаётся в воздухе...

Что значит "по верх него строится ospf"? OSPF он как бы не строится, он включается на интерфейсе, смотрящем (в некоторых случаях) на точно такой же маршрутизатор с включенным на аналогичном интерфейсе OSPF. Если коннекта нет, то либо нам знать о вашем OSPF не зачем, либо у вас там всё так хитро, что без конфигов не разобраться.

Давайте начнём с простого:
Файрволы, маршруты, правила в манглах обоих сторон.

Покажите логи, настройки, опустите\поднимите версию до 6.25 (после этой версии у них есть баг, возможно приводящий к таким сиптомам)

PfSense

Маркировка нужного трафика и отправление его в отдельную таблицу маршрутизации - это если тонко. Или одно правило маршрутизации - это если грубо.

Такс, если рассматривать практическую сторону, то:
1. У вас обязательно грамотно построена сеть, с разнесением всё на отдельные сегменты и делением на уровень доступа и ядро. Это могут быть как простые гигабитные свичи, так и что-то более серьёзное (отдельно l2 коммутаторы, ядро - на l3) решение. Все вайфай сети отдельно, телефония отдельно. Несколько провайдеров с автопереключением. Между офисами (если их несколько) туннели с IPSec и OSPF, ведь у вас обязательно по два канала в каждом удалённом офисе. Внутри локальных сетей у вас обязательно протокол семейства stp следит за петлями и сходимостью, и нигде нигде нет простых "мыльных" коробок аля дес1004 или что там сейчас помоешного выпускает длинк? Вся коммутация сделана заранее и ве имеющиеся порты заранее обспечены линком и вся сеть, что самое главное, к такому повороту готова.

2. Хранение. У вас обязательно разнесено хранение данных от вычислительной обработки. Хотя бы на уровне абстракции (хотя в идеале - физически это разное железо). Хранение рассчитано на текущую нагрузку плюс резерв на момент наращивания мощностей (грубо говоря пока едут дополнительные диски - вы не упали под нагрузкой если вдруг припёрло). Доступы у вас через отдельные ip сети или через fc san (имхо, в данный момени это очень рядом). СХД умеет делать снепшоты и тонко выделять ресурсы. Так же она умеет а\синхронно реплицироваться (и у вас есть куда). Хранилка имеет +1 питание, +1 диск каждого типа и +1 голову контроллера. А так же +1 линк до вычислителей.

3. Вычисление. У вас есть отдельные одинаковые железки на которых благодаря виртуализации вы развернули ферму вычислителей для основной ИС, а так же крутите всё ваше многообразие почтовых серверов и контроллеров домена. (кто-то скажет что КД в идеале крутить физически, возможно). Сервера рассчитаны с запасом минимум 1 штука, чтобы можно было смело смигрировать виртуалки и опустить его в мейнтейм.

Про софт тоже могу накидать если нужно.