web-dev-qa-db-ja.com

2つのNIC間で同じIPを共有し、1つのIPを専用のNIC

同じスイッチに接続されたいくつかのホストがあり、それらはすべて同じサブネット（10.0.0.0/16）上にあります。これらのホストのうちの2つは、より高速なネットワークインターフェイスを備えているため、これらを相互に接続しました。つまり、これら2つのマシンは、スイッチを経由せずに相互に直接リンクしています。

ここで、これら2つのマシンが相互に通信しようとしたときに、パケットがスイッチを介した低速リンクよりもこの高速直接リンクを通過するようにルーティングを設定する必要があります。

最も簡単な方法は、直接リンクを別のサブネット上に構成することですが、使用するインターフェイスに応じて異なるIPまたはホスト名を使用する必要があり、すべてのマシンに標準構成を展開できるようにします。 （たとえば、ホスト名を使用したNFSマウント）/etc/hostsでカスタムIPオーバーライドを維持する必要がないため、このソリューションでは、ホスト名を間違えてトラフィックを間違ったインターフェイスに送信するのは簡単すぎると思います。

私が探しているのは、2つのLinuxマシンに、eth0が10.0.0.0/16を処理する場合でも、10.0.0.5と通信したい場合は、eth0のサブネットにあるにもかかわらず、パケットを送信することを伝える方法です。代わりにeth1。

正しいインターフェイスでパケットを送信するroute add -Host 10.0.0.5 dev eth1を使用してホストルーティングルールを追加しようとしましたが、これは間違ったIPアドレス（元のサブネットではなく直接リンクのサブネット）からのものです。

これを修正する唯一の方法は、両方のインターフェイスに同じIPアドレスを設定することだと思いますが、これにより問題が発生しますか？マシンは、問題を引き起こすことなく、複数のNICで同じIPを正しく持つことができますか？スイッチに接続されているNICが優先されるように、ルーティングメトリックを適切に設定する必要があると想定しています（サブネットのすべてのトラフィックが誤って他のホストに送信されるのを防ぐため） 、しかし、この設定で知っておく必要のあることは他にありますか？他の問題や解決が難しい問題につながる可能性はありますか？

それとも、これを達成するためのより良い、より堅牢な方法はありますか？

編集：これは@ A.Bによって要求された追加のものです：

$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
eth0             UP             ec:f4:xx:xx:xx:a4 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth1             UP             ec:f4:xx:xx:xx:a5 <BROADCAST,MULTICAST,UP,LOWER_UP> 

$ ip -br address
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.4/16
eth1             UP             10.0.99.4/24

$ ip route
default via 10.0.0.1 dev eth0 proto static 
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.0.4
10.0.0.5 dev eth1 scope link 
10.0.99.0/24 dev eth1 proto kernel scope link src 10.0.99.4

別のサブネットに直接リンク（eth1）を設定してから、元の投稿でrouteコマンドを試しましたが、これが現在の状況です。直接ルートにsrc属性を設定する必要があるようです。

linuxroutingmulti-homed
1
Malvineous

10.0.99.4は10.0.0.0/16の一部であるため、このIPアドレスは避ける必要があります。そうしないと、Linuxが 弱いホストモデル を使用していることを考慮しても、ethでも、実際の10.0.99.4/16アドレスと競合し、デフォルトでARP要求に応答します。このIPアドレスは10.0.99.4のethにもあり、ARPの競合が発生します。競合するIPアドレスを使用しないでください。

掃除：

ip route flush dev eth1
ip address flush dev eth1

接着剤IPアドレスを使用する標準的な方法

2つのホストが使用する2つの無関係なアドレスを選択してみましょう。それらはネットワーク上で使用されている他のものと衝突する必要はありませんが、ポイントツーポイント/ 32アドレスであるため、何でもできます。LANの一部としては使用されず、ポイントツーポイントとしてのみ使用されます。ポイント/ピアアドレス。 192.168.100.4/32と192.168.101.5/32を任意に使用します。後でこれらのホストのうち2つ以上がより高速なスイッチを継承し、この個別のスイッチを使用して相互に接続された場合、これをわずかに修正して、同じブロックに関連するIPアドレスを含めることが再び簡単になります。

ホスト10.0.0.4の構成：

# /32 : no route gets created (beside the hidden *local* routing table)
ip address add 192.168.100.4/32 dev eth1 
# add the peer (point to point) route on the same link
ip route add 192.168.101.5/32 dev eth1

実際、上記の2つのコマンドにはショートカットがあり、両方を以下の1つのコマンドに置き換えることができます。

ip address add 192.168.100.4 peer 192.168.101.5/32 dev eth1

