обеденить сети

Давай схему сети.

а что у тебя в iptables у 10.10.10.1? вангую что forward сделал, а на input болт забил :))

дада. только вспомнил. там то и нет ничего. вообще. можете накидать что можно прописать. а завтра буду уже изучать что да почему...

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

Поэтому, если тебе нужны советы, то рисуй схему сети.

вот схема

https://ibb.co/iwnLTx

маскардинг и форвардинг на 10.10.10.6 tun100 есть?

или таблицу маршрутизации настраивать

обеденить сети

не совсем понятно, ты хочешь НАКОРМИТЬ(обедом накормить) сеть, или её ОБАНКРОТИТЬ(бедной сделать) ?? =)

Если main сервер является шлюзом для сети A и B и т.е. на нём включен IP forwarding, то на 10.10.10.1 достаточно прописать маршрут, что сети 172.10.10.0 и 192.168.10.0 доступны через IP 10.10.10.6.

Если на VPN сервере прописывать маршруты нельзя, тогда делай NAT на main сервере для пакетов с адресом назначения в сети 10.10.10.0.

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

маршруты через route или ip route ??? forwarding само собой включен.

Либо маршруты на VPN сервере, либо просто NAT на main сервере.

хорошо. сейчас попробую. отпишу по результатам

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

ip route add 192.168.10.0/24 via 10.10.10.6
RTNETLINK answers: Network is unreachable 

и такое. успешно но реакции ноль. с сети 192.168.10.0 так и проходил пинг на 10.10.10.6, но на 10.10.10.1 не проходил

ip route add 192.168.10.0/24 dev tun1

с сервера на клиент пинги ходят (с сервера с приложением на меин сервер)

ping 10.10.10.6
PING 10.10.10.6 (10.10.10.6) 56(84) bytes of data.
64 bytes from 10.10.10.6: icmp_seq=1 ttl=64 time=59.5 ms
64 bytes from 10.10.10.6: icmp_seq=2 ttl=64 time=59.7 ms

«Зевая» iroute в ccd клиента?

вот что добавил на сервере где приложение в /etc/openvpn/ccd/apps

iroute 192.168.10.0 255.255.255.0

и в конфиг

client-config-dir /etc/openvpn/ccd

