プロキシ環境でも容易に導入可能 エンタープライズ SD-WAN とは ~ Office 365 をより快適に使うためのジュニパーのクラウド最適化ソリューション ~ 2019 年 9 月 19 日 2019 Juniper Networks Juniper Public

Transcription

1 プロキシ環境でも容易に導入可能 エンタープライズ SD-WAN とは ~ Office 365 をより快適に使うためのジュニパーのクラウド最適化ソリューション ~ 2019 年 9 月 19 日

2 SD-WAN とは

3 ONUG SD-WAN 評価 No 評価項目可否ジュニパーネットワークス 1 Active/Active 構成で様々な回線 WANの制御が可能なこと 2 コモディティHW 上で 仮想的にCPEを提供できること 3 アプリケーション等のポリシーに基づき ダイナミック制御が可能なこと 4 個別のアプリに対して 可視化 優先順位付け ステアリングが可能なこと 5 可用性 柔軟性の高いハイブリッドなWANの構築が可能なこと 6 L2/L3に対応 7 拠点 アプリケーション VPN 品質等をダッシュボードでレポーティングができること 8 オープンなノースバウンドAPIを持ちコントローラーへのアクセスや制御ができること 9 ゼロタッチプロビジョニングに対応すること 〇〇〇〇〇〇〇〇〇 Public WAN, Private WAN のマルチホーミング (Active/Active) での利用ができます vsrx( バーチャル SRX) にて SRX の機能を仮想マシン形式の CPE としてご利用いただけます SRX NFX の AppRoute(APBR) にてアプリケーションベースのダイナミックな制御が可能です アプリケーションの可視化 アプリケーションベースでの優先制御 (QoS) が可能です 複数の Private WAN, Public WAN での構成が可能で回線障害時も動的に切り替えが可能です SRX NFX は L2/L3 に対応します CSO / Sky Enterprise では各種ダッシュボード機能 パフォーマンスレポーティングの機能を備えております REST API をはじめ各種スクリプトを提供 資料を公開しています SRX NFX は ZTP( ゼロタッチプロビジョニング ) に対応しております NFX は vsrx( バーチャル SRX) を標準搭載します 10 FIPS-140-2( セキュリティ ) を取得できること 〇 SRX NFX250 および Junos は FIPS に対応しています

4 何故 SD-WAN が必要なのか

5 SD-WAN を検討するモチベーション CAPEX/OPEX の軽減 WAN, LAN, Wi-Fi を一元管理 テンプレート作成による簡単運用 ZTP による拠点構築 ユーザ体感の向上 クラウドアプリケーションを利用するユーザの体感を改善 拠点間通信の最適化 収益モデルの構築 サブスクリプションモデルにより 必要に応じてセキュリティサービスを追加 カタログモデルの販売 (3 rd パーティー VNF をオンデマンドで提供 ) 5

6 エンドユーザが SD-WAN を必要とする理由 CAPEX/OPEX の軽減 WAN, LAN, Wi-Fi を一元管理 テンプレート作成による簡単運用 ZTP による拠点構築 ユーザ体感の向上 クラウドアプリケーションを利用するユーザの体感を改善 拠点間通信の最適化 収益モデルの構築 サブスクリプションモデルにより 必要に応じてセキュリティサービスを追加 カタログモデルの販売 (3 rd パーティー VNF をオンデマンドで提供 ) 6

7 クラウドサービスの普及と課題 クラウドサービスの利用で労働生産性は向上 SaaS 利用が急速に拡大している ソフトウェアの国内市場 ( パッケージ /SaaS) 65.6% 増 労働生産性約 30% 高 Source : Smartcamp Co, Ltd 企業での SaaS 利用は拡大 Source : 富士キメラ総研ソフトウェアビジネス新市場 2018 年版 7

8 クラウドサービスの普及と課題 メールやアプリケーションサーバをクラウドに移行すると ネットワークの帯域や FW へかかる負荷が増大プロキシサーバを経由する場合はプロキシサーバの負荷が増大 レスが遅い! 拠点 A 帯域不足 IP-VPN DC インターネット 拠点 B スペック不足 アプリケーションは増える一方 8

9 アプリケーション制御による課題の解決 9

10 SRX を利用したネットワークが遅くなった原因の判別 アプリケーションの使用帯域 セッション数 使用したユーザを表示 OFFICE365-CREATE-CONVERSATION GB OFFICE365-CREATE-CONVERSATIO Takezawa 12.3GB 原因となっているアプリケーション ユーザを特定できる 10

