タグ: 導入

カテゴリー
2021年 Riverbed SD-WAN クラウド コンピューター 技術一般

リバーベッドのSD-WAN製品分析と実装メモ


にほんブログ村

某お客様で SD-WAN を導入したいという話がありました。そこでリバーベッドテクノロジー社の SD-WAN 製品であるSteelConnect EX を提案しました。

その時にいろいろと動作確認しましたので、メモとして残しておこうと思いました。

SD-WAN ですが、ヘッドノードのサーバーで構成されるコントロールプレーンと、実際にユーザーデーターを転送するデータプレーンの 2つで構成されます。

ヘッドノードは、ハードウェア版と仮想版があるのですが、今回は、仮想版を使用しました。VMWare ESXi上で動作します。

SD-WAN ヘッドノードですが、

  1. Director
  2. Controller
  3. Analytics

という 3つのサーバーから構成されます。

このうち、1 と 2 はヘッドノードとして必須コンポーネントとなり、3 はオプションとなります。

注意点は、ヘッドノードを構成して運用が始まった後に、Analyticsサーバーを後から追加するためには、設定を全て初期化する必要があります。

そのため、Analyticsが必要であるかどうかは、最初によく検討しておく必要があります。

SD-WAN がなぜ求められるのか

SD-WAN と言っても、結局は、ルーターやスィッチです。

ですが、コントロールプレーンとデータプレーンを分け、設定や管理は全てコントロールプレーンで集中管理し、データプレーンはデータを転送することのみに集中しているという点が異なります。

これにより、データプレーンの機器は比較的安価なもので良くなり、中央管理できるので、運用管理のコストも下げられます。

また、クラウドを利用することが当たり前になった今、ローカルブレークアウトを使うことも普通になりました。

このためには、アプリケーションをポート番号レベルではなく、L7（アプリケーション）レベルで認識する必要があります。

このアプリケーション情報を使って、アプリ1 はインターネット、アプリ2 は MPLS、アプリ3 はインタネットVPN、という感じで経路を使い分けることができます。

これは、従来のルーターやスィッチでは難しかったことです。

PBR (Policy Based Routing) で、経路を使い分けることはできました。ですが、PBR のポリシーは、ACL (Access Control List) で定義されます。ACL は、IPアドレスとポート番号の組み合わせで成り立っています。

現在のアプリケーション、特にインターネット向けは、85% 以上が暗号化されています。つまり HTTPS（TCP/443）です。

ポート番号でしか指定できないと、HTTPS が一括りでしか制御できず、経路選択の意味がほとんどないという状態になります。

ここで Ciscoは、PfR (Performance Routing) と NBAR (Network Based Application Recognition) を組み合わせた設定を推していましたが、これを使うためには、ルーターにパワーが必要です。大型の機器になってしまうのです。

こういった点でも、SD-WAN ならお手軽に実現できます。

リバーベッドテクノロジー社の SD-WAN

リバーベッドテクノロジー社の SD-WAN ですが、最初はドイツの Ocedo社を買収しています。これを自社製品として、SteelConnect CX として販売をしました。

ですが、この製品は、エンタープライズクラスのルーティング向けには機能が足りないことが分かり、今度は、Versa Networks社と技術提携し、OEM 販売をしています。これが今回の SteelConnect EX です。

Versa Networks ですが、元々 Juniper Networks にいた人たちが結成した会社であり、ルーティング機能は非常にしっかりしています。エンタープライズルーティングという面でバッチリです。

そして、Next-Gen Firewall、URL フィルタリング、Anti Virus、IPS/IDS といったセキュリティー機能も豊富に搭載しています。リバーベッドテクノロジー社はこれを OEM 販売しているため、SteelConnect EX にも、同じ強みと特徴があります。

そして、リバーベッドテクノロジー社と言えば、WAN最適化のSteelHeadです。リバーベッドテクノロジー社の SD-WAN ルーターには、SteelHead の機能も搭載できます。

SteelConnect EX には、エンタープライズルーティング、セキュリティー、WAN最適化という SD-WAN に求められる 3つの機能の全てが搭載されているという訳です。

私のお客様も、SteelHead 大好きユーザーの1つでして、SD-WAN を検討された際に、SteelConnect EX 以外は考えられないと言われてました。

次回から、SteelConnect EX のヘッドノードをインストールした際のメモを紹介していきます。

関連する記事：

最近の記事：

カテゴリー
2021年 Linux Riverbed SaaS Windows キャッシュ クラウド コンピューター 技術一般 自動化 証明書

モバイル PC で SaaS の快適アクセス

Riverbed TechnologyのClient Accelerator（旧SteelHead Mobile） という製品を触ってみました。

なぜ、この製品を触ってみたかというと、バージョン 6.2.2 にSSL Agent (SSL Simplification)という機能が搭載され、最適化動作にサーバ証明書の管理が不要となったためです。これは便利！と思い、早速、評価してみました。

SteelHead Appliance とは

業界をリードする WAN 最適化装置です。WAN越し、インターネット越しのアプリケーションアクセスのパフォーマンスを向上させます。WAN やインターネットに流れるデータを、特別なキャッシュの技術を使ってデータ削減します。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

