Не понимаю как задать маршрут..

А что мешает прописать маршруты к машинам 192.168.0.241-245 через vpn-серверы, на которых проброшены туннели?

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

А что мешает прописать маршруты к машинам 192.168.0.241-245 через vpn-серверы, на которых проброшены туннели?

Зачем гнать трафик до соседней машины через впн-сервер на другом конце планеты? Или я не правильно понял мысль? Кстати, конфиг удаленных впн-серверов редактировать я не могу..

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

Вот если б вкратце пояснили как это делается.. У меня не хватает навыков..

Вот если б вкратце пояснили как это делается..

Маркировка пакетов:

iptables -t mangle -I PREROUTING -m iprange --src-range 192.168.0.241-192.168.0.245 -d 192.168.2.0/24 -j MARK --set-mark 0x2

Маршрутизация:

ip rule add fwmark 0x2/0x2 lookup main

iptables -t mangle -I PREROUTING -m iprange --src-range 192.168.0.241-192.168.0.245 -d 192.168.2.0/24 -j MARK --set-mark 0x2 

почему-то меняется на

 -A PREROUTING -d 192.168.2.0/24 -m iprange --src-range 192.168.0.241-192.168.0.245 -j MARK --set-xmark 0x2/0xffffffff 

и не работает..

Значение метки неважно, можете любое выбрать. Главное, чтобы оно совпадало в этих двух командах.

Туннели поднимаются на шлюзе с помощью скриптов типа:
openvpn --config /etc/openvpn/vpn1.conf &
sleep 2
ip rule add from 192.168.0.241 table vpn1.out
ip route add default dev tun1 table vpn1.out

Достаточно «не разумный скрипт».
1. ip route add У ovpn есть параметр up в него и нужно прописать путь до скрипта с роутингом. А не заниматься ерундой со sleep
2. ip rule add. В случае перезапуска вашего скрипта эти правила у вас будут плодиться. Достаточно при старте системы прописать эти правила. Это по простому. Или вычищать при перезапуске ovpn.

Немного критики
1. Зачем маркировать если тут достаточно правил ip rule ?
2. fwmark 0x2/0x2 зачем тут указываем маску ?
3. Если ТС сделал как вы написали (ip rule add fwmark 0x2/0x2 lookup main) а скорее всего он так и сделал, добавив его после «ip rule add from 192.168.0.241 table vpn1.out» то это правило уже не сработает.

Достаточно «не разумный скрипт».

1. ip route add У ovpn есть параметр up в него и нужно прописать путь до скрипта с роутингом. А не заниматься ерундой со sleep 2. ip rule add. В случае перезапуска вашего скрипта эти правила у вас будут плодиться. Достаточно при старте системы прописать эти правила. Это по простому. Или вычищать при перезапуске ovpn.

Спасибо, переделаю попозже.. Насколько я понимаю на работоспособность оно не влияет..

Сейчас бы разобраться как решить проблему..

 ip rule add fwmark 0x2/0x2 lookup main 

Я не очень понял что конкретно ты делаешь, но скажу так iptables только фильтрует и изменяет входящие в систему и исходящие из системы пакеты, она не перебрасывает их между интерфейсами и не перемещает пакет с входных цепочек на выходные или наоборот, выходных на входные.

Команда route определяет только то, в выходную цепочку какого интерфейса будет направлен пакет.

Перенаправлением пакетов или маршрутизацией занимается программа bridge-utils.

П.С. Гуру следует бы знать, что новички часто думают что команда route управляет не только тем на какой интерфейс будет отправлен исходящий пакет, но и перенаправляет пакеты между интерфейсами, в частности после изменения адреса в iptables, что вообще не так.

Есть сервак, который натит офисную сетку (192.168.0.1-192.168.0.240)
Есть несколько виртуальных машин с адресами 192.168.0.241-192.168.0.245, которые в интернет ходят через опенвпн. У каждой свой туннель.
На этом же сервере поднят опенвпн-сервер, который выдаёт удаленным пользователям адреса из подсети 192.168.2.0/24

Так вот, офисные сотрудники (192.168.0.1-192.168.0.240) могут подключаться на эти виртуалки по рдп. А удаленные сотрудники (192.168.2.0/24) не могут.
По-моему элементарная задача, но у меня скилл не прокачан.

