web-dev-qa-db-ja.com

Linuxソースルーティング、ストロングエンドシステムモデル/ストロングホストモデル？

マルチホームのLinuxマシンは、本当の Strong ES Model を実装できますか？

特定のユースケース

5つの異なるインターフェースを備えたシステムがあり、それぞれが同じサブネットに接続されているため、インターネットへのゲートウェイも同じです。

  • 同じポートで各インターフェイスを個別にリッスンし、パケットが常に同じインターフェイスから発信されるようにし、「間違った」インターフェイスに入ろうとするパケットが確実に破棄されるようにしたいと思います。
  • 各インターフェイスにバインドし、バインドした同じソースIPから常に発信されるインターネット宛先への発信接続を確立したいと思います。例えば、
    curl-インターフェース interface_ip http://ipecho.net/plain
    常に--interfaceでバインドしたのと同じIPアドレスを表示する必要があります。
  • 静的ルートは、これらのインターフェースの1つでDHCPを使用するために問題がある可能性があります。

RFC 1122

From RFC 1122 -インターネットホストの要件-通信層 セクション3.3.4.2 –マルチホーミング要件 ：

インターネットホストの実装者は、マルチホーミングに2つの異なる概念モデルを使用しています。以下の説明で簡単に要約します。このドキュメントでは、どちらのモデルが好ましいかについては説明しません。それぞれに場所があるようです。このあいまいさは、（A）と（B）がオプションであることの問題に反映されています。

  • 強力なESモデル

      強力なES（エンドシステム、つまりホスト）モデルは、ホスト/ゲートウェイ（ES/IS）の区別を強調しているため、上記の問題（A）および（B）でMAYを代替する必要があります。マルチホームホストを、同じ物理ホスト内の論理ホストのセットとしてモデル化する傾向があります。

      （A）に関して、Strong ESモデルの支持者は、自動インターネットルーティングメカニズムは、宛先アドレスに対応しない物理インターフェイスにデータグラムをルーティングできなかったと述べています。

      Strong ESモデルでは、送信データグラムのルート計算は次のマッピングです：
           route(src IP addr, dest IP addr, TOS) -> gateway

      ここでは、対応する物理インターフェイスで直接到達可能なゲートウェイを選択するために、送信元アドレスがパラメータとして含まれています。このモデルでは、各IP送信元アドレスに対して、一般に少なくとも1つのデフォルトゲートウェイ、できれば複数のデフォルトが存在することが論理的に必要であることに注意してください。


  • 弱いESモデル

      この見解は、ES/ISの区別を重視しないため、問題（A）および（B）でMAY NOTを代用してはならない（MUST NOT）。このモデルは、ゲートウェイルーティングプロトコルを盗聴するホストにとってはより自然なモデルである可能性があり、ゲートウェイ機能が埋め込まれているホストには必要です。

      弱いESモデルにより、リダイレクトメカニズムが失敗する可能性があります。データグラムが宛先アドレスに対応しない物理インターフェイスに送信される場合、ファーストホップゲートウェイは、リダイレクトを送信する必要があるタイミングを認識しません。一方、ホストにゲートウェイ機能が組み込まれている場合は、リダイレクトをリッスンせずにルーティング情報を持っています。

      Weak ESモデルでは、発信データグラムのルート計算はマッピングです：
           route(dest IP addr, TOS) -> gateway, interface

LinuxはデフォルトでWeak ESモデルですが、FreeBSDや他のUnixはStrong ESシステムとして機能します。 Strong ESシステムのように動作させる方法はありますか？

追加する新しいインターフェイスに特定のルーティングルールを追加せずに、デフォルトでStrong ESのように動作させるには、どのsysctlまたはコンパイル時の設定を設定する必要がありますか？ net.ipv4.conf.default.rp_filter = 1を使用して厳密なソースルートフィルタリングを実行できることはわかっていますが、それだけではないようです。デフォルトでソースベースルーティングを実行するにはどうすればよいですか？

linuxnetworkingfreebsdrouting
11
Will

ファイアウォールルールを追加するだけでは、これは十分ではありません。ちょうど同じハードウェアとプロセスを共有する2つの独立したシステムであるかのようにシステムがトラフィックをルーティングするようにします。それが、Strong ESモデルの効果的なものです。

