res2001

1. У вас на openvpn сервере и на клиенте винда? Какие версии и там и там? Если Home или Pro, то надо включить маршрутизацию: параметр в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter (REG_DWORD) выставить в значение 1 и перезагрузиться. На серверной винде маршрутизация обычна уже включена.
2. на openvpn сервере в клиентский конфиг (находящийся в каталоге C:\\OpenVPN\\ccd) добавить директиву:
iroute 192.168.1.0 255.255.255.0
Это добавит на openvpn сервере маршрут к сети клиента при подключении клиента (при отключении - удалит).
3. в основной конфиг openvpn сервера добавить добавить директиву:
push "route 192.168.0.0 255.255.255.0"
Это добавит на клиенте маршрут до сети за сервером при подключении.
4. На остальных компах за сервером стоит шлюзом по умолчанию интернет роутер, поэтому они все пакеты, предназначенные клиентской сети шлют на роутер, а не на сервер opewnvpn. Вам надо добавить в таблицу маршрутизации на каждом компе в сети (кроме openvpn сервера) маршрут до клиентской сети командой:

route -p add 192.168.1.0 mask 255.255.255.0 192.168.0.2

Маршрут не обязательно добавлять руками, можно политиками AD или опциями при раздаче адреса в DHCP.
5. На компах в сети за клиентом происходит то же самое, что и в сети за сервером, только там маршрут будет немного другим:

route -p add 192.168.0.0 mask 255.255.255.0 192.168.1.2

Указать в параметре remote

Конфиги в студию. Приведенные ошибки на стороне клиента или сервера?
Ошибки, видимо 2:

Unknown TCP service "993 ."

Видимо описан лишний сервис в конфиге, уберите его.

[!] Service [openvpn]: Cannot resolve accept target

Доступен ли openvpn по адресу и порту, указанному во фразе accept?

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

Это лишнее:

push "route 192.172.10.0 255.255.255.0" \\Сеть за микротом
push "route 192.168.10.0 255.255.255.0"

Это уберите в файл клиента, в опцию iroute
route 192.172.10.0 255.255.255.0
Почему у вас локальная сеть за микротом имеет белые адреса? Вы арендуете у прова подсеть? (192.172.10.0/24)
Но это к делу отношения не имеет.

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

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

Любые ВПН вообще и OpenVPN в частности не имеют отношения к вашим хотелкам. Вы можете делать это с ВПН или делать без ВПН - как угодно. Для этого используется другое ПО никак не связанное с ВПН. Оно работает на уровне выше, чем работает ВПН.

Возможно.

не предлагать прокси прописать в клиентский конфиг

В этом случае прокси у вас должен быть прозрачный. Просто перенаправляйте трафик с ВПН на прокси средствами фаервола. Собственно взаимодействие клиентов ВПН с прокси отношения к ВПН не имеет - все настраивается так же как и без ВПН.

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

При чем тут openvpn?
Причину вы понимаете не правильно - ВПН создает новый виртуальный сетевой адаптер, его IP ни с чем не конфликтует (хотя теоретически может, но это достаточно редкий случай).
Ваша ситуация похожа на наиболее частую ошибку, когда ВПН соединение перезаписывает "шлюз по умолчанию" на клиенте. Это поведение обычно можно отключать. Как именно зависит от используемого варианта ВПН.

Никак. Не нужен тут IPBAN, пользователь неудачно ввел пароль в винду, при этом с ВПН у него проблем нет.

Это делается другими средствами. Настройте политики винды (АД или локальные) на блокировку пользователя на какое-то время в случае N неудачных регистраций.

Т.к. белые адреса раздают провайдеры, то покупаете у прова целую подсеть с нужным количеством адресов и раздаете клиентам по ВПН. Учтите, что сервер ВПН то же должен иметь адрес из этой подсети.
Это может быть дорого. Не каждый провайдер сейчас готов давать в аренду целые подсети. Если нужно много адресов, то это еще более проблемно.

error=unable to get local issuer certificate:

У вас проблема с сертификатами.
Возможно закончился срок действия вашего сертификата или сертификата ЦА или на сервере сменили сертификат ЦА и свой серверный. В общем комбинаций несколько, т.к. в цепочке подключения обычно используются 3 сертификата (ваш, сервера, ЦА).
В конфиге openvpn в соответствующих директивах указаны пути к файлам сертификатов, проверьте их. Обычно их содержимое в читабельном виде, но могут быть варианты.

Зачем вам server-bridge? Ниразу не видел openvpn работающий в этом режиме. Ну может оно и работает ...
Режим topology subnet + server наше все.
В общем когда ВПН клиент подключится к серверу останется только правильно настроить таблицы маршрутизации на ВСЕХ участниках обмена.