☰

この特殊なケースでこのネットワークを機能させるにはどうすればよいでしょうか?

tag-icon • tag-icon debian networking routing
この特殊なケースでこのネットワークを機能させるにはどうすればよいでしょうか?

問題があります。私のマシンはすべて、モデムの ETH ポートに接続されたルーターの背後にあります。そのポートはダウンロード/アップロードに制限が多すぎます。そこで、ルーターからモデムの 2 つのポートに 2 本のケーブルを接続してみました。この問題を解決する方法にかなり取り組んできましたが、もう何を試したらよいかわかりません。

私のルーターには 4 つのインターフェースがあります:

enp1s0f0   172.16.0.3
enp4s0f1   10.0.0.6
enp1s0f1   192.168.0.3
enp4s0f0   192.168.0.6

ご覧のとおり、eth3 と eth4 は同じネットワーク上にあります。これは奇妙です。2 つの ETH ポートを使用してモデム (192.168.0.1) に接続するには、この方法にする必要がありました。

そこで、私が試してみたことは次のとおりです。

echo "1   myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table

結果として次のルートが得られます:

$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink 
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6 
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3 
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3 
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link

$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0

$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 enp1s0f1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f1
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f0
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 enp4s0f0

私は ufw を NAT ファイアウォールとして使用しています。 *nat セクションに以下を追加しました:

:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE

問題は、10.0.0.0 ネットワークのマシンがモデム (ゲートウェイ 192.168.0.1) から ping 応答を受信するか、172.16.0.0 ネットワークのマシンが ping 応答を受信するかのどちらかです。状況によっては逆の場合もありますが、その理由はわかりません。

私のモデムは、2 つの ETH ポートでクライアント 192.168.0.3 と 192.168.0.6 の両方を認識します。

では、このトポロジ (同じネットワーク上に 2 つのインターフェースを持つルーター) を使用して、すべてのマシンとすべてのネットワークで WAN アクセスを実現することは可能ですか?

答え1

明示的には書かれていませんが、次のようにトラフィックを分割することが目標だと思います。

  • 172.16.0.0/24 のトラフィックは enp1s0f1 を通過します。
  • 10.0.0.0/24 トラフィックは enp4s0f0 を通過します。

OP が書いたように、これにはポリシー/ソースベースのルーティングが必要です。iptablesそしてネットフィルターほとんど役に立たない（少なくとも単独では）：

  • 一般的に言えばiptablesそしてネットフィルタールーティングを行わず、ルーティングを気にしません。ネットワークルーティングスタックのルート。iptables' アクションは依然としてルーティング決定の変更を引き起こします (この概略図）
  • 行われたあらゆる行為ポストルーティング名前の通り、起こる後ルート決定が下されたので、ルートを変更するには遅すぎます。ここではnat/ポストラウティングルールが必要な場合は、ルートは変更されません。

いつでもiptablesルーティング問題を解決するために回避できる場合は、回避したほうがよいでしょう。回避できない場合もあります（そして通常はiptablesパケットにマークを追加するために使用され、このマークはエントリで使用されますip rule。

ルート

私はそう仮定しますrp_filter=1ほとんどのディストリビューションではデフォルトで有効になっているため、すべてのインターフェースで設定されています。厳密なリバースパス転送。

送信元アドレスはルールによって選択され、宛先はルーティング テーブルによって選択されます。追加のルーティング テーブルには、複数のルートのうち 1 つだけを選択する必要があるときに、ルートを (曖昧さなく) 上書きするのに十分な情報が必要です (その場合、この 1 つだけがテーブルに追加されます)。多くの場合、メイン テーブルからの追加ルートもコピーする必要があります。そうしないと、問題が発生する可能性があります。

私の回答では、どちらかのネットワークを優先することはしません。各ネットワークは独自のルーティング テーブルを取得します。テーブル 1 は忘れて、LAN 10.0.0.0/24 にはテーブル 10 を使用し、LAN 172.16.0.0/24 にはテーブル 172 を使用します。NAT ルールは保持し、ルールと追加のルーティング テーブルを192.168.0.1 dev enp4s0f0 scope linkメインから削除します。

  1. 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/default のルート:

     ip rule add from 10.0.0.0/24 lookup 10
 ip route add table 10 10.0.0.0/24 dev enp4s0f1
 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6
 ip route add table 10 default via 192.168.0.1

上記では、10.0.0.0/24の重複したルートエントリがなければ、システム自体はこのLANにアクセスできません。ルートはデフォルトゲートウェイを経由する必要があると解決されますが、厳密なリバースパス転送(SRPF) 目的のため、デバッグが困難です。これは追加しない場合の悪い例です。疑わしい場合は、ルートを複製するだけです。

追加のルートの代わりに、上記のルールを次のように変更するという同等のオプションもあります。

    ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10

