プライマリゲートウェイのバックアップタスクは、ネットワーク管理で最も一般的なものの1つです。 彼女は、Linuxベースのルーターを含む最新のルーターの大部分の発信チャネルの優先順位付けまたはバランス調整のメカニズムを実装する多くのソリューションを持っています。
フェイルセーフルーターに関する記事で、この問題を解決するための社内標準であるオープンソース
NetGWM製品
について簡単に言及し 、このユーティリティについて詳しく説明することを約束しました。 この記事では、ユーティリティの仕組み、使用する際に使用できる「機能」、および代替ソリューションの使用を放棄することにした理由について説明します。
なぜNetGWMなのか？
Linuxのメインゲートウェイの従来のバックアップスキームは、iproute2によって実装され、ほぼすべてのソースでほぼ同じに見えます。
- 指定：2つのプロバイダー。
- オペレーターごとにルーティングテーブルを作成します。
- どのトラフィックが1つまたは別のルーティングテーブルに分類されるかに応じて、ルール（
ip rule ）を作成します（たとえば、ソースおよび/またはiptablesのラベルによって）。 - メトリックまたはifupdownスクリプトにより、メインゲートウェイの優先順位を決定します。
このスキームの詳細は、「linux policy routing」のリクエストにより簡単にグーグル検索されます。 私たちの意見では、このスキームにはいくつかの明らかな欠点があり、それがNetGWMユーティリティを作成する主な動機となりました。
- スキームを変更する複雑さ、不十分な処理。
- ゲートウェイの数が3つ以上の場合、スクリプトロジックは複雑であり、メトリックに基づくゲートウェイの選択の実装も複雑です。
- チャネル損失検出の問題。 多くの場合、物理リンク、さらにはオペレーターのゲートウェイにもアクセスできますが、オペレーターのインフラストラクチャ内または上位のサービスプロバイダーの問題により、ネットワークには実際にはアクセスできません。 この問題を解決するには、ifupdownスクリプトに追加のロジックを追加する必要があり、メトリックに基づくルーティングでは原則として解決できません。
- ハンプティダンプティの問題。 このような問題は、優先度の高いチャネルで短期間の頻繁な通信の中断が見られる場合に発生します。 この場合、ゲートウェイはバックアップに正常に切り替わります。 問題はどこから来たように見えますか？ 事実、電話、ビデオ通信、VPNトンネルなどの多くのサービスでは、中断の事実を判断して新しいセッションを確立するために特定のタイムアウトが必要です。 中断の頻度に応じて、これによりサービスの品質が急激に低下するか、完全に利用できなくなります。 この問題を解決するには、スクリプトロジックを複雑にすることも必要であり、メトリックでは完全に解決できません。
4つすべての問題を解決するのに役立つものを見ました：2つ以上のデフォルトゲートウェイをサポートするシンプルで管理可能なツール。チャネルの可用性を診断し、安定性をテストできます。 そして、そのようなオプションが見つかりませんでした。 それがNetGWMの始まりです。
GitHubおよびFlantリポジトリからのインストール
NetGWM（Network GateWay Manager）は、メインゲートウェイに優先順位を付けるための小さなユーティリティで、Pythonで記述され、無料のGNU GPL v3ライセンスで配布されます。 オリジナル版の作者は
driusha （Andrei Polovov）です。
ソースコードと英語のドキュメントは
GitHubで入手でき、ロシア語の簡単なドキュメントと説明は
こちらから入手でき
ます 。
GitHubからのインストール：
さらに、NetGWMを備えた既製のDEBパッケージをUbuntuのFlantリポジトリからインストールできます。 Ubuntu 14.04 LTSのインストールは次のようになります。
Ubuntuでルーティングユーティリティテーブルを追加したり、cronを構成したりする必要はありません。 パッケージをインストールすると、テーブルが自動的に追加されます。 さらに、インストール中に
netgwmサービスが登録され、そのinitスクリプトはデーモンとして小さなシェルスクリプト
/usr/bin/netgwmを開始し、次に
/etc/default/netgwmから
INTERVALパラメーターの値を読み取り
/etc/default/netgwm （秒単位） ）そして、指定された頻度で
netgwm.py呼び出し
netgwm.py 。
カスタマイズ
NetGWMはポリシールーティングにも基づいており、各オペレーターのルーティングテーブルを事前に構成する必要があります。
オペレーターが3人いて、失敗した場合-オペレーター2が使用され、両方が失敗した場合-オペレーター3の場合、メインオペレーターがオペレーター1であることを確認する必要があるとします。
最初のオペレーターがeth1インターフェースに接続され、2番目がeth2に、3番目がeth3に接続されているとします。 最初のオペレーターには88.88.88.88ゲートウェイ、2番目のオペレーターには99.99.99.99ゲートウェイ、3番目には100.100.100.100があります。
いくつかの基本的なゲートウェイを使用してネットワークをセットアップする場合、ほとんどの場合、パケットラベル付けとNetFilterのconntrackモジュールを使用します。 これは、状態に基づいてルーティングテーブル間でパケットを配布するのに役立ちますが、必須ではありません。
パケットマーキングとconntrackを設定します。
iptables -t mangle -A PREROUTING -i eth1 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A PREROUTING -i eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A PREROUTING -i eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff iptables -t mangle -A OUTPUT -o eth1 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A OUTPUT -o eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A OUTPUT -o eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff iptables -t mangle -A POSTROUTING -o eth1 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A POSTROUTING -o eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A POSTROUTING -o eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
2.マークされたパケットのルーティングルールを追加します。 これは、loインターフェイスでの
post-upイベント中に
/etc/network/interfacesから呼び出されるスクリプトを使用して行います。
3.
/etc/iproute2/rt_tablesルーティングテーブルを宣言します。
4. NetGWMを構成します。 デフォルトでは、
netgwm.pyは
/etc/netgwm/netgwm.ymlで構成ファイルを
/etc/netgwm/netgwm.ymlますが、
-cスイッチでこれをオーバーライドできます。 ユーティリティをセットアップします。
# # () . 1 - # , # . ( # ) ( ). # # /etc/iproute2/rt_tables gateways: operator1: {ip: 88.88.88.88, priority: 1} operator2: {ip: 99.99.99.99, priority: 2} operator3: {ip: 100.100.100.100, priority: 3} # «-», # ( ) «». # ( ), # netgwm , min_uptime: 900 # , netgwm # . # , , # . , netgwm # ( AND) check_sites: - 8.8.8.8 # Google public DNS - 4.2.2.2 # Verizon public DNS # netgwm # . — .. # , true, netgwm # check_all_gateways: false
5.切り替え時のアクションを構成する
切り替えが発生した場合、メインゲートウェイを変更すると、
/etc/netgwm/post-replace.d/*ディレクトリにあるすべての実行可能ファイルが実行されます。 この場合、6つのコマンドラインパラメーターが各ファイルに転送されます。
$1新しい演算子の名前。$2新しいゲートウェイが確立できなかった場合、新しくインストールされたゲートウェイまたはNaNのIP。$3ゲートウェイを確立できなかった場合、新しいゲートウェイまたはNaNのデバイス名。$4ゲートウェイが初めてインストールされる場合、古い演算子またはNaNの名前。$5ゲートウェイが初めてインストールされる場合、古いオペレーターまたはNaNのIP。$6ゲートウェイが初めてインストールされる場合、古いオペレーターまたはNaNのデバイス名。
これらの変数に基づいて、スクリプトは接続するオペレーターに応じてアクションのロジックを記述できます（ルートの追加または削除、通知の送信、シェーピングの構成など）。 たとえば、通知を送信するシェルスクリプトを提供します。
6. DEBパッケージをインストールした場合、Ubuntuで
netgwmサービスを開始します。
$ sudo service netgwm start
GitHubからNetGWMを受け取った場合、以前にインストールされたcronのジョブはすでにメインゲートウェイの可用性をチェックしているため、追加の手順は必要ありません。
ロギング
NetGWMは、切り替えイベントをlog
/var/log/netgwm 。
$ tail -n 3 /var/log/netgwm.log 2017-07-14 06:25:41,554 route replaced to: via 88.88.88.88 2017-07-14 06:27:09,551 route replaced to: via 99.99.99.99 2017-07-14 07:28:48,573 route replaced to: via 88.88.88.88
保存された切り替え履歴は、インシデントを分析し、中断の理由を判断するのに役立ちます。
生産で検証済み
約4年間、NetGWMはさまざまなサイズの30以上のLinuxルーターで当社で使用されています。 ユーティリティの信頼性は、動作中に繰り返しテストされています。 たとえば、2014年5月以降、インストールの1つで、NetGWMは137人のオペレータの切り替えを問題なく処理しました。
私たちのすべてのニーズをカバーする安定性と、長期間にわたる運用上の問題の欠如は、私たちが実際にプロジェクトの開発に携わらないという事実につながりました。 NetGWMコードはPythonで記述されているため、ユーティリティを新しいバージョンのオペレーティングシステムに適合させる必要はありません。 ただし、
パッチをGitHubに送信
するか、コメントに機能リクエストを書くだけでNetGWMの開発に参加することにした場合は、非常に満足しています。
おわりに
NetGWMには、メインゲートウェイの優先度を管理するためのニーズを完全にカバーする、安定した、柔軟で、拡張可能な（スクリプトの助けを借りて）ユーティリティがあります。
NetGWMの使用に関する質問も歓迎します。コメント欄でご確認ください。
PSブログで「 フォールトトレラントLinuxルーターのレシピ 」もお読みください。新しい資料を見逃さないように登録してください。