28 марта 2024, 23:03

Цитата дня:

Успех -- это способность идти от поражения к поражению, не теряя оптимизма. Уинстон Черчилль


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

Автор aborel, 29 октября 2019, 15:09

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

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

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

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:

ifconfig-push 10.8.0.5 255.255.255.0

iroute 192.168.1.0 255.255.255.0

# disable


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

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

#5
30 октября 2019, 14:50 Последнее редактирование: 30 октября 2019, 15:02 от 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

#9
30 октября 2019, 16:43 Последнее редактирование: 30 октября 2019, 16:45 от aborel
Со стороны маршрутизации как сетевого уровня проблем нет, маршруты все рабочие. А какое сообщение при пинге приходит?
превышен интервал ожидания для запроса
во втором посте еще есть скрин с трасером с клиента сети 192.168.12.0 до овпн-клиента

ival

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

aborel

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

Уваров А.С.

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

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 -файле для клиента за которым первая подсеть:

iroute 192.168.1.0 255.255.255.0

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

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

#16
31 октября 2019, 09:33 Последнее редактирование: 31 октября 2019, 09:40 от 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) не пингуется в любом случае, пингуется только впн-адрес

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

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 только одна строчка

iroute 192.168.1.0 255.255.255.0

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

Уваров А.С.

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

aborel

#19
31 октября 2019, 10:49 Последнее редактирование: 31 октября 2019, 11:03 от aborel
таблица маршрутизации с клиента:
https://i.imgur.com/vYg2Cpt.jpg

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

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

Уваров А.С.

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

aborel

#21
31 октября 2019, 11:59 Последнее редактирование: 31 октября 2019, 12:03 от aborel
А постоянный нулевой маршрут у вас зачем прописан? У него дистанция меньше чем у динамического. Следовательно пакеты пойдут на шлюз, а не в туннель.
постоянный нулевой маршрут добавлен автоматически при определении ip-адреса и шлюза вручную в параметрах сетевой карты

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

Уваров А.С.

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

aborel

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

Обмен пакетами с 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 не истек
Трассировка маршрута к 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]


Это после того как истек:
Трассировка маршрута к 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

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 это надо сделать руками. Спасибо за внимание, может, кому-то поможет )

Уваров А.С.

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

iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

либо

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 и сохранить...
Те самые танцы с бубном, что все админы любят )

Вверх