検索
連載

オンプレミス環境とのプライベート接続――「AWS VPN」接続の基本：AWSで学ぶクラウド時代のネットワーク基礎知識（3）

これまであまり物理的なネットワークに触れてこなかったエンジニアを対象に、AWSを用いてネットワークの基礎知識を解説する連載。今回は、オンプレミス環境とのプライベート接続について解説し、AWSにおけるVPNの設定手順を示す。

[東竜一，ネットワンシステムズ] PC用表示 関連情報
Share
Tweet
LINE
Hatena

　これまであまり物理的なネットワークに触れられてこなかったSEやサーバ管理者、情シスなどの方を対象にネットワークの基本を「Amazon Web Services」（AWS）を用いて解説する本連載「AWSで学ぶクラウド時代のネットワーク基礎知識」。連載初回は、基本的なIPネットワークの概念を解説し、「Amazon Virtual Private Cloud」（VPC）の操作手順を示しました。前回の第2回では、インターネットへの接続について解説し、AWSにおける「Network Address Translation」（NAT）の設定手順を示しました。

　第3回の本稿では、オンプレミス環境とAWS間でのプライベートな接続について解説します。離れたネットワーク間をつなげるに当たり「セキュアにつなげられること」「あたかも直接つながっているように接続できること」が望ましいので、その実現方法、機能も説明します。またオンプレミス環境とVPC間のプライベートな接続方法についても、環境を構築して説明します。

　なお、本稿に記載しているAWSの操作画面は2022年2月時点のものです。

離れたネットワーク間のプライベートな通信

　皆さんは日々インターネットによってWebや動画サービスの閲覧、SNSや通販などさまざまなITサービスを利用されていると思います。最近ではコロナ禍でテレワークの利用が加速しており、会社や取引先のネットワークへのアクセスにインターネットを利用している方が増えていると思います。

　ただしインターネットはオープンなネットワークであり、盗聴や情報流出、データ改ざんなどの危険性があるので、通信内容に個人情報や秘匿すべき情報が含まれる場合、そのまま利用するのは望ましくありません。また特にIPv4ではインターネット通信でNATを利用するので、2つのネットワーク間をつなげるためにいろいろと考慮する必要があります。

　そこで離れたネットワーク間をセキュアかつ容易につなげられるように仮想的な接続を作成する接続技術「Virtual Private Network」（VPN）が開発されており、企業の拠点間の接続や、オンプレミスとAWSをはじめとするクラウド間の接続といった用途に利用されています。セキュリティリスクの観点からクラウドへの接続はVPNの利用が推奨されます。

VPNとは

　VPNの主な目的は、前述の通り離れたネットワーク間をセキュアかつ容易につなげることです。VPNは通信経路によって大きく次の2つに分けられます。

  1. インターネットを通して接続する「インターネットVPN」
  2. キャリアの回線サービスを利用して閉域で接続する「閉域網型VPN」

インターネットVPN

　インターネットVPNは、インターネットを経由して2つの拠点間をセキュアかつ容易につなぐことを目的としており、「暗号化」と「トンネリング」の2つの機能で構成されます。

　暗号化とは、パケットを盗み見られたとしても「どのようなデータか」を読み取れないようにパケットを変換して、「セキュアな通信」を実現する処理です。送信元と宛先の端末間だけで利用できる鍵を生成、交換しておき、送付するパケットを送信元端末で暗号化、宛先端末で復号することで、2端末間でのみ解読可能な通信を可能にします。

　トンネリングとは2ネットワーク間に仮想的なトンネルを作成して、「容易な接続」を実現します。具体的には、あるネットワークからもう一方のネットワークに送りたいパケットを、ネットワーク間の通信パケットでカプセル化し、もう一方のネットワークに送付し、カプセル化を解除してネットワーク内に転送します。これにより、まるで直結されているような通信が可能です。経路の途中でNATが行われていてもうまく通せる仕組みを持っており、NAT環境でも容易に接続できます。

