web-dev-qa-db-ja.com

同じネットワーク上の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

アプローチ

私の調査に基づいて、 herehere 両方の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
5
Vadimo

確認してください。返信があるか(他のインターフェースから返信が出ている可能性があります)、返信がありません。

リバースパスフィルターの設定を確認します( '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 
1
Anton Danilov