Проблема с маршрутизацией в VPN-сети

[aborel]

Добрый день.
Настраивал OpenVPN-сеть и столкнулся со следующей проблемой.

Есть LAN1 - 192.168.12.0/24
В ней находится OVPN-сервер (Windows Server 2012 R2)
192.168.12.101 (lan)
10.8.0.1 (vpn)


Есть LAN2 - 192.168.1.0/24
В ней находится OVPN-клиент (Windows 7)
192.168.1.5 (lan)
10.8.0.5 (vpn)


Есть VPN-сеть - 10.8.0.0/24

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

Code Select Expand

proto udp4

port 1194

dev tun

tls-server
tls-auth ..\\ssl\\ta.key 0

ca ..\\ssl\\ca.crt
cert ..\\ssl\\server.crt
key ..\\ssl\\server.key
dh ..\\ssl\\dh2048.pem

client-config-dir ..\\ccd

topology subnet

client-to-client

server 10.8.0.0 255.255.255.0

cipher AES-128-CBC
comp-lzo

verb 3

keepalive 5 60

route-delay 5
route-method exe

Конфиг в папке ccd:

Code Select Expand

ifconfig-push 10.8.0.5 255.255.255.0

iroute 192.168.1.0 255.255.255.0

# disable

Конфиг клиента:

Code Select Expand

proto udp4

port 1194

dev tun

remote 11.22.33.44

tls-client
remote-cert-tls server
tls-auth ta.key 1

ca ca.crt
cert client.crt
key client.key

route-delay 5
route-method exe

cipher AES-128-CBC
comp-lzo

keepalive 5 60

verb 3

Брандмауэры в обеих сетях выключены, сторонних файерволлов нет.
К VPN-сети клиент и сервер подключаются нормально.

С ovpn-сервера пинг до ovpn-клиента идет нормально по обоим адресам (10.8.0.5 и 192.168.1.5)
В обратную сторону так же, клиент пингует сервер по обоим адресам (10.8.0.1 и 192.168.12.101)

Сеть за ovpn-сервером клиент не видит пока не сделать сетевой адаптер, который смотрит lan2, общедоступным (скриншот)
Такая же ситуация и с сетью lan1.

Окей. После того, как выставил галочки, ovpn-клиент стал свободно заходить на сетевые шары и пинговать все хосты в сети LAN1 (192.168.12.0/24), и наоборот, сервер свободно пингует хосты в сети LAN2 (192.168.1.0/24)

Но на этом все.
Как не пробовал, заставить компьютеры из LAN1 пинговать LAN2, ничего не выходило

Т.е. проблема заключается в том, что компьютеры, которые находятся в LAN1 (192.168.12.0), не пингуют компьютеры которые находятся в LAN2, и наоборот, компьютеры из LAN2 не пингуют LAN1

На OVPN-сервере вручную прописан маршрут до сети LAN2:
route -p add 192.168.1.0 mask 255.255.255.0 10.8.0.5

На OVPN-клиенте вручную прописан маршрут до LAN1:
route -p add 192.168.12.0 mask 255.255.255.0 10.8.0.1

На клиенте в LAN1 прописан маршрут до сети LAN2 и на всякий случай до VPN-сети:
route -p add 192.168.1.0 mask 255.255.255.0 192.168.12.101
route -p add 10.8.0.0 mask 255.255.255.0 192.168.12.101

Таблица маршрутизации OVPN-сервера:
https://i.imgur.com/01Rzf26.png

Таблица маршрутизации OVPN-клиента (прошу прощения за такой "скрин"):
https://i.imgur.com/FryaMNF.jpg

Таблица маршрутизации одного из компьютеров в LAN1:
https://i.imgur.com/CqqeI4h.png

Служба "Маршрутизация и удаленный доступ" включена только на OVPN-сервера и OVPN-клиенте
Параметр реестра IpEnableRouter выставлен в 1 так же только на сервере и клиенте.

На обычных клиентских компах в лан1 и лан2 это не делалось.

Подскажите, что я делаю не так =)

[aborel]

Скриншот с трасером с клиентского компьютера LAN1 до OVPN-сервера LAN2
https://i.imgur.com/kkoMrqq.png

