Linux-2つのサブネット、1つのインターフェース、1つのゲートウェイ-NAT追加のサブネット
現在、すべて同じLANを使用するサーバーがいくつかあります。
Host1: eth0 10.0.0.1/24
Host2: eth0 10.0.0.2/24
Host3: eth0 10.0.0.3/24
Gateway: 10.0.0.254
これらのサーバーでいくつかのVM（VirtualBox）を実行したいと思います。ホストのeth0にブリッジするように設定できますが、将来割り当てられる可能性があるため、10.0.0.0/24の範囲のアドレスを使用することはできません。
したがって、別のサブネットを使用することにしました。
Host1VM: eth0 192.168.0.1/24 (bridge to Host eth0)
Host2VM: eth0 192.168.0.2/24 (bridge to Host eth0)
Host3VM: eth0 192.168.0.3/24 (bridge to Host eth0)
これは問題ありません。すべてのVMは、同じ物理インターフェイスを使用する同じサブネット上にあるため、相互に通信できます。
私たちが直面している問題は、これらのVMに10.0.0.254ゲートウェイ経由でインターネットへのアクセスを許可する必要があることです。そこで、ホストの1つを選択して、ルーター/ NATとして使用しないのはなぜかを考えました。
Host1: eth0 10.0.0.1/24, eth0:0 192.168.0.254/24
これで、VMに192.168.0.254のゲートウェイを与えることができます。次に表示される問題は、Host1がNAT正しく表示されないように見えることです。
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to 10.0.0.1
私はそれがうまくいくと思いました、そして我々はそれがパケットと一致するのを見ます。 a VMがインターネットにpingを実行すると、ICMPパケットがHost1に着信し（ルーターであるため）、ホストはインターネットホストであるNATであるため、ICMPを再送信します。ホストに応答しますが、そこで終了します。ホストがパケットをVMに転送することを期待していましたが、そうではありません。
私は何が欠けていますか、またはこのセットアップは単に不可能ですか？
編集：明確にするために、iptables内にDENYルールはなく、すべてがデフォルトのACCEPTです。 IP転送も有効にしています。
pdate1-iptables
virbr0を無視します-VirtualBox VMとは関係ありません
# Completed on Fri Sep 20 16:50:45 2013
# Generated by iptables-save v1.4.12 on Fri Sep 20 16:50:45 2013
*nat
:PREROUTING ACCEPT [171383:10358740]
:INPUT ACCEPT [1923:115365]
:OUTPUT ACCEPT [192:21531]
:POSTROUTING ACCEPT [169544:10254463]
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source 10.0.0.1
COMMIT
# Completed on Fri Sep 20 16:50:45 2013
# Generated by iptables-save v1.4.12 on Fri Sep 20 16:50:45 2013
*filter
:INPUT ACCEPT [96628707:25146145432]
:FORWARD ACCEPT [195035595:22524430122]
:OUTPUT ACCEPT [44035412:304951330498]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Fri Sep 20 16:50:45 2013
# Generated by iptables-save v1.4.12 on Fri Sep 20 16:50:45 2013
*mangle
:PREROUTING ACCEPT [291641356:47665886851]
:INPUT ACCEPT [96628707:25146145432]
:FORWARD ACCEPT [195035595:22524430122]
:OUTPUT ACCEPT [44035838:304951365412]
:POSTROUTING ACCEPT [239078922:327477732680]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Fri Sep 20 16:50:45 2013
更新2-tcpdump
16:58:37.189758 IP 192.168.0.2 > 74.125.128.106: ICMP echo request, id 1, seq 2, length 40
16:58:37.189805 IP 10.0.0.1 > 74.125.128.106: ICMP echo request, id 1, seq 2, length 40
16:58:37.194607 IP 74.125.128.106 > 10.0.0.1: ICMP echo reply, id 1, seq 2, length 40
(no final reply back to the VM)
これが私がそれを解決した方法なので、私は自分の質問に答えるつもりです。他の答えは通常の状況では正確であると確信していますが、インターフェースエイリアスの使用に関するバグまたは警告のために機能しなかったと思います。
そのため、インターフェイスエイリアスが問題の原因であると考えて、仮想インターフェイスを提供する他の方法を探しました。MAC-VLANと呼ばれる仮想インターフェイスタイプがあり、基本的に、物理インターフェイスに仮想インターフェイスとして接続されていることがわかりました。独自のMACアドレス。
これを使用すると、NATは最初は問題なく機能したので、MAC-VLANインターフェイスが完全に別個のインターフェイスとしてカーネルに表示されたためだと思いますが、インターフェイスエイリアスはどこかで混乱を引き起こしています。
参考までに、MAC-VLANを作成するコマンドは次のとおりです。
ip link add dev macvlan0 link eth0 type macvlan
これは本当に素晴らしい機能です。これまで聞いたことがないなんて信じられません。
これは言っています：
16:58:37.189758 IP 192.168.0.2 > 74.125.128.106: ICMP echo request, id 1, seq 2, length 40
16:58:37.189805 IP 10.0.0.1 > 74.125.128.106: ICMP echo request, id 1, seq 2, length 40
16:58:37.194607 IP 74.125.128.106 > 10.0.0.1: ICMP echo reply, id 1, seq 2, length 40
アップストリームルーター（10.0.0.254）がHost1に応答を送り返しているため、ルーティングとSNATが機能しています。問題は、Host1がその応答を192.168.0.0/24ネットワークに返さないことです。
適切な接続追跡カーネルモジュールがロードされていますか？
トラフィックが接続追跡テーブルに入っていることを確認します。
grep src=192.168.0.2 /proc/1/net/nf_conntrack
先日、カーネルのrp_filterが原因であることが判明した、TCPパケットで同様の問題が発生しました。ここでは、それがどのように問題になるかわかりません。しかし、それは非常に似ています。Host1からルートテーブル（ip route show）を投稿し、rp_filter設定を確認できますか？（cat /proc/sys/net/ipv4/conf/default/rp_filter）
NATそれらが必要なのはなぜですか？プレフィックスが異なり、トラフィックをルーティングしているので、10.0のゲートウェイの仮想マシンを介してルートを設定してみませんか？ 0.0/24ネットワーク？
また、eth0:0を構成する場合、通常はeth0を構成します。その逆も同様です。 eth0:1を使用するか、さらに良いことに、古いnet-toolsツールの使用をやめ、代わりにiproute2（ip addr add 192.168.0.254/24 dev eth0など）を使用します。 SNATルールが正しいため、これが問題になる可能性があります。ルーターが10.0.0.1であることを認識していない場合、ルーターはNATリターントラフィックを返しません。
ip addr show dev eth0に両方のアドレスが表示されている場合は、NATが正しく設定されており、機能しているはずです。NAT =は、異なる送信元アドレスを使用して同じインターフェイスでパケットを送信しています。これは珍しいシナリオです。
ただし、このシナリオを厄介にするものの一部は、ICMPリダイレクトの存在です。通常、これらは悪であると考えられており（攻撃者が状況によってはルーティングテーブルを変更できるため）、ほとんどの場合無効になっていますが、Linuxは通常、トラフィックを同じインターフェイスから転送するときに送信します。この場合、基本的には「ホストはローカルセグメントにあります。私を介して転送する必要はありません」というメッセージです。 SNATのため、（前のホップの）ホストが実際にそうする必要があることを除いて、これは通常正しいでしょう。それらを無効にするには、次のsysctl設定を使用します。
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
ネクストホップデバイスによっては、そのデバイスを再起動するか、何らかの方法で構成するか、リダイレクトがなくなるまでしばらく待つ必要がある場合があります（それが問題の原因である場合）。
トポロジを考えると、私が理解したように、最善の策は、ネットワーク192.168.0.0/24ネットワークにルーター上のインターネットへのアクセスを許可することです。これを機能させるには、ルーターにネットワーク192.168.0.0/24のアドレスを指定する必要があります。
それができない場合は、MASQUERADEを使用する必要がありますが、VMネットワーク上にない宛先に制限してください。すべてのホストで次のようになります。
iptables -A POSTROUTING -o eth0 ! -d 192.168.0.0/24 -j MASQUERADE
このようにして、VM間のすべてのトラフィックは変更されず、VMから他のネットワークへのすべてのトラフィックは、ネットワーク上のホストアドレスとともに表示されます。