web-dev-qa-db-ja.com

サブネット内の一部のIPに到達できません

私は3台のDebianサーバーを実行しており、それぞれに独自のIPMIがあります。すべてのIPは、同じゲートウェイを持つ同じサブネット内にあります。問題は、各サーバーが独自のIPMIにpingを実行できるが、他の2つのサーバーのIPMIにはpingを実行できないことです。

とは言うものの、3つのIPMIとサーバーはすべて、IPによって外部からping可能でアクセス可能です。

各サーバーには2つのNICがあり、eth0は外部へのネットワークであり、eth1はサーバー間の内部トラフィックに使用されます。

私のネットワーク構成は次のようになります。

eth

1.2.3.84    (Server1)
1.2.3.85    (Server2)
1.2.3.86    (Server3)

1.2.3.71    (IPMI Server1)
1.2.3.76    (IPMI Server2)
1.2.3.66    (IPMI Server3)

1.2.3.65    (Gateway)
255.255.255.224 (Netmask)

eth1

10.10.10.1  (Server1)
10.10.10.2  (Server2)
10.10.10.3  (Server3)

/ etc/network/interfaces（この例ではServer1の1つ）

auto  eth0
iface eth0 inet static
  address   1.2.3.84
  netmask   255.255.255.224
  gateway   1.2.3.65

  # default route to access subnet
  up route add -net 1.2.3.64 netmask 255.255.255.224 gw 1.2.3.65 eth0


auto eth1
iface eth1 inet static
  address 10.10.10.1
  netmask 255.255.255.0

route -n（server1上）

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.2.3.64        1.2.3.65        255.255.255.224 UG    0      0        0 eth0
1.2.3.64        0.0.0.0         255.255.255.224 U     0      0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         1.2.3.65        0.0.0.0         UG    0      0        0 eth0

他のサーバーからIPMIにアクセスできない理由はありますか？

[〜＃〜]編集[〜＃〜]

使用されるIPMIは、共有NICを管理用に構成し、オペレーティングシステムと共有する（マニュアルによる））を使用する「IntelRemote Management Module（RMM）」です。

サーバー（およびサブネット外の外部サーバー）は、IMPIへの接続に問題はありません。

Server1のRMMのネットワーク構成は次のとおりです。

IP Address: 1.2.3.71
Subnet Mask: 255.255.255.224
Default Gateway: 1.2.3.65

サーバーから独自のIPMIへのtracerouteは、次のようになります。

traceroute to 1.2.3.71 (1.2.3.71), 30 Hops max, 60 byte packets
 1  static.25.184.x.y.clients.your-server.de (y.x.184.25)  0.921 ms  0.914 ms  0.941 ms
 2  static.71.3.2.1.clients.your-server.de (1.2.3.71)  10.457 ms  10.460 ms  10.446 ms
networkingdebianroutingip
4
crash3k

私はあなたの最大の問題は（だった）だと思います：

# default route to access subnet
up route add -net 1.2.3.64 netmask 255.255.255.224 gw 1.2.3.65 eth0

これにより、ルーティング（ゲートウェイ/ルートが必要）ではなく、物理的に接続された（ローカル）ネットワークに対してルートが定義されます。このルートは、リンクローカルトラフィックよりも優先されます（ルーティングテーブルの最初に表示されます）。

このように構成されたシステムは、すべてのトラフィックをゲートウェイに転送し、ゲートウェイに依存してトラフィックを転送するため、ルーティングされたネットワーク上の他のホストと直接通信することはできません。

1.2.3.65は、受信したインターフェイス/ネットワークからパケットを転送していない可能性があります（つまり、パケットは1.2.3.64/27から送信され、1.2.3.64/27ネットワーク宛てであるため、明らかに必要ありません。転送される）。これにより、サーバーが1.2.3.64/27ネットワーク上の他のホストと間接的に通信するのを防ぎます。直接通信能力と間接通信（ゲートウェイで跳ね返る）がないため、通信はありません。

サーバーは10.10.10.0/24ネットワーク上で相互に通信できることに注意してください。これは正常に機能し、おそらく/ etc/hostsまたはDNS内のホスト用に構成されたIPアドレスです。個々のサーバーが1.2.3.64/27ネットワークIPアドレス上の他のサーバーに到達できないと思われます。

1.2.3.64/27に構成されたルートを削除する場合、各システム（RMMおよびサーバー）に構成されたデフォルトゲートウェイは、必要なすべてのルーティングである必要があります。

唯一の奇妙なことは、RMMがゲートウェイ用にアドレス指定されている（レイヤー2）にもかかわらず、RMMが宛先のトラフィック（レイヤー3）に応答していることです。私の推測では、RMMはインターフェイスを共有しているため、MACアドレスなどのばかげたことに関係なく、パケットが交差するときにパケットをスナッフィングします。スイッチはMACアドレスを尊重し、パケットをブロードキャストしないため、RMMはゲートウェイ宛ての他の物理デバイスからのパケットを認識しません。

1
Slartibartfast