LINUX.ORG.RU
решено ФорумAdmin

libvirt guest: запретить смену IP

 , ,


0

1

Категорически приветствую! Есть сервер с centos 7 где установлен libvirt и существуют 2 бриджа br0 (192.168.0.1/24) и br1 (8.8.8.8/24). При создании гостей интерфейсы последних просто добавляются в бридж и внутри устанавливается адрес. Так вот вопрос: А как запретить менять/удалять/добавлять адреса? Если, допустим, я создам какой-нить virbr средствами libvirt со встроенным его dhcp и при загрузке машина будет получать адрес оттуда, его ж всё равно можно будет руками сменить? И как в этом случае быть с машинами, где нужен только внешний адрес (Без NAT’a во всех его проявлениях) из br1 ?

Ответ на: комментарий от int13h

Но Вы же просто перечислили кучку технологий и дали ссылку на картинку из cloudstack, это не помогает от слова совсем :( Cloudstack это программное решение где создаётся виртуальная машина через которую происходит NAT к прочим машинам (см. http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/networking_and_traffic.html) - всё это динамически управляется Cloudstack. Правильно ли я понимаю, что Вы фактически мне предлагаете написать второй Cloudstack? Это то же самое, как если бы я спросил решение виртуализации и Вы бы предложили написать libvirt FACEPALM В любом случае спасибо за попытку :)

В действительности существует libvirt nwfilter и в частности CTRL_IP_LEARNING (см. https://libvirt.org/formatnwfilter.html), но у меня нет опыта использования этой штуки. Как это настроить для системных бриджей? Можно ли использовать без DHCP? Защитит ли это от IP/APR/DHCP (в случае с dhcp очевидно) spoofing? Оно работает как-то вроде IP Source Guard? Может есть какие-то другие аналоги, которые не подразумевают написания кода и дают аналогичные возможности из коробки? Так много вопросов :(

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

До этого момента я использовал

<filterref filter='clean-traffic'>
  <parameter name='CTRL_IP_LEARNING' value='any'/>
</filterref>

Единственный изъян такого решения (в моём случае) - это то, что если внутри гостя сменить адрес и затем ребутнуть хост - произойдёт переобучение и адрес установленный вручную будет считаться валидным.

Ваш вариант защищает от таких случаев и подходит для меня больше, премного благодарен :)

P.S. В этих ваших интернетах бытует мнение, что лучше бы ещё указывать <parameter name='MAC' value='ТУТ_МАК_АДРЕС'/> но у меня он в параметрах интерфейса указан, так что я пренебрёг этим советом. Оставлю это тут, а то вдруг у кого чуть-чуть человекочасов хватать не будет для написания cloudstack, но проблему всё же решить нужно будет ^_^

Grotesque ()