ここで、10.0.0.5/32（10.0.0.0/16よりも具体的）に到達するために、ピアIPアドレスを使用するルートがあるが、別の送信元IPアドレスを優先することをホストに伝えますデフォルトで選択されるものよりも（廃止されたrouteコマンドはこれを実行できません）：

ip route add 10.0.0.5/32 via 192.168.101.5 dev eth1 src 10.0.0.4

これを適切に配置すると、次のようになります。

# ip route get 10.0.0.5
10.0.0.5 via 192.168.101.5 dev eth1 src 10.0.0.4 uid 0 
    cache

小さな欠点が1つあります。IPブロードキャストはまだethに送信され、 Strict Reverse Path Forwarding がアクティブな場合（sysctl net.ipv4.conf.eth0.rp_filterまたはsysctl net.ipv4.conf.all.rp_filterのいずれかが1を与える0または2）よりも大きい）これらのブロードキャストは、ピアによって送信された場合（たとえば、ピアホスト10.0.0.5で実行されている場合はecho test | socat udp4-datagram:10.0.255.255:5555,broadcast -に似ています）、現在wrongインターフェイスで受信されるため、無視されます。したがって、これに依存するプロトコルを使用していて、すでにStrict Reverse Path Forwardingを適用している場合は、必要に応じてethをLooseモードに切り替えます。

sysctl -w net.ipv4.conf.eth0.rp_filter=2

ホスト10.0.0.5の同等の構成：

ip address add 192.168.101.5 peer 192.168.100.4/32 dev eth1
ip route add 10.0.0.4/32 via 192.168.100.4 dev eth1 src 10.0.0.5
sysctl -w net.ipv4.conf.eth0.rp_filter=2

たとえば、Debianのようなifupdowninterface 設定ファイルでは、pointopointキーワードと、いくつかのup追加コマンドを、同等の方向設定がないコマンドに使用できます。 （sysctlはむしろ /etc/sysctl.d に配置されます）。

追加の（または重複しない）IPアドレスを使用しない簡略化された方法

実際、192.168.100.4と192.168.100.5の唯一の役割は、リンク層アドレスを解決して10.0.0.4と10.0.0.5のルートを知ることです。他の役割を果たさない、ある種の接着剤として使用されます。これらのIPアドレスは完全に見えなくなり、IPパケットがコンテンツで192.168.100.4または192.168.100.5を使用することはありません（これらを明示的に使用する場合を除いて）、ARP要求と応答のみが使用されます。このようなグルーIPアドレスを使用する必要はまったくありません。

たとえば、ホストプロバイダー Hetznerが例を示します ：

ip route add 203.0.113.40/32 dev tap0

インターフェイスのIPアドレスに到達するにはこのインターフェイスのIPアドレスを構成せずに（このインターフェイスをブリッジポートとして使用することもありません）。この例では、tap0のピア（反対側のVM）にリンクされたイーサネットモードのtun/tapデバイス）は、リンク層を解決するためにARP要求に応答する必要がありますアドレス。

しかし、対称的な理由から、他の場所ですでに構成されている場合は、IPアドレスを構成する必要はありません。eth1を介して行われたARP要求に適切に応答するために、これも Linuxの一部） '実装 弱いホストモデルの。

したがって、これは、単一のコマンドのみを使用して追加のIPアドレスを使用することなく、ホスト10.0.0.4に簡単に使用できます。

ip route add 10.0.0.5/32 dev eth1

または、ソースを指定するには（ホストに複数ある場合のあいまいさを避けるため）：

ip route add 10.0.0.5/32 dev eth1 src 10.0.0.4

また、ホスト10.0.0.5の場合：

ip route add 10.0.0.4/32 dev eth1 src 10.0.0.5

ethでピアからの「遅い」ブロードキャストを受け入れるには、以前と同様に次のことが必要です。

sysctl -w net.ipv4.conf.eth0.rp_filter=2

IPアドレスを解決するためのARP要求は、両方のインターフェイスで応答できます（上記のリンクのとおり Linuxはデフォルトでこれを行います ）が、ここでは通常の（古い）側の解決またはエントリeth =もしあれば（例えば：それらの設定が行われる前に） ARPフラックス 両方のピアが構成されているため一緒に使用するeth1ルートに他の可能な解釈を残しません。

ご希望の方法を選択してください。前者はより古典的で、後者はより簡単な設定です（ただし、ピアから「これは機能しない」というメッセージがいくつか表示される場合があります）。手動で追加されたルートは、インターフェイスがadministrativelyに設定されてから停止されると失われるため、これらの設定を適切に有効にするには、適切なネットワーク構成設定に含める必要があります。

2
A.B