LINUX.ORG.RU
ФорумAdmin

OpenVpn сеть за клиентом

 ,


1

1

Ситуация такова на openvpn поднят туннель из центрального офиса с подсетью 192.168.0.0/16 я вижу окончание туннеля(клиента) сетевая карта второй стороны не пингуется предполагаю потому что маршрут по умолчанию уходит на шлюз физической машины на которой установлен сервер openvpn с клиентской стороны я пингую подсеть за сервером openvpn но еще хотелось бы увидеть подсеть за клиентом. Подскажите как смаршрутизировать это дело?

server

/etc/openvpn/ccd

iroute 192.168.x.x 255.255.0.0

push «redirect-gateway def1»

поэтому я понимаю все заворачивается в туннель

client eth2

192.168.3.254

255.255.0.0

10.55.0.6 туннель

хочу увидеть машину за клиентом на ней

192.168.3.3

255.255.0.0

192.168.3.254

iroute 192.168.x.x 255.255.0.0

Именно x.x прописано? :)

И поясни, на том клиенте, за которым находится сеть, к которой хочешь получить доступ, какие сетевые интерфейсы есть и как настроены? Он является дефолтным шлюзом для машин за клиентом?

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

/etc/openvpn/ccd

iroute 192.168.1.0 255.255.0.0

push «redirect-gateway def1»

сам клиент это шлюз

eth0 смотрит в мир eth2 смотрит в локальную сеть и пока за ней всего одна машина к которой хочу хотя бы пропинговаться но traceroute упорно посылает в туннель. Да он проставлен как дефолтный. Спасибо.

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

А вывод traceroute на всякий случай можно?

Ttt ☆☆☆☆☆ ()

