2 つの WAN インターフェイスを持つ NAT を介した異常なパケット損失

2 つの WAN インターフェイスを持つ NAT を介した異常なパケット損失

私は Linux サーバー マシンを持っており、これをネットワーク ゲートウェイ / 「ルーター」としても使用しています。このマシンには 3 つのネットワーク インターフェイスがアクティブになっています。2 つのネットワーク インターフェイスは異なる ISP 経由でインターネットに接続されており、3 つ目のネットワーク インターフェイスは NAT 経由でローカル マシンにインターネット アクセスを提供しています。WAN リンク間で負荷分散を行っています。

サーバーからは、ネットワークに問題なくアクセスできます。すべてが機能し、負荷分散も機能し、パケット損失もほとんどありません。サーバーとローカルマシン間の接続も完全に正常に機能します。しかし、ローカルマシンからサーバーを介してインターネット/WANにアクセスすると、常に約40%のパケット損失が発生します。これにより、接続が非常に不安定になります。少し調べてみると、両方のインターフェースからほぼ均等にパケットを受信(および損失)していることがわかりました。ないインターフェースの 1 つがすべてのパケットを失うことで、他のすべてのパフォーマンスを低下させているような場合です。

2 つの WAN リンクのいずれかを無効にすると、このパケット損失は即座に消えます。両方の WAN リンクを再度有効にすると、即座に再び現れます。

何が原因でしょうか? WAN リンクの 1 つを放棄せずにこの問題をトラブルシューティングする方法についてのヒントはありますか?

私のiptablesフィルターテーブル:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination     

私のiptablesNATテーブル:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.42.0.0/24        !10.42.0.0/24 

私のiptablesマングルテーブル:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            mark match ! 0x0
MARK       all  --  0.0.0.0/0            0.0.0.0/0            state NEW MARK set 0x2
MARK       all  --  0.0.0.0/0            0.0.0.0/0            state NEW statistic mode random probability 0.50000000000 MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination    

ip route show出力:

default 
    nexthop via 10.7.0.254  dev eth0 weight 1
    nexthop via 78.62.255.254  dev eth2 weight 1
10.7.0.0/16 dev eth0  proto kernel  scope link  src 10.7.5.102 
10.42.0.0/24 dev eth1  proto kernel  scope link  src 10.42.0.254 
78.62.192.0/18 dev eth2  proto kernel  scope link  src 78.62.239.10 
169.254.0.0/16 dev eth1  scope link  metric 1000 

すべて編集されていないそのままの状態です。この場合、「プライバシー」についてはあまり気にしません。

答え1

示された表に基づくと、NAT がフローを開始したのと同じインターフェイスから送信し続けるようにするための操作は何も行われていないため、送信パケットの約半分が誤って変換されている可能性があります。

NAT ロード バランシングを正しく行うには、新しいフローをランダムに 1 または 2 でマークするマングル テーブル上の事前ルーティング ルール、1 とマークされip ruleたパケットを WAN インターフェイス 1 にルーティングするルール、2 とマークされたパケットを WAN インターフェイス 2 にルーティングするルール、およびiptablesNAT テーブル上の各 WAN インターフェイスごとに 1 つずつ個別の SNAT ルールが必要です。

詳しい説明については、 Diego Lima の Iptables ロード バランシングの概要

関連情報