Как минимум должны быть маршруты на openvpn сервере и на хосте в сети vpn в сеть за роутером. Хост за роутером не за NAT?

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

ОТВЕТ №1

Назначил имена участникам сети (A, B, C, D) - https://prnt.sc/mfn0ge Отключил NAT на роутере - http://prntscr.com/mfn2h4 Вопрос какие именно маршруты должны быть на сервере openvpn «C» ? И если я правильно понимаю, в случае если маршруты есть на сервере, они дублируются через конфиг на клиенты, верно?

root@pritunl:/home/enemy# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 enp0s10 192.168.0.0 * 255.255.255.0 U 0 0 0 enp0s10 192.168.240.0 * 255.255.255.0 U 0 0 0 tun1 192.168.245.0 * 255.255.255.0 U 0 0 0 tun17 192.168.250.0 * 255.255.255.0 U 0 0 0 tun14

Дефолтная таблица, которая сейчас в данный момент на сервере «С», добавлять пробовал по разному цель 192.192.5.0/24 через 192.168.245.1 и через 245.56, всё безтолку. Пробовал и такое добавлять 192.168.0.0/24... Пробовал также добавлять правило маршрутизации 192.168.5.0/24 через web интерфейс pritunl, в этом случае происходил конфликт с настройками на роутере асус... короче всё что я пробовал до жопы, нужно прописать то что заработает.

Лучше покажи таблицы маршрутизации на A и D.

Я так подозреваю, B есть маршрут по умолчанию для своей локалки, а C нет? Хотя, если проходит всё в одну сторону, то странно. В общем, маршруты на всех узлах интересны. Или, наверное, D это клиент к VPN серверу?

«B» - это роутер асус, он в локалке с «A»

«D» - это клиент VPN сервера «C».

маршруты:

таблица A - http://prntscr.com/mfoacq

таблица D - http://prntscr.com/mfoape

Поищи аналог traceroute под винду и попробуй им глянуть как далеко пакету удаётся улететь. Ping такая вещь, что он может быть банально отключен.

в случае если маршруты есть на сервере, они дублируются через конфиг на клиенты, верно?

Только те маршруты, которые сконфигурированны посредством openvpn, и только если в конфиге прописан push для них.

команда tracert ?

При этой команде пакет стопарится на шлюзе 192.168.245.1

Это сервер openvpn «C»

Судя по картинке, у тебя в принципе нет маршрута в сеть 5.0/24 на этом шлюзе.

Вот ещё на почитать: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

Обрати внимание на masquerading.

Да, я всё что прописывал удалил, до первоисходного состояния, чтобы Вам легче было понять.

Что нужно прописать на сервере openvpn чтобы он указал куда перенаправлять пакеты из хоста D в хост A?

Ну тут всё понятно. Тебе надо просто в конфиге VPN сервера дописать, чтобы пушился маршрут на клиентов через него на сеть 192.168.5.0/24. Потому что у тебя сейчас проблема, что на клиенте VPN есть только маршрут по L2 в сеть VPN, а для всего остального он использует свой маршрут по умолчанию.

ПС: а с A на D ходит потому что у A асус оно же и клиент к VPN, поэтому маршрут уходит сначала туда, далее он знает, что это по VPN, уходит на VPN сервер, VPN сервер знает своих клиентов и по L2 прокидывает пинг дальше, по L2 клиент отвечает и далее в обратном порядке ответ пинга уходит. ППС: push route или типа того на сервере. Погугли сначала сам, поэкспериментируй. Если не получится, я тебе потом напишу что конкретно куда писать.

Кстати, и на VPN сервере маршрута до 192.168.5.0/24 у тебя нет. Надо прокладывать через 192.168.245.56. На VPN сервере то пингуются 192.168.5.1 и 192.168.5.147?

1. В конфиг сервера
route 192.168.5.0 255.255.255.0
2. В конфиг сервера или ccd клиента D 245.4 (если нужно только ему)
push "route 192.168.5.0 255.255.255.0"
3. В ccd клиента B 245.56
iroute 192.168.31.0 255.255.255.0