А тем удалёнщикам, которые 192.168.2.0/24, маршрут на 192.168.0.0/24 сетку раздается?

Не важно что у тебя там, важно что не только каждый хост, но и каждая виртуалка, сервер или клиент это отдельный сетевой интерфейс и если тебе надо перегонять пакеты с одного интерфейса на другой то делать это надо отдельной программой со своим отдельным конфигом.
Программа называется bridge-utils, как с ней работать разбирайся сам.

Могу сказать иначе, тебе в LAN надо поставить *зеркало* которое будет отражать пакеты от *vpn сервера* обратно в *сервер* чтобы их увидели виртуалки так же, как и других пользователей LAN.
Делается такое *зеркало* программой bridge-utils внутри сервера.

У него уже прямо сейчас

офисные сотрудники (192.168.0.1-192.168.0.240) могут подключаться на эти виртуалки по рдп

Да, в /etc/openvpn/server.conf есть строка push «route 192.168.0.0 255.255.255.0 192.168.2.1»

А ещё удалёнщики (192.168.2.0/24) могут подключаться к офисным сотрудникам (192.168.0.1-192.168.0.240)

А если

-A POSTROUTING -s 192.168.0.241/32 -o tun1 -j MASQUERADE

заменить на

-A POSTROUTING -s 192.168.0.241/32 -d !192.168.2.0/24 -o tun1 -j MASQUERADE

Пробовал, не помогло (только "! -d", а не "-d !")

Хммм, а для начала 192.168.2.1 пингуется с виртуалок?

Ну вот как-то так

 C:\Users\Администратор>ping 192.168.2.1

Обмен пакетами с 192.168.2.1 по с 32 байтами данных:
Ответ от 192.168.2.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.2.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.2.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.2.1: число байт=32 время<1мс TTL=64

Статистика Ping для 192.168.2.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

C:\Users\Администратор>tracert 192.168.2.3

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

  1    <1 мс    <1 мс    <1 мс  gw.gr.local [192.168.0.1]
  2  gw.gr.local [192.168.0.1]  сообщает: Заданный узел недоступен.

Трассировка завершена.

C:\Users\Администратор>

gw.gr.local [192.168.0.1] сообщает: Заданный узел недоступен.

Хммм. А в FORWARD ничего не затесалось с reject-with icmp-host-unreachable или чем подобным?

Нет.. ничего такого..

Как насчет выхлопа ip addr, ip route, iptables -L и brctl show?

[root@gw /]# brctl show bridge name bridge id STP enabled interfaces [root@gw /]#

Вот тут должна быть информация о соединении выхода сервера openvpn и интерфейсов виртуальных машин или одного интерфейса ведущего к ним, ну или отправка пакетов в lo из которой пакеты попадут к интерфейсам локальных машин.
Ранее я писал:

Перенаправлением пакетов или маршрутизацией занимается программа bridge-utils.

В общем изучай как работать с этим пакетом, команда brctl оттуда.

Таааак, стоп.

А каким образом вообще сеть появляется на виртуалках?

Стандартно в libvirt, насколько я понимаю, создается виртуальный мост, к которому цепляются виртуальные адаптеры и (в зависимости от конфигурации) физический адаптер хоста.

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

Что говорит выхлоп ps ax | grep qemu?

лол)))
Извините, что я вас запутал, ребята... Но я не говорил, что виртуалки подняты на этом же сервере...
Они лежат на соседнем серваке))

Вот тут должна быть информация о соединении выхода сервера openvpn и интерфейсов виртуальных машин

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

Они лежат на соседнем серваке))

THANK YOU MARIO! BUT OUR PRINCESS IS IN ANOTHER CASTLE

ЛОЛ XD

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

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

Каждый порт имеет вход(конец Chain OUTPUT) и выход(начало Chain INPUT) и сама ОС так же имеет порт который так же имеет вход и выход.
По умолчанию все порты соединяются с портом ОС.
Чтобы соединить порты между собой надо сделать специальные настройки, той-же brctl скорее всего.

iptables просто определяет какие пакеты могут приходить или уходить с конкретного порта и как их надо изменять.

route определяет какие пакеты исходящие из порта ОС на какой порт надо отправлять.