[Уваров А.С.]

Читаем то, что написано про настройку маршрутизации в этой статье: https://interface31.ru/tech_it/2016/09/organizaciya-kanalov-mezhdu-ofisami-pri-pomoshhi-openvpn-na-platforme-linux.html

[aborel]

Читаем то, что написано про настройку маршрутизации в этой статье: https://interface31.ru/tech_it/2016/09/organizaciya-kanalov-mezhdu-ofisami-pri-pomoshhi-openvpn-na-platforme-linux.html

перечитал несколько раз и все равно не понял, в чем проблема.
маршруты на противоположные сети через ovpn-сервер/клиент на клиентских компьютерах прописаны.
в целом конфиги отличаются лишь ручной маршрутизацией на компьютерах в моем случае. или проблема как раз в этом?
сейчас добавлю маршруты в конфиге сервера, посмотрю, что изменится.

или дело в операционных системах?

[Уваров А.С.]

Сначала настройте правильно маршрутизацию в OpenVPN, чтобы не писать ее руками. Затем уже будем смотреть что и почем. Также не забывайте, что на узлах OPVN сервера и клиента должна быть включена маршрутизация.

[aborel]

Сначала настройте правильно маршрутизацию в OpenVPN, чтобы не писать ее руками. Затем уже будем смотреть что и почем. Также не забывайте, что на узлах OPVN сервера и клиента должна быть включена маршрутизация.

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

.
server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
route 192.168.1.0 255.255.255.0 10.8.0.5
push "route 192.168.12.0 255.255.255.0"

с ovpn-клиента пинг до ovpn-сервера идет по обоим адресам. ровно то же самое в обратную сторону.

с клиентов за ovpn-сервером (192.168.12.0/24) пинг до ovpn-клиента по LAN-адресу (192.168.1.5) не идет.
маршрут до сети 192.168.1.0 на клиентах выглядит следующим образом: route add -p 192.168.1.0 mask 255.255.255.0 192.168.12.101

таблица маршрутизации на ovpn-сервере
https://i.imgur.com/xFjQznL.png
таблица маршрутизации с клиентского компьютера за ovpn-сервером:
https://i.imgur.com/rMg1yQ3.png


Еще хотел уточнить: адрес, выделенный красным, я не зря поставил?
Пробовал и без него, но тогда маршрут на ovpn-сервере до сети ovpn-клиента (192.168.1.0/24) добавляется через адрес 10.8.0.1. В таком случае ovpn-клиент не пингуется по lan-адресу даже с ovpn-сервера.

[ival]

С любого пк из сети 192.168.1.0 покажите таблицу маршрутов

[aborel]

С любого пк из сети 192.168.1.0 покажите таблицу маршрутов

В данный момент в сети 192.168.1.0 из устройств есть только OVPN-клиент (192.168.1.5) и провайдерский модем (192.168.1.1), который дает интернет.

вот таблица маршрутов с ovpn-клиента
https://i.imgur.com/vYg2Cpt.jpg

[ival]

Со стороны маршрутизации как сетевого уровня проблем нет, маршруты все рабочие. А какое сообщение при пинге приходит?

[aborel]

Со стороны маршрутизации как сетевого уровня проблем нет, маршруты все рабочие. А какое сообщение при пинге приходит?

превышен интервал ожидания для запроса
во втором посте еще есть скрин с трасером с клиента сети 192.168.12.0 до овпн-клиента

[ival]

превышен интервал ожидания для запроса
во втором посте еще есть скрин с трасером с клиента сети 192.168.12.0 до овпн-клиента

Это значит что хост найден, но не ответил за указный проведуток времени. Когда нет маршрута у вас будет destination host unrichible, указанный хост не достежим

[aborel]

Это значит что хост найден, но не ответил за указный проведуток времени. Когда нет маршрута у вас будет destination host unrichible, указанный хост не достежим

может тогда подскажете, в какую сторону копать в данном случае?

[Уваров А.С.]

В конфиге сервера

Code Select Expand

route-gateway 10.8.0.1
route 192.168.1.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"
В ccd -файле для клиента за которым первая подсеть:

