Сетевая изоляция виртуальных машин в openvz
Подскажите пожалуйсто.
Поднял парочку VE. Настроил на них сетевушки через vethdev. Сеть работает, все всех видят.
HN 192.168.0.1
VE1 192.168.0.101
VE2 192.168.0.102
Хотелось бы, чтоб виртуальные сервера могли взаимодействовать друг с другом без посредства HN.
На данный момент это невозможно реализовать по причине работы каждой VE через отдельное виртуальное соединение на HN.
Тоесть на HN есть veth101.0 для соеденения с VE1 и veth102.0 для соеденения с VE2.
Между VE взаимодействие происходит через HN посредством proxy_arp.
Соответственно опускаю veth10x.0 машины друг друга видеть перестают, что собственно логично с учетом вышенаписаного!
Упомяну, что при настройке сети мне пришлось для каждой машины на HN прописать маршрут
route add -host 192.168.0.101 dev veth101.0 route add -host 192.168.0.102 dev veth102.0
Не знаю на сколько это правильно, но без этих маршрутов никто никого не видит.
если сделать tracepath от одной VE до другой, можно увидеть, что пакеты проходят через HN.
Реально ли повесить все VE на одно виртуальное соединение? И будут ли VE видеть друг друга, если это соединение на HN опущено?
- Для комментирования войдите или зарегистрируйтесь
Можно использовать один venet
Можно использовать один venet за место множества veth.
PS: Различия между venet и veth.
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
а как насчет опустить это
а как насчет опустить это venet соединение? будут VE видеть друг друга?
В смысле опустить? ifconfig
В смысле опустить? ifconfig venet0 down? а зачем?
У venet как такого-то нет ip-адресса в хост системе (HN), он что-то в роде тунеля (tun/tap) или моста.
IP для VE выдаётся простой командой vzctl set $VEID --ipadd ${IP} и VE свободно видят друг друга без дополнительных действий.
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
Назначь на машины ип адреса
Назначь на VE ип адреса 192.0.2.{3,4}
Вы ведете речь об vznetdev? Я
Вы ведете речь об vznetdev? Я его завтра буду пробовать...
Сейчас пока vzethdev
Если при его использовании назначить этим VE другой диапозон, то VE невидят друг друга
Можно конечно с помощью nat их заставить друг друга видеть. Но все пакеты будут ходить опять же ТОЛЬКО через HN.
Вывод: на данный момент получив доступ к фаер-маршрутизатору, злоумышленники смогут догадаться, что находятся на одной из VE внутри HN, когда увидят, что все пакеты до других машин идут не на прямую, а через некий адрес. Получив таким образом ip HN, они смогут получить доступ к HN и соответственно ко всем VE.
Так как опасность остаться без виртуального серверного парка есть, я считаю необходимостью обеспечить независимость работы виртуальной сети от HN.
Идея в следующем: хочу с внешнего физ. интерфейса(инет) HN сделать bridge на VE(фаер-маршрутизатор), а уже на нем фильтровать и рулить траффик на остальные VE.
Сама HN получит случайный адрес и случайный порт для ssh. А так же ей будут запрещены icpm пакеты, чтоб на ping не отвечала. Тогда злоумышленник даже не догадается, что взломал лишь один из виртуальных серверов...
Еще раз повторюсь - vznetdev
Еще раз повторюсь - vznetdev то что вам нужно.
И как рулить траффик тоже уже давно в доках описано - http://wiki.openvz.org/Using_NAT_for_container_with_private_IPs
А про злоумышленника: настоящий (читай крутой) взломщик в любом случаи догадается, что он находиться в VE и сможет вычислить архитектуру твоего виртуального парка (если ему это очень надо). Вопрос только в том представит ли реальную угрозу эта информация, а это уже зависит от настроек сервисов в VE и HN.
/ Enchant /
"Никакую проблему нельзя решить на том же уровне, на котором она возникла"
Сможет вычислить, тока если
Сможет вычислить, тока если он реально крут )
Это как искать иголку в стоге сена, а если еще и виртуальная сеть сделана /16 - вообще каюк )