сетевая карта второй стороны не пингуется Такая же проблемма,даже тему создавал... Не могу добиться пинга от сервера к физическому адресу клиента. с маршрутизацией на серверной стороне тож не получается разобраться(((

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

client

traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 10.55.0.1 (10.55.0.1) 114.325 ms 114.607 ms 114.652 ms

2 x.x.x.x (x.x.x.x) 114.840 ms 114.884 ms 114.935 ms

(x.x.x.x здесь это адрес реальной карты шлюза server openvpn)

c сервера я соответственно ухожу на шлюз реальной карты.

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

Имеено

сетевая карта на client ни в какую...думаю специалисты нам разъяснят.

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

Сегодня как раз эту тему читал смотрю тихо

Я думал что вы разрешили свою проблему.

zvergpincher ()

меня зовут масяська и я не читаю документаську!

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

Можно подробнее?

Это физически невозможно или я где-то упустил важную информацию?

zvergpincher ()
Ответ на: Можно подробнее? от zvergpincher

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


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

То что ты хочешь - легко реализуемо, для этого надо сесть и нормально прочитать как работает маршрутизация на уровне openvpn.

tazhate ★★★★★ ()

где конфиги сервера и клиента openvpn? где таблицы роутинга с сервера и клиента? где настройки узлов за «клиентом»?

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

Спасибо за ответ

Раз это реализуемо легко,то остается еще более углубиться в чтение. Спасибо за ваши очень полезные уроки русского языка.

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

Меня интересует traceroute с сервера не на интернетовский IP, а на компьютер из подсети openvpn-клиента.

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

traceroute 192.168.3.3

traceroute to 192.168.3.3 (192.168.3.3), 30 hops max, 60 byte packets

1 192.168.0.17 (192.168.0.17) 2999.789 ms !H 2999.669 ms !H 2999.650 ms !H

это eth0 сервера

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

А route сервера можно? Значит, скорее всего, iroute не сработало.

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

Пожалуйста

10.55.0.0 10.55.0.2 255.255.255.0 UG 0 0 0 tun0

10.55.0.2 * 255.255.255.255 UH 0 0 0 tun0

x.x.x.x * 255.255.255.252 U 0 0 0 eth1

172.12.12.0 * 255.255.255.0 U 0 0 0 tap3

172.12.13.0 * 255.255.255.0 U 0 0 0 tap4

172.12.14.0 * 255.255.255.0 U 0 0 0 tap5

172.12.15.0 * 255.255.255.0 U 0 0 0 tap6

172.16.10.0 * 255.255.255.0 U 0 0 0 tap0

172.16.11.0 * 255.255.255.0 U 0 0 0 tap1

172.16.12.0 * 255.255.255.0 U 0 0 0 tap2

localnet * 255.255.0.0 U 0 0 0 eth0

tap'ы не мои здесь стоит zentyal и через web-интерфейс их поднимали

zvergpincher ()
Ответ на: Пожалуйста от zvergpincher

нет маршрута к сети 192.168.3.0 на tun0

iroute 192.168.x.x 255.255.0.0

может надо iroute 192.168.3.0 255.255.255.0

vxzvxz ★★★ ()
Ответ на: Пожалуйста от zvergpincher

Прошу прощения, помимо директивы iroute, в конфиге сервера нужно ещё директиву route с теми же значениями указать. В твоём случае route 192.168.0.0 255.255.0.0

route заставляет openvpn-сервер прописать маршрут в таблицу маршрутизации ОС (чтобы ОС направляла пакеты openvpn-серверу), а iroute нужен самой openvpn, чтобы знать, какому клиенту отсылать.

https://openvpn.net/index.php/open-source/documentation/howto.html

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Ttt ☆☆☆☆☆ ()
Последнее исправление: Ttt (всего исправлений: 2)
Ответ на: комментарий от vxzvxz

Спасибо за отклик

По вашему совету сменил

iroute на 192.168.3.0 255.255.0.0

но к сожалению в роутах не появляется маршрут и я соответственно снова ухожу на реальный шлюз

traceroute 192.168.3.3 traceroute to 192.168.3.3 (192.168.3.3), 30 hops max, 60 byte packets

1 192.168.0.17 (192.168.0.17) 2997.062 ms !H 2996.995 ms !H 2996.977 ms !H

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

У меня такая же проблемма,и правка конфигов сервера не помогает,есть ли необходимость руками на сервере прописывать путь к сети клиента?Просто в документации об этом ни слова!Спасибо...

Возможно тебе надо форвардинг включить на сервере,но мне не помогло...

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

Совсем забыл в конфигах я уже такое писал

При таких настройках сервер уходит в себя и в сознание уже не возвращается. Отследить что там происходит нет возможности поскольку сервер в работе.

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

Я ее не использую крутили до меня

вообще на 50 компов поднимать /16 не знаю зачем надо было наверное планы были помасштабнее. По остальным вопросам на client вообще ничего не прописано. Как только route в конфигах server ставлю 192.168.0.0 255.255.0.0 сервер перестает отвечать. и в офисе пропадает инет.

zvergpincher ()
Ответ на: Я ее не использую крутили до меня от zvergpincher

route 192.168.0.0 /16 вроде не правильно! Эта команда обьявляет удаленную сеть для твоего сервера! У тебя должно быть route 192.168.3.0 твоя маска - как я понял у тебя удаленка 192.168.3.0

puz27 ()
Ответ на: согласен от zvergpincher

0

В общем потерял я клиентскую сторону и никак не простучаться...на той стороне никого нет сейчас...ЗАСАДА! Спасибо всем за участие. Продолжу свои мучения завтра.

zvergpincher ()
Ответ на: 0 от zvergpincher

Держи в курсе,так у меня по сути такая же проблема... И решения я пока тоже ищу...

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

Лады

Нерешаемых нет в конце концов среди концов найдем конец мы наконец))))

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

Хотел с утра но не успел...были проблемы

Давайте все же все вместе посмотрим конфиги

CLIENT

client

dev tun

proto udp

remote 92.46.124.162 35500

resolv-retry infinite

nobind

user nobody

group nogroup

persist-key

persist-tun

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/client1.crt

key /etc/openvpn/keys/client1.key

ns-cert-type server

cipher BF-CBC

comp-lzo

