☰

Linux 2インターフェイス2ゲートウェイルーティングの問題

tag-icon • tag-icon linux routing route
Linux 2インターフェイス2ゲートウェイルーティングの問題

2つのネットワークカードに2つのIPアドレスを持つOracle Linux 8.4を実行しているサーバーがあります。

    link/ether 34:48:ed:f6:d3:5c brd ff:ff:ff:ff:ff:ff
    inet 10.154.224.252/24 brd 10.154.224.255 scope global noprefixroute eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::3648:edff:fef6:d35c/64 scope link
       valid_lft forever preferred_lft forever
3: ens2f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether bc:97:e1:7a:41:e0 brd ff:ff:ff:ff:ff:ff
    inet 10.154.226.252/24 brd 10.154.226.255 scope global noprefixroute ens2f0np0
       valid_lft forever preferred_lft forever
    inet6 fe80::be97:e1ff:fe7a:41e0/64 scope link
       valid_lft forever preferred_lft forever

/etc/iproute2/rt_tables db and app そのため、スクリプトに2つのテーブルパスを作成しました。

#!/bin/sh
ip route add 10.154.226.0/24 dev ens2f0np0 src 10.154.226.252 table db
ip route add default via 10.154.226.1 dev ens2f0np0 table db
ip rule add from 10.154.226.252/24 table db
ip rule add to 10.154.226.252/24 table db

ip route add 10.154.224.0/24 dev eno1 src 10.154.224.252 table app
ip route add default via 10.154.224.1 dev eno1 table app
ip rule add from 10.154.224.252/24 table app
ip rule add to 10.154.224.252/24 table app 

ip r command show:
 
10.154.224.0/24 dev eno1 proto kernel scope link src 10.154.224.252 metric 100
10.154.226.0/24 dev ens2f0np0 proto kernel scope link src 10.154.226.252 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

すべてのインターフェイスでシステムにSSHで接続できますが、サーバーからインターネットまたは他のサブネットに接続することはできません。

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.154.224.0    0.0.0.0         255.255.255.0   U     100    0        0 eno1
10.154.226.0    0.0.0.0         255.255.255.0   U     100    0        0 ens2f0np0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

何か抜けましたか？この問題をどのように解決できますか？

ベストアンサー1

インターネットにアクセスできない理由は次のとおりです。基本ルーティングテーブルにはデフォルトパスはありません。

したがって、たとえば、バインドされていないTCPソケットが作成されて接続されている場合（たとえば、INADDR_ANYにバインド）、パスルックアップを使用してソケットconnect(2)に割り当てるローカルIPアドレスを決定します。結果が何であるかを判断するためにソケットがバインドされていないため、このパスはINADDR_ANYローカルアドレスを使用します。したがって、比較された値は0.0.0.0なので一致しないため、ポリシールールを特定のソースアドレスと一致させません。基本ルーティングテーブル。

以下を使用して確認できますip route get。

# ip route get 8.8.8.8
RTNETLINK answers: Network is unreachable

ただし、クライアントアプリケーションがアドレスをバインドする場合（たとえば、curl --interface=10.154.226.252 ifconfig.coDNSも影響を受けるため、この例に追加する必要があります。DNS--dns-interface=10.154.226.252サーバーが接続可能なLANにない場合）、ポリシールールが一致し、代替パスは次のとおりです。 。 Apply を使用すると接続が可能になります。

# ip route get from 10.154.226.252 104.21.25.86
104.21.25.86 from 10.154.226.252 via 10.154.226.1 dev ens2f0np0 table db uid 0 
    cache 
# ip route get from 10.154.224.252 104.21.25.86
104.21.25.86 from 10.154.224.252 via 10.154.224.1 dev eno1 table app uid 0 
    cache

したがって、「デフォルト」のデフォルトパスがまだ必要です。基本クライアントアプリケーションがホストに属するIPアドレスに明示的にバインドされていない場合は、選択する必要があります。私たちを入れましょうアプリエッジを選択:

ip route add default via 10.154.224.1

だから今：

# ip route    
default via 10.154.224.1 dev eno1 
10.154.224.0/24 dev eno1 proto kernel scope link src 10.154.224.252 
10.154.226.0/24 dev ens2f0np0 proto kernel scope link src 10.154.226.252 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 

# ip route get 8.8.8.8
8.8.8.8 via 10.154.224.1 dev eno1 src 10.154.224.252 uid 0 
    cache

もし本物デフォルトのパスを追加する代わりに、ip ruleINADDR_ANYで成功したパスの検索を許可するように作成されたコマンドで置き換えることができます。

ip route del default

ip rule add from 0.0.0.0/32 lookup app

使用する以外は同じ結果アプリ代わりにテーブル基本テーブル：

# ip route get 8.8.8.8
8.8.8.8 via 10.154.224.1 dev eno1 table app src 10.154.224.252 uid 0 
    cache

どのインターフェイスが重要ではなくロードバランシングが必要な場合は、上記のデフォルトパスを代わりに使用できます。マルチパス路線：

ip route del default # was already done
ip rule del from 0.0.0.0/32 lookup app

ip route add default nexthop via 10.154.224.1 dev eno1 nexthop via 10.154.226.1 dev ens2f0np0

発信アドレスを「ランダムに」選択し（実際に信頼性の高いパスを取得するためにソースと宛先に基づいていくつかのハッシュアルゴリズムに従います）、選択したインターフェイスでバインドする暗黙的なソースアドレスを選択し、追加の送信パケットはポリシールーティングを使用します。 （ただし、ポリシールーティングがなくても、ハッシュはそれを同じインターフェイスに保持し、ループではありません。）

はい（他のシステムによって異なる場合があります。少なくとも4つの連続したIPアドレスを試してください）：

# ip route get 8.8.8.9
8.8.8.9 via 10.154.224.1 dev eno1 src 10.154.224.252 uid 0 
    cache 
# ip route get 8.8.8.10
8.8.8.10 via 10.154.226.1 dev ens2f0np0 src 10.154.226.252 uid 0 
    cache

マルチパスをそのまま使用するには、さまざまな注意事項があります。一部の場所では、適切なSNAT / MASQUERADEがまだ必要ですが（しかし正しく機能する必要があります）、インターフェイスへのルーティングが失敗すると、クライアント側のアンバインド接続の試行の半分が失敗します。回復メカニズムは必要ありませんが、以前は100％または0％でした。

おすすめ記事