Code Select Expand

iroute 192.168.1.0 255.255.255.0
И уберите ifconfig-push 10.8.0.5 255.255.255.0 - раздавать адреса руками в 2019 году дурной тон. Вместо него в конфиг сервера:

Code Select Expand

ifconfig-pool-persist ipp.txt

Пробовал и без него, но тогда маршрут на ovpn-сервере до сети ovpn-клиента (192.168.1.0/24) добавляется через адрес 10.8.0.1. В таком случае ovpn-клиент не пингуется по lan-адресу даже с ovpn-сервера.

Маршрут добавляется правильно, а не работает, потому что маршрутизация настроена неправильно. Для всех клиентов OVPN сети в ней один шлюз - 10.8.0.1 - он же сервер, маршрутизация внутри строится самим OVPN на основе опций route и iroute.

route в конфиге сервера говорит ему, какие пакеты заворачивать в OVPN сеть. Через push отправляется route клиентам, чтобы они заворачивали в туннель сеть за сервером. Здесь вопросов нет, шлюз знает эту сеть и отправит пакет дальше. А вот про сети за клиентами он ничего не знает, для этого есть опция iroute в ccd файлах клиентов, которая настраивает внутреннюю маршрутизацию, т.е. говорит слать пакеты к этой сети через вон того клиента.

Если часть этой схемы будет не настроена или настроена неправильно, то она работать не будет.

[ival]

Уваров, я отступлюсь наверное но у меня свой вопрос. Я не работал с OVPN, поэтому прошу обьяснить по возможности. директивы route, push route и ccd являются обязательными? Почему такой вопрос сейчас попробую объяснить, по факту ведь все равно как объявлять маршруты, статически писать их в таблице ОС или предположим я захочу использовать quagga зачем мне тогда директивы route, push route и ccd? Мне же нужен от openvpn только туннель, я не прав?

[aborel]

В ccd -файле для клиента за которым первая подсеть:

И уберите ifconfig-push 10.8.0.5 255.255.255.0

Маршрут добавляется правильно, а не работает, потому что маршрутизация настроена неправильно. Для всех клиентов OVPN сети в ней один шлюз - 10.8.0.1 - он же сервер, маршрутизация внутри строится самим OVPN на основе опций route и iroute.

Если часть этой схемы будет не настроена или настроена неправильно, то она работать не будет.

определение айпи-адресов через файл ifconfig-pool-persist уже сделал ранее, не стал упоминать.
в ccd файле строка iroute 192.168.1.0 255.255.255.0 также присутствует, и название этого файла соответствует CN клиента (его содержание было указано в первом посте)

при этом, если прописать в конфиге сервера маршрут до первой подсети следующим образом: route 192.168.1.0 255.255.255.0, то ovpn-клиент (адрес 192.168.1.5) не будет пинговаться даже с сервера

[Уваров А.С.]

при этом, если прописать в конфиге сервера маршрут до первой подсети следующим образом: route 192.168.1.0 255.255.255.0, то ovpn-клиент (адрес 192.168.1.5) не будет пинговаться даже с сервера

Значит у вас неправильно настроена маршрутизация, все маршруты внутри OPVN сети с топологией subnet идут через объявленный в route-gateway шлюз. Проверяйте iroute для клиента.

А вот это:

Сеть за ovpn-сервером клиент не видит пока не сделать сетевой адаптер, который смотрит lan2, общедоступным (скриншот)
Такая же ситуация и с сетью lan1.

Косвенно говорит о том, что у вас не работает маршрутизация на узле.

Почему такой вопрос сейчас попробую объяснить, по факту ведь все равно как объявлять маршруты, статически писать их в таблице ОС или предположим я захочу использовать quagga зачем мне тогда директивы route, push route и ccd? Мне же нужен от openvpn только туннель, я не прав?

Не совсем так. В OVPN сейчас используется топология subnet, т.е. фактически мы отходим от традиционного для VPN режима точка-точка и имеем внутри VPN полноценную /24 сеть. Для управления маршрутизацией в ней и применяются опции iroute, именно они определяют маршруты внутри OVPN сети.  Директивы route - это указание маршрутов в системе, да, их можно написать руками, но особого смысла в этом нет.

