☰

виртуальная сеть с iptables на хосте KVM

tag-icon • tag-icon networking iptables kvm-virtualization bridge
виртуальная сеть с iptables на хосте KVM

Я работаю над проектом для устройства на базе Linux и ищу способ использовать KVM для уровня виртуализации. В системе есть 3 ВМ, соединенные между собой очень специфическим образом. Диаграмма пакетов fag, которую мне дали, выглядит так...

       www
        |
+------ | ------------+
|       |             |
|      |A|            |
|       |             |
|       |             |
|      |B|-----|C|    |
|       |             |
+------ | ------------+
        |
       dbs

По сути, это отражает поток данных — веб-сервер спереди с сервером бэкэнда за ним и вспомогательной службой сбоку. A и C должны находиться в «отдельных» сетях из-за близости к Интернету и т. д. Это нормально для большей части системы, но это означает, что весь трафик управления для виртуальных машин A и C должен будет проходить через виртуальную машину B, чтобы достичь внешнего сервера syslog или чего-то подобного. Аналогично для доступа по ssh нам понадобится что-то вроде переадресации портов на B. Хотя объем этого трафика минимален по сравнению с трафиком приложений, он выглядит довольно ужасно, особенно с учетом того, что автоматическая сборка этих виртуальных машин с использованием kickstart или чего-то подобного означает, что мы не можем начать сборку A или C, пока не будет завершена сборка B.

Поэтому я думаю о том, чтобы сделать все это еще более запутанным, сделав что-то вроде этого:

     www
      |
+---- | ----------------------+
|     |                       |
|     |       +-----------+   |
|     |       |           |   |
|    |A|-----|B|-----|C|  |   |
|     |       |       |   |   |
|     |       b       |   |   |
|     +-----a x c-----+   |   |
|             d           |   |
|             |           |   |
+------------ | --------- | --+
              |           |
             mgt         dbs

Таким образом, поток данных между AB и C для приложения в значительной степени идентичен (но здесь изображен плоским), и мы добавляем второй сетевой адаптер управления к каждой виртуальной машине, подключенной к другому мосту, который также имеет интерфейс на хосте (a, b и c). Затем между этими интерфейсами виртуальных хостов и внешним миром (d) используется iptables и переадресация, чтобы гарантировать, что хотя все машины могут напрямую обращаться к внешним службам ниже в среде, они не могут обращаться друг к другу таким образом, чтобы компрометация виртуальной машины A не снижала безопасность в большей степени. Я, вероятно, мог бы использовать ebtables и один мост в своих дополнениях, но я думаю, что это будет выглядеть слишком тонко, поскольку A и C все еще находятся в одной подсети.

Справедливо отметить, что есть существенный угол зрения на то, как все выглядит на диаграмме для управления, а также фактическая техническая достоверность вещей (отсюда «отдельно» против отдельного)! Простота также является огромным мотиватором, но за счет пропуска всего дополнительного трафика через вторую виртуальную машину это кажется действительно неудобным, а также добавляет, возможно, 5-10 минут для сборки в чувствительной ко времени среде

Так, по сути, я сошел с ума?

Спасибо

Крис

решение1

Нет, не сумасшедший. Но я думаю, что вы делаете это более сложным, чем оно должно быть. Я прочитал ваш вопрос несколько раз, и все еще есть несколько вещей, которые я не понимаю. Что на самом деле делает машина C? Зачем она вам там нужна? Что делают машины A и B?.

В любом случае, если следовать вашей первой схеме, то все, что вам нужно сделать, это применить простую IP-маршрутизацию, и все будет в порядке. Если машина C образует отдельную подсеть с B (так, чтобы она была отделена от остальных), то для того, чтобы добраться до нее, маршрутизация должна быть настроена следующим образом:

  • на dbs: направлять весь трафик через B (это шлюз по умолчанию, который знает, как направлять
  • трафик на C, поскольку он подключен напрямую).
  • на www: маршрутизировать весь трафик для C через A (необходимо только если A не является шлюзом по умолчанию)
  • на A: маршрутизировать весь трафик для C через B (необходимо только в том случае, если B не является шлюзом по умолчанию)
  • на C установите B как шлюз по умолчанию.

После того, как маршрутизация будет установлена, вы можете добавить брандмауэры, чтобы убедиться, что трафик идет только туда, куда вы хотите. Если у вас нет опыта в таких вещах, я бы рекомендовал сначала запустить маршрутизацию, а затем добавлять брандмауэры (по одному шагу за раз, чтобы вы всегда знали, что сломало его. Потому что вы его сломаете).

Связанный контент