res2001

Для того чтобы веб сервер на Raspberry мог и дальше принимать запросы из интернета надо просто настраивать OpenVPN сервер так что бы он не делал себя маршрутизатором по умолчанию для клиентов. Для этого достаточно не указывать/закоментировать одну директиву в конфиге сервера (впрочем она, по моему, и так закоментирована по умолчанию):
push "redirect-gateway def1 bypass-dhcp"

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

push "route IP MASK"
где IP и MASK адрес подсети и маска где находится ваш сервер. Маршрут к указанной сети прописывается на стороне клиента, шлюзом будет ВПН сервер.
Кстати, рекомендую использовать для ВПН UDP, а не TCP. Работает гораздо быстрей, это особенно актуально на плохих каналах связи.

Значит дело в фаерволе, смотрите разрешающее правило на ВПН сервере.
На клиентах, обычно, все работает по умолчанию.

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

Первый вариант - ВПН сервер открыт для атак снаружи, там придется настраивать фаервол практически аналогично Керио. А это уже превращает этот вариант в третий :-) и керио становится не нужен.

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

Как альтернатива микротику - у асуса старшие модели не плохие, прошивки имеются.

1.В чем смысл балансировки на одном хосте? Балансировка нужно, если хост не справляется и нужно направить часть подключений на другой хост. Поэтому балансировать на одном хосте - полная фигня.
2.Самый простой вариант балансировки - с помощью двух записей А в ДНС для одного имени сервера OpenVPN. DNS в этом случае будет отдавать записи по round robin и у вас получится бесплатная балансировка.
Нужно будет на разных серверах OpenVPN назначать клиентам адреса разных подсетей, иначе, как вы сами правильно заметили начнутся грабли с маршрутизацией.
OSPF в такой конфигурации вообще не нужен.

build-ca и прочие скрипты были во 2 версии easy-rsa, в третьей только один скрипт - easyrsa, но с теми же параметрами. easy-rsa - это надстройка над openssl, просто скрипт, автоматизирующий операции.
Я с 3 версией дела не имел, как-то все время попадалась 2 версия. Откройте скрипт в текстовом редакторе, там обычно довольно внятные комментарии. Имея инструкцию для 2 версии можно ее достаточно легко адаптировать к 3 версии, я так думаю. Скрипт vars так и остался с предыдущей версии. В vars инициализируете переменные для генерации ключей, которые будут использоваться в основном скрипте.
PS: не так давно настраивал OpenVPN для винды, комплект брал с сайта разработчика, там еще были скрипты второй версии. Но для винды скрипты easy-rsa всегда требовали доработки напильником.

Не знаю как сейчас, а года 2-3 назад скрипты для генерации ключей под Windows из состава дистрибутива OpenVPN без допиливания не работали, поэтому я обычно делал ключи на линукс - там они давно обкатаны и работоспособны.

Правильно как раз ключи генерировать на клиенте, в центр сертификации передается запрос на сертификат, ЦС возвращает сертификат, клиент передает сертификат на сервер. ЦС и сервер в общем случае это разные сущности, и, если по взрослому, это даже разные организации.

Явно МТУ тут был ни причем. Проблемы с МТУ проявляются по другому.

Маршрут на винде прописан нормально, дальше надо разбираться почему 192.168.0.254 не отправляет пакеты в сеть 192.168.35.0/24.
Смотри маршруты на этом шлюзе. Имеет ли он сам доступ к подсети 192.168.35.0/24? На сколько я понимаю это внутренняя подсеть, а ВПН работает через интернет? Возможно OpenVPN настроен не корректно. Может быть на 192.168.0.254 не настроена маршрутизация из одной сети в другую. Может быть на 192.168.35.254 нет маршрута до подсети 192.168.0/24 или не включена маршрутизация.

Не стоит пробрасывать еще один порт - используйте ВПН для доступа к сети за ВПН сервером.
У вас нет строки конфигурации, которая бы прописывала маршрут на стороне клиента к сети за ВПН-сервером. В файле cli1 должно быть что-то типа:
push "route 192.168.142.0 255.255.255.0"
(адреса подставить свои)
Инструкция iroute добавляет маршрут на ВПН сервере до сети за клиентом.

Как правило достаточно прописать маршрут до этого диапазона напрямую, через шлюз по умолчанию.
route add /?
OpenVPN в типичной конфигурации после установки подключения на клиенте меняет адрес шлюза по умолчанию, на адрес сервера OpenVPN.

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