LINUX.ORG.RU
решено ФорумAdmin

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

 , , , ,


0

1

День добрый.

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

Конфиг сервера:

port 1194

proto tcp

dev tun

ca ca.crt

cert server.crt

key server.key

dh dh2048.pem

topology subnet

server 10.8.7.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push «route 10.8.7.0 255.255.255.0»

push «route 10.0.84.0 255.255.255.0»

client-config-dir ccd

route 10.0.84.0 255.255.255.0

client-to-client

keepalive 10 120

cipher AES-128-CBC # AES

user nobody

group nogroup

persist-key

persist-tun

status openvpn-status.log

verb 3

Создаю конфиг для клиента ccd/client004

iroute 10.0.84.0 255.255.255.0

Вот вывод команды ip route на сервере:

10.0.84.0/24 via 10.8.7.2 dev tun0

10.8.7.0/24 dev tun0 proto kernel scope link src 10.8.7.1

Проблема в том что у моего клиента IP-адрес 10.8.7.5

Пробовал в конфиге сервера методом перебора комментить вот эти строки

;push «route 10.8.7.0 255.255.255.0»

;push «route 10.0.84.0 255.255.255.0»

;client-config-dir ccd

;route 10.0.84.0 255.255.255.0

В результате либо маршрута нет вовсе в выводе ip route, либо все так же через 10.8.7.2.

В чем может быть проблема?

Вот тебе конфиг 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

lucky_guy ★★★ ()
Ответ на: комментарий от samson

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

artemich ()
Ответ на: комментарий от anc

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

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

По этой ветке

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

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

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

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

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

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

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

10.0.84.0/24 via 10.8.7.2 dev tun0

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

Почему так?

artemich ()
Ответ на: комментарий от lucky_guy

Спасибо.

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

push "redirect-gateway def1 bypass-dhcp"

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

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

artemich ()
Ответ на: комментарий от artemich

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

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

anc ★★★★★ ()
Ответ на: комментарий от artemich

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

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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


#*nat

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

#COMMIT

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

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

artemich ()
Ответ на: комментарий от artemich

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

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

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

redirect-gateway def1

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

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

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

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

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

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

artemich ()
Ответ на: комментарий от artemich

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

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.