Нет, пинга с сервера openvpn «C» до хостов 192.168.5.1 и 192.168.5.147 нету!

Маршрут до 192.168.5.0/24 я добавлял, по разному, возможно ошибочно, как именно нужно добавить маршрут на «C» до 192.168.245.56 чтобы он заработал?

Кстати при добавлении роута на 192.168.5.0/24 из вебинтерфейса PRITUNL - у меня вылазил конфликт маршрутизации на роутере асус «B», почему? И так же в ответ тишина от хостов 192.168.5.0/24...

Клиенту «D» - я прописывал роутинг вручную из командной строки, он перенаправляет пакеты 192.168.5.0 на 192.168.245.1 и там стопориться...

3. В ccd клиента B 245.56 iroute 192.168.31.0 255.255.255.0

192.168.31.0 - это кто?

Мля автоматом набрал, думая о другом :)
iroute 192.168.5.0 255.255.255.0

У тебя на B и C должна быть разрешена маршрутизация ip_forward (/proc/sys/net/ipv4/ip_forward). Затем, на C у тебя должно работать если в консоли пропишешь

ip route add 192.168.5.0/24 via 192.168.245.56

Если всё норм пропингуется, придумаем куда его прописать.

Проверил включена ли маршрутизация на «С» командой:
sysctl net.ipv4.ip_forward.

Вроде ок. Как проверить включен ли ip_forward на «B» роутере asus RT-AC52U B1??? Через SSH по адресу (/proc/sys/net/ipv4/ip_forward) файл ip_forward присутствует, но внести какие либо корректировки через vi не получается, сохраняю через ESC :wq! захожу, снова пусто.. Может это можно сделать как то иначе?

В консоли «C» прописал команду:
ip route add 192.168.5.0/24 via 192.168.245.56

Пингов на 192.168.5.0 нет! traceroute пусто... Скрин консоли «C» https://prnt.sc/mgcjvd

Как проверить включен ли ip_forward на «B» роутере asus RT-AC52U B1???

Можно считать, что там включено. Без этого он инет раздавать не смог бы.

Пингов на 192.168.5.0 нет!

А сам 192.168.245.56 пингуется? Возможно, там проблема ещё с тем, что на маршрутизаторе асус настроен файрволл и он левые сетки отсекает, коим и считает сеть с VPN.

Почитай таки про маскарадинг. Ну, или, если интерес академический, пошукай для начала tcpdump'ом. Нет на асусе? ССЗБ надо было брать зиксель а не это оверпрайснутое г.

192.168.245.56 пингуется с сервера openvpn «C».

Тогда думаю, что там файрволл режет. Какие там настройки файрволла?

firewall «брандмауэр» выключен - http://prntscr.com/mh9c8w

Пинги в сеть 192.168.5.0/24 с «C» на «B» не идут при включенном ip route на «C»:
ip route add 192.168.5.0/24 via 192.168.245.56[/br]

Какие есть ещё предположения?

Мне кажется что мы что-то не так делаем, я не уверен, что эта команда действительно перенаправляет запросы 192.168.5.0/24 через 192.168.245.56, потому, что в команде traceroute из консоли сервера «C» не отображается последовательность вообще, как будто игнорируется эта маршрутизация и вовсе..

Вот например в Windows из командной строки при включении маршрутизации 192.168.5.0/24 через 192.168.245.1 сразу видно что маршрут пошёл через заданный шлюз.. Не знаю, может это специфика конкретно этой команды в ОС Ubuntu... Или нет?

Интересное виденье открывает tcpdump

Всё таки идёт перенаправление пакетов 192.168.5.0 через 192.168.245.1 и далее на 192.168.245.56 если я правильно понял эти строки из tcpdump http://prntscr.com/mh9x6f

Это отображается в консоли «C» при попытке пропинговать «B» из командной строки «D».

Но ответа по прежнему нет, куда копать? :)

Куда копать сейчас не скажу, а в общем и целом, рекомендую текстовую информацию передавать в текстовом виде :)

