Маршрутизация в Proxmox/Linux?

Question

[Андрей]

Всем привет, помогите понять как верно сделать?
Есть нода на Proxmox
Есть два сетевых интерфейса eno1, eno2
Они объединены в bond0
Есть два vmbr10 и vmbr20
vmbr10- 10.10.0.1/24 (vlan10)
vmbr20- 10.20.0.1/24 (vlan20)
Дефолтный- vmbr10 он со шлюзом
Так же созданы Linux vlan(10/20) которые ссылаются на bond0
Мне нужно, чтобы весь трафик для 10.20.0.0/24 уходил через мой vmbr20-10.20.0.1(vlan20) и не грузил основной(дефолтный) vmbr10

почитал что это настраивается через iproute2 и так и сделал, но нифига не работает

верно ли я понимаю что трафик надо роутить через бридж(vmbr20)?? или я ошибаюсь?

Конфиг

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode balance-tlb
        
auto vmbr10
iface vmbr10 inet static
        address 10.10.0.1/24
        gateway 10.10.0.1
        bridge-ports vlan10
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#WEB/VLAN10

auto vmbr20
iface vmbr20 inet static
           address 10.20.0.1/24
           bridge-ports vlan20
           bridge-stp off
           bridge-fd 0
           bridge-vlan-aware yes
           bridge-vids 2-4094
           post-up ip route add 10.20.0.0/24 dev vmbr20 10.20.0.1 table rt2
           post-up ip route add default via 10.20.0.1 dev vmbr20 table rt2
           post-up ip rule add from 10.20.0.1/24 table rt2
           post-up ip rule add to 10.20.0.1/24 table rt2
#VLAN20 from BackSrv

auto vlan10
iface vlan10 inet manual
<------>vlan-raw-device bond0

auto vlan20
iface vlan20 inet manual
<------>vlan-raw-device bond0

Answer 1

[Александр Карабанов]

В виду того, что на интерфейс добавлен IP 10.20.0.1 подсеть 10.20.0.0/24 является directly connected и трафик беспрепятственно может в неё уходить через vmbr20. Никакие route rule ненужны.

Цель, которую ты пытаешься достичь не ясна, в связи с чем поясню: технология VLAN позволяет только разделить физическую сеть на логические, изолированные друг от друга сети. Увеличить пропускную способность VLAN-ы никак не помогут.

Таким образом если трафик в одном VLAN будет утилизировать пропускную способность интерфейса на 100%, и не настроены какие либо лимиты и QoS, то трафик в другом VLAN будет неизбежно деградировать - физический интерфейс-то один.

Если ты хочешь, избежать этого убери BOND. Назначь VLAN-ы каждый на свой интерфейс. Либо настрой QoS.

Comments

[Андрей]

Человек который занимается сетевым оборудованием объяснил это так, стоят межсетевые экраны которые проверяют весь внутренний трафик во всех виланах, и есть несколько виланов, которые они не трогают, тут дело не в уменьшении, или увеличении пропускной способности канала, а дело в том, чтобы оборудование не захлебнулось.
Bond я убрать не могу, таковы условия

[Александр Карабанов]

Стало яснее.
Убери route rule что ты добавил - в них нет необходимости (да и выглядят они странно, так как не указан коннектед маршрут, а значит трафиктбудет ходить через default route таблицы main, что ты и описал в вопросе).

Под убрать подразумевается не только убрать из конфига, но и удалить:

ip route del 10.20.0.0/24 dev vmbr20 10.20.0.1 table rt2
ip route del default via 10.20.0.1 dev vmbr20 table rt2
ip rule del from 0/0 to 0/0 table rt2

Убедись, что есть коннектед маршрут в сторону 10.20.0.0/24 в таблице main (введи ip route) его добавляет ядро, но мало ли...
Коннектед маршруты это вот эти странненькие с proto kernel scope link

[Андрей]

