Обходной путь для OpenVPN Требуется проблема - может подключаться только к одному IP в удаленной сети


0

Я попробовал это решение, но оно не сработало. По сути, я могу подключиться к своей удаленной сети через OpenVPN, но только к одному IP в сети. Для соединений с сервером я использовал перенаправление портов через ssh. Это сработало, и я получил доступ к некоторым ресурсам, но я все еще не могу подключиться к некоторым сетевым ресурсам, к которым мне нужен доступ.

Есть идеи / советы / обходные пути?

РЕДАКТИРОВАТЬ - Вот конфиги:

клиент

dev tun
proto udp
remote remote.mydomain.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert cert.crt
key key.key
comp-lzo
verb 3

сервер

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0. 255.255.255.0
ifconfig-pool-persist
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-kiey
persist-tun
status openvpn-status.log
verb 3

Я должен отметить, что эта конфигурация работала в течение многих месяцев. Это все еще работает (вроде) в том смысле, что я могу получить доступ через VPN-туннель к серверу, на котором работает VPN. Я просто не могу получить доступ к другим IP-адресам в сети без обходных путей (это новое поведение).

Единственное, что я могу подумать об этом, это то, что я перенастроил Drobo в той же сети, что и Samba.

РЕДАКТИРОВАТЬ 2 - Вот еще немного информации о настройке сети для этой ситуации:

Где я сижу, это локальная сеть: 192.168.5.0/24

Где я работаю, это еще одна локальная сеть: 192.168.1.0/24

Сеть VPN: 10.8.0.0/24

В сети 192.168.1.0 есть пара серверов (один из которых - сервер OpenVPN) и пара общих сетевых ресурсов, к которым мне нужен доступ. Используя переадресацию порта ssh, я могу подключиться к маршрутизатору WRT (192.168.1.1 - у которого есть переадресация порта для VPN через порт 1194) и к другому необходимому мне серверу CRM: 192.168.1.20. Компьютер с VPN (192.168.1.10) является единственным доступным IP-адресом, когда я использую свою существующую конфигурацию VPN (см. Выше), которая ранее работала хорошо (это означает, что у меня был доступ ко всем сетевым ресурсам, всем серверам, всем локальным общим машинам). в сети 192.168.1.0).

Один из сетевых ресурсов находится на 192.168.1.15. Drobo, который я обсуждал ранее, находится на сервере CRM (192.168.1.20). Drobo раньше был DroboShare, со своим собственным IP (192.168.1.16). Это было недавно изменено. Я могу подключить рассмотренные здесь сетевые ресурсы к 192.168.1.10 (поскольку я могу получить доступ к этой машине через ssh), так что технически у меня есть доступ ко всему, что мне нужно. Проблема в том, что так делать неудобно, тем более что я привык к тому, что VPN работает должным образом.

Надеюсь, это редактирование прояснит ситуацию.


Вы управляете VPN? Нам понадобятся дополнительные особенности конфигурации, чтобы решить эту проблему. А именно, является ли маршрутизируемый VPN, какие маршруты проталкиваются и включена ли директива «клиент-клиент»? Как минимум, они необходимы для связи между VPN-клиентами.
Имоатама

Да. Конфиги, чтобы следовать ...
nicorellius

Машины, к которым вы пытаетесь подключиться, в подсети VPN 10.8.0.0? Если это так, вам нужно включить client-to-clientдирективу сервера. Если они не находятся в подсети VPN, а подключены к серверу через физическую локальную сеть, например, с подсетью 192.168.10.0, вам нужно добавить push "route 192.168.10.0"директиву в конфигурацию сервера.
Имоатама

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

EDIT 2 выше должен очистить конфигурацию сети (ей). @ imoatama - я не думаю, что мне нужна директива клиент-клиент. Но возможно push "route".
Никорелий

Ответы:


1

Я предполагаю, что другие машины в вашей сети не знают, как маршрутизировать к диапазону IP, который используют клиенты OpenVPN (в вашем случае, 10.8.0.0/24). Если ящик с сервером OpenVPN также не является маршрутизатором по умолчанию, то сетевые хосты, вероятно, отправляют свои пакеты в 10.8.0.x на маршрутизатор вместо сервера OpenVPN.

Самый простой обходной путь - добавить статический маршрут на маршрутизаторе для 10.8.0.0/255.255.255.0, где шлюз - это IP-адрес вашего сервера OpenVPN в локальной сети. Если это невозможно, вы также можете добавить один и тот же статический маршрут к каждому серверу или хосту, с которыми клиенты должны общаться.

Также можно настроить OpenVPN для работы в мостовом режиме, чтобы клиенты находились в той же подсети локальной сети, что и сервер OpenVPN. Это сложнее настроить; в Linux вам нужно создать интерфейс крана и подключить его к интерфейсу Ethernet.


Ваши предложения очень хороши. Я использовал мостовой режим раньше. У меня есть настройка брандмауэра pfSense в моей локальной сети (сеть 192.168.5.0). В конечном итоге я не использовал этот режим, но я вижу, как это может работать. Моя главная проблема заключается в том, почему, черт возьми, это работает, а затем нет, просто потому, что я добавил сетевой ресурс в конфигурацию samba?
Никорелий

1

В зависимости от дизайна VPN вам, вероятно, потребуется включить следующие директивы конфигурации сервера:

  • server
  • dev tun
  • push route <network>
  • client-to-client (это будет зависеть от архитектуры - это необходимо, если все подключаются к серверу через VPN, а не к серверу, находящемуся в той же сети, что и некоторые машины, другие получают доступ к ним через VPN)

Есть много мест, где это может пойти не так, например,

  • Никакой маршрут не выдвигается для адреса (ов) серверов
  • Серверы подключены только к VPN-серверу через VPN, а не к физической локальной сети, и client-to-clientне включены
  • Непонятные ошибки в OpenVPN ( надеюсь, не этот! )

Можете ли вы опубликовать (отредактированные) копии файлов конфигурации вашего сервера и клиента? В противном случае вы можете дать нам базовое представление о сетевой архитектуре?

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.