11 ローカルブレークアウトの需要 帯域不足でファイルのダウンロードに時間が掛かる今後のどれだけクラウドサービスを使用していくか不明瞭なため単純な回線増強ではすぐに頭打ちになってしまう データセンタ側のFWに負荷が掛かり処理に時間が掛かる 拠点 A SRX320 業務アプリ インターネット通信 Office 365 通信 帯域不足 IP-VPN DC インターネット 拠点 B スペック不足 Office 365 トラフィック過多の原因 インターネット SRX300 11

12 ローカルブレークアウトの需要 IP-VPN 回線の増強は不要トラフィック過多の原因となっていたO365はインターネット回線から通信インターネットへのアクセスもFW 経由なので問題なし 拠点 A SRX320 業務アプリ インターネット通信 Office 365 通信 IP-VPN DC 帯域 OK セキュリティOK インターネット 負荷分散 拠点 B Office 365 SRX300 インターネット 他のアプリに影響を与えない 12

13 ローカルブレークアウトソリューションの課題 クラウド化が進む中で DC に向かうトラフィック量が増大している インターネット回線を用意してトラフィックの負荷分散をしたいが セキュリティのために Proxy サーバを導入しており 一部のアプリケーションのみ Proxy サーバを経由しない設計は困難 そのため ローカルブレークのソリューションは導入できない 拠点 A 業務アプリ インターネット通信 Office 365 通信 IP-VPN DC インターネット Proxy サーバ拠点 B Office 365 インターネット 13

14 ローカルブレークアウトソリューションを導入できない原因 Proxy サーバを使用している環境ではクライアントはアプリケーションサーバの IP アドレスではなく Proxy サーバの IP アドレスへ通信を開始する そのため アプリケーションを判別して経路を変更しても通信が成立しない IP-VPN Proxy サーバ xxx.xxx.xxx Office 365 クライアント PC にとって Office365 の宛先は Proxy サーバ O365 Dst: インターネット Dst: ?? Office365 の通信をインターネット経由にしても宛先経路がなく通信が成立しない! 14

15 ローカルブレークアウトソリューションを導入できない原因の解決 アプリケーションを判別した後 ブレークアウト対象のアプリケーション通信であれば本来の宛先に変更して通信させる Proxy サーバ xxx.xxx.xxx IP-VPN Office 365 クライアント PC にとって Office365 の宛先は Proxy サーバ O365 Dst: インターネット Dst: 200.xxx.xxx.xxx ブレークアウトの対象となるアプリケーションの宛先を本来の宛先に変更する 15

16 ブレークアウトを実施する際の動作 クライアントPC S1 (Client session) SYN Packet SRC IP = Client IP DST IP = External Proxy SRX データはIP headerの書き換えて S1とS2の間をリレーする DNS External proxy SYN-ACK SRC IP = External Proxy DST IP = Client IP ACK HTTP Connect SRC IP = Client IP DST IP = External Proxy CONNECT office365.com:443 HTTP/1.1 Host: office365.com Host を参照してブレークの対象アプリかを判別 対象アプリの場合 DNS で名前解決を実施してサーバとコネクションを確立する S2 (Proxy session) SYN Packet SRC IP = Client IP DST IP = O365 SYN-ACK SRC IP = O365 DST IP = Client IP CONNECT OK ACK Client Hello Client Hello 16

17 ブレークアウトしない際の動作 クライアント PC SRX DNS External proxy website SYN Packet SRC IP = Client IP DST IP = External Proxy ACK SYN-ACK SRC IP = External Proxy DST IP = Client IP HTTP Connect SRC IP = Client IP DST IP = External Proxy CONNECT juniper.net:443 HTTP/1.1 Host: juniper.net Host を参照してブレークの対象アプリかを判別 対象アプリでない場合 Pass through mode として動作する SYN Packet SRC IP = Client IP DST IP = External proxy SYN-ACK SRC IP = External proxy DST IP = Client IP ACK SRX と External proxy で temporary のセッションを作成 HTTP connect request を External proxy へ forward した後は SRX は通信をインターセプトしない HTTP Connect SRC IP = Client IP DST IP = External Proxy CONNECT juniper.net:443 HTTP/1.1 Host: juniper.net CONNECT OK Client Hello 17

18 ブレークアウトした通信ログの表示 HTTPS(SSL) の通信でもアクセス先 (URL) とユーザ名をログ出力することが可能 ユーザ名 アクセス先 18

19 ビデオ動画や音声通話が品質劣化する要因 SaaS の普及に伴い WAN に流れ込むトラフィック量が増大しタイムクリティカルなアプリケーションが影響を受ける VoIP やオンライン会議の音声品質が低下し会話が聞き取り難くなる 声が途切れて話が聞こえん! 拠点 A 帯域不足 IP-VPN DC インターネット 拠点 B スペック不足 アプリケーションは増える一方 19

