同じネットワーク上の2つのNICへのトラフィックのルーティング
ScalewayにいくつかのLinuxテストボックスがあり、それぞれに2x NICがあり、すべて同じネットワークに接続されています10.0.0.0/8ですが、それぞれに独自のゲートウェイがあります。
NIC（eth0/eth1）とIPの両方を通信に使用できるようにしたいと考えています。したがって、アプリケーションがIP .187にバインドされている場合は、dev eth0を使用する必要があります。アプリケーションがIP .189にバインドされている場合は、eth1を使用する必要があります。
現在、IP .187のインターフェースeth0のみがリクエストに応答しています。すべてのリクエスト（テストのためにpingとsshを使用するのはそのためです）。ただし、デフォルトルートをeth0からeth1（ip .189）に変更すると、発信トラフィックはeth1を介して正しくルーティングされます。この場合、eth0は使用できなくなります。
ボックスの設定方法です。両方のインターフェイスが使用できるようになります。
与えられた
Box 1:
eth0_ip = 10.5.68.187/31
eth0_gw = 10.5.68.186
eth1_ip = 10.5.68.189/31
eth1_gw = 10.5.68.188
アプローチ
私の調査に基づいて、 here 、 here 両方のNICを使用できるように、テーブルに静的ルートを追加する必要があるbashスクリプトを作成しました。
#/bin/bash
# My Vars with IP and GW for eth0
eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
#ip route add 10.0.0.0/8 dev eth0 table 1 priority 100
#ip route add ${eth0_ip} dev eth0 table 1
ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip}/32 table 1
#ip route add 10.0.0.0/8 dev eth1 table 2 priority 110
#ip route add ${eth1_ip} dev eth1 table 2
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip}/32 table 2
ip route flush cache
スクリプトのバリエーションをいくつか作成しましたが、どれも機能しませんでした
出力
[node]# ip route
default via 10.1.229.186 dev eth0
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1
[node]# ip route show table 1
10.1.229.187 dev eth0 scope link
[node]# ip route show table 2
10.1.229.189 dev eth1 scope link
テスト中
[]]# ip route get 10.5.68.187 from 10.1.229.187
10.5.68.187 from 10.1.229.187 via 10.1.229.186 dev eth0
cache
[]# ip route get 10.5.68.187 from 10.1.229.189
10.5.68.187 from 10.1.229.189 via 10.1.229.188 dev eth1
cache
別のマシンから。
ping 10.1.229.187 # OK
ping 10.1.229.189 # NOK
nmap 10.1.229.187 -p 22 # OK
nmap 10.1.229.189 -p 22 # NOK
では、ルーティングを設定してそれが機能するようにするには、どうすれば.187と.189を同時に通信できるでしょうか。
アップデート2：
このセットアップで、私はある種の成功を収めることができました。
eth0_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1)
eth0_gw=$(ip route list dev eth0 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
ip route add default via ${eth0_gw} dev eth0 table 1
ip rule add from ${eth0_ip} table 1
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} table 2
上記のスクリプトを適用した後、デフォルトルートを変更し、eth1に切り替えてから元に戻し、その後、.187と.189にpingを送信できました。 （別の例では、これも完全に削除しました）私はここの問題が何であるかわかりません。
# remove and add route
ip route change default via ${eth1_gw} dev eth1
ip route change default via ${eth0_gw} dev eth0
ip route flush cache
更新3：
さまざまなトライアウトから、表2は完全に無視されているように思えます。 ISPにはカスタムカーネルがあるので、カーネルのルーティングテーブルを無効にできますか？どうすればテストできますか？
アップデート4：
もう一度、私は少し進歩しましたが、まだ実用的な解決策には程遠いです。さまざまなオプションを試してみて、私はこの奇妙な状況に遭遇しました。 eth1が機能することを確認するために、最初に問題のインターフェイスを使用する必要があります。
IP .189（node1）からネットワーク上の別のノードにpingする必要があります。例：Node 1-> Node 2：ping -I 10.1.229.189 10.5.68.187これは機能し、次に突然Node 2-> Node 1からのpingを返しますping 10.1.229.189 取り組んでいます。 （Node 1-> Node 2））から最初の接続/ pingを実行しない場合、（Node 2-> Node 1）はワーキング。
ただし、ここでの問題は、マシンを再起動するか、しばらく（10〜60分）待機すると、初期状態に戻ることです。
部分的に機能している最小のセットアップはこれです（後ですべてを削除しましたが、違いはありませんでした）。
eth1_ip=$(ip -o -4 addr list eth1 | awk '{print $4}' | cut -d/ -f1)
eth1_gw=$(ip route list dev eth1 | awk '{print $1}' | tail -1 | cut -d'/' -f1)
ip route add default via ${eth1_gw} dev eth1 table 2
ip rule add from ${eth1_ip} lookup 2
これは@Anton Danilovから要求された出力です
[root@cluser-node-1 ~]# ip -4 r ls table all
default via 10.1.229.188 dev eth1 table 2
default via 10.1.229.186 dev eth0
10.1.229.186/31 dev eth0 proto kernel scope link src 10.1.229.187
10.1.229.188/31 dev eth1 proto kernel scope link src 10.1.229.189
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1
local 10.1.229.187 dev eth0 table local proto kernel scope Host src 10.1.229.187
broadcast 10.1.229.187 dev eth0 table local proto kernel scope link src 10.1.229.187
local 10.1.229.189 dev eth1 table local proto kernel scope Host src 10.1.229.189
broadcast 10.1.229.189 dev eth1 table local proto kernel scope link src 10.1.229.189
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope Host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope Host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope Host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1
broadcast 172.18.0.0 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1
local 172.18.0.1 dev docker_gwbridge table local proto kernel scope Host src 172.18.0.1
broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1
[root@cluser-node-1 ~]# ip rule list
0: from all lookup local
32765: from 10.1.229.189 lookup 2
32766: from all lookup main
32767: from all lookup default
[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE
[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:36:17.237182 ARP, Request who-has 10.1.229.188 tell 10.1.229.189, length 28
16:36:17.237369 ARP, Reply 10.1.229.188 is-at 00:07:cb:0b:0d:93, length 46
2 packets captured
4 packets received by filter
0 packets dropped by kernel
これは、システムの再起動後または15〜30分のタイムアウト後のもう1つの出力です。
[root@cluser-node-1 ~]# tcpdump -ni eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root@cluser-node-1 ~]# ip n ls dev eth1
10.1.229.188 lladdr 00:07:cb:0b:0d:93 REACHABLE
確認してください。返信があるか（他のインターフェースから返信が出ている可能性があります）、返信がありません。
リバースパスフィルターの設定を確認します（ 'nstat -az'または 'netstat -S'の出力のカウンターを確認してください-rp_filterによってドロップされたパケットにはTcpExtIPReversePathFilterがあります）。これを無効にするか、ルーズモードに設定します（ sysctl settins description を参照）。想定を確認するために、着信パケットの逆ルートを検索します。
直接接続されたネットワークのルートは、対応するゲートウェイのarp解決と、直接接続されたネットワーク内の他のホストとの通信に必要であるため、ルートテーブルに追加する必要があると思います。これらの設定はあなたのケースを解決するのに十分でなければなりません：
ip route add 10.5.68.186/31 dev eth0 table 1 ip route 0/0 via 10.5.68.186 dev eth0 table 1 ip route add 10.5。 68.188/31 dev eth1 table 2 ip route 0/0 via 10.5.68.188 dev eth1 table 2 ip rule add from 10.5.68.187 lookup 1 ip 10.5.68.189ルックアップ2からのルールの追加
また、この設定は、アドレス指定が重複しているこれらのインターフェースのIPアドレスが異なる場合にのみ該当することも知っておく必要があります。それ以外の場合は、ファイアウォールマークによるCONNMARKおよびpbrでより複雑なスキームを使用する必要があります。
Host itselsからHostにpingを送信する場合は、次のコマンドを使用する必要があります。
ip route add local 10.5.68.187 dev eth0 table 1 ip route add 10.5.68.186/31 dev eth0 table 1 ip route 0/0 via 10.5.68.186 dev eth0 table 1 ip route add local 10.5.68.189 dev eth1 table 2 ip route add 10.5.68.188/31 dev eth1 table 2 ip route 0/0 via 10.5.68.188 dev eth1 table 2 ip rule add iif eth0 lookup 1 pref 101 ip rule add iif eth1 lookup 2 pref 102 10.5.68.187ルックアップ1設定201 からのipルール追加10.5.68.189ルックアップ2設定202 からのIPルール追加ローカル設定300 ip rule del pref 0