web-dev-qa-db-ja.com

この特別な場合にこのネットワークを機能させる方法は？

私は問題があります。私のすべてのマシンは、モデムの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ネットワークのいずれかのマシンが問題になります。瞬間によっては逆になることもありますが、理由はわかりません。

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

それで、WANこのトポロジのすべてのマシンとすべてのネットワーク（同じネットワーク上に2つのインターフェイスを持つルーター）にアクセスすることは可能ですか？

debiannetworkingrouting
2
cr1ptal

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

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

OPが書いたように、これにはポリシー/ソースベースのルーティングが必要です。iptablesおよびnetfilterはめったに役に立ちません（少なくとも単独で）：

  • 一般的に言えば、iptablesおよびnetfilterはルーティングせず、ルートを気にしません。ネットワークルーティングスタックルート。iptables'アクションの一部は、ルーティング決定の変更を引き起こします（これで説明されているように 回路図 ）
  • [〜＃〜] postrouting [〜＃〜]で行われたアクションは、その名前が示すように、afterで発生します。 /ルーティングの決定が行われました。ルートを変更するには遅すぎます。ここでは、nat/POSTROUTINGルールが必要ですが、ルートは変更されません。

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

ルート

rp_filter=1 はほとんどのディストリビューションのデフォルトであるため、すべてのインターフェイスで設定されていると想定し、 Strict Reverse Path Forwarding を有効にします。

送信元アドレスはルールによって選択され、宛先はルーティングテーブルによって選択されます。追加のルーティングテーブルには、複数の中から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.6enp4s0f0のルート| 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にアクセスできません。ルートは、デフォルトゲートウェイを経由する必要があるとして解決されます。 StrictReverseパス転送 （SRPF）の目的で、これをデバッグするのが困難になります。追加しないと悪いことの例です。疑わしい場合は、ルートを複製してください。

    上記のルールを次のように変更するための追加ルートの代わりに、他の同等のオプションがあった可能性があります。

    ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10

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

  2. 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

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

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

  4. ルールからのオーバーライドされたルートを含む特別でない場合も複製する必要があります

    ここで欠落しているルートは、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はenp1s0f1（enp1s0f1レースに勝った）でenp1s0f1 /を使用して応答しますのMACアドレスは192.168.0.6であることを通知します。
  • 数秒から数分の間、192.168.0.6のルーターからの将来の入力IPパケットはenp1s0f1に到着します。
  • 同時に出力192.168.0.6からのパケットはenp4s0f0を使用して送信されます。

この非対称ルーティングは Strict Reverse Path Forwarding （ rp_filter ）によって捕捉され、トラフィックは失敗します。これは、数秒間ランダムに機能し、その後再び失敗するように見えることさえあります。全体的なトラフィックによっては、問題が後で他のリンクに切り替わる可能性があります（その後、問題は他のLANに切り替わります）。

幸いなことに、これを防ぐために、Linuxには、ポリシールーティングと一緒にのみ使用される設定が用意されており、ARPはルーティングで定義されたのと同じルールに従うようになっています： arp_filter 。

arp_filter-BOOLEAN

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の動作は正しくなりました。設定を行ったばかりの場合は、peers（ここではモデム）のARPキャッシュを強制的にフラッシュする必要があります。 arping （fromiputils/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

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

デバッグする方法

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

これは、ルール（の欠如）と追加のルートに応じて結果がどのように変化するかを示しています。最後の結果は、Reverse Path Forwardingチェックが失敗した（=>ドロップ）ことを示すエラーメッセージです。

次に、ARPエントリやtcpdumpなどをチェックするためのip neigh（peerシステムで最も役立ちます）があります。

2
A.B