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