virtuelles Networking mit iptables im KVM-Host

virtuelles Networking mit iptables im KVM-Host

Ich arbeite an einem Entwurf für ein Linux-basiertes Gerät und möchte KVM für die Virtualisierungsschicht verwenden. Das System hat 3 VMs, die auf ganz bestimmte Weise miteinander verbunden sind. Das Fag-Paket-Diagramm, das ich erhalten habe, sieht so aus ...

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

Dies spiegelt im Grunde den Datenfluss wider – ein Webserver vorne mit einem Backend-Server dahinter und einem untergeordneten Dienst an der Seite. A und C müssen sich aufgrund der Nähe zum Internet usw. in „getrennten“ Netzwerken befinden. Für den Großteil des Systems ist das in Ordnung, aber das bedeutet, dass der gesamte Verwaltungsverkehr für VM A und C über VM B laufen müsste, um einen externen Syslog-Server oder Ähnliches zu erreichen. Ähnlich verhält es sich mit dem SSH-Zugriff, für den wir so etwas wie eine Portweiterleitung auf B benötigen würden. Obwohl das Volumen dieses Verkehrs im Vergleich zum Anwendungsverkehr minimal ist, fühlt es sich ziemlich schrecklich an, insbesondere da der automatische Aufbau dieser VMs mit Kickstart oder Ähnlichem bedeutet, dass wir nicht mit dem Aufbau von A oder C beginnen können, bis B fertig ist.

Ich denke also darüber nach, das Ganze noch verwirrender zu machen, und zwar etwa so:

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

Der Datenfluss zwischen AB und C für die App ist also weitgehend identisch (hier jedoch flach dargestellt) und wir fügen jeder VM, die mit einer anderen Brücke verbunden ist, eine zweite Verwaltungs-NIC hinzu, die auch eine Schnittstelle auf dem Host hat (a, b und c). Dann werden iptables und Weiterleitung zwischen diesen virtuellen Hostschnittstellen und der Außenwelt (d) verwendet, um sicherzustellen, dass zwar alle Maschinen direkt auf externe Dienste weiter unten in der Umgebung zugreifen können, sie sich jedoch nicht auf eine Weise gegenseitig erreichen können, die bedeutet, dass eine Gefährdung von VM A die Sicherheit nicht in größerem Maße verringert. Ich könnte in meinen Ergänzungen wahrscheinlich ebtables und eine einzelne Brücke verwenden, aber ich denke, es würde zu subtil aussehen, wenn sich A und C immer noch im selben Subnetz befinden.

Es ist fair zu sagen, dass es einen wichtigen Aspekt gibt, wie die Dinge in einem Diagramm für das Management aussehen, sowie für die tatsächliche technische Glaubwürdigkeit der Dinge (daher „separat“ vs. getrennt)! Einfachheit ist auch ein großer Motivator, aber auf Kosten der Weiterleitung des gesamten zusätzlichen Datenverkehrs über eine zweite VM fühlt es sich wirklich unangenehm an und verlängert den Build in einer zeitkritischen Umgebung um vielleicht 5 bis 10 Minuten.

Bin ich also im Grunde verrückt?

Danke

Chris

Antwort1

Nein, nicht verrückt. Aber ich finde, Sie stellen das komplizierter dar, als es sein muss. Ich habe Ihre Frage mehrmals gelesen, und es gibt immer noch ein paar Dinge, die ich nicht verstehe. Was macht Maschine C eigentlich? Warum brauchen Sie sie dort? Was machen die Maschinen A und B?

Wenn ich Ihrem ersten Diagramm folge, müssen Sie auf jeden Fall nur einfaches IP-Routing anwenden und alles ist in Ordnung. Wenn Maschine C mit B ein separates Subnetz bildet (so dass es vom Rest getrennt ist), muss das Routing wie folgt eingerichtet werden, um dorthin zu gelangen:

  • auf dbs: Leiten Sie den gesamten Verkehr über B weiter (das ist das Standard-Gateway, das weiß, wie es weiterleitet
  • Verkehr zu C, da es direkt verbunden ist).
  • unter www: den gesamten Datenverkehr für C über A umleiten (nur erforderlich, wenn A nicht das Standard-Gateway ist)
  • auf A: den gesamten Datenverkehr für C über B umleiten (nur erforderlich, wenn B nicht das Standard-Gateway ist)
  • Stellen Sie auf C B als Standard-Gateway ein.

Sobald das Routing eingerichtet ist, können Sie Firewalls hinzufügen, um sicherzustellen, dass der Datenverkehr nur dorthin fließt, wo Sie ihn haben möchten. Sofern Sie keine Erfahrung mit dieser Art von Dingen haben, empfehle ich, zuerst das Routing einzurichten und dann die Firewalls hinzuzufügen (einen Schritt nach dem anderen, damit Sie immer wissen, was es kaputt gemacht hat. Denn Sie werden es kaputt machen).

verwandte Informationen