Linuxで強力なESモデルを目指す場合、最初に次のsysctl設定が必要です。

net.ipv4.conf.all.arp_filter=1 
net.ipv4.conf.all.arp_ignore=1 # or even 2
net.ipv4.conf.all.arp_announce=2

これらの設定により、Strong ESモデルでARPが適切に動作します。つまり、ARP要求が受信されると、要求された正確なアドレスを持つインターフェイスのみが応答し、発信元アドレスへのトラフィックが実際にその特定のアドレスを通じて送信される場合のみインターフェース。

次に、ルーティングに関して異なる動作をさせたい5つのインターフェースがあるので、5つのカスタムルーティングテーブルを設定する必要があります。番号を使用してそれらを識別することもできますが、一般的にはそれらの名前を指定する方が明確です。したがって、1から252までのそれぞれの番号と、適切な名前を選択してください。 （0、253、254、255は予約されています。）

たとえば、100 = rtable0、101 = rtable1、102 = rtable2、103 = rtable3、104 = rtable4を選択してみましょう。これらの番号と名前を/etc/iproute2/rt_tablesファイルの最後に追加します。

# ...default stuff above...
100    rtable0
101    rtable1
102    rtable2
103    rtable3
104    rtable4

次に、各カスタムルーティングテーブルに、各インターフェイスに適した最小限のルートエントリのセットを入力します。 （私は実際の値を、うまくいけばわかりやすい名前の環境変数名に置き換えています。）

ip route add $ETH0_NET dev eth0 proto static src $ETH0_IP table rtable0
ip route add default via $ETH0_GW dev eth0 proto static src $ETH0_IP table rtable0

ip route add $ETH1_NET dev eth1 proto static src $ETH1_IP table rtable1
ip route add default via $ETH1_GW dev eth1 proto static src $ETH1_IP table rtable1

# ... and so on, for all 5 interfaces

最後に、各パッケージのソースアドレスをチェックし、それに応じて使用するルーティングテーブルを選択する高度なルーティングルールを追加します。

ip rule add from $ETH0_IP table rtable0
ip rule add from $ETH1_IP table rtable1
#...

このすべての構成を再起動後も永続化するには、Linuxディストリビューションの規則に適合するようにカスタム起動スクリプト（またはifup-preまたはifup-postスクリプト）を記述する必要がある場合があります。

追加の保険として、インターフェイスごとのiptablesルールを追加して、間違ったインターフェイスで受信される可能性のある着信パケットをサイレントにドロップすることができます。すべてが順調である場合、これらのパケットカウントはゼロのままである必要があります。パケット数が増加し始めた場合、構成で何かを見落としている可能性があります。

iptables -A INPUT -m addrtype --dst-type UNICAST -i eth0 ! -d $ETH0_IP -j DROP
iptables -A INPUT -m addrtype --dst-type UNICAST -i eth1 ! -d $ETH1_IP -j DROP
# ... and so on for each interface

注：リックジョーンズや他のネットワーキンググルによる古いインターネットディスカッションに基づいて、このような設定を実装したことがあります。彼らは言い換えて、「Linuxで強力なホストモデルの動作を実現するためには、これがすべて明らかに必要です一方で、それがすべての可能なユースケースに十分」。それは完璧に機能しました。何に使用するかによって、それで十分な場合とそうでない場合があります。

警告：この構成をセットアップするときは、システムへの何らかのローカルまたはリモートのコンソールアクセスがあることを確認してください。このセットアップは、半分しか行われていないのに、ネットワークアクセスを完全に混乱させる可能性が非常に高いです。

（N-1）個のカスタムルーティングテーブルのみでNインターフェイスをセットアップすることは可能ですが、私の個人的な好みは、高度なルーティングを使用するときにすべてのルーティング構成をカスタムテーブルに移動することです。 route -nまたはip route showが本質的に空になるのは、システムにネットワーク接続があることは明らかですが、何か特別なことが起こっていることを示す非常に大きな手がかりになります。それでも、このようにシステムをセットアップしたときは、/etc/motdで、高度なルーティングが有効であることと、それをセットアップした実際のスクリプトの場所についての恒久的な通知もセットアップしました。

8
telcoM

ARP処理をより詳細に制御できる別のオプションがあります。見て arp_ignore。

1
Hauke Laging