☰

この特定の状況でこのネットワークを操作する方法は？

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

NATファイアウォールとしてufwを使用してください。 *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）または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そしてWebフィルタほとんど役に立たない（少なくとも単独で）：

  • 一般的に言えばiptablesそしてWebフィルタルーティングせず、ルーティングにも興味がありません。ネットワークルーティングスタックルーティング。一部iptables'タスクは依然としてルーティング決定を変更します（ここで説明されているように）。模式図)
  • 実行されたすべての操作背面配線名前が示すように、そのようなことが起こりました。後ろに経路決定が行われた。パスを変更するには遅すぎます。それでもここnat/ポストルーティングルールが必要で、コースは変わりません。

いつでもiptablesルーティングの問題を解決することは避けることができ、回避する方が良いです。時には避けられないことがあります（そして一般的にiptablesパケットにタグを追加するために使用され、そのタグはエントリip ruleに使用されます。

路線

私は仮定しますrp_filter=1ほとんどのディストリビューションではデフォルト値なので、すべてのインターフェイスに設定して有効にします。厳格なリバースパスの転送。

ソースアドレスはルールによって選択され、宛先はルーティングテーブルによって選択されます。複数のルートのいずれかを選択する必要がある場合（そしてこのルートのみをテーブルに追加する必要がある場合）、追加のルーティングテーブルには（明確な）ルートをカバーするのに十分な情報が必要です。多くの場合、基本テーブルの他のパスもコピーする必要があります。そうしないと、悪いことが起こる可能性があります。

私の答えでは、あるネットワークまたは別のネットワークの優先順位を指定しません。各ネットワークには独自のルーティングテーブルがあります。表1は忘れて、LAN 10.0.0.0/24には表10を使用し、LAN 172.16.0.0/24には表172を使用します。 NATルールを維持し、ルールと追加のルーティングテーブルを削除し、192.168.0.1 dev enp4s0f0 scope linkmain.confからルールと追加のルーティングテーブルを削除します。

  1. 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 |パス enp4s0f1 192.168.0.6 <--> 192.168.0.1/デフォルト:

     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/デフォルト:

     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情報はリモートシステムにキャッシュされ、一定期間そのまま残ります。最終的にキャッシュが期限切れになり、同じことが発生しますが、結果は異なる場合があります。それでは、これはどのように問題を引き起こす可能性がありますか？例は次のとおりです。

  • ルーター（モデム）は、元の10.0.0.0/24から送信されたトラフィックへのルーティングとNAT（Linux経由）の応答を再送信するために192.168.0.6にARP要求を送信します。
  • Linuxが答えたenp1s0f1（enp1s0f1ゲームで勝利）を使うenp1s0f1応答で通知されるMACアドレスは192.168.0.6です。
  • 数秒から数分で、192.168.0.6 のルータから将来の着信 IP パケットが到着します。enp1s0f1、
  • 同時に出口192.168.0.6のパケット使用量enp4s0f0。

この非対称ルーティングがキャプチャされました。厳格なリバースパスの転送（rp_filter）トラフィックが失敗します。これは数秒間ランダムに機能し、再び失敗する可能性があります。トラフィック全体によっては、問題が後で別のリンクに切り替わる可能性があります（その後、問題は別のLANに切り替えられます）。

幸いなことに、Linux は ARP がパスで定義されているのと同じルールに従うようにポリシー ルーティングでのみ動作する設定を提供します。arp_filter。

arp_filter - ブール

1 - 同じサブネットに複数のネットワークインターフェイスを持ち、各インターフェイスにARPを提供できます。相互作用以下に基づいて答えてください。カーネルがARPのIPからこのインターフェイスにパケットをルーティングするかどうか（だからソースベースのルーティングを使用する必要があります。この作業のため）。つまり、arp要求に応答するカード（通常1枚）を制御できます。

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

これでARPの動作は正しいです。設定が正しく適用されたら、ARPキャッシュを強制的にフラッシュする必要があります。仲間（ここではモデム）冗長アドレス検出を行い、arping（からアイチルス/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

正しいARP検証を行うには、IPアドレス192.168.0.3と192.168.0.6がポリシールーティングルールで一致する必要があるため、前のセクションの3番目のエントリの2つのルールが必須です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（最も役に立つ仲間tcpdumpシステム）ARP項目などを確認してください。

おすすめ記事