オフィスゲートウェイ上の複数のプロバイダー間の穏やかなバランス

この記事では、異なるプロバイダーのチャネル間でトラフィックのバランスを取るためのLinuxベースのゲートウェイの構成について説明します。





このマニュアルで得られる結果は、 同様のマニュアルの結果とは異なります。各クライアントに同じ外部IPアドレスが使用されるため、1回のセッションでクライアントのIPアドレスを変更する準備ができていないインターネットサービスの問題がなくなります。

問題

独自のアドレスブロックを持たず、通信事業者レベルでルートの交換に参加しない一般消費者の場合、各インターネットプロバイダーが各チャネルに提供するアドレスからのみインターネットにアクセスできます。 つまり、「ホーム」インターネットプロバイダーから1つのノードへの複数のチャネルの接続には、異なるアップストリームゲートウェイ間の選択だけでなく、それらと通信するための正しい発信アドレスの選択も必要です。



この状況は、標準のルーティングメカニズムの仕組みに反します。 一般に、ルーティングテーブルのルートは宛先アドレスのみに依存し、送信者アドレスは変更しません。 したがって、解決する必要がある最初のタスクは、クライアントからパケットを転送するときに、送信インターフェイス、ゲートウェイ、および発信アドレスの対応を整えることです。



解決する必要がある2番目のタスクは、顧客からの負荷を合理的に分散する方法です。



マルチパスルートを使用した分散（記事の冒頭のリンクのように）は、宛先アドレスで実行され、必ずしも魅力的なソリューションのようには見えません。 同じ外部アドレスを持つ価値がある場合、1つのセッションのクライアントは別のセッションを取得できます。逆もまた同様です。人気のあるリソースにアクセスする場合、すべてのクライアントは1つの共通チャネルを使用します。



送信者アドレスでのバランスは、互換性と配布の粒度の間で妥協する可能性があります。 ローカルネットワーク内の各コンピューターは常に同じ外部アドレスを持ち、ネットワーク内のかなりの数のコンピューターで、チャネル上で適切な負荷分散が行われます。 ハッシュがローカルアドレスから形成され、ハッシュスペース全体がチャネルの重みに比例して分割され、このハッシュの値がチャネルの選択に使用される場合、このような分割を実現できます。

ツール

Linuxカーネルには、パッケージが満たす基準に応じて、複数の異なるテーブルを同時に使用する機能があります。 多くの場合、このメカニズムはポリシーベースルーティング（PBR）と呼ばれます。 このメカニズムは、iproute2ユーティリティセットによって制御されます。



問題の記述を多少簡略化すると、ルート、インターフェイス、発信アドレスを区別するために必要なことは、このプロバイダーのこのチャネルが唯一のものであるかのように見える各プロバイダーの追加ルーティングテーブルを作成することだけです。 次に、対応するトラフィックの適切なルーティングテーブルをフロートさせるルール（同じルーティングポリシー）を追加する必要があります。



送信者のバランシングに関しては、このためにnetfilter（iptables）ネットワークフィルターを使用できます。 HMARKアクションを使用して、アドレスからのハッシュでパケットをマークします。 ルーティングルールのfwmark基準（ip ruleコマンド）により、目的のルーティングテーブルにパケットを転送します。 ここでは、iproute2とiptablesはペアでうまく機能します。

例

例として、2つの異なるプロバイダーからの3つのチャネルを介したインターネットアクセスを提供するDebianベースのゲートウェイを取り上げます。 この例は、1つのプロバイダーの同じ上位ゲートウェイが2本の異なる配線を介して利用できる場合の微妙な状況を考慮するため、特別に選択されました。 説明した構成は、Ubuntuを含む他のすべてのdebianライクなオペレーティングシステムでも同様です。



ゲートウェイには4つの機能するインターフェースがあります。

Int。	説明	収容人数	住所	ゲートウェイ
eth0	ローカルエリアネットワーク		10.0.0.1/16	-
eth1	最初のプロバイダーの最初のチャネル	100 Mbps	100.1.1.92/24	100.1.1.1
eth2	2番目のプロバイダーからの唯一のチャネル	80 Mbps	200.2.2.22/24	200.2.2.1
eth3	最初のプロバイダーの2番目のチャネル	100 Mbps	100.1.1.93/24	100.1.1.1

