Маскардинг не работает в вашем случае. Добавляйте явное правило SNAT для таких пакетов.
В общем, всё выглядит примерно так.
1. LAN client -> Mikrotik, 192.168.0.100:4555 -> 1.2.3.4:87 (на роутере у этого пакета будет in-interface ether2, так как пакет действительно прилетел из локальной сети) - если в правиле указано сопоставление пакета по входящему интерфейсу для dst-nat (логичнее предположить, что он у вас указан как ether1), то никакого перенаправления не будет. Либо заводите два правила, либо не проверяете для перенаправляемых пакетов входящий интерфейс, а только адрес назначения, протокол и порт. Двигаемся дальше.

2. Mikrotik -> LAN server, 192.168.0.100:4555 -> 192.168.0.2:87 (output-interface ether2) - Победили перенаправление и пакеты теперь успешно улетают в локалку после замены адреса назначения (в том-то и суть dst-nat). Но что будет дальше? Локальный сервак получает перенаправленный через роутер пакет и отвечает на него напрямую в обход роутера.

3. LAN server -> LAN client, 192.168.0.2:87 -> 192.168.0.100:4555 - Это ответный пакет от сервера. Но клиент ожидает пакеты с адресом источника 1.2.3.4, а не эти, и отбрасывает их. Либо молча, либо явно с посылкой ICMP-сообщения.

Вот такие дела. Отсюда решение. Правила ната на микротике.
1. Правило для проброса портов из интернета:

chain = nat/prerouting,
  input-interface = ether1, 
  dst-ip = 1.2.3.4, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

2. Правило для проброса портов из локалки:

chain = nat/prerouting
  input-interface = ether2, 
  dst-ip 1.2.3.4, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

3. Правило для source-nat, чтобы ответные пакеты сервера так же пошли через роутер:

chain = nat/postrouting,
  output-interface = ether2, 
  dst-ip = 192.168.0.2, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = src-nat, 
  src-nat-address = 192.168.0.1

Вот как-то так. Можно, кстати, пакеты из локалки в локалку метить в цепочке FORWARD и уже на основе метки делать src-nat.

1. eth0:1 — это не виртуальный интерфейс, а всего лишь алиас, он не может иметь отдельную дисциплину очереди.
2. tc подойдёт. На весь интерфейс (eth0) вешается дисциплина и создаётся два дочерних класса — один с ограничением скорости, второй — на всю ширину. В класс с ограничением скорости направлять все пакеты с заданным адресом отправителя (это как раз и будет ip-адрес на eth0:1). За подробностями рекомендую обратиться к lartc.

Собственно, рекомендую Scheme в комплекте с книгой «Structure and Interpretation of Computer Programs» (Структура и Интерпретация Компьютерных Программ aka SICP) за авторством Харольда Абельсона и сотоварищей. Если читать внимательно и выполнять хотя бы часть заданий, то очень неплохо освоить можно функциональное программирование, и на изучение функциональных языков уйдёт на порядок меньше времени. Если хочется более актуального языка, то Haskell или Erlang.

1. Для того, чтобы можно было с помощью iptables фильтровать трафик, проходящий транзитом через мост необходимо выставить следующие системные переменные sysctl:

net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

2. После того как установите переменные sysctl, можно использовать для этого iptables, используя сопоставление (match) -m physdev --physdev-in / --physdev-out
3. См. предыдущий ответ.
Как-то так.