Как потребовать, чтобы вся сетевая активность проходила через гостевой брандмауэр KVM, прежде чем достигнуть хоста?
Большая часть информации, с которой я столкнулся, имеет тенденцию устанавливать брандмауэр KVM с использованием соединения моста.
Из моего понимая, что это угроза безопасности, если сетевой трафик может достигать хоста без предварительного прохождения межсетевого экрана.
Я видел, что основной сетевой адаптер (например, eth0 ) был установлен как сетевой адаптер виртуальной машины, но исключает ли это доступ хоста к eth0 ?
Другой вариант, который приходит на ум, - это сквозная передача PCI сетевой карты, однако я столкнулся с проблемами при использовании этого метода.
Есть ли другие подходы к требованию, чтобы трафик хоста сначала проходил через брандмауэр? Какой метод вы рекомендуете использовать?
Первая идея состоит в том, чтобы разделить, какие интерфейсы используются для добавления сетевого доступа к ВМ и какие используются для управления хостом. Часто третий набор интерфейсов используется для доступа к образам ВМ на каком-либо общем сетевом хранилище. Таким образом, в идеале у вас есть 6 интерфейсов: 4 из Gigabit Ethernet и 2 из 10 Gigiabit Ethernet.
Вторая идея заключается в том, что вы можете использовать разные VLAN 802.1q для хоста и для виртуальных машин. Я построил сеть, в которой ВМ располагалась в трех разных виртуальных локальных сетях, и иногда одна ВМ могла участвовать в нескольких виртуальных локальных сетях (путем создания нескольких виртуальных сетевых карт и объединения их с несколькими разными виртуальными локальными сетями на хосте)
Сервер записей должен был иметь BMC, который используется для внеполосного управления хостом. По сути, это маленький компьютер, который имеет доступ к сенсорам компьютера-хоста, он может видеть значения (температуру, число оборотов вентилятора), включать/выключать/сбрасывать хост, как будто вы нажимаете кнопку, даже имеет функцию IP KVM и т.д., и имеет свой сетевой адрес. Он также обычно реализует протокол IPMI. Он часто используется совместно с LAN1 (т.е. как маленький коммутатор, не совсем коммутатор - хост и BMC не могут общаться, но оба они коммутируют с внешними устройствами) или с независимым разъемом ethernet, который маршрутизируется исключительно на BMC. В blade-системах может быть один или два (резервных) BMC на клетку, а не в каждом blade-сервере.
Безопасная установка выглядит следующим образом:
bond0 - это (eth0, eth1), объединенный LACP, он имеет IP-адрес на хосте и используется для управления хостом.
bond1 - это (eth2, eth3), объединенный LACP. Он разделен на vlans, т.е. у хоста есть bond1.10, bond1.552 виртуальные подинтерфейсы и т.д. Созданы мосты: br10 мостов bond1.10 и все хост-стороны VM для VM, которые участвуют в vlan 10, br552 мосты bond1.552 и все хост-стороны VM для vlan 522 и так далее. Ни один из этих интерфейсов не имеет IP-адреса, Поэтому ВМ не могли общаться с хостом.
bond2 (eth4, eth5) объединен и используется для доступа к образам дисков ВМ через iSCSI, CEPH, для синхронизации DRBD и так далее. Он имеет IP в хосте, но подключен к полностью разделенной сети хранения данных с его особыми требованиями.
bond0 и bond1 рекомендуется быть раздельными физически, чтобы виртуальные машины не могли не только общаться с хостом, но даже насыщать сеть управления хоста. Эта сеть используется, например, для передачи содержимого памяти виртуальной машины в случае реального переноса на другой хост, и ни одна ВМ не сможет насытить производительность этого процесса.
Даже если вы строите небольшую систему с одним физическим интерфейсом для размещения пяти виртуальных машин и должны сочетать функциональность bond0 и bond1, вы можете иметь IP-адрес только на физическом интерфейсе (доступном как по умолчанию/внутренний vlan) и подинтерфейсы, участвующие в мостах с адаптерами VM на стороне хоста, все они помечены тегами. Однако виртуальные машины не могли получить прямой доступ к хосту, а интеллектуальный коммутатор L2 и отдельное устройство брандмауэра или коммутатор L3 могли выполнять маршрутизацию и фильтрацию трафика между виртуальными машинами
. Поскольку мост Linux создает соответствующий сетевой интерфейс (например, br0) на хосте, я не думаю, что есть способ сделать мост полностью недоступным для операционной системы хоста. При запущенной ВМ вашего брандмауэра, brctl show скажет вам, что интерфейсы eth0 и vnet0 к нему подключены, но на самом деле он работает как трех-портовый переключатель: один порт переходит на eth0, другой - на vnet0 (ВМ), а третий - на интерфейс br0 на хосте.
Вы, вероятно, могли бы установить некоторые правила ebtables, чтобы блокировать все кадры, идущие к или от интерфейса хоста br0. Это может быть лучшим подходом, но я не знаю достаточно много об ebtables, чтобы предоставить какую-либо детальную информацию о том, как это сделать.
Другой вариант - просто не настраивать IP адреса на интерфейсе моста, что должно помешать обычным приложениям общаться через него. Он всё равно будет доступен таким приложениям, как Wireshark с привилегиями root (и это может пригодиться)
В системах, основанных на Debian (например, Ubuntu), вы можете поместить следующее в /etc/network/interfaces:
auto br0
iface br0 inet manual
bridge_ports eth0
bridge_stp off
"manual" означает "не присваивать никаких адресов при вызове интерфейса"; он предназначен для установок, где что-то другое присваивает адрес позже, но он также работает, когда вы просто не хотите, чтобы адрес был вообще.
Единственным исключением является IPv6 link-local адрес, который присваивается автоматически ядром, а не скриптами сетевых настроек дистрибутива, так что вы получите его даже при "ручной" настройке. Вы можете избежать этого, полностью отключив IPv6 на интерфейсе. Создайте файл в /etc/sysctl.d и поместите это в него:
net.ipv6.conf.br0.disable_ipv6=1
(Было бы неплохо, если бы вы могли полностью отключить IPv4 и на интерфейсе, но для этого нет соответствующей опции)
.