Ich versuche, die Unterschiede zwischen zwei Netzwerkkonfigurationen für MAAS zu verstehen. Meines Wissens erfüllen beide die gleichen Aufgaben, wobei das erste Netzwerk eine Verbindung zum Internet herstellt und das zweite von MAAS verwaltet wird. Das zweite Netzwerk ist dann so konfiguriert, dass der Datenverkehr über die öffentliche Netzwerkschnittstelle weitergeleitet wird.
Obwohl die Ergebnisse identisch sind, sieht die Konfiguration ganz anders aus und das ist der Grund für meine Verwirrung.
Erste Konfiguration
Die erste vorgeschlagene Konfiguration stammt aus dem folgendenCloudbase Solutions Wiki-Seite. Sie schlagen eine einfache Lösung vor, /etc/network/interfacesbei der eth0man sich mit einem externen Netzwerk verbindet, eth1in ein internes Netzwerk geht und eine statische Adresse erhält:
# 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
Die entsprechenden iptablesRegeln werden dann in festgehalten /etc/rc.local. Soweit ich das beurteilen kann, hat das etwas mit der Weiterleitung des Netzwerkverkehrs zwischen eth1und zu tun 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
Zweite Konfiguration
Die zweite Konfiguration stammt aus demUbuntu OpenStack Installer für Multi-Installer-Handbuch. Ihre /etc/network/interfacesDatei verfügt über mehr Netzwerkschnittstellen, ähnelt aber der vorherigen Konfiguration, bei der eth0eine Verbindung zu einem externen Netzwerk hergestellt wird und eth1es sich um ein internes Netzwerk handelt:
# 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
Fragen, die mir in diesem Stadium in den Sinn kommen, sind, warum es loeinen DNS-Namensserver gibt und iptablesdieser darauf angewendet wird. Warum wird in diesem Fall eine überbrückte Verbindung verwendet?
Ihre iptableRegeln sehen auch anders aus und werden in gesetzt /etc/network/iptables.rulesund setzen voraus, dass dies die Weiterleitung des Datenverkehrs ermöglicht:
*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
Zusammenfassung
Kann jemand erklären, was sie anders machen und warum?
Sagen Sie mir Bescheid, wenn diese Frage zu umfangreich ist, dann kann ich sie in einzelne Fragen aufteilen, aber zunächst dachte ich, dass dies mehr Kontext bietet.
Antwort1
Beide Konfigurationen sind bis auf einige Nuancen ziemlich gleich.
iface lo inet loopback
dns-nameservers 127.0.0.1
pre-up iptables-restore < /etc/network/iptables.rules
Diese Konfiguration garantiert, dass Sie auch dann noch einen DNS-Resolver und Firewall-Regeln eingerichtet haben, wenn Ihr eth0-Kabel beim Booten ausgeschaltet ist (es ist schwierig, ein Loopback-Netzwerkgerät loszuwerden, oder?). Natürlich setzt dieses Beispiel voraus, dass Sie lokal einen laufenden DNS-Resolver-Dienst haben.
Ich sehe keine Probleme beim Einrichten eines Bridge-Geräts. Diese Konfiguration sollte problemlos funktionieren, aber ich glaube nicht, dass Sie sie in Ihrem Fall wirklich brauchen, es sei denn, Sie planen etwas, bei dem sie verwendet wird (z. B. virtuelle KVM-Maschinen).
Im ersten Fall werden iptables-Regeln für ein Shell-Skript geschrieben, weshalb ihre Syntax anders aussieht als /etc/network/iptables.rules, das mit iptables-restore verwendet werden sollte.
*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
Hier gibt es nur eine Regel und diese erlaubt die Maskierung des Subnetzes 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
Die oben genannten Regeln erlaubenbeliebigSubnetz von eth1 bis eth0, das mit einer gewissen Filterung maskiert werden soll.
Persönlich würde ich lieber einen Mix der oben genannten Konfigurationen wählen.
Antwort2
Die erste Netzwerkkonfiguration ist ziemlich klar. Die Datei /etc/network/interfaces ist jedem bekannt und natürlich ist bei der Verwendung von MAAS eine IP-Weiterleitung über iptables erforderlich, um den von MAAS verwalteten Knoten Internet bereitzustellen.
Die zweite Konfiguration außer dem DNS-Teil und dem br0-Teil ist verständlich. Der DNS-Teil soll dem MAAS-Server tatsächlich klar machen, dass er selbst die DNS-Dienste hostet. Diese Zeile kann nach /etc/resolve.conf verschoben werden, das andere DNS-Konfigurationen enthält. Wenn dieser DNS-Eintrag nicht vorgenommen wird, tritt während des JUJU-Bootstraps dieser Fehler auf:https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/901
Bei der Bridge br0 bin ich mir allerdings nicht ganz sicher. Hat diese Netzwerkkonfiguration tatsächlich funktioniert?