Client Acceleratorとは

SteelHead アプライアンスをソフトウェアにした製品です。Windows や Mac のラップトップにインストールして使えます。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

なぜ、SSL Agentが良いのか？

インターネットの通信の 85%以上が SSL 通信（HTTPS）であると言われています。つまり、暗号化されているのです。

こういった暗号化された通信を制御する製品では、通信を一旦終端し、暗号化を解く必要があります。

この暗号化には、サーバ証明書を使用しています。

企業内にホスティングされている Web サーバーであれば、そのサーバーの管理者に依頼すれば、サーバー証明書を入手することは可能です。

ですが、これがインターネット上のサーバーだったら、どうでしょうか。誰が管理者か分からないし、管理者が仮に分かっても、サーバ証明書は通常得られません。

インターネット上サーバーの証明書は、管理者に依頼しなくても、サーバ証明書の内容は入手することは可能です。ですが、いつそれらの証明書の内容が変更になるかは分からないという点は変わりません。その内容に合わせて代理証明書を作っても、元の証明書の内容が変更になるたびに代理証明書の方も変更する必要があり、管理が大変です。

WAN 最適化装置も、クライアント PC と Web サーバーの間の通信に入り込んで動作しますので、暗号化された通信は一度復号化する必要があります。そこに、サーバ証明書を使っています。

企業内の Web サーバーであれば、管理者に依頼してサーバー証明書を入手し、その証明書を WAN 最適化装置にもインストールしれば良いので対応できます。

しかし、これが Microsoft 365（Office 365）へのアクセスだったらどうでしょうか。マイクロソフトからサーバー証明書はもらえません。

復号化ができませんので、最適化動作（特に問題になるのはデータ削減）ができなくなります。

仮に、先ほどの方法で内容を把握し、自分で代理証明書を作成することは可能ですが、その内容が変更になったら、証明書がないのと同じです。マイクロソフトは、M365 の証明書をかなり頻繁に変更しています。

SSL Agent の登場

こういった問題を解決できるのが、SSL Agent です。この機能を使えば、サーバ証明書のインストールは不要になります。どうやったら証明書が入手できるのかとか、いつ変更になるのかを気にする必要はもうありません。

動作確認の構成

テスト構成はこんな感じです。

Client Accelerator と SteelHead の間に WAN シミュレーターを入れ、ここで疑似インターネットを作っています。WAN シミュレーターで、帯域幅や遅延、パケットロスが設定できます。今回のテストでは、100ミリ秒の遅延を入れています。

WAN シミュレーターには、WANemを使っています。

そして、アクセス先は、実際の M365 を使っています。私が個人で契約して使っているものですので、東京リージョンになります。M365 へのアクセスは、実インターネットの通信です。

データ削減の効果

OneDrive に保存してある 68MB のパワーポイントのドキュメントをダウンロードしてみました。

以下のグラフの一番上のコネクションが、OneDrive からのダウンロードのコネクションです。転送データの内、41% のデータが重複排除され削減されています。通信の宛先ポート番号がTCP/443（HTTPS）になってますね。サーバ証明書なしで、データ削減ができています。

キャッシュの無い一回目のデータ転送でも半分弱のデータが削減されてます。すごい効果ですね。40秒ほどで、ダウンロードが完了しています。

今度は、二回目の転送です。以下のグラフの上から2番目のコネクションが、OneDrive からのダウンロードのコネクションです。

同じパワーポイントのファイルを再度転送しています。91% のデータ削減です。もうほとんど、疑似インターネット上にはデータが流れてません。流れるデータの量が減れば、とうぜん体感のスピードだって上がりますよね。数秒でダウンロードは完了しています。

同じファイルなんだからデータが減って当たり前、という考え方もあります。

ですが、Riverbed 社のキャッシュは、ファイルキャッシュではなく、バイトキャッシュを使っています。

約100バイトの大きさにデータを細切れにし、その中の「0」と「1」の配列が同じであれば、1つにするという方式で、データ削減を行っています。

リバーベッドテクノロジー社初心者向け技術トレーニング資料より抜粋

つまり、この「0」 と「1」の配列が同じであれば良いだけで、パワーポイントで得たキャッシュで、エクセルでも PDF でも、データ削減が出来ちゃうという訳です。すごい技術を持ってます。

もう一つのテスト構成

Web プロキシーサーバーというものは、企業でよく使われています。これがあった場合でも、この WAN 最適化の仕組みは動くのだろうか？という疑問が湧きましたので、追加で動作も見てみました。

Web プロキシーサーバーには、 Unveil Technology 社のOpen Squidbox を使ってます。Linux でお馴染みの Squid なんですが、仮想アプライアンスみたいになってて、手軽に使えます。GUI の画面からグラフを見られて便利です。

Web プロキシー経由での、一回目のデータダウンロードです。以下のグラフの上から2番目のコネクションです。今度は、宛先ポート番号がTCP/3128（Squid）になってますね。

一回目のキャッシュなしのダウンロードで、44％のデータ削減が実現しています。