20 リアルタイム性の高いアプリケーションを最優先させ通信を制御 オンラインストレージ 出力キュー パケット廃棄率 Low ` パケット廃棄率 Medium パケット廃棄率 High パケット廃棄優先度 PLP が低いほど優先的に転送 High Medium High Medium Low Low ウェブ閲覧 SRX シリーズ WAN オンライン会議 良く聞こえるようになった! 高品質な音声通信 20

21 AppQoS デモ 帯域上限に近いトラフィックを送信し Skype ビデオ映像の乱れを比較 trust ゾーン untrust ゾーン PC Skype 通信 その他通信 Queue Queue AppQoS-PLP 通信 Skype その他 Packet Loss Priority Low high PC パケットジェネレータ その他通信 帯域上限に近い通信量を送信 SRX パケットジェネレータ 21

22 AppQoS デモ 動画のリンクは下記を参照 22

23 ユーザベースのアプリケーション制御 ユーザ属性とアプリケーションを条件に通信を制御 連携 DC CEO 全アプリケーション通信許可 Skype は IP-VPN 経由で最優先 SRX IP-VPN AD サーバ O365 はブレークアウト 社員 アプリケーション通信は IP-VPN 経由のみで通信可能 YouTube の閲覧 NG インターネット Office

24 ユーザベースのアプリケーション制御 ユーザ属性とアプリケーションを条件に通信を制御 QoS で対応 ブレークアウトで対応 24

25 カスタムアプリケーション Juniper Networks が定義していないアプリケーションもユーザ側で個別に定義して制御することが可能 set services application-identification application CUSTOM-VIEW over SSL signature s1 member m01 context ssl-server-name set services application-identification application CUSTOM-VIEW over SSL signature s1 member m01 pattern ".*\juniper.net*" set services application-identification application CUSTOM-VIEW over SSL signature s1 member m01 direction client-to-server 25

26 アプリケーション通信の最適化 26

27 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE 該当するアプリケーションが SLA に違反した場合 経路を変更する SLA Value Packet loss (%) 5% Jitter (ms) 100 ms RTT (ms) 300 ms CPE 本社 アプリケーションサーバ 拠点 B 拠点 A CPE DC App の通信経路 SLA に違反した場合の通信経路 27

28 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE SLA を定義 28

29 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE 該当する通信に紐づける 29

30 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE SLA 違反を検知すると経路が切り替わる 経路切り替え前 経路切り替え後 WAN1 のリンクにはトラフィックは流れていない SLA 違反のため WAN1 から WAN2 に切り替えて通信を開始 30

31 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE SLA 違反は時系列で確認可能 31

32 アプリケーション単位で SLA を定義して経路を動的に変更する APPQOE 動画のリンクは下記を参照

33 JUNIPER NETWORKS が提供するアプリケーション制御 可視化したトラフィックをほぼ 100% 有効活用できる Proxy 環境であってもブレークアウトのソリューションを展開できる お客様の環境 例えば Proxy サーバのアドレスを SRX に変更する などの変更は不要 アプリケーションを識別するシグネチャをユーザ側で定義することができる 4000 種類以上あるアプリケーションで定義していない通信もユーザ側で個別に定義して制御することが可能 アプリケーションコントロールは SRX 単体が保有する機能 そのため SD-WAN コントローラーはあくまでオプション SD-WAN を検討したい場合 用途 規模に応じてコントローラーを選択できる 簡易 SD-WAN by Sky Enterprise, Full SD-WAN by CSO 33

34 Appendix 拠点間通信の最適化 34

35 拠点間の通信を最適化するダイナミック VPN 1. 拠点間通信はデフォルトではハブを経由 CSO 2. セッション数が閾値を超えるとダイナミックに拠点間でトンネルを自動作成 3. セッション数が閾値を下回るとトンネルは自動消滅 Dept Cloud HUB Cloud HUB Path A Path A Path A Gateway Dept Gateway HQ Site HQ Site Multiple mesh tags Dept Dept Dept Site 1 Site 2 Site 3 tag tag KPI: Session close rate Path B Tags: Gold, Silver, Bronze

36 拠点間の通信を最適化するダイナミック VPN 動画のリンクは下記を参照

37 Appendix 拠点間通信の品質向上 37

38 パケットを複製して品質を高める MULTI PATHING SUPPORT 該当するアプリケーションを複製してデータ遅延 欠損を補完する パケットロスが発生した場合 欠損したパケットを補完する 同じパケットを複数受信した場合は2 番目に受信したパケットを捨てる MPLS CPE CPE 2 1 拠点 聞こえる? Internet 1 パケロス 2 1 本社 良く聞こえます! 38