OpenVPN (server) + MikroTik (client) не правильно назначается маршрут в подсеть.

А что не работает-то? Может подскажите.

www.linux.org.ru/help/lorcode.md

ну не читается же нормально то что вы написали...

Вот тебе конфиг 100% рабочего сервера

port 1194
proto udp
dev tun
ca ca.crt
cert vpn-server.crt
key vpn-server.key
dh dh.pem
topology subnet
server 10.10.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
client-to-client
keepalive 10 120
tls-auth keys/ta.key 0 # This file is secret
cipher AES-256-CBC   # AES
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 3

Извиняюсь. Это моё первое сообщение. Какой тэг использовать для конфигов? code=Shell

Всем спасибо!

Решилась проблема комментом строки в IPTABLES

По этой ветке

OpenVPN на debian (нет пинга с сервера до клиента), туннель в сеть за OpenWRT не работает (комментарий)

Нашлось решение.

Может кто-то прокомментировать поведение системы?

Изначально был один ВПН север и к нему цеплялись три клиента.

Один из них, Виндовый, выходил в сеть Интернет через ВПН-Сервер. Поэтому в IPTABLES был дописан маскарадинг.

После того как я заккоментил эту строку, подсеть за одним из клиентов стала доступной. Как с севера, так и для других клиентов.

Вывод ip route остался прежним.

10.0.84.0/24 via 10.8.7.2 dev tun0

Но пакеты пошли. Хотя ip-адрес у клиента, за которым находится нужная подсеть 10.8.7.5

Почему так?

Спасибо.

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

push "redirect-gateway def1 bypass-dhcp"

А только некоторые.

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

Но пакеты пошли. Хотя ip-адрес у клиента, за которым находится нужная подсеть 10.8.7.5
Почему так?

Потому что ovpn так и работает, все вполне логично. У вас есть локальный интерфейс ovpn tun0 на который и зароучена сеть 10.0.84.0/24. А уже кому из клиентов отправлять пакет для сети 10.0.84.0/24 принимает решение ovpn, именно для этого и прописывается iroute в ccd соответствующего клиента.

После того как я заккоментил эту строку, подсеть за одним из клиентов стала доступной. Как с севера, так и для других клиентов.

Так покажите эту строку.

Сейчас вот так

#*nat

#-A POSTROUTING -s 10.8.7.0/24 -o ens18 -j MASQUERADE

#COMMIT

Причем маскарадинг для Виндового клиентоса работает сам по себе.

Делал трассировку на клиенте. Пакеты идут через ВПН-Сервер.

Честно говоря сходу не вижу чем она может мешать. Или я вашу схему не до конца понял. ens18 это внешний интерфейс сервера?

Да ens18 это внешний интерфейс.

В последней версии Бубунты именно так их стали нумеровать, вместо привычного eth0.

Изначально стояла задача зароутить Виндового клиента через ВПН-сервер. На клиенте в конфиг писалась стока

redirect-gateway def1

И в IPTABLES на сервере

*nat
-A POSTROUTING -s 10.8.7.0/24 -o ens18 -j MASQUERADE
COMMIT

Только тогда пакеты бегали от клиента в Инет через ВПН-сервер.

Потом задача изменилась. Нужно было получить доступ в подсети расположенные за одним из клиентов.

Доступ был нужен как с сервера, так и Виндового клиента.

Сейчас задача решена.

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