マルチホームLinuxマシンは真のStrongESモデルを実装できますか?
特定のユースケース
私は5つの異なるインターフェースを備えたシステムを持っており、それぞれが同じサブネットに接続されているため、インターネットへの同じゲートウェイになっています。
- 同じポートで各インターフェイスを個別にリッスンし、パケットが常に同じインターフェイスから送信されるようにし、「間違った」インターフェイスに入ろうとするパケットが破棄されるようにします。 >
- 各インターフェイスにバインドして、バインドしたのと同じ送信元IPから常に発信されるインターネット宛先への発信接続を確立できるようにしたいと思います。たとえば、
curl --interface interface_ip http://ipecho.net/plain
--interface
でバインドしたのと同じIPアドレスを常に表示する必要があります 。 - 静的ルートは、これらのインターフェイスの1つでDHCPを使用しているため、問題が発生する可能性があります。
RFC 1122
RFC 1122から–インターネットホストの要件–通信レイヤー、セクション3.3.4.2 –マルチホーミング要件:
インターネットホストの実装者は、マルチホーミングに2つの異なる
概念モデルを使用しており、以下の説明で簡単に要約します。
このドキュメントは、どのモデルが優先されるかについて
立場をとっていません。それぞれに
場所があるようです。このアンビバレンスは、(A)
および(B)オプションの問題に反映されています。
強力なESモデル
強力なES(エンドシステム、つまりホスト)モデル
は、ホスト/ゲートウェイ(ES / IS)の区別を強調しているため、
したがって、
問題のMAYの代わりにMUSTを使用します(A )および(B)上記。
マルチホームホストを
同じ物理ホスト内の論理ホストのセットとしてモデル化する傾向があります。(A)に関して、Strong ES
モデルの支持者は、自動インターネットルーティング
メカニズムがデータグラムを
対応していない物理インターフェースに
ルーティングできなかったことに注意します。
宛先アドレス。ストロングESモデルでは、発信データグラムのルート計算
はマッピングです:route(src IP addr, dest IP addr, TOS) -> gateway
ここでは、対応する物理インターフェースで直接到達可能な
ゲートウェイを選択するために、送信元アドレスがパラメーターとして
含まれています。
このモデルでは、論理的には、
一般に、IPソースアドレスごとに少なくとも1つのデフォルトゲートウェイが必要であり、
できれば複数のデフォルトゲートウェイが必要であることに注意してください。弱いESモデル
この見解は、ES / ISの区別を強調していません。したがって、
は、問題(A)および(B)の
MAYの代わりにMUSTNOTを使用します。このモデルは、
ゲートウェイルーティングプロトコルをワイヤタップするホストにとってより自然なモデルである可能性があり、
ゲートウェイ機能が組み込まれているホストに必要です。ESモデルが弱いと、リダイレクトメカニズムが失敗する可能性があります
。データグラムが
宛先アドレスに対応しない物理的な
インターフェースから送信された場合、ファーストホップゲートウェイは
リダイレクトを送信する必要があるときを認識しません。一方、
一方、ホストにゲートウェイ機能が組み込まれている場合は、
リダイレクトをリッスンせずに、
ルーティング情報があります。ウィークESモデルでは、
送信データグラムのルート計算はマッピングです:route(dest IP addr, TOS) -> gateway, interface
Linuxはデフォルトで弱いESモデルですが、FreeBSDや他のUnixの種類は強いESシステムとして機能します。強力なESシステムのように動作させる方法はありますか?
sysctl
とは または、コンパイル時の構成を設定して、追加する新しいインターフェイスに特定のルーティングルールを追加せずに、デフォルトで強力なESのように動作させる必要がありますか? net.ipv4.conf.default.rp_filter = 1
を介して厳密なソースルートフィルタリングを実行できることはわかっています。 、しかしそれ以上のものがあるようです。デフォルトでソースベースのルーティングを行うにはどうすればよいですか?
承認された回答:
これには、ファイアウォールルールを追加するだけでは不十分です。たまたま同じハードウェアとプロセスを共有する2つの独立したシステムであるかのように、システムがトラフィックをルーティングする必要があります。これが、StrongESモデルの効果です。
関連:Linux –rootで実行した後にのみマニュアルページが見つかりましたか?LinuxでStrongESModelを目指す場合は、最初に次の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
これらの設定により、ARPはStrong ESモデルで適切に動作します。つまり、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
#...
再起動時にこのすべての構成を永続化するには、カスタムの起動スクリプト(または、場合によってはifup-pre
)を作成する必要があります。 またはifup-post
スクリプト)Linuxディストリビューションの規則に適合させます。
追加の保険として、インターフェイスごとの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
にも恒久的な通知をセットアップしました。 有効な高度なルーティングと、それを設定した実際のスクリプトの場所について。