Тебе нужно понять до какой машины пакет не долетает в обе стороны в общем случае. Потом на том хосте где пакет не передаётся дальше исправлять ситуацию и проверять дальше.

Вангую, что у тебя где то недонастроен nat (google: iptables masquerading vpn), или маршрутизация.

Боюсь, под брандмауром они понимают немного другое. Внешний адрес же роутера извне не пингуется? Можно на его вебку зайти?

Ну чтобы понять, что работает маршрут, посмотри на C

ip route get 192.168.5.1

Но ответа по прежнему нет, куда копать? :)

Я по прежнему думаю, что виноват маршрутизатор и файрволл на нём. Посмотри пока на него OpenWRT влезает?

Прописал на «C»:
ip route get 192.168.5.1

Выдал:
enemy@pritunl:~$ ip route get 192.168.5.1 192.168.5.1 via 192.168.245.56 dev tun3 src 192.168.245.1 cache - это значит работает?

Внешний адрес не пингуется (ip адрес провайдера серый), на вебку зайти нельзя (из вне).

Да, всё правильно, по идее, туда и уйдёт. А VPN адрес нормально пингуется?

Да 192.168.245.56 «B», пингуется со всех сторон «A» «B» «C» «D».

На В что показывает?

 
iptables -L

iptables -L с роутера "B"

admin@(none):/tmp/home/root# iptables -L

Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED DROP all -- anywhere anywhere DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate DNAT

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Chain ACCESS_RESTRICTION (0 references) target prot opt source destination

Chain FUPNP (0 references) target prot opt source destination

Chain INPUT_ICMP (0 references) target prot opt source destination

Chain PControls (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere

Chain PTCSRVLAN (0 references) target prot opt source destination

Chain PTCSRVWAN (0 references) target prot opt source destination

Chain SECURITY (0 references) target prot opt source destination RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST RETURN icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 DROP icmp -- anywhere anywhere icmp echo-request RETURN all -- anywhere anywhere

Chain logaccept (0 references) target prot opt source destination LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "ACCEPT " ACCEPT all -- anywhere anywhere

Chain logdrop (0 references) target prot opt source destination LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP " DROP all -- anywhere anywhere admin@(none):/tmp/home/root#

Да, куча правил файрволла. ) Хотя, вроде, разрешать должно, но что-то надо вникать.

Просто FORWARD какой-то непонятный. Вроде разрешает, а вроде и дропает.

На всякий случай уточню, вы сделали то что я советовал выше?
Сеть за роутером подключенным к сети VPN (комментарий)
Сеть за роутером подключенным к сети VPN (комментарий)

Да, куча правил файрволла. ) Хотя, вроде, разрешать должно, но что-то надо вникать.
Просто FORWARD какой-то непонятный. Вроде разрешает, а вроде и дропает.

Да вы прямо «знаток» iptables как я посмотрю. Даже интересно, вы зачем спрашивали если один фиг непонимаете выхлоп?
2ТС в фильтре все открыто. Но могут быть правила в nat,mangle. Точнее в nat-то по любому есть :)

Всё сделал, но не через конфиг, а через консоли.

На «С» в консоли прописал:
ip route add 192.168.5.0/24 via 192.168.245.56
Для перенаправления трафика в сеть 5.0 через 245.56

В консоли на «D» прописал перенаправление:
route add 192.168.5.0 mask 255.255.255.0 192.168.245.1
для того, чтобы 5.0 шли через шлюз openvpn 245.1

Для «B» уточню, т.к. команда опасная, можно потерять связь до роутера. А нет ли этого правила уже в маршрутизации? И можно ли его прописать не через ccd? И на сколько обязательно выполнить все эти команды именно через сервер openvpn? Т.к. я хз, где там конфиг даже лежит, этож pritunl :) Я его и поставил чтобы головняков небыло! До этого момента всё было как по маслу :)
admin@(none):/tmp/home/root# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.81.11.145 * 255.255.255.255 UH 0 0 0 vlan2 239.255.255.250 * 255.255.255.255 UH 0 0 0 br0 10.81.11.144 * 255.255.255.248 U 0 0 0 vlan2 192.168.240.0 192.168.245.1 255.255.255.0 UG 0 0 0 tun15 192.168.5.0 * 255.255.255.0 U 0 0 0 br0 192.168.245.0 * 255.255.255.0 U 0 0 0 tun15 192.168.250.0 192.168.245.1 255.255.255.0 UG 0 0 0 tun15 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 10.81.11.145 0.0.0.0 UG 0 0 0 vlan2 admin@(none):/tmp/home/root#