verb 6

log-append /var/log/openvpn/openvpn_client1.log

status /var/log/openvpn/status

SERVER

port 35500

proto udp

dev tun

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/server.crt

key /etc/openvpn/keys/server.key

dh /etc/openvpn/keys/dh1024.pem

ifconfig-pool-persist ipp.txt

push «route 192.168.0.0 255.255.0.0»

push «route 192.168.1.0 255.255.0.0»

client-config-dir /etc/openvpn/ccd

route 192.168.3.0 255.255.0.0

keepalive 10 120

cipher BF-CBC

comp-lzo

user nobody

group nogroup

persist-key

persist-tun

status /var/log/openvpn-status.log

verb 6

CCD

iroute 192.168.3.0 255.255.0.0

Ну вот как то так. При этом пинги в мою подсеть 192.168.1. 255.255.0.0 идут

а вот за клиента я не простукиваюсь.

zvergpincher ()
Ответ на: Хотел с утра но не успел...были проблемы от zvergpincher

push «route 192.168.0.0 255.255.0.0»

push «route 192.168.1.0 255.255.0.0»

Явно неправильно. У тебя на все адреса 192.168.*.* будет ходить через openvpn. На какие именно нужно? Если на 192.168.0.* и 192.168.3.0, то

push "route 192.168.0.0 255.255.255.0"

push "route 192.168.1.0 255.255.255.0"

На сервере то же самое. Если интересуют адреса 192.168.3.*, то в обоих местах маска должна быть 255.255.255.0

И да, советую почитать https://ru.wikipedia.org/wiki/Маска_подсети (если неправильная маска подсети — не опечатка, т.к. подсеть типа 192.168.1.0 с маской 255.255.0.0 явно некорректная.

Ttt ☆☆☆☆☆ ()
Последнее исправление: Ttt (всего исправлений: 1)
Ответ на: комментарий от Ttt

Спасибо за подсказку

В самом начале я писал что физическая сеть в офисе 192.168.1.0/16 сервера сидят в своей подсети 192.168.0.0/16 клиенту я придумал 192.168.3.0/16

/16 255.255.0.0 и это не опечатка если это невозможно реализовать на таких подсетях то тогда я буду думать как реорганизовать.

и второе я спорить конечно еще зелен но как я понял

push «route 192.168.0.0 255.255.255.0»

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

zvergpincher ()
Ответ на: Спасибо за подсказку от zvergpincher

физическая сеть в офисе 192.168.1.0/16 сервера сидят в своей подсети 192.168.0.0/16

Ну не бывает такого. Это одна и та же подсеть. маска 16 (255.255.0.0) говорит о том, что первые два октета обозначают подсеть, а последние два — хост в подсети.

Ttt ☆☆☆☆☆ ()
Последнее исправление: Ttt (всего исправлений: 2)
Ответ на: комментарий от Ttt

Спасибо еще раз использую неправильную терминологию

На сервере то же самое. Если интересуют адреса 192.168.3.*, то в обоих местах маска должна быть 255.255.255.0

Что значит на сервере то же самое...я на клиенте никаких ccd не прописывал и в конфигурации клиента этого нет но если это нужно то конечно я додбавлю.

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

Большое спасибо

Теперь пинги от сервера уходят до физической карты компьютера клиента...но вот теперь еще один вопрос...получается я должен на машине за клиентом прописать 255.255.255.0 так?

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

Сейчас там некому разрулить ситуацию

Мой низкий поклон за ваши разъяснения!!! Завтра как только все организую составлю описание и выложу здесь может кому-то понадобиться,а сам когда все будет работать все же возьмусь за более углубленное изучение сетей и соединением через openvpn...потому что чувствую что слаб.

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

Посмотри описание

У меня сейчас отрабатывает практически все! Попробуй сделать так же!

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

Идентичная ситуация

При пингах за клиента меня заворачивает на шлюз eth0 вместо eth2 думаю что дело в отсутствующем правиле route на клиентской машине который надо писать ручками...

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