概要 #
この記事では、以下の点を識別して解決する方法について説明します。 非対称ルーティングの問題 RELIANOID ロード バランサに、異なるサブネットに接続された複数のネットワーク インターフェイスがある場合のデプロイメント。
この状況は、ロード バランサが両方のネットワークにインターフェイスを持っているときに、フロントエンド クライアントが別のサブネットにあるバックエンド サービスにアクセスする必要がある場合に発生する可能性があります。
不適切なルーティング動作により、応答トラフィックが受信リクエストに使用されたものとは異なるインターフェースから出力され、その結果、 非対称ルーティング.
問題の説明 #
一部の展開では、 RELIANOID ロード バランサは、異なるネットワークに接続された複数のインターフェイスで構成されています。
以下の構成は デモンストレーション目的で使用されるサンプル環境.
| インタフェース | ネットワーク | 目的 |
| eth0 | 192.168.1.0/24 | マネジメント |
| eth1 | 192.168.110.0/24 | フロントエンド |
| eth2 | 192.168.100.0/24 | アプリケーション / バックエンド |
バックエンドサーバーは 192.168.100.0/24 サブネットであり、ロード バランサー上に構成されたファームを通じてアクセスされます。
しかし、一部のクライアントは 192.168.110.0/24 ネットワークは、 192.168.100.0/24 ネットワーク。
ロードバランサは両方のネットワークにインターフェースを持っており、IP転送はデフォルトでアクティブになっているため、システムは応答トラフィックを フロントエンドインターフェース（eth1） 予想されるゲートウェイを経由してルーティングする代わりに。
これにより 非対称ルーティングこれにより、接続障害やパケットのドロップが発生する可能性があります。
インターフェース構成の例 #
非対称ルーティングとは #
非対称ルーティングは、 同じ接続の受信トラフィックと送信トラフィックは異なるネットワークパスをたどります.
フロー例 #
宛先パス: 192.168.110.11（eth2経由）（クライアント） > 192.168.100.100（ロードバランサ） > 192.168.100.42（バックエンド）
リターンパス（誤り）: 192.168.100.42 (バックエンド) > 192.168.100.100 (ロードバランサー) > eth1 経由の 192.168.110.11 (クライアント)
戻りトラフィックは別のインターフェースから送信されるため、ファイアウォールやルーターなどの中間デバイスによってパケットがドロップされる可能性があります。
ルーティングテーブルの仕組み #
RELIANOID 使用されます インターフェースごとのルーティングテーブル ネットワーク間でトラフィックを転送する方法を制御します。
各インターフェースは独自のルーティング テーブルを自動的に生成します。
ルーティングテーブルの例: table_eth1, table_eth2
これらのルーティング テーブルは次のものを定義します。
- インターフェースに関連付けられたルート
- トラフィック転送に使用されるゲートウェイ
- トラフィックをルーティングできるインターフェース
各ルーティング テーブル内で、インターフェイスは次のように設定できます。
管理インターフェース #
IP 転送機能を利用してルーティング テーブル内でトラフィックをルーティングできるインターフェイス。
管理されていないインターフェース #
そのテーブルのルーティング決定から除外されているインターフェースと IP 転送は、それらのインターフェースには適用されません。
どのインターフェースが管理対象か、または管理対象外かを制御することにより、管理者はトラフィックがロードバランサーを通過する方法に影響を与え、ルーティングの競合を防ぐことができます。
ルーティングテーブルの例 #
解決策 #
非対称ルーティングの問題を解決するには、競合するインターフェースをバックエンド ネットワークに関連付けられたルーティング テーブルから除外する必要があります。
このシナリオでは、 eth1はルーティングテーブルから削除する必要があります table_eth2トラフィックが正しいゲートウェイを経由してルーティングされるようにします。
Web UIを使用したソリューション #
- 移動先: ネットワーク > ルーティング
- バックエンド インターフェイスに関連付けられたルーティング テーブルを選択します。
table_eth2 - ページの一番下までスクロールします。
- 動画内で 管理インターフェース のセクションから無料でダウンロードできます。
- インターフェースを移動する eth1 from 管理インターフェース 〜へ 管理されていないインターフェース.
これにより、バックエンド ルーティング テーブルが使用されている場合に、トラフィックがフロントエンド インターフェイスを介して直接ルーティングされることが防止されます。
CLIを使用したソリューション #
同じ構成は、 RELIANOID CLI。
ステップ1: APIアクセスを有効にする #
システム > ユーザー設定に移動します
APIアクセスを有効にし、APIキーを設定します。独自のキーを定義することも、ランダムに生成することもできます。
キーを作成したら、それをコピーして保存します。これは、noid-cli を使用して CLI に初めてアクセスするときに必要になります。
ステップ2：アクセス RELIANOID CLI #
システム コンソールから次のコマンドを実行します。
noid-cli
プロンプトが表示されたら API キーを入力します。
ステップ3: ルーティングテーブルからインターフェースを削除する #
次のコマンドを実行します。
ネットワークルーティングテーブル管理されていないテーブル_eth2を追加 -インターフェースeth1
このコマンドはトラフィックが eth1 ルーティングテーブルを使用する場合 table_eth2.
ステップ4: 構成を元に戻す（オプション） #
必要に応じて、次のコマンドで設定を元に戻すことができます。
ネットワークルーティングテーブル管理対象外 table_eth2 eth1 を削除
ベストプラクティス #
- ルーティングの変更を実行 トラフィックの少ない時間帯やメンテナンスの時間.
- 構成を適用した後、接続を検証します。
- ルーティングの変更によって他のサービスが影響を受けないことを確認します。
結論 #
ロード バランサが複数のネットワークに接続され、トラフィックが着信接続に使用されたインターフェイスとは異なるインターフェイスを介して返される場合、非対称ルーティングの問題が発生する可能性があります。
In RELIANOIDこの問題は、ルーティング テーブルの構成を調整し、競合するインターフェイスを特定のルーティング テーブルから除外することで解決できます。
これにより、トラフィックが正しいネットワーク パスをたどり、接続の問題を防ぐことができます。
