異なるサブネットに2つのネットワークカードを持つRhel 8.7システムがあります。こうしておいてくださいeth1-IP:10.10.10.4/24 ,gateway:10.10.10.1。このゲートウェイは、2番目のNICだけでなく、この仮想マシンのデフォルトゲートウェイでもありますeth2, IP:10.10.20.2 , gateway:10.10.20.254。
状態：このコンピュータには複数のスタティックルートがあります。
両方のネットワークカードにはSSH経由で接続する必要がある特定のIP（10.10.30.33）があります（icmpもテストに許可され使用されます）。 eth1にデフォルトゲートウェイがあるため、他のサブネット上のこのIPは変更なしでeth1 IP：10.10.10.4に完全に接続できますが、eth2：10.10.20.2には接続できません。応答パケットがデフォルトゲートウェイの代わりにeth2ゲートウェイを通過するように固定パスを設定すると、アクセスは可能ですが、デフォルトゲートウェイへのインターフェイスはもはや可能ではなく、固定パスを追加する前の接続は機能しました。
ターゲット：着信インターフェイスの特定のIPに基づいて応答トラフィックのみをルーティングします。 10.10.30.33 が 10.10.10.4 に到達しようとした場合は eth1 から応答を送信し、10.10.20.2 に到達しようとすると応答パケットを eth2 から送信する必要があります。デフォルトでは、10.10.30.33が両方のシステムインターフェイスにアクセスできることを願っています。
ベストアンサー1
長い話を短く
10.10.30.33でのみマルチホーム設定を有効にするには、次の3つのコマンドを実行します。
ip route add 10.10.20.0/24 dev eth2 table 1002
ip route add default via 10.10.20.254 dev eth2 table 1002
ip rule add from 10.10.20.2 to 10.10.30.33 iif lo lookup 1002
上海
これが必要ですポリシールーティングデフォルトでは、Linuxはデフォルトのルーティングテーブルでメトリックが最も低いデフォルトパスのみを使用するためです。ポリシールーティングを使用すると、代替結果を選択するルーティングルールセレクタに応じて、代替デフォルトパスを持つ代替ルートテーブルを使用できます。ほとんどの場合、セレクタはソース（ターゲットではありません：パスで十分です）に関連付けられていますが、OPは10.10.30.33のみが異なる動作をトリガーする必要があることを明示的に指定したため、10.10.30.33に関する追加のセレクタパスも使用されます。 。
NetworkManagerを使用してRHEL 8でこの機能を正しく統合するか、廃止された方法を使用するには/etc/sysconfig/network-scripts/（NetworkManagerがインストールされている場合は、以前の方法が機能するかどうかわかりません）：
10.10.30.33に限定されない一般的なマルチホーミング使用の場合は、単にto 10.10.30.33。
使用されているパスのみがバックアップルーティングテーブル1002にない
eth2かのようにコピーされます（値1002はランダムに選択されます）。eth1ip route add 10.10.20.0/24 dev eth2 table 1002 ip route add default via 10.10.20.254 dev eth2 table 100210.10.20.2でローカルに開始されたトラフィック（応答を含む）に対して代替ルートテーブル1002を選択するには、ルーティングルールを使用します。
ip rule add from 10.10.20.2 to 10.10.30.33 iif lo lookup 1002統合が容易な場合は、ほとんどの場合
iif lo必要なく、ルールから削除できます。次の規則は、次の場合にのみ必要です。
ping -I eth2 10.10.30.33IPアドレス（ping -I 10.10.20.2 10.10.30.33）以外のインターフェイス（例：）にのみバインドする場合- デフォルトのルーティングテーブルに、この結合インターフェイスを使用するデフォルトパスがない場合（選択したデフォルトパスよりもメトリックが高い）、このパスがない場合、このインターフェイスのデフォルトパスは強制されますが、ゲートウェイがないと正しいパスは使用されません（症状：システムは別のネットワークにARPを送信します）。
- 未接続モード（たとえば、呼び出しが使用されていない）のICMPクライアントまたはUDPクライアントにのみ適用されます。
connect(2)ほとんどの設定では、正しい送信元IPアドレスは次のように設定されます。基本ソケットが使用されている場合、アドレスはソースのルーティングテーブルを暗示するように設定されますconnect(2)。以前のルーティングルールは、放出されるととにかくトリガされます。
ip rule add to 10.10.30.33 oif eth2 lookup 1002OPが実際に2番目のデフォルトパスを追加したようです。
2番目のネットワークカード：eth2、IP：10.10.20.2、ゲートウェイ：10.10.20.254
これで、上記のルールはもう必要ありません。基本ルーティングテーブルで十分です。
eth2多くの設定では、代替インターフェイス（）に定義されたデフォルトパスがないため、このルールは便利です。着信トラフィックには特定のルールは必要ありません。着信パケットのルートルックアップが早期に処理されます。地元のルーティングテーブル。
これは、トラフィックをルーティングするために必要な場合があります。たとえば、次のようになります。機械仮想マシンまたはコンテナを実行します。 OPはこれについて言及していない。とにかく、ここではより詳細な情報が必要です。Netfilter（iptablesまたはnftables）はルータエンクロージャに適しています。
これ以降、システム10.10.30.33は10.10.10.4または10.10.20.2でsshまたはpingを実行できる必要があります。同様に（ファイアウォールブロックがない場合）、デュアルホマーはインターフェイスeth2（または）またはアドレス10.10.20.2にバインドして10.10.30.33（たとえば、ping -I eth2 10.10.30.33または）にアクセスすることを選択でき、通常はデフォルトルーティングのデフォルト設定を使用します。テーブル。ssh -B eth2 10.10.30.33ping -I 10.10.20.2 10.10.30.33ssh -b 10.10.20.2 10.10.30.33
同等の構成は、デフォルトのeth1ルーティングテーブルですでに正しく処理されているため、オプションです。また、次のことを行います。
ip route add 10.10.10.0/24 dev eth1 table 1001
ip route add default via 10.10.10.1 dev eth1 table 1001
ip rule add from 10.10.10.4 to 10.10.30.33 iif lo lookup 1001
注：UDPサービス
基本的にUDP応答は、着信クエリに対するローカルシステムのIPアドレスまたはインターフェイスが何であるかを知るためにコンテキストを継承しません。したがって、デフォルトでは、UDPソケットがINADDR_ANY（0.0.0.0）にバインドされている場合、0.0.0.0は、ルート、インターフェイス、および遅すぎる送信元IPアドレスを確認するためにネットワークスタックに提供される初期送信元アドレスになります。これは、10.10.20.2 が次のルールで提供されないため、以前のルーティングルールのいずれも一致しないことを意味します。基本インターフェイスはまだ選択可能です。インターフェイスが認識されると、そのインターフェイスに適切なIPアドレスが選択され、デフォルトで選択されたインターフェイスのルーティングプライマリIPアドレスになります。これは、マルチホーミング認識をサポートしていないUDPサービスがeth110.10.20.2の要求を受信したとき（LAN 10.10.20.0/24から来る場合を除き）、まだ間違ったインターフェイス（）とアドレス（10.10.10.4）で応答する意味です。働く）。この動作はLinuxに限定されず、同様の理由で弱い機能を使用する他のオペレーティングシステムにも影響を与える可能性があります。ホストモデルとBSDソケットAPI。
これらのUDPサービスに両方のインターフェイスからアクセスする必要がある場合は、この問題を解決する2つの方法があります。
代わりに各アドレスに明示的にバインドします
INADDR_ANY。たとえば、HTTP / 3サービスがUDPポート80を使用している場合は、0.0.0.0:80にバインドするのではなく、2つの別々のソケットバインディングを使用するように設定する必要があります。 10.10.10.4: 80 および 10.10.20.2:80。この場合、UDPソケットを介した応答は、バインドされたアドレスをソースとして選択して、正しいルーティングルールとインターフェイスをトリガします。たとえば、DNS サーバーが通常行う作業は次のとおりです。バインディング9。ほとんどのアプリケーションには、このための特定の構成があります。UDPを処理するときにアプリケーションがマルチホーミングを認識できるようにします。これにはアプリケーションのアクティベーションが必要です。補助メッセージ実際の受信インターフェイスおよび/またはUDPパケットが受信されたアドレスを取得するには、次のようにします。
IP_PKTINFOソケットオプションを選択して応答するときにこの情報を使用してください。たとえば、DNS サーバーが通常行う作業は次のとおりです。束縛されていない。これにはアプリケーションに特定のコードが必要です。
TCPはこの問題を経験しません。応答には、正しいソースアドレスを選択し、正しいルーティングルールをトリガするコンテキストがあります。