[aborel]

Значит у вас неправильно настроена маршрутизация, все маршруты внутри OPVN сети с топологией subnet идут через объявленный в route-gateway шлюз. Проверяйте iroute для клиента.

А вот это:

Косвенно говорит о том, что у вас не работает маршрутизация на узле.

Не совсем так. В OVPN сейчас используется топология subnet, т.е. фактически мы отходим от традиционного для VPN режима точка-точка и имеем внутри VPN полноценную /24 сеть. Для управления маршрутизацией в ней и применяются опции iroute, именно они определяют маршруты внутри OVPN сети.  Директивы route - это указание маршрутов в системе, да, их можно написать руками, но особого смысла в этом нет.

iroute указан корректно, в логе сервера строки:

internal route 192.168.1.0/24 -> client/xx.xx.xx.xx:11054
Learn: 192.168.1.0/24 -> client/xx.xx.xx.xx:11054

имеются.




может подскажете, какая может быть проблема в работе службы маршрутизации (ОС чистая, никакие роли не развернуты, находится в домене)?
перенес сейчас серверную часть на вин10, проблема осталась

служба "Маршрутизация и удаленный доступ" также запускается в автоматическом режиме;
параметр IpEnableRouter в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters также выставлен в 1

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

дополнительно ipconfig впн-сервера (теперь уже вин10)
https://i.imgur.com/c2LS7KD.png
и пинги с впн-сервера до впн-клиента
https://i.imgur.com/d0XSIbK.png

[aborel]

даже не так:

локальный адрес овпн-клиента (192.168.1.5) не пингуется в любом случае, пингуется только впн-адрес

конфиг на данный момент:

Code Select Expand

server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
route 192.168.1.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"
в ccd только одна строчка

Code Select Expand

iroute 192.168.1.0 255.255.255.0
таблица маршрутизации на впн-сервере выглядит так
https://i.imgur.com/TN0zhM9.png

[Уваров А.С.]

На сервере все верно, сделайте трассировку к внутреннему адресу клиента и приведите таблицу маршрутизации с него. У вас в пинге отвечает почему-то внешний интерфейс, а это неправильно.

[aborel]

таблица маршрутизации с клиента:
https://i.imgur.com/vYg2Cpt.jpg

трасер лан-адреса клиента показывает, что пакет идет через шлюз по умолчанию, хотя по таблице маршрутов пакеты должны идти через впн-интерфейс
https://i.imgur.com/rRWBUBa.png

upd
вот еще трасер сразу после перезапуска овп-сервера и подключения к нему клиента
сначала пакет идет через нужный нужный интерфейс, потом через шлюз
https://i.imgur.com/Df1jJVJ.png

[Уваров А.С.]

А постоянный нулевой маршрут у вас зачем прописан? У него дистанция меньше чем у динамического. Следовательно пакеты пойдут на шлюз, а не в туннель.

[aborel]

А постоянный нулевой маршрут у вас зачем прописан? У него дистанция меньше чем у динамического. Следовательно пакеты пойдут на шлюз, а не в туннель.

постоянный нулевой маршрут добавлен автоматически при определении ip-адреса и шлюза вручную в параметрах сетевой карты

на овпн-клиенте ситуация с маршрутами аналогичная, но лан-адрес сервера пингуется корректно

[Уваров А.С.]

"Заданный узел недоступен" - это как раз нет маршрута. Скорее всего проблемы со службой маршрутизации на клиенте, что косвенно подтверждается включением общего доступа.

[aborel]

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

На овпн-клиенте служба маршрутизации так же работает в автоматическом режиме, параметр EpEnableRouter также выставлен в 1
В чем еще может быть проблема, если в сети по сути только компьютер и шлюз..
при пинге с сервера попрежнему 1ый пакет идет через овпн-сервер, дальше начинает работать основной шлюз

Code Select Expand

