Estoy trabajando en un diseño para un dispositivo basado en Linux y busco usar KVM para la capa de virtualización. El sistema tiene 3 VM interconectadas de formas muy específicas. El diagrama de paquetes de cigarrillos que me han dado se ve así...
www
|
+------ | ------------+
| | |
| |A| |
| | |
| | |
| |B|-----|C| |
| | |
+------ | ------------+
|
dbs
Básicamente, esto refleja el flujo de datos: un servidor web en la parte frontal con un servidor back-end detrás y un servicio subsidiario en el lateral. A y C deben estar en redes "separadas" debido a la proximidad a Internet, etc. Esto está bien para la mayor parte del sistema, pero significa que todo el tráfico de administración para las máquinas virtuales A y C tendría que pasar a través de la máquina virtual B para llegar a un syslog externo. servidor o similar. De manera similar, para el acceso ssh, necesitaríamos algo como el reenvío de puertos en B. Si bien el volumen de este tráfico es mínimo en comparación con el tráfico de la aplicación, se siente bastante horrible, especialmente porque la construcción automatizada de estas máquinas virtuales usa kickstart o algo así. significa que no podemos empezar a construir A o C hasta que B esté terminado.
Así que estoy pensando en hacerlo todo mucho más confuso con algo como esto:
www
|
+---- | ----------------------+
| | |
| | +-----------+ |
| | | | |
| |A|-----|B|-----|C| | |
| | | | | |
| | b | | |
| +-----a x c-----+ | |
| d | |
| | | |
+------------ | --------- | --+
| |
mgt dbs
Entonces, el flujo de datos entre AB y C para la aplicación es en gran medida idéntico (pero dibujado aquí) y agregamos una segunda NIC de administración a cada VM conectada a otro puente que también tiene una interfaz en el host (a, byc). . Luego se utiliza iptables y el reenvío entre estas interfaces de host virtual y el mundo exterior (d) para garantizar que, si bien todas las máquinas pueden acceder directamente a servicios externos que se encuentran más abajo en el entorno, no pueden comunicarse entre sí de una manera que comprometa la máquina virtual. A no reduce la seguridad en mayor medida. Probablemente podría usar ebtables y un puente único en mis adiciones, pero creo que parecería demasiado sutil con A y C todavía en la misma subred.
¡Es justo señalar que existe un ángulo significativo sobre cómo se ven las cosas en un diagrama para la gestión, así como la credibilidad técnica real de las cosas (por lo tanto, "separados" versus separados)! La simplicidad también es un gran motivador, pero a costa de desechar todo el tráfico adicional a través de una segunda máquina virtual se siente realmente incómodo, además de agregar quizás de 5 a 10 minutos para la compilación en un entorno en el que el tiempo es urgente.
Básicamente, ¿estoy loco?
Gracias
cris
Respuesta1
No, no locos. Pero creo que estás haciendo que esto parezca más difícil de lo necesario. He leído tu pregunta varias veces y todavía hay algunas cosas que no entiendo. ¿Qué hace realmente la máquina C? ¿Por qué lo necesitas allí? ¿Qué hacen las máquinas A y B?
En cualquier caso, si sigo su primer diagrama, todo lo que necesita hacer es aplicar un enrutamiento IP simple y estará bien. Si la máquina C forma una subred separada con B (de modo que esté separada del resto), entonces, para llegar a ella, el enrutamiento debe configurarse de esta manera:
- en dbs: enruta todo el tráfico a través de B (esa es la puerta de enlace predeterminada, que sabe cómo enrutar
- tráfico a C, porque está conectado directamente).
- en www: enruta todo el tráfico de C a través de A (solo es necesario si A no es la puerta de enlace predeterminada)
- en A: enruta todo el tráfico de C a través de B (solo es necesario si B no es la puerta de enlace predeterminada)
- en C establezca B como puerta de enlace predeterminada.
Una vez que el enrutamiento esté implementado, puede agregar firewalls para asegurarse de que el tráfico solo fluya hacia donde usted desea que fluya. A menos que tenga experiencia con este tipo de cosas, le recomendaría iniciar el enrutamiento primero y luego agregar los firewalls (un paso a la vez, para que siempre sepa qué lo rompió. Porque usted lo romperá).