各チャネルは、静的アドレスを使用して通常のイーサネット経由で接続されます。

初期状態

すでに1つのチャネルを介してアクセスが構成されているとします。 ファイル/ etc / network / interfacesの形式は次のとおりです。



ご覧のとおり、デフォルトルートを持つインターフェイスは1つだけです。



/etc/sysctl.confで、net.ipv4.ip_forwardの値が1に設定されます。iptables-persistentパッケージがインストールされ、/ etc / iptables / rules.v4ファイルの内容は次のとおりです。



3つの外部インターフェイスを介して送信されるパケットのアドレスを変換するためのルールは3つだけです。 仮面舞踏会を使用することは重要ではありませんが、私はそれに決めました。 ゲートウェイは現在1つのインターフェイスのみで構成されているため、実際には最初のルールのみが機能します。

ルーティングルール

ここで最も難しいのは、アドレス、インターフェース、ゲートウェイのマッチングという最初の問題を解決することです。 異なるプロバイダーに使用する3つの追加ルーティングテーブルを準備します。

オプションのステップから始めましょう-番号でどこにでもルーティングテーブルを言及しないために、番号とテーブル名の対応のファイルにそれらを入れてください/ etc / iproute2 / rt_tables：



今のところかなり簡単です。 これらのテーブルにルートを入力します。 各外部チャネルの各テーブルに、他の外部インターフェイスを経由するルートを除く、すべてのインターフェイスのすべてのルートが含まれるようにします。 各外部インターフェイスを上げるときに、送信者のアドレスがこのインターフェイスのアドレスと等しい場合、合意された追加のルーティングテーブルを使用するように指示するルールを追加します。



注：メインルーティングテーブルはまだ1つのゲートウェイのみを取得します。1つを除くすべてのゲートウェイディレクティブはコメント化されています。

ここでは、upディレクティブによって追加のルートとルールが発行されます。upディレクティブは、インターフェイスを上げるときにコマンドを実行するだけです。 ルートとルールを追加するためのコマンドは、それらを実装できるインターフェースの下にグループ化されます-これはloインターフェースの例で最も明確に見られます。



ネットワークを再起動した後、ip rule listコマンドのルールのリストの出力がどのように変更されたかに気づくことができます：



対応するテーブルは、ip ro li table XXXコマンドで表示できます。



すでにこの位置にあるため、サーバーはすべてのインターフェイスを一度に使用する準備ができています。 すべてのインターフェイスを順番に使用して、外部から観測されたアドレスを確認することで、これを確認します。



外部インターフェイスに実際の「ホワイト」アドレスがある場合、任意のアドレスを使用してサーバーへの参加を試みることができます。サーバーは、正しいチャネルと正しいプロバイダーを介して各インターフェイスを通じて通信します。 もしそうなら、最も難しい部分が背後にあります。

バランス調整

私の例では、100 Mb / sと80 Mb / sの2つのチャネルがあります。 負荷をそれらの間で均等に分割するには、14の部分に分割し、5つの部分を2つの100メガビットチャネルに、4つの部分を80メガビットチャネルに送信するだけで十分です。 発信IPアドレスに応じて、10000〜10013の番号でパケットをマークするルールをファイアウォールに追加します。

# iptables -t mangle -A PREROUTING -s 10.0.0.0/16 -j HMARK --hmark-tuple src --hmark-offset 10000 --hmark-mod 14 --hmark-rnd 0xfeedcafe

# /etc/init.d/netfilter-persistent save







簡単です。 パラメータと値はそれ自身を表しています。 現在では、異なる番号でマークされたトラフィックを異なるインターフェースを介して転送することが残っています。 その結果、/ etc / network / interfacesは次の形式を取ります。



インターフェイスごとに、「up ip rule add from 10.0.0.0/8 fwmark MARK table TABLE」タイプの行が追加されました。 それぞれが、指定されたテーブルにルーティングするための対応するマーキング付きのパケットを送信します。 私の例では、統一のためにインターフェイス間で数字が混在しています。

それだけです！

必要に応じて、チャネルの1つでドロップを検出し、これを念頭に置いて負荷を再分散するスクリプトをこのようなルーティングスキームに追加できます。 ただし、実装の詳細は好みに依存するため、読者に任せる方が良いでしょう。