PertinoでセキュアなAWSリージョン間ネットワークを構築する

特集

大瀧隆太

2015.02.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
Pertinoで構築する次世代VPNシリーズの2本目行きます！前回はリモートアクセスとしてPertinoを利用しました。今回は端末-サーバー間ではなくサーバー-サーバー間の例として、AWSの異なるリージョンにあるEC2同士でSSL-VPNによるセキュアな相互通信をやってみたいと思います。

構成の概要

AWSの東京リージョンとオレゴンリージョンに1台ずつEC2インスタンスを用意し、Pertinoクライアントをインストールします。図で示すと、以下のようになります。

pertino2-01

各インスタンスでのPertinoクライアントのセットアップ手順は前回のUbuntu Linuxへのインストールと特に変わりません。メールアドレス/パスワードの認証だけで中継サーバーへの接続とデフォルトNetworkへの参加をやってくれるのが簡単でいいですね。オレゴンリージョンのインスタンスから東京リージョンのインスタンス(aws-tokyo-1.XXXXXX.pertino.net)にpingコマンドを実行してみます。 

ubuntu@aws-oregon-1:~$ ping -n aws-tokyo-1.XXXXXX.pertino.net
PING aws-tokyo-1.XXXXXX.pertino.net (50.203.XX.XX) 56(84) bytes of data.
64 bytes from 50.203.XX.XX: icmp_seq=1 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=2 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=3 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=4 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=6 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=7 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=8 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=9 ttl=64 time=114 ms
64 bytes from 50.203.XX.XX: icmp_seq=10 ttl=64 time=114 ms
^C
--- aws-tokyo-1.XXXXXX.pertino.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 114.359/114.675/114.859/0.168 ms
ubuntu@aws-oregon-1:~$

レスポンスが返ってきており、ちゃんと接続できていますね。110ms台ということなので、EC2インスタンスのグローバルIP同士(≒インターネット経由)での非暗号化通信と大差ない、良好なレイテンシです。

Cloud Network Engineの仕組み

ここでは、PertinoのSSL中継サーバーについてもう少し詳しく調べてみます。PertinoのSSL中継サーバーはCloud Network Engine(以下CNE)と呼ばれる分散構成になっており、以下で参照できるTechnical Briefに詳しく説明されています。

適宜脚注に引用しつつ、解説してみます。

Master ControllerとTunnel Server

Technical Briefでは、脚注引用 *1 のように"CNEはSDNアーキテクチャに基づいてControl PlaneとData Planeに分かれて構成している"とあり、これがMaster ControllerとTunnel Serverを指すと考えられます。

Master ControllerはCNE全体を管理するサーバーで、以下の役割を担います。クライアントが接続するIPアドレスする限りでは、現在AWSバージニアリージョンにあるようです。

  • Pertinoクライアントの認証
  • PertinoクライアントへのTunnel Serverの割り当て

対してTunnel Serverは、実際のSSL-VPNの中継を担当します。脚注引用 *2の通り、Tunnel Serverは世界中の複数のデータセンターに仮想マシンとして用意されていて、クライアントの接続元から近い仮想マシンがMaster Controllerによって選択されます。図で示すと以下のようなイメージです。

pertino2-02

EC2インスタンスでPertinoクライアントを実行する場合、東京リージョンとオレゴンリージョンではそのインスタンスと同じAWSリージョンのTunnel Serverが選択されました。他のロケーションで利用する場合も、どこにあるTunnel Serverに接続することになるのか検証するのが良いでしょう。AWS以外のクラウドに配置されるケースも、DigitalOceanの例などがあります。

Tunnel ServerとのSSL-VPN接続

