Compreenda as diferenças entre duas configurações de rede para MAAS

0

Estou tentando entender as diferenças entre duas configurações de rede para o MAAS. Meu entendimento é que ambos alcançam as mesmas tarefas em que a primeira rede se conecta à internet e a segunda é gerenciada pelo MAAS. A segunda rede é então configurada para encaminhar o tráfego através da interface de rede pública.

Apesar de alcançar os mesmos resultados, a configuração parece bastante diferente, e é aí que reside minha confusão.

Primeira configuração

A primeira configuração sugerida vem da seguinte página Wiki do Cloudbase Solutions . Eles propõem um simples /etc/network/interfaces com eth0 conectando a uma rede externa e eth1 indo para uma rede interna e recebendo um endereço estático:

# The primary network interface (external)
auto eth0
iface eth0 inet dhcp

# The secondary NIC (used internal for MAAS)
auto eth1
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0

As regras iptables correspondentes são mantidas em /etc/rc.local . Tanto quanto eu posso dizer isso tem algo a ver com o encaminhamento do tráfego de rede entre eth1 e eth0 .

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Segunda configuração

A segunda configuração vem do Guia do instalador do Ubuntu Openstack para vários instaladores . Seu arquivo /etc/network/interfaces tem mais interfaces de rede, mas é semelhante à configuração anterior, em que eth0 se conecta a uma rede externa e eth1 é interno:

# The loopback network interface
auto lo
iface lo inet loopback
  dns-nameservers 127.0.0.1
  pre-up iptables-restore < /etc/network/iptables.rules

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet manual

auto br0
iface br0 inet static
  address 172.16.0.1
  netmask 255.255.255.0
  bridge_ports eth1

Perguntas que me surpreendem neste estágio são por que o lo tem um Servidor de Nomes DNS e iptables aplicado a ele? Por que uma conexão em ponte é usada nesta instância?

Suas regras iptable também parecem diferentes e são colocadas em /etc/network/iptables.rules e supõem que isso possibilita o encaminhamento do tráfego:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 172.16.0.1/24 ! -d 172.16.0.1/24 -j MASQUERADE
COMMIT

Resumo

Alguém pode ajudar a explicar o que está fazendo de forma diferente e por quê?

Deixe-me saber se essa pergunta é muito grande e posso dividi-la em questões separadas, mas, no primeiro caso, achei que isso forneceu mais contexto.

    
por A Dark Divided Gem 18.04.2016 / 04:19

2 respostas

1

Ambas as configurações são praticamente as mesmas com algumas nuances.

iface lo inet loopback
  dns-nameservers 127.0.0.1
  pre-up iptables-restore < /etc/network/iptables.rules

Esta configuração irá garantir que, mesmo que o seu cabo eth0 esteja desligado durante a inicialização, você ainda terá um resolvedor de DNS e um conjunto de regras de firewall (é difícil se livrar do dispositivo de rede de loopback?). Claro que este exemplo presume que você terá um serviço de resolução de DNS em execução localmente.

Não vejo nenhum problema com a configuração de um dispositivo de ponte. Esta configuração deve funcionar sem nenhum problema, mas você não acha realmente necessário no seu caso, a menos que você esteja planejando algo que vai usá-la (máquinas virtuais KVM, por exemplo).

No primeiro caso, as regras do iptables são escritas para um script de shell e é por isso que sua sintaxe parece diferente de /etc/network/iptables.rules, que deve ser usada com o iptables-restore.

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 172.16.0.1/24 ! -d 172.16.0.1/24 -j MASQUERADE
COMMIT

Há apenas uma regra aqui e ela permite que a sub-rede 172.16.0.0/24 seja mascarada.

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

As regras acima permitem que qualquer subnet proveniente de eth1 a eth0 seja mascarada com alguma filtragem envolvida.

Pessoalmente prefiro ir com uma mistura de configurações acima.

    
por zalmarge 19.04.2016 / 22:09
1

A primeira configuração de rede é bem clara. O arquivo / etc / network / interfaces é familiar a todos e é claro que o encaminhamento de IP através do iptables é necessário enquanto estiver usando o MAAS, para fornecer internet aos nós que estão sendo gerenciados pelo MAAS.

A segunda configuração diferente da parte DNS e da parte br0 é compreensível. A parte do DNS é fazer com que o servidor MAAS perceba que ele está hospedando os serviços DNS. Essa linha pode ser deslocada para /etc/resolve.conf, que inclui outras configurações de DNS. Se essa entrada de DNS não for feita, você obterá esse erro durante o bootstrap do JUJU: link

No entanto, não tenho muita certeza sobre a ponte br0. Essa configuração de rede realmente funcionou?

    
por saisrinivas 19.04.2016 / 12:52