次のトポロジを検討してください。
host BからにICMP（ping）パケットを送信しています10.0.1.1。彼らは目標を達成し、目標は答えられましたreply。接続がうまく機能しています。
実行時にオンにします。host A
tcpdump -i eth1 icmp: パケットが見えないtcpdump -i eth2 icmp：パケットを見た
eth1インターフェイスに送信したいパケットが実際にそのインターフェイスに到着したことを確認する方法はありますか？
ある日、カーネルがレベルeth2（パケットが到着する最初のインターフェース）で応答を処理するという内容を読んだことを思い出してください。これは、モニタリングがeth1何も生成できない理由を説明します。
この特定のケースを確認する理由は次のとおりです。パケットがホストのインターフェイス（最初の最初のインターフェイス）に到着しますが、予想されるインターフェイスに到着しないような状況があります（実際のアプリケーションではありません）。開始）。これらのテストにより、ファイアウォール/配信が正常であるか、問題が他の場所にあるか（アプリケーションの設定、アプリケーションのバグなど）を確認できます。
答え1
Linux では、受信パケットをローカル コンピュータで処理する必要があるかどうかを確認してルーティングされます。必要に応じて、まず「正しいインターフェイス」を介してルーティングせずに直接処理します。 IPアドレスはシステムのエイリアスにすぎず、パケットがどのインターフェイスに到着するかは重要ではありません。
ローカルでこれを実行しても同じことが起こりますtelnet 10.0.1.1。ローカルシステムから自分のシステムへのすべてのパケットを処理しているようには見えませんeth1。lo
ただし、アウトバウンドパケットの場合、アドレスが属するインターフェイスは異なります。カーネルは最初にパケットをルーティングする方法を決定し、次にそのルートに基づいてパケットに最適な送信元 IP を選択します。
を使用して「すべてのパケット」を確認する必要がある場合は、これを行うことがtcpdumpできますtcpdump -i any icmp。インターフェイスは表示されませんが、すべてのパケット（例：10.0.1.1。
答え2
あなたが話す主題は弱い/強いホストモデルLinuxは基本的に弱いものを使います。
eth1インターフェイス用のパケットがそのインターフェイスに到着したことを確認する方法はありますか？
ファイアウォールがそのような制限を加えることを許可すると言いたいと思います。
パケットがホストのインターフェイス（最初のパケット）に到着しましたが、予想されたインターフェイスに到着しないような（実際のアプリケーションが起動しない）状況に直面しました。これらのテストにより、ファイアウォール/配信が正常であるかどうか、他の問題があるかどうか（アプリケーションの設定、アプリケーションのバグなど）を確認できます。
前の例では ICMP に言及しました。実際の接続を確認するためにこれを使用するのに問題がありますか？
また、この時点では、提供にループバックインターフェイスを使用する慣行に非常に近いです。これは主に動的ルーティングで使用されますが、主なアイデアは非常に簡単です。要求がどのインターフェイスから来るかは問題ではありません。ただ方法を見つけて答えを送ることもできることが重要です。ループバックインターフェイスは手動で指示しない限り終了しません。 「実際の」インタフェースOTOHは、リンクの損失などによって状態を変更することができます。