RomanKu

Не знаком с этими системами, но общие правила следующие

1. На 10.0.0.10/24 прописываем статический маршрут подсети 192.168.10.254/24 через шлюз 10.110.0.2
   
2. На 192.168.10.254/24 прописываем статический маршрут подсети 10.0.0.10/24 через шлюз 10.110.0.1 - вот тут у вас, скорее всего проблема, т.к. комп с IP 192.168.10.10 при попытке достучаться на 10.0.0.200 пойдет в дефолтный роутер 192.168.10.1 а он ничего не знает по соседнюю сеть, соответственно, надо на роутере 192168.10.1 для сети 10.0 и 10.100 прописать next-hoop в лице 192.168.10.254, в теории, можно на роутере 192.168.10.1 в dhcp прописать отдачу статических маршрутов, у меня дома это нормально работает.
   
3. Отключить везде маскарадинг и оставить только маршрутизацию (на 10.0.0.10 и 192.168.0.254)
   
4. На фаерволах открыть правило forward = allow для того, чтобы ходил трафик между сетями (на 10.0.0.10 и 192.168.0.254)
   

У вас проходит Трассировка из сети OpenWRT это не из сети 192.168.0.0/24 а с самого OpenWRT устройстава 192.168.10.254?

• Если да, то это работает потому, что пинг идет не из сети 192.168, а из сети 10.100, соответственно, роутер знает, что сеть 10.0.0.0/24 доступна через 10.100.0.1 и отправляет туда пакет, с адреса 10.100.0.2, хост 10.0.0.200 получает пакет и отвечает на адрес 10.100.0.2, но он его или отправлять опять на свой дефолтный роутер 10.0.0.1, что неправильно, или же у вас дефолтным является 10.0.0.10 и тогда работает, но я встречался с ситуацией, когда даже при дефолтном 10.0.0.1 хост 10.0.0.200 прописывал у себя маршрут в сеть 10.110.0.0/24 через 10.0.0.10
  В Linux можно посмотреть командой `ip route`
  
• Если нет, то все равно смотреть маршруты
  

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

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

1. На хосте в сети прописать что-то типа route add -net 10.0.0.0/24 gw 192.168.10.254 - это самое простое, что можно сделать для того, чтобы убедиться, что это работает
   
2. На роутере 192.168.0.1 в маршрутизацию 10.0.0.0/24 через next-hoop 192.168.10.254
   
3. На роутере в для dhcp сервера добавить опции 121 и 249 с зашитым маршрутом
   

Еще в UPD и UPD2 у Вас Одинаковый target, что странно

Если оставить схему с 2 микротиками (допустим, так надо), то на 1 надо включить маскарадинг на 2, т.е. вместо маршрутизации настроить NAT по аналогии тем, как это сделано на 2 роутере. В итоге 1 роутер будет знать кто и куда ходит, а на второй роутер будет уходить только один адрес 1 роутера. https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT

Если необходимо полностью скрыть присутствие узлов 192.168.88.100, то надо исправить ttl в пакетах.

/ip firewall mangle add action=change-ttl chain=prerouting new-ttl=increment:1 passthrough=yes

Был опыт хостинга сайтов на этом типе инстанса. По памяти и скорости связка nginx+php-fpm показала себя лучше да и сейчас не вижу смысла начинать проект с апачем. БД будет тесно по оперативке и она будет периодически выдавать фризы, связанные с работой с диском.
Опять же из опыта на t2-micro прикручивание CloudFlare дает ощутимое снижение нагрузки на сервер за счет кеширования статики и, соответственно, снижения количества запросов на сервер.

Подозреваю, что следующее поможет решить Вашу проблему

/interface l2tp-server server set caller-id-type=number

UPD
Должно было помочь в теории, но на практике все равно не работает.