Linuxの同じサブネット上の2つのネットワークインターフェイスと2つのIPアドレス

最近、2つのSSL / TLSサイトを実行できるように、1つのLinuxホストに割り当てられた同じサブネット上の2つのIPアドレスが必要な状況に遭遇しました。私の最初のアプローチは、たとえばeth0：0、eth0：1などを使用してIPエイリアシングを使用することでしたが、ネットワーク管理者は、このアイデアを押しつぶすセキュリティのためにかなり厳しい設定をしています。

1. DHCPスヌーピングを使用し、通常は静的IPアドレスを許可しません。静的アドレス指定は静的DHCPエントリを使用して行われるため、同じMACアドレスが常に同じIP割り当てを取得します。この機能は、スイッチポートごとに無効にすることができ、その理由があります（ありがたいことに、私はネットワーク関係者と良好な関係にあり、これは難しくありません）。
2. DHCPスヌーピングがスイッチポートで無効になっていると、MACアドレスXにIPアドレスYを許可するというルールをスイッチに設定する必要がありました。残念ながら、これにはMACアドレスX IPアドレスY。IPエイリアシングでは、MACアドレスXに2つのIPアドレスが割り当てられている必要があったため、これは機能しませんでした。

スイッチ構成でこれらの問題を回避する方法があったかもしれませんが、ネットワーク管理者との良好な関係を維持するために、別の方法を見つけようとしました。2つのネットワークインターフェイスを持つことは、次の論理的なステップのように思えました。ありがたいことに、このLinuxシステムは仮想マシンであるため、2つ目のネットワークインターフェイスを簡単に追加できました（再起動せずに追加できます-かなりクールです）。数回キーを押すと、2つのネットワークインターフェイスが起動して実行され、両方がDHCPからIPアドレスを取得しました。

しかし、その後、問題が発生しました：ネットワーク管理者は両方のインターフェースのARPエントリを（スイッチ上で）見ることができましたが、最初に立ち上げたネットワークインターフェースのみがpingまたはあらゆる種類のTCPまたはUDPトラフィックに応答しました。

たくさんの掘り出しと突き詰めた後、ここに私が思いついたものがあります。それはうまくいくように思えますが、それは単純なものであるように思われる何かのための多くの仕事でもあるようです。他のアイデアはありますか？

手順1：すべてのインターフェイスでARPフィルタリングを有効にします。

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

Linuxカーネルドキュメントのnetworking / ip-sysctl.txtファイルから：

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

ステップ2：ソースベースのルーティングを実装する

私は基本的にhttp://lartc.org/howto/lartc.rpdb.multiple-links.htmlからの指示に従いましたが、そのページは異なる目標を念頭に置いて書かれています（2つのISPに対処する）。

サブネットが10.0.0.0/24、ゲートウェイが10.0.0.1、eth0のIPアドレスが10.0.0.100、eth1のIPアドレスが10.0.0.101であるとします。

/ etc / iproute2 / rt_tablesにeth0およびeth1という名前の2つの新しいルーティングテーブルを定義します。

... top of file omitted ...
1    eth0
2    eth1

これら2つのテーブルのルートを定義します。

# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1

新しいルーティングテーブルを使用するタイミングのルールを定義します。

# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1

メインルーティングテーブルはすでにDHCPによって処理されています（この場合、厳密に必要であることは明らかではありません）が、基本的には次のようになります。

# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101

そして出来上がり！すべてがうまくいくようです。両方のIPアドレスへのpingの送信は正常に機能します。このシステムから他のシステムにpingを送信し、特定のインターフェイスを使用するようにpingを強制することは正常に機能します（ping -I eth0 10.0.0.1、ping -I eth1 10.0.0.1）。そして最も重要なことは、いずれかのIPアドレスとの間のすべてのTCPおよびUDPトラフィックが期待どおりに機能することです。

繰り返しになりますが、私の質問は、これを行うより良い方法はありますか？これは、一見単純な問題に対する多くの作業のようです。

更新： 上記の解決策は不完全でした。トラフィックが同じサブネットに留まる場合は問題なく動作しましたが、2番目のインターフェイスを使用した他のサブネットへの通信は適切に機能しませんでした。より大きな穴を掘るのではなく、ネットワーク管理者と話をして、1つのインターフェイスに複数のIPアドレスを許可し、IPエイリアス（たとえば、eth0とeth0：0）を使用できるようにしました。

はい。適切なビジネスケースを構築し、スイッチのルールを緩和して、1つのNICに複数のIPを持たせることがより良い方法です。