そのため、ローカル (ルーティングされていない) トラフィックには一致せず、メイン テーブルのみが使用されます。

  1. 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/default のルート:

     ip rule add from 172.16.0.0/24 lookup 172
 ip route add table 172 172.16.0.0/24 dev enp1s0f0
 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3
 ip route add table 172 default via 192.168.0.1

  2. Linux システムで発信元 IP アドレスを変更するときに、ローカルで開始された発信トラフィックのルート (リンク) も変更します。これはオプションのはずですが、ARP フラックスに関する次の部分では必須になります。

     ip rule add from 192.168.0.6 lookup 10
 ip rule add from 192.168.0.3 lookup 172

  3. ルールからオーバーライドされたルートを含む非特別なケースも複製する必要があります。

ここで欠落しているルートは、2 つの特別な LAN 自体の間だけです。

テーブル10では172.16.0.0/24に到達し、
テーブル172では10.0.0.0/24に到達します。

追加の各テーブルにはまだこの反対側へのルートがないため、デフォルト ルートが使用され (ただし、SRPF によって再びブロックされます)、2 つの特別なネットワークが相互に通信できなくなります。そのため、各テーブルで不足しているルートを複製するだけです。

    ip route add table 10 172.16.0.0/24 dev enp1s0f0
    ip route add table 172 10.0.0.0/24 dev enp4s0f1

このモデルでは、たとえば他の 2 つの「通常の」内部ネットワークを追加する場合、それらのネットワークは追加設定なしで相互に通信できます (メイン テーブルのデフォルト ルートを使用して外部へ出ます)。ただし、2 つの特別な LAN と通信するには、各追加ルーティング テーブルでルートを複製する必要があります。

ルートは問題ありませんが、まだ...

のARPフラックス問題

Linuxは弱いホストモデルこれは IP ルーティングの場合に当てはまり、Linux が ARP 要求に応答する方法も同様です。任意のインターフェイスから任意の IP に対して応答しますが、もちろんインターフェイス自身の MAC アドレスを使用します。複数のインターフェイスが同じ LAN 上にある場合、これはすべてのインターフェイスで同時に発生する可能性があるため、通常は最速のインターフェイスが優先されます。次に、ARP 情報はリモート システムにキャッシュされ、しばらくそこに残ります。最終的にキャッシュの有効期限が切れると、同じことが起こりますが、結果は異なる可能性があります。では、これがどのように問題を引き起こすのでしょうか。次に例を示します。

  • ルータ (モデム) は、192.168.0.6 に対して ARP 要求を送信し、最初に 10.0.0.0/24 から送信されたトラフィックに対して、ルーティングされ、NAT された (Linux による) 応答を返します。
  • Linuxは応答します翻訳元（翻訳元レースに勝った）翻訳元の MAC アドレスは 192.168.0.6 であると返信されます。
  • 数秒から数分の間、192.168.0.6のルータからの今後の入力IPパケットは翻訳元、
  • 同時に出口192.168.0.6からのパケットは翻訳:。

この非対称ルーティングは、厳密なリバースパス転送（rp_filter) となり、トラフィックが失敗します。数秒間ランダムに動作しているように見えても、その後再び失敗することもあります。全体的なトラフィックによっては、問題が後で他のリンクに切り替わることもあります (その後、問題が他の LAN に切り替わります)。

幸いなことに、これを防ぐために、Linux はポリシー ルーティングと組み合わせてのみ使用される設定を提供し、ARP がルーティングによって定義された同じルールに従うようにします。arp_filter。

arp_filter - ブール値

1 - 同じサブネット上に複数のネットワークインターフェースを持ち、それぞれにARPを設定できます。インターフェースに基づいて回答されるカーネルがARPされたIPからのパケットをそのインターフェースにルーティングするかどうか（したがってソースベースのルーティングを使用する必要がありますこれが機能するには、次の操作が必要です。言い換えると、どのカード (通常は 1 枚) が ARP 要求に応答するかを制御できるようになります。

sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1

これでARPの動作は正しくなりました。設定が完了したら、ARPキャッシュを強制的にフラッシュする必要があります。仲間（ここではモデム）重複アドレス検出を行うことでarping（からiputils/iputils-arping) はピアにブロードキャストされ、ピアのキャッシュが更新されます。

arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3

前の部分の箇条書き 3 の 2 つのルールが必須になっていることに注意してください。これは、 で ARP を正しく解決するには、ポリシー ルーティング ルールで IP アドレス 192.168.0.3 と 192.168.0.6 が一致している必要があるためですarp_filter=1。

デバッグ方法

ip route getルートの確認や逆パスフィルタリングに非常に便利です。

上記の箇条書き 4 の新しいテスト ケース:

# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10 
    cache iif enp4s0f0 
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172 
    cache iif enp1s0f0

ルールまたはルートを削除する場合:

# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10 
    cache iif enp4s0f1 
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
    cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
    cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link

これは、ルール (の欠如) と追加ルートに応じて結果がどのように変化するかを示しています。最後の結果は、リバース パス転送チェックが失敗した (=> ドロップ) ことを通知するエラー メッセージです。

そして、ip neigh（最も役立つのは仲間システムなど）を使用して ARP エントリtcpdumpなどを確認します。

関連情報