res2001

В винде по умолчанию при установке openvpn добавляется только 1 виртуальный tun/tap адаптер, чтоб запустить несколько экземпляров openvpn нужно для каждого экземпляра использовать свой виртуальный адаптер.
В комплекте установки есть утилита tapctl, позволяющая добавлять адаптеры, а так же в меню пуск есть ярлыки для запуска этой утилиты с правильными параметрами.

На самом деле в актуальной версии openvpn по умолчанию устанавливается 3 виртуальных адаптера, но каждый из них разного типа: tun, tap, dco. Похоже можно использовать разные типы адаптеров, изменив опцию dev.
На сколько помню, раньше был только 1 тип адаптера: tun. Его я и использовал всегда. На сколько хорошо работают остальные типы адаптеров под виндой - не в курсе.

Кроме того OpenVPN устанавливает свои службы, которые удобно использовать на серверах, когда нужно, чтоб openvpn стартовал автоматически при старте винды, без вмешательства пользователя.

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

Обычно конфиг клиента делают максимально "легким". Там указывают только необходимые опции для подключения к серверу (протокол, адрес и порт сервера, параметры шифрования и логирования). Все что касается маршрутизации между сетями (route, push route) убирается в конфиг сервера.
Опция push "route ..." - добавляет маршрут на удаленной стороне. Т.е. если опция указана в конфиге сервера, то маршрут добавляется на стороне клиента.
Для добавления маршрута на стороне сервера в конфиге сервера используется опция: route

CCD файлы:
У вас не правильный синтаксис для опции ifconfig-push.
Правильный такой: ifconfig-push client_ip mask
Т.е. IP сервера не требуется указывать.
В опции iroute указываем сети за этим конкретным клиентом. Эти маршруты добавятся в таблицу маршрутизации сервера при подключении клиента. Не нужно дублировать эти маршруты опциями route в основном конфиге сервера.
Так же можно в CCD файле указать опцию push route для добавления маршрута клиенту для сети за сервером. Обычно push route указывают в основном конфиге сервера и она работает для всех клиентов.

Но! Что бы сети за клиентом и сервером могли друг друга видеть они должны знать по каким маршрутам передавать трафик друг для друга. Если ВПН сервер и ВПН клиент являются для своих сетей шлюзами по умолчанию - то проблемы нет, компы внутри сетей и так будут слать весь трафик через них. Но если ВПН сервер и/или ВПН клиент не являются шлюзами по умолчанию для своих сетей, то требуется добавить дополнительные маршурты для соседних сетей через ВПН сервер/клиент. Централизованно маршруты можно добавить через опции DHCP, возможно политиками AD.

Фаерволы на любом узле могут блокировать трафик. Для отладки взаимодействия сетей через ВПН рекомендую сначала отключить фаерволы на всех тестовых устройствах. После того как настроите маршрутизацию фаерволы включайте по одному, сразу проверяйте работу и вносите изменения в правила фаервола, если необходимо.

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

Попробуйте добавить сертификат в Personal, Trusted People или Trusted Device
А вообще - не используйте самоподписанный сертификат.
Поднимите свой ЦС. Сгенерируйте сертификат ЦА, и сертификат сервера, который будет подписан сертификатом ЦА. На клиентах устанавливаете в корневые доверенные центры сертификации сертификат ЦА и будет вам счастье.
Можно использовать встроенный в Windows Server Центр сертификации, или использовать openssl.

Другой вариант - ослабить проверку сертификата у клиента. Думаю как-то это должно делаться в винде, возможно через реестр или GPO. Но я бы не стал этого делать.

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

Файлы можно бэкапить с помощью xcopy, используя аттрибут файла "Архивный" как сигнал о том, что файл был модифицирован после последней архивации. После любой модификации файла аттрибут установится автоматически.
Если надо сжимать, то консольный rar умеет так же работать с этим атрибутом. После архивации файла атрибут сбрасывается. Если правильно помню флаг -ac у него за это отвечает. На счет других архиваторов не знаю, есть ли у них поддержка такой возможности (вроде у старого доброго arj еще была такая фишка).
Собственно, основывая бэкап на использовании этого аттрибута можно накидать не сложный батник для бэкапа, который будет архивировать любым нужным архиватором выбранные файлы. Отбирать файлы по атрибутам можно с помощью dir, архивируем файл, сбрасываем аттрибут, профит.

Есть альтернатива ssh доступу - git-демон.
Входит в комплект с гитом. Принимает запросы по сети, без непосредственного доступа к файлам для клиентов. Не универсальный как ssh, поэтому с его помощью нельзя запустить например консоль :-) Но в отличие от ssh никак незащищает канал передачи, но в локальной сети это не актуально, а в интернете - доступ к нему можно завернуть в ВПН.