MAASの2つのネットワーク構成の違いを理解する


0

MAASの2つのネットワーク構成の違いを理解しようとしています。私の理解では、両方とも同じタスクを達成し、最初のネットワークはインターネットに接続し、2番目のネットワークはMAASによって管理されます。次に、2番目のネットワークは、パブリックネットワークインターフェイスを介してトラフィックを転送するように構成されます。

同じ結果を達成しているにもかかわらず、構成がかなり異なって見えるため、混乱が生じています。

最初の構成

最初に推奨される構成は、次のCloudbase Solutions Wikiページからのものです。彼らは、外部ネットワークに接続して内部ネットワークに行き、静的アドレスを与えられるシンプルな方法/etc/network/interfacesを提案します:eth0eth1

# 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

次に、対応するiptablesルールがに保持され/etc/rc.localます。私が知る限り、これはeth1との間のネットワークトラフィックの転送に関係しています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

2番目の構成

2番目の構成は、Ubuntu Openstack Installer for Multi Installer Guideからのものです。それらの/etc/network/interfacesファイルには、より多くのネットワークインターフェイスがありますがeth0、外部ネットワークに接続しeth1内部にある以前の構成に似ています。

# 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

この段階で頭に浮かぶ質問は、なぜloDNSネームサーバーがありiptables、それに適用されるのですか?このインスタンスでブリッジ接続が使用されるのはなぜですか?

それらのiptableルールも異なって見え、配置され/etc/network/iptables.rules、これによりトラフィックの転送が可能になると想定しています。

*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

概要

誰かが違うことをしている理由とその理由を説明できますか?

この質問が大きすぎて別の質問にまとめることができるかどうかを教えてください。しかし、最初はより多くのコンテキストを提供できると思いました。

回答:


1

両方の構成は、いくつかの微妙な違いはほとんど同じです。

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

この構成により、起動中にeth0ケーブルがオフになっても、DNSリゾルバーとファイアウォールルールが設定されたままになります(ループバックネットワークデバイスを正しく削除するのは難しいですか?)。もちろん、この例では、DNSリゾルバーサービスをローカルで実行していることを前提としています。

ブリッジデバイスの設定に問題はありません。この構成は問題なく動作するはずですが、使用するもの(KVM仮想マシンなど)を計画している場合を除き、実際に必要だとは思わないでください。

最初のケースでは、シェルスクリプト用にiptablesルールが記述されているため、その構文はiptables-restoreで使用される/etc/network/iptables.rulesとは異なります。

*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

ここにはルールが1つしかなく、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

上記のルールにより、eth1からeth0からのサブネットは、何らかのフィルタリングを使用してマスカレードできます。

個人的には、上記の構成を組み合わせて使用​​します。


1

最初のネットワーク構成は非常に明確です。/ etc / network / interfacesファイルは誰もが知っているものであり、もちろんMAASを使用している間は、MAASが管理しているノードにインターネットを提供するためにiptablesを介したIP転送が必要です。

DNS部分とbr0部分以外の2番目の構成は理解できます。DNSの部分は、実際にMAASサーバーに、それ自体がDNSサービスをホストしていることを認識させることです。その行は、他のDNS構成を含む/etc/resolve.confにシフトされる場合があります。このDNSエントリが作成されていない場合、JUJUブートストラップ中にこのエラーが発生します:https : //github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/901

ただし、ブリッジbr0についてはよくわかりません。このネットワーク構成は実際に機能しましたか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.