今度は二回目のダウンロードです。以下のグラフの下から4番目のコネクションです。94％のデータ削減が実現しています。Web プロキシーを経由しても、データ削減の効果は得られていますし、変わらない結果が得られました。

評価のまとめ

  • キャッシュを使ってのデータ削減と差分データ転送の効果は高い。
  • 運用すればするほどキャッシュは溜まるので、一回目のデータ転送時のデータ削減効果は高くなることが期待できる。
  • SaaS アプリケーションだけでなく、Yahoo や Facebook など、インターネット上にある Web サーバーは何でも最適化対象にできる。
  • ただし、ある程度の転送データ量があるコネクション（OneDrive や SharePoint のアクセス）を対象にしないと、投資効果が合わない。
  • ダイレクトアクセスでも、Web プロキシー経由のアクセスでも、通信を最適化することができる。

私のオーストラリアの某お客様が、シンガポールのデータセンターにある Web プロキシーを経由して Microsoft 365にアクセスしているが遅いといっていますので、早速、この SSL Agent を提案してみたいと思います！

SSL Agent の設定

最後に、設定内容もメモとして記載しておきます。

SteelHead アプライアンス側設定

SSL Main Setting のところで、SSL Optimization を有効にします。

SSL Advanced Settings のところで、TLS Blade を有効にします。

Client Accelerator Controller の自己証明書をコピーし、SteelHead アプライアンスのMobile Trust のリストに追加します。

これは、Client Accelerator ソフトウェアとSteelHead アプライアンス間（最適化通信のコネクション）を暗号化するためです。

Client Accelerator Controller 側のポリシーの設定

Port Label で、「Web」というラベルを作成し、TCP/80, 443, 3128を対象としています。Port Label とは、複数のポート番号をグループ化して名前で管理できるようにするものです。

In-Path ルールで、Webでまとめたポート番号向けの通信を全て最適化対象とするというルールを設定します。

今回使用しているルールの内容です。

Peering 証明書のところに、SteelHeadアプライアンスの自己証明書をコピーして追加します。Client Accelerator ソフトウェアとSteelHeadアプライアンス間の最適化通信を暗号化するためです。

SSL 設定のところで、SSL Optimization を有効にします。

その設定ページの下の方にあるTLS Optimization を有効にします。

Client Accelerator の評価版は、こちらから申請して試すことが可能です。


にほんブログ村

関連する記事：

最近の記事：

カテゴリー
2021年 Linux NPM Raspberry Pi Riverbed SNMP コンピューター 可視化 技術一般

Raspberry Pi で SNMP エージェントを動かす


にほんブログ村

Network Performance Monitoring（NPM）製品の動作確認をしていて、SNMPポーリングから、対象機器の情報を取得してトポロジーマップを作成するという機能を知りました。

私は、家の各部屋に Cisco スィッチ、インターネットルーターも Cisco ルーターを使っているので、それぞれの機器に SNMP の設定をしたのですが、今回は、Raspberry Pi にも SNMP の設定をしてみました。

私の Raspberry Pi では、Softether VPN サーバーが動いてますので、是非ともトポロジーマップに含めて、どのように表示されるのかが見たかったためです。

今回は、Raspberry Pi で SNMP エージェントを動かす設定を試した時のメモです。

Raspberry Pi OS は、Debian という Linux なので SNMPのエージェントには、Net-SNMP が使われています。

ですが、デフォルトではインストールはされていないようです。

追加インストールします。

$ sudo apt install snmpd

これでインストールは完了です。

次に、Net-SNMP の設定を行います。

設定ファイルは、「snmpd.conf」というファイルになります。保存場所は、/etc/snmp ディレクトリー配下になります。

ファイルを編集する前に、バックアップを取っておきましょう。これは Linux の設定を変更する時の基本ですね。

snmpd.conf ファイルが保存されているディレクトリーに移動します。

cd /etc/snmp

cp (Copy) コマンドで、バックアップファイルを作成します。

sudo cp ./snmpd.conf ./snmpd.conf.bak

作成されましたね。これでいつでも戻せます。

それでは、ファイルを編集して、設定をしていきます。

個人的には、編集の際には、vim を入れておくと便利だと思います。

「AGENT BEHAVIOUR」という項目の、以下の部分のコメントアウトを削除して、有効化します。

sudo vim ./snmpd.conf

コメントアウトを外します。

次に、MIB のアクセス範囲を広げておきます。

「ACCESS CONTROL」の項目の一行目に、以下のように記入しておきます。

最後に、「SYSTEM INFORMATION」の項目で、SysLocation と SysContact を入力しておきます。

基本的にはこれで完了です。

設定を変更しましたので、反映させるために、SNMP のプロセスを再起動しておきます。

sudo service snmpd restart

自分で使っているSNMPマネージャーでアクセスしてみましょう。

私が今回使っているのは、リバーベッドテクノロジー社のSteelCentral シリーズの NetIM という製品です。こいつから、Raspberry Pi に対して、SNMP ポーリングを行います。

Raspberry Pi が表示されました。

対象機器の情報を取得するまでに時間がかかるので、情報取得後に、トポロジーマップを確認してみたいと思います。

関連する記事：

最近の記事：