■ Amazon VPCとEC2を接続
前編ではVPCを作成しました。これで自分だけのプライベートネットワーク空間が作成された事になります。しかし、その中でサーバを動作させない事には何の意味もありません。それではEC2インスタンスを起動させてみましょう。
まず、VPCダッシュボードの画面から今度は右側の「EC2インスタンスの作成」を押します。
色々とマシンイメージが並んでいます。これはOSのテンプレートで選択する事により、OSのインストール行為をしなくてもAWSに最適化されたOSが起動します。とても良い時代になりましたね。
今回は無料枠の「Microsoft Windows Server 2016 Base - ami-157fe573」を「選択」します。
同様に分かりやすく「無料利用の対象」と教えてくれるのでこのOSを選択し、画面一番下の「次の手順: インスタンスの詳細の設定」をクリックします。
【ステップ 3: インスタンスの詳細の設定】画面に移ります。
ここで大切なのは、【ネットワーク】と【サブネット】です。これを先程作成した、「vpc-09cb696e | kamuikotan (任意)」と「subnet-c1a3e388|ciset01|ap-northeast-1a(任意)」を選択します。【自動割り当てパブリック IP】は「無効化」しておいてください。後はデフォルトのままで大丈夫です。
入力が完了したら画面一番下の「確認と作成」をクリックします。
(ストレージの追加等は今回必要無いので割愛します)
【ステップ 7: インスタンス作成の確認】まで飛びました。
このままだとリモートデスクトップのみがポート開放されている状態です。他のポート開放が行われていないので、このまま他のポート開放の設定もしてしまいましょう。特にICMP(pingの応答)は開放しておきたいです。画面上部の「6. セキュリティグループの設定」をクリックしてください。
【セキュリティグループの割り当て:】は「新しいセキュリティグループを作成する」のままにしてください。
デフォルト設定で、リモートデスクトップだけは開いています。例えば、WEBサーバを公開したいと思ったら、「ルールの追加」をクリックして、【タイプ】の項目から「HTTP」を選択します。これでポート80番が開放されます。ソースはソース元IP制限です。現時点だとリモートデスクトップは全世界からアクセス可能状態なので、必要に応じてIP指定してください。ICMPも同様です。
一通り設定が完了したら、画面一番下の「確認と作成」をクリックします。
【ステップ 7: インスタンス作成の確認】に戻ってきました。
【セキュリティグループ】に先程追加した項目が増えていると思います。
一通り確認して問題が無ければ、画面一番下の「作成」をクリックします。
【既存のキーペアを選択するか、新しいキーペア作成します】という表示が出ます。EC2インスタンスの設定なので割愛しますが、既存のキーペアがある場合はそちらを使ってください。判らなければ、「新しいキーペアの作成」を選択して【キーペア名】を任意で付けたら「キーペアをダウンロード」を押して保存します。
これはEC2インスタンスへのログインに必要なので、絶対になくさないように注意しましょう。ちなみにFirefox58では、何故かボタンが押せませんでした。
全てが完了したら「インスタンスの作成」を押しましょう。
EC2が作成されました。
構築にはしばらく時間が掛かりますので、気長に待ちましょう。
【ステータスチェック】が【初期化しています】から【2/2のチェックに合格しました】と変われば、OSが起動しています。
早速接続してみましょう。接続の仕方は先程ダウンロードした pem ファイルがパスワード複合用となっているので、コピペするだけです。この辺りはEC2インスタンスの詳しい解説サイトを見てください。これでVPCと同一ネットワークに入れさえすれば、リモートデスクトップで接続できるようになります。
【説明】の欄で確認すると、【パブリック DNS (IPv4)】と【IPv4 パブリック IP】が割当されておらず、グローバル経由では接続できない様になっています。
■ Amazon VPCとVPN接続する (例:RTX1200)
それでは最後に、Amazon VPCに対してVPN接続します。
もう一度VPCの設定画面に戻ってください。
画面左に「仮想プライベートゲートウェイ」という項目があるのでクリックし、画面上部の「仮想プライベートゲートウェイの作成」というボタンを押します。
【名前タグ】は任意で構いません。
【ASN】は「Amazon のデフォルト ASN」のままで大丈夫です。
完了したら、「仮想プライベートゲートウェイの作成」のボタンを押しましょう。【仮想プライベートゲートウェイの作成に成功しました】と表示されるはずです。これを閉じると、仮想プライベートゲートウェイの一覧が出てきますので、作成したゲートウエイを右クリックします。
「VPCにアタッチ」という項目をクリック。これでVPCと仮想プライベートゲートウエイを繋げて外部への接続口を作成します。
ちゃんと先ほど作成した VPC が表示されますので、そらちを選択して「はい、アタッチする」を押してアタッチします。
【状態】が detach から attaching に変わり、VPCと接続された事が確認できます。
そうしたら、もう一度「VPCダッシュボード」に戻ってください。左下の方に「VPN接続」というリンクがあるので、これをクリックします。
下の方に「VPN接続の作成」というボタンがあるので、これをクリックします。
【名前タグ】は任意で入力してください。
【仮想プライベートゲートウェイ】は先程作成したゲートウェイを選択します。
【カスタマーゲートウェイ】は「新規」を選択します。
【IPアドレス】は自分のルーターに付与されているグローバルIPを記載します。
【BGP ASN】はそのまま「65000」とします。
【ルーティングオプション】は「動的(BGPが必要)」を選択します。
後は全て空欄で構いません。
最後に「VPN接続の作成」をクリックすれば、VPN接続が作成されます。
左メニューの一番下「VPN」をクリックします。
VPN接続が作成されて【保留中】になっています。これは対向ルーターから接続されていない為です。VPCの受け側の作成はできたので、今度は自分の方のルーターに設定を入れます。画面上部に「設定のダウンロード」というボタンがあるので、そちらをクリックします。
ありとあらゆるベンダーのルーターの設定がダウンロードできます。これは先程作成したVPNに対して接続する為の物なので、基本的には何も弄る必要がありません。今回はYAMAHA RTX1200に導入するので、そちらを選択して「ダウンロード」を押します。設定はテキストファイルでダウンロード可能です。
これをルーターに流し込むだけ…なのですが、注意が必要です。先程、基本的には何も弄る必要がありませんと言ったので矛盾していますが、これはあくまで既存ルーターにVPN設定が無い場合を想定した設定です。既にルーター側で tunnel を作成している場合、そのまま流し込むと設定が上書きされてしまいます。あくまでこのダウンロードしたファイルは何の設定も無い所に流し込む用に作られているので、そこは環境に合わせてカスタマイズする必要があります。
自分の環境で設定を流し込み接続を確認しました。(tunnel 5,6)
show ipsec sa
sa sgw connection dir life[s] remote-id
4 5 isakmp - 27539 13.114.40.64
5 5 tun[005]esp send 2341 13.114.40.64
6 5 tun[005]esp recv 2341 13.114.40.64
7 6 isakmp - 27542 52.199.238.189
8 6 tun[006]esp send 2344 52.199.238.189
9 6 tun[006]esp recv 2344 52.199.238.189
AWS VPC VPN側の表示が【使用可能】になりました。下の画面でもステータスが「アップ」となってVPN接続されている事が確認できます。これで自分のルーターとAmazon VPCがBGPによるVPN接続されました。
■ VPN経由でEC2を操作してみる
EC2インスタンスでダウンロードした、rdpファイルとパスワードで
リモートデスクトップをしてみます。
無事に接続できました。
この状態では、EC2インスタンスは外部へ接続できません。勿論そのように設計したので当然です。理由は、EC2インスタンスのデフォルトゲートウェイがVPCのゲートウェイのIP(10.0.1.1) になっているからです。10.0.1.1 に投げられたデータは、VPNを通ってこちらのルーターに届きます。
しかしこちらのルーターにNAT設定が無い為、外部に出る事はできない訳です。例えば、RDPのコマンドプロンプトを開いて外部にpingを打ってみます。(ちなみに名前解決はVPC内部の 10.0.0.2 でやっている様です。)
ちゃんと接続できない事が確認できました。もし、このEC2インスタンスを一時的に外部へ接続したい場合には、RTXルーターにNATディスクリプターを設定する必要があります。
(RTX1200設定例)
nat descriptor type 2 masquerade
nat descriptor address outer 2 ルーターのグローバルIP
nat descriptor address inner 2 10.0.1.1-10.0.1.254
nat descriptor masquerade incoming 2 through
これで 10.0.1.0/24 はIPマスカレードにより外部と通信する事が可能です。
ちゃんと外部に出れるようになりました。
■ まとめ
昨今、流出事件は後を絶ちません。例えばメールに添付されていたデータを何気無く開いただけで感染し、ネットワーク内部のデータが全て暗号化される、といったマルウェアも存在します。
全てのデータがインターネットに接続されている必要性はございません。例えば、会計ソフトはプライベートクラウド上のWindowsにインストールし、データは全てそこで管理する。インターネットへ接続できないので流出する危険性は極めて低く、ルーターの設定で、そのプライベートクラウドに接続できるパソコンを限定してしまえば更に安全性は高まるでしょう。
ゲームの開発もVPSでやっているという話をよく聞きます。これも結局、何かの拍子に不正アクセスされてしまったら……こういう時にプライベートクラウドが役立ちます。インスタンスはいくらで増やせるので、開発に応じたスケーラビリティの確保が可能です。
唯一の欠点は、VPC経由の通信は通信料がそれなりに掛かる為、大容量のデータの移動には向きません。
1時間当たり5円程、そして転送量が1GBあたり1円掛かります。ここはコストとデータの重要性とのトレードオフかと思います。
但し、クラウド上にデータを置けば全て安全かというとそうではありません。昔、ファーストサーバ事件という前代未聞の大消失事件が発生致しました。クラウド上に置いてあったデータが、バックアップも含めて全て消えてしまったのです。当時の事は鮮明に覚えていて、特に影響を受けたのがサイボウズというグループウエアソフトでした。かなりの顧客が、このサイボウズのクラウドサービスを利用していたそうです。スケジュールから顧客情報も全て、このサイボウズで管理していたらしく、データが消失した瞬間に今まで積み上げてきたものが全て無くなったと聞いています。
流出を防ぐ為のプライベートネットワーク、そしてそれをまた別のサービスでバックアップを取る、
例えば、AWS S3 や Amazon Glacier というサービスがあります。
それらをうまく組み合わせて、重要なデータを守りつつコストダウンを量るのはいかがでしょうか？