Tunnel ServerとのSSL-VPN接続は、技術的には脚注引用 *3の通りNVGRE上にフラットなL2ネットワークが構築されます。ざっと検証したところトンネルインターフェースに割り当てられるアドレス以外のトランジットなトラフィックとブロードキャストトラフィックは通らず、クライアント同士のユニキャストトラフィックを前提とした作りです。そのため、Pertinoクライアントを実行するインスタンスをVPNゲートウェイとするサイト間接続としてPertinoを利用することは基本的にはできないようです *4。SSL-VPN接続を利用する全てのインスタンスにPertinoクライアントをインストールすることになります。

どのクライアントと接続するかは、Networkという単位でグループ分けすることができます。明示的に指定しない限り、Pertinoアカウントの登録ウィザードで作成する既定のNetworkに接続することになりますが、別途Networkを作成しクライアントからNetworkを選択することで別グループを構成することも可能です。

2台目のクライアントからPertinoに接続すると、Tunnel Serverは同じネットワークに接続している1台目と同じTunnel Serverが割り当てられます。1台目のクライアントが東京から接続したのであれば、2台目がオレゴンなど別のロケーションだったとしても、東京のTunnel Serverが割り当てられます。

pertino2-03

Tunnel Serverに接続するクライアントが増えてくるとパフォーマンスに影響がないか気になるところですが、Freeプランで利用できる3ノードの範囲では、複数のTunnel Serverが割り当てられTunnel Serverが相互で中継するような挙動は特に見られませんでした。

3台以上で使用するときの注意

前述の通り同一Networkに接続するPertinoクライアントは、1台目に割り当てられるTunnel Serverを介してVPN通信を行うことになるので2台目以降の相互通信のルートが極端に遠くならないような考慮が必要です。例えば、以下のように1台目は東京、2台目と3台目はオレゴンにあるとすると、1台目に合わせて東京のTunnel Serverが割り当てられるため、2台目と3台目間の相互通信がオレゴン→東京→オレゴンと太平洋を往復するルートになってしまいます。

pertino2-04

Technical Briefにはパフォーマンスや可用性の問題を自動で検出、回避する *5とあるので、Master Controllerによってトラフィックのデータ量などから実績ベースでTunnel Serverの構成が調整されるかもしれませんが、初期構成時は最初に接続するPertinoクライアントのロケーションを意識して構築するのがよいでしょう。

まとめ

PertinoをAWSリージョン間VPNのために利用する構成をご紹介しました。"AWS"と書きましたが、別のクラウド同士や異種クラウド間でも特に制限なく利用できると思いますので、最近良く言われるハイブリッドクラウド構成に利用するのもアリだと思います。Pertinoで柔軟なクラウドネットワーク構成を活用しましょう！

脚注

  1. Combining next gen cloud and network technology - Software-defined networking (SDN)の一節

    Pertino’s Cloud Network Engine is built on SDN architecture that moves the network complexity into the cloud and allows virtual networks to be rapidly provisioned, migrated, scaled, and adapted for new services.
    (中略)
    By separating the control plane (which translates policies into network programming) from the data plane (which manages data inspection, policy enforcement, service injection, and data forwarding), the process of building a network and adapting it to the needs of specific users and services is now simplified and in real-time.

    ↩

  2. Combining next gen cloud and network technology - Elastic cloud infrastructureの一節

    Our cloud network platform runs on off-the-shelf virtual machines (VMs) within multiple top tier data centers around the world.

    ↩

  3. Combining next gen cloud and network technology - Network virtualizationの一節

    This is enabled by Pertino’s multi-tenant network virtualization technology, which overlays data center routing infrastructure with a virtual LAN-like network with enhanced NVGRE encapsulation.

    ↩

  4. クライアント同士でL3レイヤーのIPトンネルを構築するなど、工夫はできると思います。 ↩
  5. Combining next gen cloud and network technology - Real-time optimization and orchestrationの一節

    If a platform element experiences any performance or availability issues, the affected virtual networks are automatically migrated to another zone, another data center, or even another cloud provider—instantly. Usually, without network users even knowing.

    ↩

AWS