Александр Карабанов, в /etc/iproute2/rt_tables прописан 1 rt2
сейчас с такой конфигурацией как есть, это работает, но работает криво
нода видит vlan20 и пингует только шлюз 10.20.0.1 и больше никого не пингует, а её в этой подсети пингуют все, если сделать nmap -sP 10.20.0.0/24 то он выдаст список хостов в подсети, фаервола на ноде нет
route выдаёт верную таблицу маршрутизации

root@cloud-p2:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.10.0.1      0.0.0.0         UG    0      0        0 vmbr10
10.20.0.0      0.0.0.0         255.255.255.0   U     0      0        0 vmbr20
10.10.0.0      0.0.0.0         255.255.255.0   U     0      0        0 vmbr10

[Александр Карабанов]

Узел 10.20.82.1 не принадлежит подсети 10.20.0.0/24 - поменяй настройки интерфейса.

В подсети 10.20.0.0/24 всего 254 IP адреса 10.20.0.1-10.20.0.254 шлюз пингуется через дефолт.
Проверь с помощью mtr 10.20.82.1 (apt update && apt install mtr-tiny).

Никогда не используй route используй ip route

[Андрей]

Александр Карабанов, я описАлся- 10.20.0.1 шлюз

root@cloud-p2:~# ip route
default via 10.10.0.1 dev vmbr10 proto kernel onlink 
10.20.0.0/24 dev vmbr20 proto kernel scope link src 10.20.0.226 
10.10.0.0/24 dev vmbr10 proto kernel scope link src 10.10.0.20

[Александр Карабанов]

Часто описываешься ;-)

У тебя в конфиге вписано address 10.20.0.1/24 это не шлюз, это IP с интерфейса Proxmos и ты пингуешь сам себя.

Проверь есть ли маршрут командой ip r g 10.20.0.5
И покажи вывод ip r, что бы были видны коннектед маршруты
И покажи вывод ip ne

И убери кастомные таблицы маршрутизации и правила, они не нужны и мешают.

PS
А вообще я предлагаю тебе обратится к тому специалисту по настройке фаирволов, пусть он тебе настроить сеть.

[Александр Карабанов]

Андрей, маршруты выглядят хорошо.
Что показывает ip ne и ip r g 10.20.0.5?

[Андрей]

Александр Карабанов, хотел как лучше, но сам запутался.........адресация другая и виланы другие, в заглавном посте хотел упростить всё для облегчения понимания информации, но сделал только хуже ) прошу прощения

истинный конфиг таков, оставил всё как есть дабы не путаться самому и не путать Вас.
из ключевого vmbr203 не работает как надо и всё как я выше писал

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto bond0
iface bond0 inet manual
	bond-slaves eno1 eno2
	bond-miimon 100
	bond-mode balance-tlb

auto vmbr0
iface vmbr0 inet static
	address 10.20.86.20/23
	gateway 10.20.86.1
	bridge-ports vlan202
	bridge-stp off
	bridge-fd 0
	bridge-vlan-aware yes
	bridge-vids 2-4094
#WEB/VLAN202

auto vmbr1
iface vmbr1 inet manual
	bridge-ports bond0
	bridge-stp off
	bridge-fd 0
	bridge-vlan-aware yes
	bridge-vids 2-4094
#VLAN1

auto vmbr200
iface vmbr200 inet manual
	bridge-ports vlan200
	bridge-stp off
	bridge-fd 0
	bridge-vlan-aware yes
	bridge-vids 2-4094
#VLAN200

auto vmbr203
iface vmbr203 inet static
	address 10.20.82.226/24
	post-up ip route add 10.20.82.0/24 dev vmbr203 10.20.82.226 table rt2
	post-up ip route add default via 10.20.82.1 dev vmbr203 table rt2
	post-up ip rule add from 10.20.82.226/24 table rt2
	post-up ip rule add to 10.20.82.226/24 table rt2
	bridge-ports vlan203
	bridge-stp off
	bridge-fd 0
	bridge-vlan-aware yes
	bridge-vids 2-4094
#VLAN203 from BackSrv

auto vlan202
iface vlan202 inet manual
	vlan-raw-device bond0

auto vlan200
iface vlan200 inet manual
	vlan-raw-device bond0

auto vlan203
iface vlan203 inet manual
	vlan-raw-device bond0

