подсети тунеля openvpn не видят друг друга

[niksan321]

есть внешняя локалка(далее просто внешка) 176.77.x.x в ней 2 сервака на убенте 176.77.x.a(сервер-впн) и 176.77.x.b(клиент-впн) в каждом серваке помимо сетевух смотрящих во внешку есть ещё по сетевухе, смотрящих в свои локалки сервер-впн 192.168.0.0/24 и клиент-впн 192.168.1.0/24
ип серваков в их локалках: сервера-впн 192.168.0.5, клиента-впн 192.168.1.1 между ними проброшен туннель с помощью опенвпн конфиг сервера-впн -

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

mode server
tls-server
daemon
ifconfig 192.168.10.1 255.255.255.0
port 1194
proto tcp-server
dev tap
client-config-dir /etc/openvpn/ccd
#push "route 192.168.10.0 255.255.255.0 192.168.10.1"
keepalive 10 120
client-to-client
#comp-lzo
persist-key
persist-tun
verb 3
log /var/log/openvpn.log
dh /etc/openvpn/dh1024.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key

файл клиента из папки /etc/openvpn/ccd -

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# приcваиваем ip-адрес
ifconfig-push 192.168.10.101 255.255.255.0
# роутинг на сети
push "route 192.168.0.0 255.255.255.0 192.168.10.1"

конфиг клиента-впн -

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

client
dev tap
proto tcp
# адрес сервера
remote 176.77.x.a
port 1194
resolv-retry infinite
nobind
persist-key
persist-tun
#comp-lzo
ns-cert-type server
dh /etc/openvpn/dh1024.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/romka.crt
key /etc/openvpn/romka.key
log /var/log/openvpn.log
verb 3

вобщем тунель поднимается, серваки друг друга видят и пингуют по ип их локалок, то есть, с сервера-впн я пингую 192.168.1.1 и он пингуется, аналогично с клиента-впн пингую 192.168.0.5 и тоже нормально, но если я хочу пингануть с клиента-впн пк из локалки сервера впн, допустим 192.168.0.100, то ничего не выходит -

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

tracepath 192.168.0.100
 1:  192.168.10.101 (192.168.10.101)                        0.924ms pmtu 1500
 1:  192.168.10.1 (192.168.10.1)                           14.779ms
 1:  192.168.10.1 (192.168.10.1)                            1.672ms
 2:  no reply

аналогично и с локалкой клиента-впн
route-n сервера-впн

(Нажмите, чтобы показать/скрыть)

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
176.77.x.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0
0.0.0.0         176.77.x.1     0.0.0.0         UG    100    0        0 eth0

route-n клиента-впн

(Нажмите, чтобы показать/скрыть)

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     192.168.10.1    255.255.255.0   UG    0      0        0 tap0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0
176.77.x.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         176.77.x.1     0.0.0.0         UG    100    0        0 eth1

проще говоря, локальные подсети серваков не видят друг друга, как поправить?
в /etc/sysctl.conf - прописано net.ipv4.ip_forward=1
в IPTABLE - на сервере-впн только маскарадинг на eth0(176.77.x.a) - чтобы интернет был в локалке сервера-впн, аналогично и с клиентом-впн

[AnrDaemon]

1. Это

Форум русскоязычного сообщества Ubuntu

Будьте так добры, пишите по-русски.

2. Ссылка по теме: https://forum.ubuntu.ru/index.php?topic=184209.0

[MooSE]

push route ... ? не?

[fisher74]

AnrDaemon, прежде чем кипятиться прочитайте хотя бы по диагонали. ТС говрит именно про tap-интерфейс, а в указанной Вами теме рассмтриваются проблемы tun-интерфейса. Хотя там и освещается решение вопроса с отказом клиент-серверной технологии и использованием PtP.

MooSE, если Вы обратите внимание, то эта команда даётся клиенту из персоналии клиента из директории ccd.
Только вот неверно она там прописата.
Должно быть:
Чтобы клиент(ы) знали, что находится за сервером нужно в конфиг самого сервера (а не в персоналию) дописать
push "route 192.168.0.0 255.255.255.0"
(возможно и персоналку клиента, но я не пробовал. Но и добавлять необходимо правильный параметр)

Кроме того серверу нужно указать маршрут на саму виртуальную сеть (в конфиге сервера)
route 192.168.10.0 255.255.255.0
Правда обычно и без этого работает, но хуже не будет.

Ну и чтобы сервер знал, какая сеть находится за клиентом, добавить в персональный файл клиента
iroute 192.168.1.0 255.255.255.0

[AlDemin]

fisher74

Кроме того серверу нужно указать маршрут на саму виртуальную сеть (в конфиге сервера)
route 192.168.10.0 255.255.255.0
Правда обычно и без этого работает, но хуже не будет.

Этот маршрут и так прописывается, на повторный в логах ругается, что такой уже есть.

# приcваиваем ip-адрес
ifconfig-push 192.168.10.101 255.255.255.0

