Estou trabalhando em um projeto para um dispositivo baseado em Linux e pretendo usar KVM para a camada de virtualização. O sistema possui 3 VMs interligadas de maneiras muito específicas. O diagrama de pacotes fag que recebi é assim ...
www
|
+------ | ------------+
| | |
| |A| |
| | |
| | |
| |B|-----|C| |
| | |
+------ | ------------+
|
dbs
Isso basicamente reflete o fluxo de dados - um servidor web na frente com um servidor back-end atrás dele e um serviço subsidiário na lateral. A e C devem estar em redes "separadas" devido à proximidade da Internet, etc. Isso é bom para a maior parte do sistema, mas significa que todo o tráfego de gerenciamento das VMs A e C precisaria passar pela VM B para alcançar um syslog externo servidor ou algo assim. Da mesma forma, para acesso ssh, precisaríamos de algo como encaminhamento de porta em B. Embora o volume desse tráfego seja mínimo comparado ao tráfego do aplicativo, é horrível, especialmente porque a construção automatizada dessas VMs usando kickstart ou algo assim, significa que não podemos começar a construir A ou C até que B esteja concluído.
Então, estou pensando em tornar tudo muito mais confuso com algo assim:
www
|
+---- | ----------------------+
| | |
| | +-----------+ |
| | | | |
| |A|-----|B|-----|C| | |
| | | | | |
| | b | | |
| +-----a x c-----+ | |
| d | |
| | | |
+------------ | --------- | --+
| |
mgt dbs
Portanto, o fluxo de dados entre AB e C para o aplicativo é praticamente idêntico (mas desenhado de forma plana aqui) e adicionamos uma segunda placa de gerenciamento a cada VM conectada a outra ponte que também possui uma interface no host (a, b e c) . iptables e encaminhamento são então usados entre essas interfaces de host virtual e o mundo externo (d) para garantir que, embora todas as máquinas possam acessar diretamente serviços externos mais abaixo no ambiente, elas não possam se alcançar de uma forma que signifique comprometimento da VM A não reduz a segurança em maior extensão. Eu provavelmente poderia usar ebtables e uma única ponte em minhas adições, mas acho que ficaria muito sutil com A e C ainda na mesma sub-rede.
É justo observar que há um ângulo significativo sobre a aparência das coisas em um diagrama de gerenciamento, bem como a credibilidade técnica real das coisas (portanto, "separadas" versus separadas)! A simplicidade também é um grande motivador, mas ao custo de lançar todo o tráfego adicional através de uma segunda VM é muito desconfortável, além de adicionar talvez 5 a 10 minutos para a construção em um ambiente sensível ao tempo
Então, essencialmente, estou maluco?
Obrigado
Chris
Responder1
Não, não é maluco. Mas acho que você está tornando isso mais difícil do que deveria ser. Li sua pergunta várias vezes e ainda há algumas coisas que não entendo. O que a máquina C realmente faz? Por que você precisa disso aí? O que as máquinas A e B fazem?
De qualquer forma, se eu seguir seu primeiro diagrama, tudo o que você precisa fazer é aplicar o roteamento IP simples e você estará bem. Se a máquina C formar uma sub-rede separada com B (de modo que fique separada do resto), então, para chegar até ela, o roteamento deve ser configurado assim:
- em dbs: roteia todo o tráfego através de B (esse é o gateway padrão, que sabe como rotear
- tráfego para C, porque está diretamente conectado).
- em www: roteia todo o tráfego de C até A (necessário apenas se A não for o gateway padrão)
- em A: roteia todo o tráfego de C até B (necessário apenas se B não for o gateway padrão)
- em C defina B como gateway padrão.
Depois que o roteamento estiver implementado, você poderá adicionar firewalls para garantir que o tráfego flua apenas para onde você deseja. A menos que você tenha experiência com esse tipo de coisa, recomendo iniciar o roteamento primeiro e depois adicionar os firewalls (um passo de cada vez, para que você sempre saiba o que o quebrou. Porque você o quebrará).