[Андрей]

ip ne

root@cloud-p2:~# ip ne
10.20.82.215 dev vmbr203 lladdr 00:50:56:67:07:90 STALE
10.20.82.12 dev vmbr203 lladdr 4c:72:b9:7b:bd:89 STALE
10.20.82.25 dev vmbr203 lladdr b4:2e:99:82:c1:09 STALE
10.20.82.22 dev vmbr203 lladdr f4:6d:04:e5:67:6b STALE
10.20.86.21 dev vmbr0  FAILED
10.20.82.211 dev vmbr203 lladdr 00:50:56:69:4d:6c STALE
10.20.82.201 dev vmbr203 lladdr 00:50:56:61:50:30 STALE
10.20.82.5 dev vmbr203 lladdr 00:50:56:6e:9d:38 STALE
10.20.82.18 dev vmbr203 lladdr 90:e2:ba:19:0e:6c STALE
10.20.82.223 dev vmbr203 lladdr 00:50:56:6f:63:80 STALE
10.20.82.1 dev vmbr203 lladdr 00:09:0f:09:00:12 STALE
10.20.82.23 dev vmbr203 lladdr 00:1b:21:39:b9:6a STALE
10.20.82.13 dev vmbr203 lladdr c8:60:00:e1:4c:11 STALE
10.20.82.26 dev vmbr203 lladdr 38:d5:47:b2:88:e3 STALE
10.20.86.22 dev vmbr0 lladdr 82:06:7d:ab:61:f3 REACHABLE
10.20.86.1 dev vmbr0 lladdr 00:09:0f:09:00:12 DELAY
10.20.82.202 dev vmbr203 lladdr 00:50:56:6b:87:e7 STALE
10.20.82.9 dev vmbr203 lladdr 00:50:56:6c:15:72 STALE
10.20.82.6 dev vmbr203 lladdr 00:50:56:6f:54:64 STALE
10.20.82.208 dev vmbr203 lladdr 00:50:56:61:af:53 STALE
10.20.82.31 dev vmbr203 lladdr 36:35:12:08:1e:77 STALE
10.20.86.19 dev vmbr0 lladdr a4:bf:01:62:6f:e8 REACHABLE
10.20.82.27 dev vmbr203 lladdr bc:ae:c5:d9:40:e6 STALE
10.20.82.14 dev vmbr203 lladdr e0:cb:4e:d7:3a:53 STALE
10.20.82.213 dev vmbr203 lladdr 00:50:56:6f:80:d5 STALE
10.20.82.203 dev vmbr203 lladdr 00:50:56:61:6c:57 STALE
10.20.82.7 dev vmbr203 lladdr 00:50:56:66:2f:dd STALE
10.20.82.20 dev vmbr203 lladdr 00:1b:21:e8:ae:00 STALE
10.20.82.10 dev vmbr203 lladdr 00:50:56:6a:fe:60 STALE
10.20.82.209 dev vmbr203 lladdr 00:50:56:69:d2:04 STALE
10.20.82.16 dev vmbr203 lladdr bc:ae:c5:bb:f2:10 STALE
10.20.82.221 dev vmbr203 lladdr 00:50:56:66:54:40 STALE
10.20.82.28 dev vmbr203 lladdr 22:6e:19:1e:d2:e4 STALE
10.20.82.15 dev vmbr203 lladdr 48:5b:39:3b:2f:90 STALE
10.20.82.217 dev vmbr203 lladdr 00:50:56:63:5e:c8 STALE
10.20.82.11 dev vmbr203 lladdr bc:ae:c5:8f:2f:94 STALE
10.20.82.21 dev vmbr203 lladdr 48:5b:39:d2:0d:60 STALE
10.20.82.24 dev vmbr203 lladdr 10:7b:44:a2:7e:cc STALE
10.20.82.17 dev vmbr203 lladdr bc:ae:c5:8f:2f:aa STALE
10.20.82.29 dev vmbr203 lladdr bc:ae:c5:89:e7:e9 STALE
fe80::206e:19ff:fe1e:d2e4 dev vmbr203 lladdr 22:6e:19:1e:d2:e4 STALE
fe80::8006:7dff:feab:61f3 dev vmbr0 lladdr 82:06:7d:ab:61:f3 STALE
fe80::3435:12ff:fe08:1e77 dev vmbr203 lladdr 36:35:12:08:1e:77 STALE