Ни то, ни другое не соединит два не ОС порта между собой.

Вообще гуглить надо, всё это ты должен был раскопать или понять сам когда я тебе рассказал про bridge-utils. А сейчас получается что я тебе по сути бесплатный мануальник написал.

Перенаправлением пакетов или маршрутизацией занимается программа bridge-utils.

Вы вообще сейчас вообще о чем? «Программа» называется iproute2
То что выше предложил Serge10 с маркировкой вроде должно сработать (во всяком случае наискосок не вижу причин почему бы и не сработать), только правило должно быть выше исходного в ОП.

Ты точно понимаешь разницу между коммутатором и маршрутизатором?

Щас перечитал ОП, и подумалось

ip route add 192.168.2.0/24 via 192.168.0.1

должно быть

ip route add 192.168.2.0/24 via 192.168.0.1 table vpn1.out

Что такое ОС и не ОС порты?

Зачем их соединять?

Объединять мостом интерфейсы нужно если между ними нужно дублировать ethernet фреймы.

Для соединения разных сетей это бессмысленно, потому что tcp/ip так не работает - машины из разных сетей будут говорить друг с другом через маршрутизатор и подставлять в dst mac мак адрес шлюза. Такие фреймы будут отбрасываться машинами из другой сети, даже если закинуть их туда через бридж и dst ip совпадает.

Тем более бридж не имеет смысла в контексте tun-девайсов, поскольку они level 3, про ethernet ничего не знают, mac-адреса не имеют, в бридж тупо не добавятся.

А, да, еще

ip route list table vpn1.out

и

ip rule list

Я настраивал много лет назад шлюз между провадером и домашней сеткой, тогда я никак не мог добиться работы шлюза пока мне не сказали что iptables и route для шлюза недостаточны и надо ещё настраивать bridge.
Хотя может я хотел прозрачную маршрутизацию?
Но вроде было всё обычно.
В общем пока не поставил bridge ничего не работало.
Ну и сейчас virt-manager мне помнится в зависимостях пакет для бриджа притягивает.
Вот я и разошёлся, хотя как сейчас я понимаю из темы маршрутизация делается ip route add.

В общем как я понял из обсуждения настройку маршрутизации я понимаю не правильно.

Сейчас бы разобраться как решить проблему..

Вы учли критику anc? Правило

ip rule add fwmark 0x2 lookup main

должно предшествовать Вашему

ip rule add from 192.168.0.241 table vpn1.out

.

Ну и повторю, что значения меток в правилах iptables и ip rule должны быть одинаковыми.

-A POSTROUTING -s 192.168.0.241/32 -d !192.168.2.0/24 -o tun1 -j MASQUERADE

И что по вашему мнению даст это правило?

Я бы попросил

ip ru s
ip r s table all
iptables-save

Вы учли критику anc?

В части запуска роутов через up.sh и ухода от sleep - пока нет, помню у меня была проблема с тем, что скрипты оттуда не запускались..

А в части ip rule - я прописал эти команды через pref (так ведь можно делать?), но всё равно не работает..

ip rule add from all fwmark 0x2 lookup main pref 1000
ip rule add from 192.168.0.241 lookup vpn1.out pref 1500

[root@gw ~]# iptables-save | grep mark
-A PREROUTING -d 192.168.2.0/24 -m iprange --src-range 192.168.0.241-192.168.0.245 -j MARK --set-xmark 0x2/0xffffffff 

iptables -t mangle -I PREROUTING -m iprange --src-range 192.168.0.241-192.168.0.245 -d 192.168.2.0/24 -j MARK --set-mark 0x2

Собственно и без pref оно не хочет функционировать..

[root@gw /]# ip ru s
0:      from all lookup local
32763:  from all fwmark 0x2 lookup main
32764:  from 192.168.0.241 lookup vpn1.out
32766:  from all lookup main
32767:  from all lookup default

