Клёвый Админ

Берите VPS в США и подключайтесь к нему VPN.

Единственный вариант завернуть весь исходящий от микротика в ВПН (так как трафик от прокси отдельно не маркируется в текущем релизе). Т.е. в мангле вешаем правила на output и маркируем трафик, потом навешиваем route mark.

Если я смог в вашу математику, то вроде получается в среднем 90 мегабит в секунду (хотя может я не смог, не потел за точность). Девайс, что вы выбрали, может от 200 до 900 мегабит (при пакете 512).

Проц там довольно хороший, на ваши 30 коннектов он точно подходит. Если это будет не лютый 256 битный IPSec то он справится легко (вангую 30% загрузку CPU в среднем), в противном случае он будет нагружен изрядно.

В общем, если не параноить за криптографию и шифрование - прибудет сила с вами.

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

Я не уверен на 100%, но есть ощущение, что IPSec не переживёт двойной нат.

Если адреса везде белые и статические - то на микротиках поднимите туннели GRE и настроите всё по моему гайду:
www.youtube.com/watch?v=XSu5WfDeyiA
(затем только IPsec нужно будет досыпать)

Если адреса серые\динамические (или etc извращения из разряда "Мой провайдер долб*ёб") - то на головном узле поднимите PPP сервер (с понравившимся протоколом работы) и линки к нему от филиалов. Маршруты - адреса - настройки, всё остальное - опять же по гайду выше.

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

Объеденяя и влавствуя
Итого:

Вам нужно добавить два правила (или одно поменять, что не очень гуд) в NAT:
1. chain=dstnat action=dst-nat to-addresses=192.168.1.2 to-ports=80 protocol=tcp in-interface=pptp-out1 dst-port=8080
2. chain=srcnat action=masquerade out-interface=pptp-out1

Так же вам нужно (в вашем случае опционально) добавить разрешающее правило в фильтре:
chain=forward action=accept protocol=tcp dst-port=80

И последнее (но не по значимости), маршруты. В вашем случае нужно сделать так, что бы весь трафик пришедшый из VPN уходил в него же, сейчас маршруты отправят его lte (как говорится "маскируй не маскируй всё равно получишь..."), для исправления этого нужно в маршрутах видеть вот такую картину:
0 ADS 0.0.0.0/0 8.8.8.96 pptp-out1 0
1 ADS %ADDR_VPN_SERVER% 192.168.0.1 0

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

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

Вот это смущает на сервере:
192.168.1.0 192.168.40.2 255.255.255.0 UG 0 0 0 tun0
Должно быть:
192.168.1.0 192.168.40.5 255.255.255.0 UG 0 0 0 tun0

На клиенте:
192.168.2.0 192.168.40.5 255.255.255.0 UG 0 0 0 tun0
А должно по логике:
192.168.2.0 192.168.40.1 255.255.255.0 UG 0 0 0 tun0

Странно как оно у вас вообще работает =)

IPSec на 1100AH до 250 мегабит, но там аппаратное ускорение.
А вообще отличная штука - IPSec особенно в связке с GRE

Через NAT, на этой железке, не протащить никак больше 350 метров (там же каждый пакет обрабатывается). Выход либо использовать ipv6 либо убрать NAT (на самом деле в обоих случаях - убрать NAT).

Про вайфай нужно понять почему он то есть то нет, может в качестве диапазона, может нагрузка, может помехи, может и вправду настройка не корректная.

не очень понятно что у вас там и как.

Но если кратко и по сути, то.
Чтобы удалённый комп ходил в локальную сетку по любому типу VPN туннеля нужно чтобы
1. Комп имел адрес в туннеле
2. Маршрутизатор имел адрес в туннеле
3. Удалённая сеть была смаршрутизированна на компе через адрес маршрутизатора в туннеле и подобный трафик должен быть разрешён.

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

Выходы:
1. Назначить шлюз по умолчанию
2. Или выдавать адреса прямо из пула локальной сети
3. Назначать маршруты динамически \ скриптом

На вашем внешнем apache поднимите реверс прокси, где целью будет сервер доступный через OpenVPN.
Доменное имя должно резольвиться в ip этого публичного сервера.

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

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

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

Используйте ВПН, забейте на "говорят, что при этом ухудшается качество связи" - всё это от лукавого.