ip r g 10.20.82.5

root@cloud-p2:~# ip r g 10.20.82.5
10.20.82.5 via 10.20.82.1 dev vmbr203 table rt2 src 10.20.82.226 uid 0 
    cache

[Александр Карабанов]

Да, всё сходится. По L2 связность есть. В таблице main маршруты ровные.

Моё мнение не поменялось - для доступа в подсеть 10.20.82.0/24 кастомная таблица маршрутизации не нужна, route rule не нужны. Убери их и трафик станет ходить.

Стереть маршруты ip route flush table rt2
Проверить что ничего не осталось ip route show table rt2
Сотри правила ip rule delete from 0/0 to 0/0 table rt2
И из конфига не забудь это убрать.

PS
Если надо что бы эта таблица rt2 зачем-то была, то:

post-up ip route add 10.20.82.0/24 dev vmbr203 scope link src 10.20.82.226 table rt2
post-up ip route add default via 10.20.82.1 dev vmbr203 table rt2
post-up ip rule add from 10.20.82.226 lookup rt2
# другие маршруты если надо
post-up ip route add x.x.x.x/24 via y.y.y.y
post-up ip route add x.x.x.x/24 via y.y.y.y
post-up ip route add x.x.x.x/24 via y.y.y.y

Ты двигался в верном направлении, но сбился с пути.

Пинговать для теста с сорсом можно так ping -I 10.20.82.226 ya.ru
Трейсы делать так mtr --address 10.20.82.226 ya.ru (как mtr накатить я выше писал).

Секурити не пострадала от того, что ты IP опубликовал, эти IP из RFC1918 есть у... Да у всех.

[Андрей]

Александр Карабанов, так если я уберу маршруты эти

post-up ip route add 10.20.82.0/24 dev vmbr203 10.20.82.226 table rt2
  post-up ip route add default via 10.20.82.1 dev vmbr203 table rt2
  post-up ip rule add from 10.20.82.226/24 table rt2
  post-up ip rule add to 10.20.82.226/24 table rt2

получится ровно то, что я хотел избежать, всё пойдёт через vmr0 10.20.86.20 c шлюзом 10.20.86.1 и следовательно через НЕ нужный вилан же, разве нет?

я просто не понимаю как так получается, что сейчас эта нода видит из вилана 203(vbr203) ТОЛЬКО шлюз(10.20.82.1) и всё, я из-за этого не могу к ней добавить proxmox-backup server из того же vlan203, но сам proxmox backup server прекрасно эту машину видит........бред какой-то

[Александр Карабанов]

Андрей, потому что у тебя коннектед маршрут не правильно добавлен.
Коннектед маршруты в таблицу main добавляет ядро, в кастомную таблицу коннектед маршруты надо добавлять самому, только делать это правильно. У коннектед маршрутов scope link.

Я ведь написал в Post Scriptum, что надо исправить чтобы заработало с кастомной таблицей.

В своих суждениях я исходил из того, что тебе достаточно доступа в подсеть 10.20.82.0/24 и никуда больше за её пределы (сотри свои правила и кастомную таблицу и доступ появится).

Если же доступ и в эту подсеть и ещё куда-то через шлюз в этой подсети 10.20.82.0/24, то в Post Scriptum ровный конфиг, используй его.

[Андрей]

Александр Карабанов, в общем разобрался, по факту никакие маршруты не нужны были, vbr203 и так работал без дефолтного шлюза, tracerout мне чётко показал, что маршрут до машин в vlan203 уходили напрямую, минуя дефолтный шлюз.
сказалась моя нехватка знаний, Александр огромное спасибо за потраченное время!!! :)

[Александр Карабанов]

Отметь ответ, как решение.
И я рад, что знания, которые я получал годами, ты получил за 23 часа.
День прошёл не зря ;-)