　このような技術で構成されるインターネットVPNはさらに、拠点＝サイトのネットワーク間を仮想的に直結する「サイト間VPN」とネットワークではなく個人PCなどの端末が企業ネットワークなどに直接接続する場合などに利用される「リモートアクセスVPN」に分類されます。

　これらで利用される主な技術として、L3（IP）レベルで対応するIPsec（Security Architecture for Internet Protocol） VPNとL4（TCP/UDP）レベル以上で対応するSSL（Secure Socket Layer） VPNが存在します。サイト間VPNはIPsecで利用することができ、これにより自宅や会社のネットワークとAWSなどのクラウド（IaaS）のネットワーク間をまるで同一LAN内にあるかのようにプライベートに通信させることが可能となります。

　ただし、インターネットVPNのデメリットとして、インターネットを利用することから通信が不確実、不安定（SLAが保証されない）であること、さらに暗号化処理によるオーバーヘッドで通信帯域を出しにくいこと、暗号化機器が必要となることが挙げられます。また通常2拠点間での接続となるので、3拠点以上の接続は設計、構築が難しくなります。

閉域網型VPN

　このデメリットの解決策として、インターネットではなくキャリアによる閉域網を利用して接続するVPNが存在します。それが2つ目の閉域網型VPNです。こちらにすると、セキュリティ保証のために暗号化する必要がなく、契約帯域まで安定した通信が可能です。

　拠点間の通信設計は基本的にキャリアの回線サービスで実現され、利用者はこの回線サービスに接続することで容易に複数拠点を接続できます。

　インターネットと異なり、グローバルIPを利用する必要がないので、そもそもNATは不要で、考慮する必要がありません。この方式の具体的なサービス名称として、L3レベルで接続する「IP-VPN」やL2レベルで接続する「レイヤー2 VPN」が存在しています。これらは主に「MPLS（Multi-Protocol Label Switching）-VPN」という技術で実現されます。

　この方式のデメリットとしては、閉域網を利用する必要があるのでインターネットVPNと比較して高額になること、また回線の敷設、撤去には1カ月〜数カ月単位の時間がかかり、迅速、容易に利用できないことが挙げられます。このため、基本的に個人で利用するものではなく、主に企業のネットワーク間の接続に利用されます。

まとめ：インターネットVPNと閉域網型VPNの違い

　上記の内容を基に2つのVPN方式を比較した結果が下表です。

項目 インターネットVPN 閉域網型VPN
セキュリティ ○ ◎
費用 ○ △
帯域 △〜× ○
安定性 × ○
利用までの時間 ○ ×
接続変更の自由度 ○ ×
多拠点接続 △〜× ○

AWS環境でのVPN接続

　ここからはAWS環境でのVPN接続について解説します。

　VPNにはインターネットVPNと閉域網を利用するVPNが存在することを説明しましたが、「AWS VPN」はプライベートなネットワーク環境であるVPCに対して両VPNでの接続に対応しています（AWSが公開しているマネージドサービスとして対応しています。「Amazon EC2」のインスタンスとしてIPsecなどを利用できるノードをデプロイしてVPNで接続することも可能です）。

　VPNの方式とAWSのサービスの対応は下表の通りです。

VPN方式 AWSサービス名称 接続技術
インターネットVPN サイト間VPN サイト間VPN（Site-to-Site VPN） IPsec VPN
リモートアクセスVPN Client VPN SSL VPN
閉域網型VPN - Direct Connect※ 経路交換にBGP（Border Gateway Protocol：ルーティングプロトコルの一つ）が必須
※厳密には、IP-VPNなどの閉域網によってオンプレミス環境とAWS環境を直接接続することが可能。AWS側でその接続を受け付けるサービスのことを「Direct Connect」という

　なお、閉域網でAWSと接続できるDirect ConnectはVPC（IaaS）に加えて、「Amazon S3」「Amazon DynamoDB」といったAWSのPaaSやSaaSとも直接接続できます。

　以降、本稿ではIPsecによるサイト型VPNでのVPCとの接続について説明します。説明に利用する構成は下図のようになります。