Я не вижу получает ли клиент этот IP
и не вижу у сервера маршрута в сеть клиента:

Код: [Выделить]

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
176.77.x.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0
0.0.0.0         176.77.x.1     0.0.0.0         UG    100    0        0 eth0не хватает строки вроде:

Код: [Выделить]

192.168.1.0    192.168.10.101     255.255.255.0   U     0      0        0 tap0

[fisher74]

и не вижу у сервера маршрута в сеть клиента:
не хватает строки вроде:

Код: [Выделить]

192.168.1.0    192.168.10.101     255.255.255.0   U     0      0        0 tap0

Эммммм.....

Ну и чтобы сервер знал, какая сеть находится за клиентом, добавить в персональный файл клиента
iroute 192.168.1.0 255.255.255.0

?

не хватает строки вроде:

Код: [Выделить]

192.168.1.0    192.168.10.101     255.255.255.0   U     0      0        0 tap0

Шлюз неверный. Не забывайте, что Вы используете tap-интерфейс. Потому шлюзом будет 192.168.10.1

[AlDemin]

?

ну да, но скорее

iroute 192.168.1.0 255.255.255.0 192.168.10.101

Т.к. это не P-t-P, тут наверное надо явно указать за каким именно GW находиться эта подсеть.
клиент же получает это от сервера:

Код: [Выделить]

push "route 192.168.0.0 255.255.255.0 192.168.10.1"соответственно маршрут на клиенте:

Код: [Выделить]

192.168.0.0     192.168.10.1    255.255.255.0   UG    0      0        0 tap0

[fisher74]

Вы где-нибудь видели, чтобы я говрил про PtP?
То что я него покосился не говорит о том, что я говорю именно про него.
В openvpn шлюз маршрута явно не указывается НИГДЕ. Внимание - НИГДЕ. Уберите шлюз из push.
Добавьте строку iroute так как я Вам дал. и рестартуйте сервер

[AlDemin]

Шлюз неверный. Не забывайте, что Вы используете tap-интерфейс. Потому шлюзом будет 192.168.10.1

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

[fisher74]

Ёлки.. Вы меня сбили. Я думал последние фразы ТС.
Сеть хоть и виртуальная, но в режиме tap - всё подчиняется привычным законам.

[AlDemin]

Вы где-нибудь видели, чтобы я говрил про PtP?

Просто у режима PtP шлюз однозначен, а если в режиме tap будет десяток клиентов со своими подсетями, ко всем подсетям будет шлюзом IP tap интерфейса сервера? По логике к каждой подсети должен быть шлюзом ip tap интерфейса соответствующего клиента?

Сеть хоть и виртуальная, но в режиме tap - всё подчиняется привычным законам.

Ну значит так как я и думал.
А команды типа:

Код: [Выделить]

push "route 192.168.0.0 255.255.255.0 192.168.10.1"
route 192.168.1.0 255.255.255.0 192.168.10.101
ОпенВПН нормально обрабатывает ставя третий аргумент шлюзом.

Ёлки.. Вы меня сбили.

Простите меня...

[fisher74]

А команды типа:

Код: [Выделить]

push "route 192.168.0.0 255.255.255.0 192.168.10.1"
route 192.168.1.0 255.255.255.0 192.168.10.101
ОпенВПН нормально обрабатывает ставя третий аргумент шлюзом.

Прокрутил man... Да, действительно. Относительно этих команд допустимо использовать с указанием шлюза, а так же метрики

--route network/IP [netmask] [gateway] [metric]

А вот iroute - это не касается

--iroute network [netmask]
              Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.

[AlDemin]

Вот тоже смотрю про iroute
"This example will only work if you are routing, not bridging, i.e. you are using "dev tun" and "server" directives."
Я так понял, что iroute применяется только в режиме tun сервера-многоточки что в общем то логично раз там нет параметра для GW.

ps: мы тут все между собой... а ТС молчит.

еще пара мыслей: у ТС в конфиге:

Код: [Выделить]

mode server
ifconfig  192.168.10.1 255.255.255.0я так понимаю это аналог:

Код: [Выделить]

server 192.168.10.1 255.255.255.0
и как я понял, что проблема ТС в том, что у него в конфиге сервера
или скорее всего в файл клиента из папки /etc/openvpn/ccd отсутствует строка

Код: [Выделить]

route 192.168.1.0 255.255.255.0 192.168.10.101Ну это в том случае, если клиент получает для своего tap0 IP=192.168.10.101

[fisher74]

Не путайте. У него есть на сервере (ccd/client)
push "route 192.168.0.0 255.255.255.0 192.168.10.1"
И с этим всё в порядке (хотя показывать GW в данном случае и нет необходимости). О чём и гласит вторая строчка клиентских route.

А вот сервер не знает про клиентскую сеть (смотрим роуты сервера). А вот если добавить в ccd/client
iroute 192.168.1.0 255.255.255.0
то и сервер будет знать как дойти до клиентской сети.

[niksan321]

всем спасибо за советы, буду пробовать, если что отпишусь