Я работаю над дизайном для устройства на базе Linux и хочу использовать KVM для уровня виртуализации. В системе есть 3 виртуальных машины, соединенных между собой очень специфическим образом. Диаграмма пакета fag, которую мне дали, выглядит так ...
www
|
+------ | ------------+
| | |
| |A| |
| | |
| | |
| |B|-----|C| |
| | |
+------ | ------------+
|
dbs
Это в основном отражает поток данных - веб-сервер спереди с внутренним сервером за ним и вспомогательная служба сбоку. A и C должны быть в «разных» сетях из-за близости к Интернету и т. Д. Это нормально для основной части системы, но это означает, что весь трафик управления для виртуальных машин A и C должен проходить через виртуальную машину B, чтобы достичь внешнего системного журнала. сервер или подобное. Точно так же для доступа по ssh нам понадобится что-то вроде переадресации портов на B. Хотя объем этого трафика минимален по сравнению с трафиком приложения, он выглядит довольно ужасно, особенно если учесть автоматическое создание этих виртуальных машин с использованием кикстарта или чего-то подобного, означают, что мы не можем начать строительство A или C, пока B не будет закончено.
Итак, я думаю о том, чтобы сделать все это намного более запутанным с помощью чего-то вроде этого:
www
|
+---- | ----------------------+
| | |
| | +-----------+ |
| | | | |
| |A|-----|B|-----|C| | |
| | | | | |
| | b | | |
| +-----a x c-----+ | |
| d | |
| | | |
+------------ | --------- | --+
| |
mgt dbs
Таким образом, поток данных между AB и C для приложения в значительной степени идентичен (но здесь нарисован плоско), и мы добавляем вторую нишу управления к каждой виртуальной машине, подключенной к другому мосту, который также имеет интерфейс на хосте (a, b и c). . Затем между этими интерфейсами виртуального хоста и внешним миром используется iptables и пересылка (d), чтобы гарантировать, что, хотя все машины могут напрямую обращаться к внешним службам, расположенным ниже в среде, они не могут связываться друг с другом таким образом, чтобы это означало компрометацию vm. A не снижает безопасность в большей степени. Я, вероятно, мог бы использовать ebtables и один мост в своих дополнениях, но я думаю, что это выглядело бы слишком незаметно, если бы A и C все еще находились в одной подсети.
Будет справедливо отметить, что существует значительный угол зрения на то, как все выглядит на диаграмме для управления, а также фактическая техническая достоверность вещей (отсюда «отдельные» против отдельных)! Простота также является огромным фактором мотивации, но за счет отбрасывания всего дополнительного трафика через вторую виртуальную машину это действительно неудобно, а также добавление 5-10 минут для сборки в среде, чувствительной ко времени.
Итак, я чокнутый?
Спасибо
Крис
Нет, не чокнутые. Но я действительно думаю, что вы делаете этот звук более трудным, чем это должно быть. Я читал ваш вопрос несколько раз, но кое-что еще не понял. Что на самом деле делает машина C? Зачем тебе это там нужно? Что делают машины A и B ?.
В любом случае, если я следую вашей первой диаграмме, все, что вам нужно сделать, это применить простую IP-маршрутизацию, и все в порядке. Если машина C образует отдельную подсеть с B (так, чтобы она была отделена от остальных), то для доступа к ней необходимо настроить маршрутизацию следующим образом:
После того, как маршрутизация настроена, вы можете добавить брандмауэры, чтобы убедиться, что трафик течет только туда, куда вы хотите. Если у вас нет опыта работы с подобными вещами, я бы рекомендовал сначала запустить маршрутизацию, а затем добавить брандмауэры (шаг за шагом, чтобы вы всегда знали, что его сломало. Потому что вы его сломаете).