　連載第1回で作成したVPC環境に対してオンプレミスからインターネットVPNで接続するようにしています。環境の作成方法については「Appendix」で後述しているので、ご興味がある方はご参照ください。

　サイト間VPNを構成するに当たり、AWSの機能として新たに次の3つのサービス、設定を利用します。

  1. 仮想プライベートゲートウェイ
  2. カスタマーゲートウェイ
  3. サイト間のVPN接続

　1の「仮想プライベートゲートウェイ」はサイト間VPNを接続するAWS側のVPN接続ノードです。これに対して、2の「カスタマープライベートゲートウェイ」はオンプレミス側のVPN接続ノードです。ただしカスタマーゲートウェイの実体はオンプレミス側の機器であり、カスタマーゲートウェイ本体のグローバルIPアドレスなどの情報を指定するために作成するリソースです。これらを3の「サイト間のVPN接続」でIPsec VPNに必要なパラメーターを指定しつなげる形です。

　これに加えて、インスタンスがオンプレミス端末と通信できるようにルートテーブルの設定と必要に応じて通信許可のためにセキュリティグループの設定が必要です。

　AWS上でのサイト間VPNは下図のVPCのページで設定します（リモートアクセスVPNを設定する場合は「クライアントVPNエンドポイント」を利用します）。

仮想プライベートゲートウェイ

　名前と動的な経路交換を行う場合、設定はBGPで必要となるパラメーターASN（Autonomous System Number）を指定するだけです。なお、リソースとしては1つだけ作成する形ですが、デプロイされるゲートウェイは2つです。ユーザーがゲートウェイ自体の冗長化を意識する必要はありません。この点がマネージドサービスの利点の一つです。

カスタマーゲートウェイ

　名前とオンプレのVPNノードを示すグローバルIP、動的な経路交換を行う場合、BGPのASNなどを設定します。冗長にする場合はオンプレミス側の設計にもよりますが、カスタマーゲートウェイを2つ作成して接続します。また接続するオンプレミス環境が複数存在する場合には、環境ごとにカスタマーゲートウェイを作成します。

サイト間のVPN接続

　上記の2つのゲートウェイを「サイト間のVPN接続」でひも付けます。詳細タブの表示から仮想プライベートゲートウェイとカスタマーゲートウェイがひも付けられていることを確認できます。

　「サイト間のVPN接続」のオプション設定として、動的な経路交換を行わない場合は「静的ルート」としてオンプレミスのセグメントを指定します。

　さらに「サイト間のVPN接続」の設定で暗号化に関するさまざまなパラメーターを指定しますが、その内容を「トンネル詳細」タブで確認できます。

　このページの中ほどにトンネルの状態としてトンネルが2つ記載されていますが、カスタマーゲートウェイから両方のトンネルに接続することによって冗長な接続となり、片側の仮想プライベートゲートウェイに障害があったとしても、もう一方の仮想プライベートゲートウェイで通信を継続できます。

仮想プライベートゲートウェイの先にオンプレミスのサブネットがある

　AWS側のサイト間VPNの設定は以上です。オンプレミス側のVPNの設定が正しければIPsec VPNで接続できます。オンプレミス側のVPNのコンフィグ情報のテンプレートは作成した「サイト間のVPN接続」の設定のダウンロードボタンからダウンロード可能です。

　ただしこの状態では、インスタンスからはルーティングの観点でオンプレミスの場所が分かりません。そこでルートテーブルで「仮想プライベートゲートウェイの先にオンプレミスのサブネットがある」という設定によって通信できるようにしています。この設定は手動でも可能ですが、「ルート伝播」（でんぱ）設定の有効化によって「サイト間のVPN接続」で設定した静的ルートを自動で登録させることができます（必要に応じてセキュリティグループで通信を許可する設定も必要となります）。

設定の確認

　下図はオンプレミスのWindows端末からVPC上のインスタンス「instance01」に対してアクセスした画面のスクリーンショットです。

　Ping、Traceroute、SSHがまるでローカルの端末にアクセスしているように利用できることを確認できます。

　また下図はPingしている状態でVPNノード間のパケットをキャプチャーした結果です。

