Como deixar o chef escutar em vários IPs

Question

Atualmente, estou jogando com o chef para avaliar se essa ferramenta de configuração pode ou não nos ajudar em nosso ambiente baseado em * nix.

Nos últimos dias, estou lutando com um problema para o qual não consigo encontrar uma solução. Basicamente, eu tenho 2 intervalos de rede privada 192.168.1.0/24 e 192.168.2.0/24. Existe um servidor (Ubuntu 14.04.4 LTS) com acesso a ambas as redes (192.168.1.1/24 no em1 e 192.168.2.1/24 no em2) que está executando o servidor do chef.

Tanto quanto eu entendo, o chef vai ouvir na interface que tem a rota padrão configurada para (aqui 192.168.1.1 no em1). No entanto, quero que o chef cuide dos servidores nas duas redes.

Quando eu inicializo os Servidores em 192.168.2.0/24, o cliente é instalado, mas não há resposta do cliente, porque o servidor chama-se 192.168.1.1, que não é visível para 192.168.2.0/24 (afinal, é apenas uma sub-rede comum).

Existe uma maneira de permitir que o chef ouça as duas interfaces (por exemplo, algo como "ouvir em 0.0.0.0/0")? Eu pesquisei toda a rede, mas só encontrei soluções para os serviços subjacentes, como estante de livros. Você tem algum conselho sobre como realizar o gerenciamento de configuração em tal ambiente?

Saudações Kenneth

    

Answer 1

Não há respostas após 2 semanas, portanto, não há uma maneira "simples" de atingir a meta.

Eu quero compartilhar minhas ideias de como minha "solução alternativa" se parece. Talvez isso ajude aqueles que enfrentam um problema semelhante.

• Sub-rede A: 192.168.1.0/24
• Sub-rede B: 192.168.2.0/24
• Sub-rede C: 192.168.3.0/24

Eu adicionei uma nova sub-rede separada (C) que é meio como um dmz (por causa do conteúdo não é nenhum, mas espero que você entenda). Depois, criei políticas para shorewall, que concede roteamento da sub-rede A e B para o C recém-criado, mas não para trás. Desta forma, os clientes-chefes de ambas as redes, A e B, são capazes de se conectar ao servidor chefe em C, mas A e B ainda não estão autorizados a se comunicar uns com os outros. Além disso, C não tem permissão para entrar em contato com sistemas atrás de A e B, portanto, mesmo que alguém intercepte A ou B, ele ainda terá problemas para acessar as outras sub-redes. Embora isso torne a adição de novos nós um pouco mais complexa, ainda é muito fácil (por exemplo, escrever um script geral instalando chef-client e conectando-o ao servidor ou usando uma versão local de 'knife').

Este é o arquivo de políticas (simplificado) atualmente em uso pelo shorewall:

#SOURCE         DEST            POLICY             LOG LEVEL        LIMIT:BURST
$FW             A               REJECT             
$FW             B               REJECT             
$FW             C               REJECT             

A               $FW             DROP             
A               B               REJECT             
A               C               ACCEPT             

B               $FW             DROP             
B               A               REJECT             
B               C               ACCEPT             

C               $FW             DROP             
C               A               REJECT             
C               B               REJECT             

# THE FOLLOWING POLICY MUST BE LAST
all             all             DROP             info

Afinal, esta não é a solução que eu estava procurando. No entanto, quanto mais eu penso sobre isso, mais eu gosto dessa solução porque não há pontes adicionais além do próprio firewall e podemos implantar software que pode ser útil em ambas as sub-redes também (por exemplo, RabbitMQ).