Обмен пакетами с 192.168.1.5 по с 32 байтами данных:
Ответ от 10.8.0.1: Заданный узел недоступен.
Ответ от 93.85.81.129: Заданный узел недоступен.
Ответ от 93.85.81.129: Заданный узел недоступен.
Ответ от 93.85.81.129: Заданный узел недоступен.

[Уваров А.С.]

У вас пакет дошел до шлюза OVPN сети и дальше не идет. Варианты: недоступен следующий узел или неверная маршрутизация. Поставьте с обоих сторон анализаторы трафика и посмотрите откуда и куда идут пакеты и что в них содержится.

[atlant_is]

Добрый день.
Я извиняюсь за некропостинг, но эту тему нагуглил как очень похожую на мой случай.
Есть два роутера, один на KeeneticOS, второй DD-WRT (свежая довольно).
На KeeneticOS сервер, за ним подсеть 192.168.1.0/24
На DD-WRT - клиент, за ним подсеть 192.168.11.0/24
Адреса в тунеле у сервера 10.100.10.1 у клиента 10.100.10.2. topology subnet
Суть проблемы - со стороны клиента прекрасно вижу подсеть 192.168.1.0/24 все работает, пинги ходят
Со стороны сервера (с компьютера в подсети 192.168.1.0/24) пингуется только роутер DD-WRT (192.168.11.1)
iroute в CCD файле прописаны, маршруты на роутерах тоже, пробовал любые варианты и случайно наткнулся вот на что. Если в конфиге клиента прописан route-delay то на время этой задержки (пробовал увеличивать, чтобы убедиться) со стороны сервера начинают ходить пинги в сеть 192.168.11.0/24 (не только 192.168.11.1 пингуется, а все устройства), как только таймаут истечет и включится роутер OpenVPN (я так это понимаю, потому что до истечения этой задержки туннель висит в состоянии ASSIGN IP) - перестает.
Зато со стороны клиента в это время подсеть 192.168.1.0/24 недоступна и начинает все работать только после применения маршрутов (логично), хотя я пробовал прописать маршруты на роутере явно, вне зависимости от состояния туннеля - все равно, начина.т работать только после "включения роутера OpenVPN", т.е. по истечении route-delay

На всякий случай покажу трейсы до истечения route-delay и после

Это пока delay не истек

Code Select Expand

Трассировка маршрута к ATLANTDACHA [192.168.11.89]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  192.168.1.1
  2   176 ms    50 ms     *     10.100.10.2
  3    98 ms   172 ms    14 ms  ATLANTDACHA [192.168.11.89]
Это после того как истек:

Code Select Expand

Трассировка маршрута к 192.168.11.89 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  192.168.1.1
  2   262 ms   214 ms    90 ms  10.100.10.2
  3     *        *        *     Превышен интервал ожидания для запроса.
Видно, что в обоих случаях маршрут успешно заворачивается в туннель, но на этом все.
Причем я пробовал вообще пробовал убирать "push route" из конфига, прописывать их на клиенте в конфиг OpenVPN, прописывать в таблицу роутера, куда угодно, результат одинаковый, к сожалению.

Просто не понимаю, куда ещё копать, это очень похоже на косяк именно в самом пакете OpenVPN в составе DD-WRT или что-то в этом духе...

[atlant_is]

Code Select Expand

iptables -I FORWARD 1 --source 10.100.10.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPTСам себе отвечу. Не хватало вот этого. Если роутер Keenetic, видимо, сам добавляет в свой нат нужные правила, то на DD-WRT это надо сделать руками. Спасибо за внимание, может, кому-то поможет )

[Уваров А.С.]

Скорее всего вам будет достаточно

Code Select Expand

iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
либо

Code Select Expand

iptables -I FORWARD -s 10.100.10.0/24 -i tun0 -o br0 -j ACCEPT
Приведенный вами вариант я бы использовать не стал. Первым правилом вы разрешаете транзит любых пакетов из сети 10.100.10.0/24 вне зависимости от того, откуда они пришли.

[atlant_is]

DD-WRT вообще себя довольно странно ведет.
Снова отказалось работать с любым из вариантов, зато нормально работает, если закомментировать команду для Firewall и сохранить...
Те самые танцы с бубном, что все админы любят )