　通信が暗号化されており、Pingしていることを読み取れない状態となっていることを確認できます。

まとめ

　本稿では、離れたネットワーク間のセキュアな接続方法としてVPNという方式があり、オンプレミスとAWSのVPCの間をインターネットVPNによりセキュアにつなげられることを確認しました。

　次回、第4回はAWSのネットワーク間を接続する方法を説明します。

Appendix

　ここからは本稿の環境の作成手順について、連載第1回で作成した「VPC01」の構成に追加する形で記載します。環境を作って動作を確認したい方は本手順を参考に環境を構築してください。

　本稿で説明している構成は下図の通りです。

　オンプレミス〜クラウド間でプライベートに接続することの確認を目的としているので最小限の設定での構成にしています。IPsec VPNを冗長化せず、暗号化のパラメーターはデフォルト値を利用しています。またオンプレミス〜クラウド間の経路解決はBGPによる動的な経路交換ではなく静的に行わせています。

　連載第1回の構成からのAWS側の変更点は次の通りです。

  1. 「仮想プライベートゲートウェイ」の作成とVPCへのひも付け
  2. 「カスタマーゲートウェイ」の作成
  3. 「サイト間のVPN接続」の作成
  4. 「ルートテーブル」での仮想プライベートゲートウェイへのルート伝播の設定
  5. 「セキュリティグループ」の許可設定

　これに加えて、オンプレミス側としてカスタマーゲートウェイの実体となるIPsec VPNで接続するルーターの設定などを行っています。

「仮想プライベートゲートウェイ」の作成とVPCへのひも付け

　「VPC」のページの「仮想プライベートネットワーク（VPN）」の項の「仮想プライベートゲートウェイ」というメニューから「仮想プライベートゲートウェイの作成」ボタンをクリックします。

　表示される画面で、名前タグに「VirtualPrivateGateway」と入力し「仮想プライベートゲートウェイの作成」ボタンをクリックします。ASNについては、今回は静的に経路を指定するのでデフォルトのままにしています。

　VirtualPrivateGatewayという名前の仮想プライベートゲートウェイを作成できました。状態が「detached」なのは作成した仮想プライベートゲートウェイは特定のVPCにひも付けることで利用するからです。またASNとして「64512」という番号が設定されていますが、作成時にデフォルトのASNを指定したからです。本稿の環境ではBGPは利用しないので、このパラメーターは特に利用しません。

　ここからはVPC01に作成した仮想プライベートゲートウェイをひも付けます。作成したゲートウェイを選択した状態で「アクション」ボタンから「VPCにアタッチ」をクリックします。

　表示される画面でアタッチするVPCとして「VPC01」を選択し、「はい、アタッチします」ボタンをクリックします。

　仮想ネットワークゲートウェイの状態が「attached」になり、VPC01がひも付けられました。なお、作成直後の状態は「attaching」ですが、少し時間を置いた後に画面を更新するとattachedになります。

「カスタマーゲートウェイ」の作成

　「カスタマーゲートウェイ」のメニューから「カスタマーゲートウェイの作成」ボタンをクリックします。

　表示されるページで、名前に「CustomerGateway」、ルーティングに「静的」、IPアドレスにオンプレミス側VPNノードに到達できるグローバルIPアドレスを指定します。「Certificate ARN」にはVPNの接続に証明書を使いたい場合にARN（Amazon Resource Name）を指定し、「Device」にはオンプレミス側の機器情報を指定しますが、今回の環境では特に指定しません。必要なパラメーターの入力後、「カスタマーゲートウェイの作成」ボタンをクリックします。

　CustomerGatewayという名前のカスタマーゲートウェイを作成できました。状態は使用可能となっており、仮想ネットワークゲートウェイで実施したアタッチという操作は不要となります。また指定したグローバルIPアドレスとBGP ASNが表示されています。今回は静的で作っているので、BGP ASNはデフォルトで指定されている値で特に使わないパラメーターです。

「サイト間のVPN接続」の作成