[root@gw /]# ip r s table all
default dev tun1  table vpn1.out  scope link
10.253.200.1 via 10.253.201.229 dev tun1
10.253.201.229 dev tun1  proto kernel  scope link  src 10.253.201.230
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
88.240.81.0/24 dev eth1  proto kernel  scope link  src 88.240.81.80
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via 88.240.81.89 dev eth1
broadcast 192.168.2.0 dev tun0  table local  proto kernel  scope link  src 192.168.2.1
broadcast 192.168.0.0 dev eth0  table local  proto kernel  scope link  src 192.168.0.1
local 192.168.2.1 dev tun0  table local  proto kernel  scope host  src 192.168.2.1
local 192.168.0.1 dev eth0  table local  proto kernel  scope host  src 192.168.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 88.240.81.255 dev eth1  table local  proto kernel  scope link  src 88.240.81.80
broadcast 192.168.2.255 dev tun0  table local  proto kernel  scope link  src 192.168.2.1
broadcast 192.168.0.255 dev eth0  table local  proto kernel  scope link  src 192.168.0.1
local 10.253.201.230 dev tun1  table local  proto kernel  scope host  src 10.253.201.230
broadcast 88.240.81.0 dev eth1  table local  proto kernel  scope link  src 88.240.81.80
local 88.240.81.80 dev eth1  table local  proto kernel  scope host  src 88.240.81.80
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
unreachable ::/96 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:a00::/24 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:7f00::/24 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:ac10::/28 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 2002:e000::/19 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101 mtu 65536 advmss 65476 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  table unspec  proto kernel  metric -1  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0  mtu 65536 advmss 65476 hoplimit 4294967295
local fe80::215:5dff:fe00:502 via :: dev lo  table local  proto none  metric 0  mtu 65536 advmss 65476 hoplimit 4294967295
local fe80::215:5dff:fe00:503 via :: dev lo  table local  proto none  metric 0  mtu 65536 advmss 65476 hoplimit 4294967295
ff02::c via ff02::c dev eth0  metric 0
    cache  mtu 1500 advmss 1440 hoplimit 4294967295
ff02::1:2 via ff02::1:2 dev eth0  metric 0
    cache  mtu 1500 advmss 1440 hoplimit 4294967295
ff02::1:3 via ff02::1:3 dev eth1  metric 0
    cache  mtu 1500 advmss 1440 hoplimit 4294967295
ff02::1:3 via ff02::1:3 dev eth0  metric 0
    cache  mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0  table local  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth1  table local  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  table unspec  proto kernel  metric -1  error -101 hoplimit 255
[root@gw /]# 

[root@gw /]# iptables-save | grep mark
-A PREROUTING -d 192.168.2.0/24 -m iprange --src-range 192.168.0.241-192.168.0.245 -j MARK --set-xmark 0x2/0xffffffff
[root@gw /]# iptables-save | grep tun1
-A POSTROUTING -s 192.168.0.241/32 -o tun1 -j MASQUERADE
[root@gw /]# iptables-save | grep eth1
-A POSTROUTING -o eth1 -m iprange --src-range 192.168.0.1-192.168.0.240 -j SNAT --to-source 88.240.81.80
[root@gw /]#

А можно таки таблицу отдельно для vpn1.out, а то хрен поймешь что где.

А можно таки таблицу отдельно для vpn1.out, а то хрен поймешь что где.

Тут только это..

[root@gw /]# ip route list table vpn1.out
default dev tun1  scope link

Ахаааа. Хотя сейчас у тебя есть еще fwmark, который теоретически должен заворачивать в main, но, видимо, что-то не работает, это надо у anc спросить.

Но если (можно было бы) опустить fwmark, то у тебя всё, что идет с 241 безусловно заворачивается на tun1 (ну и потом маскарадится).

Наверное, надо добавить в vpn1.out ip route add 192.168.2.0/24 dev tun0 (table vpn1.out, чтобы оно туда попало).

Но если fwmark работает как задумывалось, то до этого правила не дойдут пакеты.

Не вижу причин почему не робит. Кроме вариантов iptables которые вы не показали.
Но:

ip rule add priority 100 from 192.168.0.241 to 192.168.2.0/24 table main

Ничерта не понял, но после вот этого:

ip rule add priority 100 from 192.168.0.241 to 192.168.2.0/24 table main 

Ничерта не понял, но после вот этого:

Я об этом написал выше в ответе Serge10 «Зачем маркировать если тут достаточно правил ip rule ? »
Но его вариант с маркировкой тоже рабочий, просто у вас «где-то что-то» еще с правилами iptables поэтому оно (правило с mark) и не срабатывало.