Estoy tratando de comprender las diferencias entre dos configuraciones de red para MAAS. Tengo entendido que ambos logran las mismas tareas donde la primera red se conecta a Internet y la segunda es administrada por MAAS. Luego, la segunda red se configura para reenviar el tráfico a través de la interfaz de la red pública.
A pesar de lograr los mismos resultados, la configuración parece bastante diferente y ahí es donde radica mi confusión.
Primera configuración
La primera configuración sugerida proviene de la siguientePágina Wiki de Soluciones Cloudbase. Proponen una solución simple /etc/network/interfacespara eth0conectarse a una red externa e eth1ir a una red interna y recibir una dirección estática:
# 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
Las reglas correspondientes iptablesse mantienen entonces en /etc/rc.local. Por lo que puedo decir, esto tiene algo que ver con el reenvío del tráfico de red entre eth1y 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 configuración
La segunda configuración proviene de laGuía del instalador de Ubuntu Openstack para instalación múltiple. Su /etc/network/interfacesarchivo tiene más interfaces de red pero es similar a la configuración anterior donde eth0se conecta a una red externa y eth1es interna:
# 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
Las preguntas que me vienen a la cabeza en esta etapa son ¿por qué tiene loun servidor de nombres DNS y iptablesse le aplica? ¿Por qué se utiliza una conexión en puente en este caso?
Sus iptablereglas también se ven diferentes y se colocan /etc/network/iptables.rulesy asumen que esto permite el reenvío de tráfico:
*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
Resumen
¿Alguien puede ayudar a explicar qué están haciendo de manera diferente y por qué?
Avíseme si esta pregunta es demasiado grande y puedo dividirla en preguntas separadas, pero en primera instancia pensé que esto proporcionaba más contexto.
Respuesta1
Ambas configuraciones son prácticamente iguales con algunos matices.
iface lo inet loopback
dns-nameservers 127.0.0.1
pre-up iptables-restore < /etc/network/iptables.rules
Esta configuración garantizará que incluso si su cable eth0 está apagado durante el arranque, aún tendrá un solucionador de DNS y reglas de firewall establecidas (es difícil deshacerse del dispositivo de red loopback, ¿verdad?). Por supuesto, este ejemplo supone que tendrá un servicio de resolución de DNS en ejecución localmente.
No veo ningún problema con la configuración de un dispositivo puente. Esta configuración debería funcionar sin problemas, pero realmente no creas que la necesitas en tu caso, a menos que estés planeando algo que vaya a utilizarla (máquinas virtuales KVM, por ejemplo).
En el primer caso, las reglas de iptables están escritas para un script de shell, por eso su sintaxis es diferente de /etc/network/iptables.rules, que debería usarse con 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
Aquí solo hay una regla y permite enmascarar la subred 172.16.0.0/24.
/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
Las reglas anteriores permitencualquierLa subred que viene de eth1 a eth0 se enmascarará con algún filtrado involucrado.
Personalmente, prefiero optar por una combinación de las configuraciones anteriores.
Respuesta2
La primera configuración de red es bastante clara. El archivo /etc/network/interfaces es familiar para todos y, por supuesto, el reenvío de IP a través de iptables es necesario cuando se usa MAAS, para proporcionar Internet a los nodos administrados por MAAS.
La segunda configuración además de la parte DNS y la parte br0 es comprensible. La parte de DNS es hacer que el servidor MAAS se dé cuenta de que él mismo aloja los servicios DNS. Esa línea se puede cambiar a /etc/resolve.conf que incluye otras configuraciones de DNS. Si no se realiza esta entrada DNS, aparecerá este error durante el arranque de JUJU:https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/901
Sin embargo, no estoy muy seguro acerca del puente br0. ¿Funcionó realmente esta configuración de red?