　作成した2つのゲートウェイのひも付けと暗号化パラメーターを指定するためにサイト間のVPN接続を作成します。「サイト間のVPN接続」メニューから「VPN接続の作成」ボタンをクリックします。

　表示される画面でVPN接続のパラメーターを指定しています。まず名前タグは「VPN」、Target Gateway Typeは「Virtual Private Gateway」を指定し、仮想プライベートゲートウェイとして作成していたゲートウェイを選択します。カスタマーゲートウェイは作成済みなので、「既存」を指定し、カスタマーゲートウェイIDとして作成していたゲートウェイを選択します。次に、静的IPプレフィックスにオンプレミス側のセグメントとして「10.0.0.0/8」を指定します。残りのパラメーターはデフォルトのままにします。必要なパラメーターが指定できたら、「VPN接続の作成」ボタンをクリックします。

　「VPN」という名前のVPN接続が作成されました。作成直後は状態が「保留中」となりますが、しばらくすると「使用可能」になります。また下の「詳細」タブから、指定した仮想プライベートゲートウェイとカスタマーゲートウェイがひも付いていることなどを確認できます。

　「トンネル詳細」タブから、トンネルの情報や暗号化パラメーターを確認できます。トンネルが「Tunnel 1」「Tunnel 2」と2つあるのは冗長接続のためで、外部IPアドレスにVPN接続で必要となるAWS側（仮想プライベートゲートウェイ）のグローバルIPアドレス、トンネル上の仮想的な接続に利用するIPアドレスとして「内部 IPv4 CIDR」アドレスが表示されています。これらはオンプレミス側のVPNノードの設定で必要な情報です。トンネルのステータスが「ダウン」ですが、VPN接続をすると「アップ」になります。

　「静的ルート」のタブで指定したIPプレフィックスを確認できます。

　作成したVPN接続のパラメーターに基づいてオンプレミス側のVPNノードを設定する必要がありますが、「設定のダウンロード」ボタンから作成したVPN接続のパラメーターと設定する機器のベンダーなどの情報から各機器に合ったサンプルコンフィグをダウンロードできます。今回オンプレミス側のVPNノードにはCisco Systemsの「CSR1000V」を用いており、下図のように一番近いと考えられる機器を指定してダウンロードします。

「ルートテーブル」での仮想プライベートゲートウェイへのルート伝播の設定

　ここまででサイト間VPNの設定が完了していてオンプレミス側のVPNノードなどの設定が正しければ、オンプレミス環境とVPC間でIPsecによるプライベートな接続が作成されます。ただし、この状態ではまだインスタンスからはオンプレミス機器がどこにいるかが分からず、通信することができません。そこで、インスタンスが属しているサブネットの割り当てているルートテーブルに対してオンプレミス向けの経路を設定するために、ルートテーブルでの仮想プライベートゲートウェイへのルート伝播を設定します。

　設定する前に、オンプレミス側のサブネットとなる「10.0.0.0/8」が、instance01が属するサブネット「Subnet01」のルートテーブル「RouteTable01」に存在しないことを確認します。

　「ルート伝播」タブで既に仮想プライベートゲートウェイが表示されています。これは、このルートテーブルがVPC01にひも付いていて、VPC01にこの仮想プライベートゲートウェイをアタッチしているからです。まだ「伝播」は「いいえ」となっており、ルート伝播されていないことを確認できます。ルート伝播の設定のために「ルート伝播の編集」ボタンをクリックします。

　表示されるページで伝播の「有効化」にチェックを入れ、「保存」ボタンをクリックします。

　ルート伝播が有効になったことを確認できます。

　ただし、まだルートタブでルートを見ても「10.0.0.0/8」は登録されていません。これは、まだVPN接続が有効になっていないからです。

「セキュリティグループ」の許可設定

　AWS側の最後の設定として、インスタンスとオンプレミスの端末間の通信を許可するために、セキュリティグループの許可を設定します。

　今回はinstance01からPing、Traceroute、SSHを実施します。instance01にひも付けているセキュリティグループ「SecurityGroup01」のインバウンドルールとして既にSSHが全てのIPアドレスで許可されているので、「10.0.0.0/8」から「ICMP」（Internet Control Message Protocol）の通信を許可する設定のみを追加しています。アウトバウンドルールは全通信許可なので特に変更していません。

