+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема утечки трафика через Linux Bridge, Proxmox Виртуальная Среда

plastilin

Guest

27.11.2024 08:32:00

Всем привет. У меня следующая проблема. Сетевая часть в кластере работает на Linux Bridge с использованием VLAN. Проблема в том, что одна виртуальная машина получает трафик, который для неё не предназначен. Складывается впечатление, что Bridge работает как обычный сетевой хаб, а не как коммутатор, и отправляет весь трафик всем участникам сети. Если моя теория верна, то в чём может быть причина и как от этого избавиться? Очень не хотелось бы переходить на Openvswitch, ведь всё уже и так работает.

shanreich

Guest

11.12.2024 09:41:00

Я несколько дней не был в офисе, потом был немного занят — извиняюсь за поздний ответ. Я посмотрел логи, и, похоже, трафик, о котором вы говорите, имеет MAC-адреса, которые не начинаются с «BC:24:11» (а именно такой префикс для виртуальных машин Proxmox). MAC-адрес для IP-адреса с окончанием .99 отсутствует в базе пересылки, из-за чего пакет рассылается на все порты. Может быть, внутри виртуальной машины кто-то вручную настраивает MAC-адрес, что ведёт к такому поведению? Ваш ВМ случайно не является каким-то виртуальным коммутатором или роутером? Какие MAC-адреса у интерфейса объединения (bond) и его участников?

plastilin Guest	#3 0 11.12.2024 09:46:00 Спасибо за ответ. Да, виртуальная машина, которая принимает прямой трафик, — это виртуальный роутер Mikrotik CHR. У неё есть один внешний интерфейс, который не входит в мост виртуальной машины.

shanreich

Guest

11.12.2024 09:54:00

Один из MAC-адресов интерфейсов внутри виртуальной машины начинается с 82:e4:f3? Похоже, что виртуальные машины, которые обмениваются данными с Mikrotik, «узнают» этот MAC-адрес, а в мосту нет записи для него — поэтому он разбрасывает однопортовый трафик для этой виртуальной машины по всем портам.

plastilin Guest	#5 0 11.12.2024 10:04:00 Внутри виртуальной машины MAC-адрес ether1 заканчивается на 9F 7, а MAC-адрес мостa заканчивается на 41:08. Но ether1 не является частью этого моста — это интерфейс WAN.

sive.host

Guest

12.01.2025 13:25:00

Проблема исчезла. Мы просто убрали фаервол с сетевого устройства, затем склонировали виртуальную машину в новую, выключили старую и запустили клон, и утечка прекратилась. Не совсем понятно, в чём разница на бэкенде, но стоит отметить, что эти ВМ были восстановлены из бэкапов старой версии Proxmox и запущены в кластере с последней версией Proxmox.

shanreich

Guest

11.12.2024 12:40:00

Как именно настроен MikroTik Router? В любом случае, я думаю, проблема связана с тем, что трафик с / на маршрутизатор попадает на мост, а мост не знает, что с ним делать, кроме как рассылать всюду, потому что не знает MAC-адреса. Возможно, виртуальные машины узнают неправильный MAC-адрес по ARP, но в tcpdump нет ни одного релевантного ARP-запроса или ответа, на котором можно было бы это проверить. Тебе нужно разобраться, откуда изначально берётся этот изученный MAC-адрес, ведь он не совпадает с MAC-адресом интерфейса виртуальной машины. Как настроены виртуалки? Маршрутизатор должен направлять трафик между этими ВМ или он просто должен его коммутировать (через мост)? Я бы предположил второе, так как они в одной подсети.

plastilin

Guest

11.12.2024 12:59:00

В MikroTik есть 3 интерфейса, из которых у 2 есть MAC-адреса. Внешний интерфейс создан Proxmox, его MAC-адреса совпадают как внутри виртуальной машины, так и в конфигурации VM на PVE. Второй интерфейс — внутренний мост в виртуальной машине, который включает интерфейс без MAC — это EOIP, член внутреннего моста в VM. Роутер используется для NAT для удалённой сети. Всё работает нормально, но счётчики трафика на eth1 просто ужасны.

shanreich

Guest

11.12.2024 13:06:00

Но ты же сказал, что .59.108 и .59.99 — это IP-адреса сетевых интерфейсов виртуальных машин на одном и том же мосту, так? И оба интерфейса находятся на одном узле? Потому что MAC-адреса в соответствующих UDP-пакетах с .59.108 на .59.99 такие:
Код: Ethernet II, Src: fa:5b:52:62:e5:05 (fa:5b:52:62:e5:05), Dst: 82:e4:f3:93:39:1b (82:e4:f3:93:39:1b)
Адрес 82:e4:f3:93:39:1b отсутствует в таблице мостов (fdb), поэтому пакеты будут рассылаться на все порты. Виртуалки Proxmox по умолчанию используют BC:24:11 — если не переопределять.

plastilin Guest	#10 0 11.12.2024 13:16:00 Да, но трафик с этих узлов приходит на .59.77 - eth1 CHR, хотя он этого не запрашивал, при том что находится в той же VLAN, что и .59.108 и .59.99.

shanreich

Guest

#11

11.12.2024 13:52:00

Думаю, это потому, что мост не знает MAC-адрес назначения в пакетах, так как он отличается от MAC-адреса интерфейса tap, поэтому пакет рассылался на все порты моста. Исправьте меня, если я неправильно понял вашу конфигурацию. Вы писали nodes — это именно ноды или виртуальные машины? Просто хочу уточнить.

sive.host Guest	#12 0 08.01.2025 17:42:00 У нас похожая ситуация: мы поменяли MAC-адрес на авто, чтобы у ВМ и CT был MAC-адрес с префиксом 'BC:24:11', но по какой-то причине именно эти две ВМ продолжают "раздавать" свои соединения всем ВМ на том же узле. Забавно, что если их мигрировать на другие узлы, проблема переезжает вместе с ними, и все ВМ и CT на том же vmbr0 видят их пакеты при выполнении команды: sudo tcpdump -i ens18 host ИХ_IP_АДРЕС и порт 3306. Эту команду запускают на невинных ВМ, которые оказываются рядом с этими проблемными ВМ на текущем узле. У нашей ВМ настроен только один сетевой интерфейс, но мы видим несколько записей для одного и того же MAC-адреса на разных устройствах. На самом деле у других ВМ всего по две такие записи, а у этих проказников по шесть записей в выводе bridge fdb show.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры