LANの受信と同じインターフェース上の応答パケット

Question

現在、私は次のようなシナリオに苦労しています。

• 2つの別々のLANサブネットに2つのインターフェースを持つサーバーがあります。IF1、IF2
• 最初のサブネットのIPアドレスを持つラップトップを持っています
• この特定のラップトップからサーバーの 2 番目の IP アドレスに接続しようとすると、まったく応答がありません。

たとえば、IP 172.31.190.129 のラップトップから 172.31.196.185 に ping を実行しようとすると、ens224 インターフェイスの tcpdump で着信要求を確認できますが、その後、他のインターフェイスでは応答要求がありません。

これが私のネットワーク図です:

       +-------------------------+
       |                         |
       |  Laptop 172.31.190.129  +---------+
       |                         |         |
       +-------------------------+         |
                                           |                 +-------------------------+
                                           |                 |                         |
                               +-----------+---------+       |       Linux Server      |
                          +----+                     |       |                         |
                          |    | LAN 172.31.190.0/23 +-------+ IF1  -  default gw      |
                   +------+--+ |                     |       | 172.31.190.63           |
    +----------+   |         | +---------------------+       |                         |
    | Internet +---+ Gateway |                               |                         |
    +----------+   |         | +---------------------+       |                         |
                   +------+--+ |                     |       |                         |
                          |    | LAN 172.31.196.0/23 +-------+ IF2                     |
                          +----+                     |       | 172.31.196.185          |
                               +---------------------+       |                         |
                                                             |                         |
                                                             |                         |
                                                             +-------------------------+

また、次のスクリプトもあります:

IF1=ens160
IF2=ens224

P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23

IP1=172.31.190.63
IP2=172.31.196.185

P1=172.31.190.1
P2=172.31.196.1

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2

これはこのリンクに従って書かれています:https://lartc.org/howto/lartc.rpdb.multiple-links.html

私の場合、ポリシーベースのルーティングを作成するためにさまざまな方法を試しましたが、どれも成功しませんでした...

Answer 1

要約

必要はありませんiptables、マーク、リラックスすることもリバースパス転送/フィルタip rule送信パケットに一致しない を使用する代わりに、LARTCのドキュメントあなたが提供したリンク:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

そうすればすべてうまくいきます。

---

ロングバージョン

リラックスすることで物事がうまくいく可能性は常にあるとしてもリバースパス転送/フィルタ例えばsysctl -w net.ipv4.conf.all.rp_filter=2などにより非対称ルーティングが可能になるため、非対称ルーティングは常に避けるべきです。特に、ゲートウェイ（厳格なステートフルファイアウォールとして動作している場合）またはラップトップ同様の理由で許可されない場合もあります。iptables間違った動作を修正するためのマークは、すでに複雑なルーティング設定がどのように動作するかを理解するのにはまったく役立ちません。

リンクされたドキュメントでは、サーバーのIPをソースとして使用しています（$IF2/の場合）ens224: 172.31.196.185)インターフェースなしipルールでは、ルール内で着信インターフェースを指定しています（ここでdevは を意味しますiif）。これが問題です。これは期待通りの効果をもたらしません。 の説明を参照してくださいiif。ip rule:

もし名前

一致する着信デバイスを選択します。インターフェースがループバックの場合、ルールはこのホストから発信されたパケットのみに一致します。つまり、転送されたパケットとローカル パケットに別々のルーティング テーブルを作成し、それらを完全に分離することができます。

明確に書かれていないが、その逆も真なり。パケット起源このホストからのものはループバックインターフェースにのみ一致します。これらはiif ens160とも とも一致せiif ens224ず、iif lo（yesiifは着信インターフェースとiif loローカルで生成された一致発信するパケットの場合、これを「ローカル システムから着信（ルーティング ルールが指示する場所へ）」と解釈してください。これは重要です。

その後何が起こるでしょうか:

1. ラップトップ$IP2に到達しようとします（$IP2が同じLAN上のサーバーの$IF1と$IP1を介して到達可能であることは知らないし、知る必要もありません）、パケットを送信します。ゲートウェイ、

2. ゲートウェイパケットを$P2_NETに属するサーバーの$IP2にルーティングし、その$IF2インターフェースにルーティングし、

3. サーバ$IF2インターフェースで$P1_NET（172.31.190.129から）に属するパケットを受信し、

4. サーバの厳密な逆パスrp_filter=1逆ルートをチェックし、

5. 上図のように、逆ルート一致しないiifと異なるもの: iif lo2 つの新しいルールは一致しないため、唯一残っている一致するルールは、メイン ルーティング テーブルのルール: $IF1 を介したルールです。これは次のように検証されます:

    # ip route get 172.31.190.129 from 172.31.196.185
    172.31.190.129 from 172.31.196.185 dev ens160 uid 0 
        cache 
   

6. リバース パスはパケットが到着したインターフェイスを使用していません。パケットはドロップされます。

同様の理由から、現在の設定では、サーバ$IP2 を使用する場合: 再び新しいルールに一致しないため、$IF1 の使用を試みます:

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache 

したがって、LARTC に記載されているように、2 つのルールが削除され、次のように変更されます。

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

あれは：

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

ルート検索でわかるように、すべては正常に動作します (現在は を使用table T2)。

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

これら 3 つのバリエーションも機能する可能性があります (簡潔にするために、テーブル T2 のルールのみを示します)。

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

マニュアルページに記載されているように、iif lo次の場合には動作が変わります。サーバまた、その背後に他のシステムもルーティングします (この場合も、それらのシステムではルールが一致しません)。必要な場合を除いて使用しない方がよいでしょう。

必要はありませんiptablesマークを使用してインターフェースを変更すると、ルーティング、ARP要求、リバースパスフィルタリングで追加の問題が発生する可能性があります（マークを使用すると、通常、rp_フィルター) なので、避けられるのであれば使用しない方がよいでしょう。