オンプレミス環境の構築

　ここまででAWS側の設定が完了となり、オンプレミス側の環境を構築すれば接続できます。オンプレミス環境の構築方法は割愛しますが、参考としてVPNノードとしてデプロイしているCSR1000Vのコンフィグの一部を次に示します（ダウンロードしたサンプルコンフィグの「IPSec Tunnel #1」の項をベースに作成しました）。

crypto isakmp policy 200
 encryption aes
 authentication pre-share
 group 2
 lifetime 28800
!
crypto keyring keyring-vpn-03ad9d9d15e146168-0  
  local-address xx.xx.xx.xx （VPNノードのインターネット通信向けのインタフェースのIPアドレス）
  pre-shared-key address xx.xx.xx.168 （AWS VPN接続 Tunnel1のグローバルIPアドレス） key xxxxxxxxxxx
!
crypto isakmp profile isakmp-vpn-03ad9d9d15e146168-0
   keyring keyring-vpn-03ad9d9d15e146168-0
   match identity address xx.xx.xx.168 （AWS VPN接続 Tunnel1のグローバルIPアドレス） 255.255.255.255 
   local-address xx.xx.xx.247 （オンプレミス側グローバルIPアドレス）
!
crypto ipsec transform-set ipsec-prop-vpn-03ad9d9d15e146168-0 esp-aes esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile ipsec-vpn-03ad9d9d15e146168-0
 set transform-set ipsec-prop-vpn-03ad9d9d15e146168-0 
 set pfs group2
!
interface Tunnel1
 ip address 169.254.253.130 255.255.255.252 (AWS VPN接続 Tunnel1の内部 IPv4 CIDRアドレス)
 ip tcp adjust-mss 1379
 tunnel source xx.xx.xx.xx （VPNノードのインターネット通信向けのインタフェースのIPアドレス）
 tunnel mode ipsec ipv4
 tunnel destination xx.xx.xx.168 （AWS VPN接続 Tunnel1のグローバルIPアドレス）
 tunnel protection ipsec profile ipsec-vpn-03ad9d9d15e146168-0
 ip virtual-reassembly
!
ip route 192.168.0.0 255.255.255.192 Tunnel1

　上記の設定によってVPNで接続されます。下図のようにVPN接続のTunnel 1のステータスが「アップ」となることから適切に接続されていることを確認できます。

　Tunnel 2が「ダウン」のままなのは今回の構成では冗長接続にしていないからです。

　またVPN接続が有効となったことから、ルートテーブルへのルート伝播によってルートが追加されます。オンプレミス側のセグメントとして指定している「10.0.0.0/8」がルートとしてエントリされていること、ターゲットが仮想プライベートゲートウェイ（VGW）であること、「伝播済み」という項目が「はい」になっていてルート伝播が適切に動作していることを下図から確認できます。

　なお、連載第2回で設定したインターネットゲートウェイへのデフォルトルートもエントリされていますが、連載第1回で説明したロンゲストマッチの規則によって、「10.0.0.0/8」宛ての通信はインターネットではなくオンプレミスにルーティングされることになります。

環境構築結果

　これで今回の環境構築は完了となり、下図の環境を構築できました。

　オンプレミスのWindows端末からVPC上のInstance01にPing、Traceroute、SSH通信可能なことを下図から確認できます。

筆者紹介

東 竜一

ネットワンシステムズ株式会社 ビジネス開発本部 第2応用技術部

大阪大学 大学院 情報科学研究科 出身。2008年 ネットワンシステムズ入社。

学生の頃からネットワークに非常に興味を持ち同社に入社。そこから10年近くCisco Systemsのルーター／スイッチ製品担当として、製品検証、案件支援、技術問い合わせ対応などを精力的に実施。その後、同社のマルチクラウド閉域接続サービス「クラウドHUB」のメイン技術担当としてサービス開発／運用、案件対応を実施中。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る