LINUX.ORG.RU
ФорумAdmin

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

 , ,


2

2

Всем привет. Ковыряюсь неделю, не понимаю как добиться нужного.. Помогите плиз..

Итак, шлюз на centos. Локальная подсеть 192.168.0.0/24. Машины с адресами с 1 по 240 натятся через eth1

-A POSTROUTING -o eth1 -m iprange --src-range 192.168.0.1-192.168.0.240 -j SNAT --to-source External_IP

Есть несколько виртуалок в сети с адресами 241-245 и они ходят в инет через впн, каждая через свой туннель..

-A POSTROUTING -s 192.168.0.241/32 -o tun1 -j MASQUERADE
-A POSTROUTING -s 192.168.0.242/32 -o tun2 -j MASQUERADE
-A POSTROUTING -s 192.168.0.243/32 -o tun3 -j MASQUERADE
-A POSTROUTING -s 192.168.0.244/32 -o tun4 -j MASQUERADE
-A POSTROUTING -s 192.168.0.245/32 -o tun5 -j MASQUERADE

Туннели поднимаются на шлюзе с помощью скриптов типа:

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
В клиентском конфиге:
client
remote external-vpn-ip 443
dev tun1
proto udp
auth-user-pass vpn1
pull-filter ignore "redirect-gateway"
resolv-retry infinite
persist-key
persist-tun
nobind
cipher AES-256-CBC
auth SHA256
keepalive 10 180
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500
fragment 1300
mssfix 1300
log-append /var/log/vpn1.log
verb 4
comp-lzo
<ca> ... </ca>
<cert ... </cert>
<key> ... </key>

И всё вроде был работает как надо, если бы не один нюанс...
На этом же шлюзе поднят опенвпн ещё и в качестве сервера..
Клиенты получают ip с подсети 192.168.2.0/24
Так вот они попасть на эти виртуалки не могут, т.к. весь трафик с виртуалок заворачивается в туннель..
Я подозреваю, что в скрипте запуска клиентских туннелей нужно после:

ip rule add from 192.168.0.241 table vpn1.out
ip route add default dev tun1 table vpn1.out
добавить что-то типа
 ip route add 192.168.2.0/24 via 192.168.0.1
Но не работает оно так..
Подключаюсь с удаленной машины, получаю ip 192.168.2.3
Компы с адресами 192.168.0.1-192.168.0.240 вижу, а 192.168.0.241-192.168.0.245 не вижу..
Натолкните на путь истинный, пожалуйста..

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

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

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

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

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

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

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

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

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

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
Serge10 ★★★★★
()
Ответ на: комментарий от Serge10
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 

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

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

Serge10 ★★★★★
()

Туннели поднимаются на шлюзе с помощью скриптов типа:
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.

anc ★★★★★
()
Ответ на: комментарий от Serge10

Немного критики
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» то это правило уже не сработает.

anc ★★★★★
()
Ответ на: комментарий от anc

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

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

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

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

 ip rule add fwmark 0x2/0x2 lookup main 
не даёт нужного эффекта..

Mikeban
() автор топика

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

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

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

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

Есть сервак, который натит офисную сетку (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) не могут.
По-моему элементарная задача, но у меня скилл не прокачан.

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от Mikeban

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от infine

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

Mikeban
() автор топика
Ответ на: комментарий от infine

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

 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\Администратор>

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

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

infine
()
Ответ на: комментарий от infine

[root@gw /]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:15:5d:00:05:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::215:5dff:fe00:502/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:25:8d:00:02:03 brd ff:ff:ff:ff:ff:ff
    inet 88.240.81.80/24 brd 88.240.81.255 scope global eth1
    inet6 fe30::125:5sxf:f0a0:503/64 scope link
       valid_lft forever preferred_lft forever
6: gre0: <NOARP> mtu 1476 qdisc noop state DOWN
    link/gre 0.0.0.0 brd 0.0.0.0
7: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
105: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 10.246.202.198 peer 10.246.202.197/32 scope global tun2
107: tun5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 10.253.203.118 peer 10.253.203.117/32 scope global tun5
    inet6 2001:ac8:27:21:401:200:0:10dc/112 scope global
       valid_lft forever preferred_lft forever
125: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 10.249.202.246 peer 10.249.202.245/32 scope global tun3
136: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 192.168.2.1/24 brd 192.168.2.255 scope global tun0
138: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 10.249.200.46 peer 10.249.200.45/32 scope global tun1
    inet6 2001:ac8:25:13:d08:200:0:1098/112 scope global
       valid_lft forever preferred_lft forever
[root@gw /]# ip route
10.253.200.1 via 10.253.203.117 dev tun5
10.246.200.1 via 10.246.202.197 dev tun2
10.246.202.197 dev tun2  proto kernel  scope link  src 10.246.202.198
10.249.200.45 dev tun1  proto kernel  scope link  src 10.249.200.46
10.249.202.245 dev tun3  proto kernel  scope link  src 10.249.202.246
10.249.200.1 via 10.249.202.245 dev tun3
10.253.203.117 dev tun5  proto kernel  scope link  src 10.253.203.118
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
[root@gw /]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp dpt:openvpn
ACCEPT     gre  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:tr-rsrb-p3

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere            icmp address-mask-request
ACCEPT     icmp --  anywhere             anywhere            icmp timestamp-request
ACCEPT     icmp -f  anywhere             anywhere
ACCEPT     gre  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     gre  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
[root@gw /]# brctl show
bridge name     bridge id               STP enabled     interfaces
[root@gw /]#
Mikeban
() автор топика
Ответ на: комментарий от Mikeban
[root@gw /]# brctl show bridge name bridge id STP enabled interfaces [root@gw /]#


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

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

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

torvn77 ★★★★★
()
Ответ на: комментарий от Mikeban

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

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

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

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

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

infine
()
Ответ на: комментарий от infine

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

Mikeban
() автор топика
Ответ на: комментарий от torvn77

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

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

infine
()
Ответ на: комментарий от Mikeban

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

THANK YOU MARIO! BUT OUR PRINCESS IS IN ANOTHER CASTLE

ЛОЛ XD

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

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

infine
()
Ответ на: комментарий от infine

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

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

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

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

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 3)
Ответ на: комментарий от torvn77

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

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

anc ★★★★★
()
Ответ на: комментарий от torvn77

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

spectr00 ★★★
()
Ответ на: комментарий от torvn77

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

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

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

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

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

infine
()
Ответ на: комментарий от infine

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

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от Mikeban

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

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

ip rule add fwmark 0x2 lookup main

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

ip rule add from 192.168.0.241 table vpn1.out

.

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

Serge10 ★★★★★
()
Ответ на: комментарий от infine

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

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

anc ★★★★★
()
Ответ на: комментарий от Serge10

Вы учли критику 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

Mikeban
() автор топика
Ответ на: комментарий от anc

Собственно и без 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
ip r s table all
[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 /]# 

iptables можно я не буду весь выкладывать? все политики по умолчанию accept.
[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 /]#

Mikeban
() автор топика
Ответ на: комментарий от infine

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

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

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

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

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

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

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

infine
()
Ответ на: комментарий от Mikeban

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

ip rule add priority 100 from 192.168.0.241 to 192.168.2.0/24 table main
вроде должно отработать

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

ip rule add priority 100 from 192.168.0.241 to 192.168.2.0/24 table main 
всё заработало... Спасибо огромное!!

Mikeban
() автор топика
Ответ на: комментарий от Mikeban

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

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

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.