Да вы прямо «знаток» iptables как я посмотрю. Даже интересно, вы зачем спрашивали если один фиг непонимаете выхлоп?

Даже не знаю тогда зачем читать сообщение, если всё равно не понимаете его?

На «С» в консоли прописал:
ip route add 192.168.5.0/24 via 192.168.245.56
Для перенаправления трафика в сеть 5.0 через 245.56

Ты же говорил, что это не помогает.

В консоли на «D» прописал перенаправление:
route add 192.168.5.0 mask 255.255.255.0 192.168.245.1
для того, чтобы 5.0 шли через шлюз openvpn 245.1

Чтобы на узлах типа D не прописывать, можно через конфиг сервера маршрут пушить.

Без iroute iroute 192.168.5.0 255.255.255.0 в файле ccd клиента B работать не будет (на всякий случай уточняю, файлик правиться на сервере).
Поясняю почему. tun это L3. Вот у вас есть сервер ovpn предположим на интерфейсе tun0, сеть 10.0.0.0/24 ip сервера 10.0.0.1. К нему подключены клиенты C2 10.0.0.2, C3 10.0.0.3, C4 10.0.0.4, за клиентом C1 есть сеть 192.168.5.0/24. Прописан роутинг, отправлять пакеты для 192.168.5.0/24 через tun0.
Теперь с сервера отправляем пакет на 192.168.5.7, пакет попадает на tun0 на котором работает openvpn, но какому клиенту ему отправлять пакет: C1,C2,C3,C4 ? Он этого не знает. Для этого и прописывается в ccd соответствующего клиента опция iroute. В данном примере в файле ccd/C1 нужна строка iroute 192.168.5.0 255.255.255.0

PS Можно и без ccd с iroute, обычным роутингом, но только tun на tap(tap это L2) надо везде(и на сервере и на клиентах) поменять. Так что эта процедура «чуть» посложнее, чем найти конфиги на сервере :)

этож pritunl :)

Ради интереса погуглил шо це за зверь.

Я его и поставил чтобы головняков небыло!

Ну да, реально без «головняков», но с маленьким «но» :) https://docs.pritunl.com/docs/network-links

Верно не помогает!

Это «anc» спросил меня делал ли я.. и перечень пунктов, я ответил для него, что я сделал!

Но это не помогло! А предложение «Все сделал... » с чего я начал свой комментарий «07.02.2019 9:11:54» могло ввести Вас в заблуждение, что проблема решена, но это не так. По прежнему не пингуется заданная сеть.

Ну вот любопытство мистера «anc», подбросило в это пекло ещё немного дровишек :)) А я всё думал, где у них тут заканчивается та грань, невероятно чудесной страны по имени PRITUNL. А вот же она! Хотите сеть за роутером, платите баблишко :)

Попробую найти конфиг сервера.

Ну я всё еще грешу на асус. :) У тебя есть возможность его заменить чем-нибудь?

Попробую найти конфиг сервера.

Как я и думал, толку это не даст. Конфиг генерится самим pritunl при запуске сервера в /tmp/pritunl_*/*. Так что в целом у вас два варианта, или бабло или настроить ovpn (что весьма просто, статей не то что много, а очень много).

Ну я всё еще грешу на асус. :) У тебя есть возможность его заменить чем-нибудь?

Даже если предположить, что в этом топике вы читаете только ответы ТС и не разбираетесь в ovpn, то все равно предлагать заменить работающее железо ради теста софта - это офигительно мудрый совет.
Открою секрет, только не кому не говорите - есть такая штука как виртуальные машины которые можно использовать для тестирования.