не помогло( без изменений

1. У вас две сети, вторую тоже добавляйте в iroute, отдельной строкой. Но это так...
2. Добавьте еще route в конфиг сервера ovpn для этих сетей.

route 192.168.10.0 255.255.255.0
route 172.10.10.0 255.255.255.0

безрезультатно.

повторюсь. на сервере где рпиложение поднят сервер опенвпн. он имеет адрес 10.10.10.1 на нем собственно и висит приложение нужно чтобы с сетей А и В было доступно приложение - 10.10.10.1 с главного сервера пингуеться 10.10.10.1 но с какой то клиентской тачки с 192.168.10.0/24 недоступен 10.10.10.1

но доступен только 10.10.10.6 (интерфейс клиента впн на главном сервере) нужно какие то роуты добавить, но не знаю какие

Тогда традиционно, в студию:
Конфиг сервера и клиента
ip r s - с сервера и клиента
И что бы два раза не вставать то iptables-save, вдруг fw виноват.

сервер с приложением

cat /etc/openvpn/server.conf 
port 1444
proto udp
fast-io
dev tun1
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh2048.pem
server 10.10.10.0 255.255.255.0
client-to-client
topology subnet
keepalive 10 120
comp-lzo
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
push "dhcp-option DNS 8.8.8.8"
sndbuf 0
rcvbuf 0
push "sndbuf 4024000"
push "rcvbuf 4024000"
mssfix 0
client-config-dir /etc/openvpn/ccd
route 192.168.10.0 255.255.255.0
route 172.10.10.0 255.255.255.0

ip r s

default via Х.Х.Х.Х dev ens3 onlink 
10.10.10.0/24 dev tun1 proto kernel scope link src 10.10.10.1 
X.X.X.0/24 dev ens3 proto kernel scope link src X.X.X.X 
172.10.10.0/24 via 10.10.10.2 dev tun1 
192.168.10.0/24 via 10.10.10.2 dev tun1 

то же самое только с клиента (мейн сервера)

client
dev tun100
proto udp
remote X.X.X.X  1444
resolv-retry infinite
nobind
persist-tun
comp-lzo
topology subnet

<ca>
</ca>

<cert>
</cert>

<key>
</key>

ip r s

10.10.10.0/24 dev tun100 proto kernel  scope link  src 10.10.10.2
192.168.10.0/24 via 192.168.10.2 dev tun101 
192.168.10.2 dev tun101  proto kernel  scope link  src 192.168.10.1

остальное ненужное

iptables на сервере пустой

на клиенте так же пустой

А вот с этого места по подробнее плиз.

192.168.10.0/24 via 192.168.10.2 dev tun101

На вашей схеме нет никакого tun101 и более того сеть 192.168.10.0/24 висит на eno2.
Где-то вы таки врете в постановке задачи.

данный момент был упущен. сеть 192.168.10.0/24 удаленный филиал и потому через впн подключен. но суть в том что нет маршрутизации с того самого tun101 на tun100. Возможно я виноват. Желая как можно больше спростить схему много выкинул. Реально схема ооооочень большая, и переживал что что то собьет с толку

сяду книжки по роутингу читать. но именно в данный момент нужна помощь

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

Нет слов^W Подкидываете сюда фэйк и просите по нему вам помочь? Не, ну серьезно, вам самому не смешно? Рисуйте реальную.

Наискосок ваш «удаленный филиал» ничего не знает о сети 10.10.10.0/24 надо ему об этом сообщить.

простите. данная схема реальна. просто вместо eno2 tun101 и сеть 192.168.10.0/24 тоже за ОВПН. все. больше нет ничего что относиться к данному вопросу.

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

просто вместо eno2 tun101
и сеть 192.168.10.0/24 тоже за ОВПН

Афигеть насколько небольшая разница...

еще раз простите. виноват

Все тоже самое на втором ovpn iroute/route/push «route »
Теперь показываем конфиги со второго ovpn. Да и ip r s так же

по сути конфиги такие же. только ипы другие. ip r s которые относятся к данной сети скидывал

ip r s которые относятся к данной сети скидывал

Я не вижу третьего.

клиент клиента??? а да. с которого должен быть доступен 10.10.10.1

default via 192.168.10.70 dev tun0 proto static metric 50 
default via 192.168.0.1 dev wlp2s0 proto static metric 600 
Y.Y.Y.Y via 192.168.0.1 dev wlp2s0 proto static metric 600 
169.254.0.0/16 dev wlp2s0 scope link metric 1000 
192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.106 metric 600 
192.168.10.0/24 via 192.168.10.70 dev tun0 proto static metric 50 
192.168.10.70 dev tun0 proto kernel scope link src 192.168.10.69 metric 50 

на данный момент только такой клиент доступен. все как есть кидаю.

Y.Y.Y.Y - айпи второго сервера (майн сервер)

Вооот, вы видите в таблице сеть 10.10.10.0/24 ? И я не вижу. А говорите «по сути конфиги такие же»
Вам нужен push "route 10.10.10.0 255.255.255.0" в конфиге сервера 192.168.10.0/24

Хотя, стоп, я не прав. Он у вас defgw вроде как по метрикам.

Или чего-то уже не вижу, или должно работать. Посмотрите tcpdump на сервере 10.10.10.1 при пинге с клиента 192.168.10.x, пакеты точно долетают? Да и в промежутке на том который main на двух интерфейсах не лишнее. Надо понять где теряются.
Еще из возможных ошибок, название файла в ccd на apps не соответвует имени клиента, т.е. iroute не срабатывает. Проверить можно временным добавлением сроки в ccd клиента например такой push "route 1.1.1.1 255.255.255.255" после поднятия тунеля на main в ip r s должна появиться запись 1.1.1.1

Ты там привёл странный вывод route.

Во-первых, суть в том, что в моих советах я учитывал, что main сервер является шлюзом для всех сетей, а в вывод route у тебя вообще другие IP адреса.

Во-вторых, когда ты добавляешь маршрут через IP адрес VPN клиента на VPN сервере уже должно быть установлено подключение между клиентом и сервером.

который именно странный. соединения установлены

обеденить сети (комментарий)

На приведённой схеме у main сервер другие IP адреса, а не те, что default маршрутах.

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

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

Что? У вас на схеме сеть 192.168.10.0 подключена напрямую к MAIN серверу, там у вас не указано никакого ВПН.

Что бы ТС не повторяться, просто прочитайте все посты в переписке со мной выше.

в переписке с anc (выше) я уточнил что сильно упрощал и не сказал что 192.168.10.0/24 тоже за впн. И Вы простите.

вот самая актуальная и правильная схема https://ibb.co/dMkayx

Это уже можно было и не рисовать. И так додумались :) Так что с tcpdump?

делал трейсроут. уходит в роут по дефолту.

трейсроут на 10.10.10.1 лезет в дефолтный роут мейн сервера который идет в интернет

трейсроут на 10.10.10.1 лезет в дефолтный роут мейн сервера который идет в интернет

Уточню что бы не было путаницы.
С клиента 192.168.10.x мы запускаем traceroute на 10.10.10.1. Но вместо того что бы пакеты ушли с tun100 в сторону app они улетают в инет с интерфейса main сервера?
Если все верно, нет ли у вас там еще кучи подводных камней в виде iproute2+iptables ?
ЗЫ traceroute это хорошо, но все-таки запустите tcpdump на всех четырех интерфейсах (клиент 192.168.10.x, main server, main client for app, server app) и покажите сюда при одновременно снятых ip r s со всех трех. Попой чую где-то что-то не договорили вы нам. У вас настолько тривиальная задача в чистом виде, что бы не заставить работать надо постараться.