☰

コンテクスト

tag-icon • tag-icon vlan linux-networking ping gateway arp
コンテクスト

コンテクスト

サーバーは2つあります:

サーバー1 - eth0 10.129.76.16 eth0.2 192.168.0.103

サーバー2 - eth0 10.129.79.1 eth0.2 192.168.62.101

192.xxx アドレスは同じ VLAN (vlan2) に接続されており、相互に認識できます。10.xxx アドレスは異なる VLAN に接続されており、相互に認識できません。

David Swartz のリクエストにより、サーバー 1 のルーティング テーブルは次のとおりです。

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.129.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2
0.0.0.0         192.168.61.254  0.0.0.0         UG    100    0        0 eth0.2

サーバー 2 のルーティング テーブルは次のとおりです。

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <public IP gw>  0.0.0.0         UG    100    0        0 eth0.11
10.129.79.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
<public IP>     0.0.0.0         255.255.255.128 U     0      0        0 eth0.11
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2

問題：

サーバー 1 からサーバー 2 に ping すると、パケットが到着していないように見えます。逆も同様です。ルートを確認すると (route -n)、デフォルトの gw は両方のサーバーで eth0.2 を使用していることがわかります。ただし、arping を使用すると、一方向 (サーバー 2 からサーバー 1 へ) の応答は得られますが、その逆の応答はありません。

arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)

ご覧のとおり、192.xxx ではなく 10.xxx アドレスが使用されています。また、前に述べたように、10.xxx アドレスは他のサーバーからは到達できません。

arping に eth0.2 を使用するように強制すると、動作します。

これら 2 つのサーバーのいずれかから他のサーバーに ping を実行しても問題はありません。

私はarpテーブルでこれを見ました:

~# arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

そして

~# arp -n | grep 192.168.62.101

質問

非常に明白です...これらのサーバーが再びお互いを認識するようにするにはどうすればよいでしょうか?

私が結びつけたもの

arptableの適切なエントリをクリアし、(不完全)を削除しようとしましたが、最大の問題は、サーバー1からサーバー2へのパケットにeth0.2ではなくeth0が使用されていることだと思います。

David Swartzのルーティングテーブルに関するコメントを参考に、ホストを定義するルートを追加しました。

192.168.0.103   0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

そして

192.168.62.101  0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

適切なサーバーに送信しましたが、問題は解決しなかったので、問題はルーティングにないと思われます。

私の推測

問題は次の点にあると思います。

~$ arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

しかし、このエントリを削除できません。(arp -d 192.168.0.103 は効果がありません)

読んでいただきありがとうございます。そして、回答していただき、さらにありがとうございます!

答え1

以下は抜粋です:

arpping はローカル ルーティング テーブルを尊重しません。

== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess

icmp を使用してテストします:

[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem

VLANは大丈夫ですか?

[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too

答え2

使用しているカーネルや のバージョンについては言及されていませんarpingが、どちらかにバグがある可能性があります。arpingサブインターフェイスを指定して正常に実行できるということは、レイヤー 2 ネットワークのすべてが適切に動作していることを示しています。

server1 で を使用してip route get 192.168.62.101、カーネルにトラフィックの送信方法を直接問い合わせてみてください。投稿したルーティング テーブルに基づくと、eth0.2 経由での送信が明らかに正しい動作であり、ip route get異なる応答が返される場合は、カーネルのバグである可能性があります。正しい応答が返される場合は にarping責任がありますが、その可能性は低いようです。

この(incomplete)エントリは削除する必要はありません。これは、カーネルにそのIPにARPを試みたことを知らせるプレースホルダーであり、ARP応答が有効であるとみなされ、ARPポイズン攻撃、しかし、応答が得られませんでした。タイムアウトになります。

関連情報