元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2013/09/28

iPhone5s

iPhone5sを買った


エントリを書くのが遅くなってしまいましたが、9/20、iPhone5sの発売日当日に、幸運にも手に入れることができました。

以前、iPhoneに変えたときに、ドコモポイントを8000ポイント超、損失していることもあって、ドコモおかえり割引はちょっと魅力でしたが、結局ソフトバンクのまま継続することにしました。


今まで世代が変わるごとに買い換えてきましたが、正直、今回のiPhone5sは、iPhone5と比べても、すごく買い換えたくなるモチベーションが、これまで程はわいてこなかったです。

ただ、普段からカメラをかなり使う僕には、カメラまわりの進化は結構魅力的に映る。手ブレ補正の強化とか、フラッシュ性能向上(True Tone)、120フレームのスローモーション撮影、f値が2.4から2.2にあがってより暗いシーンでも使えるようになってきたり、CPUパワーアップによるAFの速さ、写真1枚撮っても、だいたいのシーンにおいて画質はやっぱり上がっているように見えます。

(そんなこんなで、えいやっと勢いで買ってしまいましたが、概ね満足しております。)


iPhone5s

色はスペースグレイ。ソフトバンクの64GBモデルです。


iPhone5 & iPhone5s

今まで使っていたiPhone5と並べたところ。左がiPhone5、右がiPhone5sです。

ホームボタンがクールな雰囲気になりましたね。


iPhone5 & iPhone5s

ちなみに並べるまで全然気付かなかったのですが、裏面と側面のアルミの色味が少し変わっています。

これがブラックとスペースグレイの違いですかね。iPhone5sの方が少し薄い感じです。


iPhone5 & iPhone5s

分かりづらいですが、ストロボたかずに撮ると、こんな色味。

そういえば、裏面の"iPhone"の文字も、iOS7にあわせて細字になってますねー。


iPhone5 & iPhone5s

重ねてみると尚わかりやすいですね。上がiPhone5sです。


過去のiPhone購入エントリ


今日はそれだけ。それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/09/25

6rdプロトコルを使って、IPv6ネットワークとAmazon VPC(EC2)をつないでみた


タイトルの通りですが、IPv6を使っている自ネットワーク環境下から、Amazon VPCにVPN接続し、VPC内のインスタンスとIPv6ネットワーク配下のサーバとを通信(連携)できるようにしてみたログです。


IPv6を使う上での前提条件/要件

まず、今回話をする上での前提となる話ですが、IPv6を使っている自ネットワークの環境は以下のような状態でした。

  • 自ネットワーク内のサーバは、割り振られているIPアドレスがIPv6アドレスonlyのケースと、IPv4/IPv6のデュアルスタックとなっているケースがある。
    • どちらのパターンのサーバであっても、VPC内のインスタンスと通信したい。
  • IPv6のアドレスはGUA(Global Unicast Address: つまりグローバルなアドレス)を割り当てている。
    • 通信するサーバ(VPC内のサーバ)もIPv6のGUAを使った宛先にしたい。

と、こんな感じでございます。


Amazon VPCではインターナルでIPv6のアドレスを割り当てられない

が、AWS公式のFAQにも記載があるとおり、現時点でAmazon VPC内では、インターナルでIPv6のアドレスが割り当てられない仕様があります。

Q: VPC 内では、どのような IP アドレス範囲を使用できますか?

RFC 1918 で定義されたプライベート IP アドレスブロック、またはグローバル IP ブロックなど、任意の IPv4 アドレス範囲から、VPC のアドレス指定を行うことができます。パブリックにルーティング可能な IP ブロックには、仮想プライベートゲートウェイ経由でのみ到達可能であり、インターネットゲートウェイを通してインターネット経由でアクセスすることはできません。AWS 側では、お客様が所有している IP アドレスブロックをインターネット上で公開しません。また、VPC は現在、IPv6 IP アドレス範囲からアドレス指定を行うことはできません。

http://aws.amazon.com/jp/vpc/faqs/#I1

ところで、念のため補足しておきますが、AWSでは、グローバル部分については、ELBがIPv6をサポートしています。

参考: Amazon Web Services ブログ: 【AWS発表】 Elastic Load Balancingが東京リージョンでIPv6をサポート、新メトリクスもサポート、複数のIPアドレスを返すように


で、話は戻って、IPv4/IPv6を共存させるためのソリューションはいくつかあって、

ちょっと古いですが、上記のページとかは「トンネリング」「デュアルスタック」「トランスレータ」などの説明があって、わかりやすい。


さて、どうしようかと、Amazon VPCインターナルでのIPv6利用事例をインターネットで検索するも、めぼしい情報が見当たらなくて、一旦、この件を、AWSのソリューションアーキテクトの方に相談したところ、より運用がシームレスかつ、GUAを柔軟に割り振れる、自動トンネリングパターンの1つである"6rd"がいいのではないかと、ご提案をいただきました。


6rdとは

"6rd"とは、IPv6での通信をIPv4網で転送するための自動トンネル技術の1つです。

6rdに関しては解説サイトがいくつかあるので、そちらを引用させていただきます。

「6rd(IPv6 rapid deployment)」とは、IPv6接続を実現する方式の一つ。IPv4ネットワークの上にIPv6パケットを流すトンネリング技術で、インターネットの標準化組織であるIETFで仕様策定が進んでいる。

ユーザー宅内に設置した6rd対応のネットワーク機器(CPE:Customer Premises Equipment)と、プロバイダーのネットワークに設置した6rd対応リレールーター(6rd Border Relay)の間にトンネルを形成し、IPv6パケットを転送する。エンドユーザー宅内と、アクセス先のサーバーなどが置いてあるネットワークはIPv6 に対応しているが、プロバイダー側にはIPv4ネットワークが残っている環境を想定した技術である(図)。

IPv6 over IPv4トンネリング技術はほかにもあるが、6rdは実装が比較的容易で、コスト負担が小さいといわれる。

具体的に、(1)既存のIPv4ネットワークに大きな変更を加えず、リレールーターを追加するだけでIPv6接続を実現できる、(2)他のトンネル方式に比べてユーザーを収容する際の効率が良い、(3)6rdではIPv4アドレスからIPv6アドレスを生成するため、新たなアドレス配布システムが必要ない、(4)リレールーターはプロバイダーごとに異なるIPv6プレフィックス(アドレスの一部)を配布するため、経路を制御しやすい──というメリットがある。

Networkキーワード - 6rd:ITpro

他、仕組みや勘所を理解するためには、以下のリンクが参考になります。


構成案

さて、以下が今回の構成案です。

f:id:rx7:20130926105606p:image:w400

青い太線IPsecトンネル緑の太線6rdのトンネルです。


今回は、Customer Gatewayに、前回のエントリ同様にCisco 1921シリーズのルーターを使って、AWS側のVPN GatewayとIPsecトンネルをはります。さらにCustomer Gateway自体を、6rdでいうBR(Border Relay)の役割を果たすリレールーターとして使います

その先のAmazon VPC網内もIPv4で構成されたネットワーク環境のため、EC2インスタンスまで6rdプロトコルのトンネルを伸ばすことで、EC2インスタンスのサーバ自身が6rdでいうCE(Customer Edge)となります。こうすることで、EC2インスタンスにIPv6のアドレスを持ったトンネルインターフェースを生成できます。

このため、6rdによるトンネリングは各インスタンス(CE)ごとに張られることになります。


こういった構成を組むことで、サーバ同士がIPv6で会話できるようになります。

6rdを組むパターンでは、CEとしてはルータを配置し、そのBRとCEで6rdトンネルを一本張って運用することが多いようですが、今回のAWS(VPC)を使った構成では各サーバをCEとして、それぞれでトンネリングする形です。(6rdトンネルは、機種によるそうですが、そもそもステートレスなプロトコルなので、かなりのトンネル数を生成しても問題なさそうで、基本的にはトラフィックバウンドとのこと。)


BRの設定(Ciscoルータ)

下記のCiscoのドキュメントを参考に設定しました。


Customer Gatewayとなるルータに、最終的に入れた設定は以下です。

ipv6 unicast-routing
!
interface GigabitEthernet 0/1
  ipv6 address 2xxx:xxxx:xxxx:f013::110/64
end
!
interface loopback 1
  ip address 10.255.255.222 255.255.255.255
end
!
interface Tunnel0
  ipv6 address 2xxx:xxxx:xxxx:f096:0aff:ffde::1/96
  tunnel source loopback 1
  tunnel mode ipv6ip 6rd
  tunnel 6rd prefix 2xxx:xxxx:xxxx:f096::/64
end
!
ipv6 route 2xxx:xxxx:xxxx:F096:AFF:FFDE::/96 Null0
ipv6 route 2xxx:xxxx:xxxx:F096::/64 Tunnel0

上から、簡単に解説すると、

  • IPv6のルーティングを有効に。
  • 自ネットワークにあるルータなので、LAN側にIPv6アドレスを付与。
  • ループバックアドレスを設定。
    • 6rdトンネルのsource用に。今回の構成ではそれほど恩恵は無いが、論理インターフェースを指定。
  • トンネルのインターフェースを指定。
    • 先程設定したループバックアドレスから、IPv6アドレスを付与。(算出方法は後述)
    • ソースアドレスを先程設定したループバックアドレスを指定。
    • VPC側のインスタンスに付与されるIPv6アドレスのプレフィックスを指定。
      • (任意、というか6rdトンネルで利用したい適切なネットワークアドレス帯を指定します)
  • IPv6用のルーティングを設定。

ちなみに、ループバックアドレス(今回の例では、10.255.255.222)を基にして、6rdのアドレスマッピングルールから算出したIPv6アドレスは以下です。

$ printf "2xxx:xxxx:xxxx:f096:%02x%02x:%02x%02x::1" 10 255 255 222
2xxx:xxxx:xxxx:f096:0aff:ffde

IPv4アドレスを16進数表記に変更したものを埋め込んでいます。

"2xxx:xxxx:xxxx:f096"の部分については、先程トンネルのインターフェースで指定した6rdで使うIPv6アドレスのプレフィックスを指定します。


CEの設定(Amazon EC2インスタンス/Amazon Linux)

続いて、CEとなる設定を、Amazon VPC内で起動したEC2インスタンスに入れていきます。

これを入れることで、BRルータと6rdプロトコルを使った通信が可能になります。(IPv6がしゃべれる)


ちなみに、Linuxで6rdプロトコルをしゃべるためには、Kernelのバージョンが2.6.33以降で、"CONFIG_IPV6_SIT_6RD"がyとなっている必要があります。


# uname -r
3.4.43-43.43.amzn1.x86_64
# grep 6RD /boot/config-`uname -r`
CONFIG_IPV6_SIT_6RD=y

今回、使ったAmazon Linuxでは、上記の通りデフォルトで利用できる状態でした。


$ printf "2xxx:xxxx:xxxx:f096:%02x%02x:%02x%02x::1" 10 96 1 100
2xxx:xxxx:xxxx:f096:0a60:0164::1

まずは、先程のBR同様に、IPv6アドレスを算出します。

(今回の例では、このCEとなるEC2インスタンスに紐付くIPv4アドレスは"10.96.1.100"となっています。)


# cat /etc/sysconfig/network-scripts/ifcfg-sit1
DEVICE=sit1
IPV6INIT=yes
IPV6_MTU=1280
IPV6_DEFAULTGW=::10.255.255.222
IPV6TUNNELIPV4=any
IPV6TUNNELIPV4LOCAL=10.96.1.100
IPV6ADDR=2xxx:xxxx:xxxx:f096:0a60:0164::1/96

トンネル用のIPv6インターフェースを"/etc/sysconfig/network-scripts/ifcfg-sit1"に、こんな感じでデバイスを作ります。

このとき、デフォルトゲートウェイを、BRで設定した6rdで使うソースアドレスと一致させておきましょう。

(6rdでは、通信そのものはIPv4で行うため、ゲートウェイの指定はIPv4アドレスです。)


# cat /etc/rc.d/rc.local

〜〜〜省略〜〜〜

ip tunnel 6rd dev sit1 6rd-prefix 2xxx:xxxx:xxxx:f096::/64 6rd-relay_prefix 10.96.1.100/32

"/etc/rc.d/rc.local"では、先ほど定義したトンネルデバイス(sit1)に、6rdで使うプレフィックスの設定を入れます。(ちなみに、Amazon LInuxでは、この設定を入れなくても軽く動作確認する感じでは問題なく動いていました。ひょっとしたら要らないかも。)

6rd-prefixは、先ほどBRで設定したものと同じ、6rdで利用するIPv6のプレフィックスを入れます。

6rd-relay_prefixは、アドレスマッピングルールとして、IPv4アドレスの何ビット分を埋め込むかを指定します。今回の例では、32ビット分全てを埋め込んでいますので、上記のような指定としています。


ここで、一度設定を反映させるために、OSをリブートします。


# ifconfig sit1
sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2xxx:xxxx:xxxx:f096:a60:164:0:1/96 Scope:Global
          inet6 addr: ::10.96.1.100/128 Scope:Compat
          UP RUNNING NOARP  MTU:1280  Metric:1
          RX packets:262 errors:0 dropped:0 overruns:0 frame:0
          TX packets:262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17292 (16.8 KiB)  TX bytes:14672 (14.3 KiB)

# ip tunnel show
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
sit1: ipv6/ip  remote any  local 10.96.1.100  ttl 64  6rd-prefix 2xxx:xxxx:xxxx:f096::/64 6rd-relay_prefix 10.96.1.100/32

# ip -6 route show | grep default
default via ::10.255.255.222 dev sit1  metric 1

起動後に、設定が反映されているか確認します。

ポイントは、トンネルデバイスに意図したIPv6アドレスが振られているか、IPv6のデフォルトルートがBRルータ(今回の例では、BRの論理インターフェース)を向いているか、あたりです。


動作確認

簡易的ではありますが、双方からpingで疎通してみましょう。


from AWS
VPC-Server$ ping6 -c 3 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8
PING 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8(2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8) 56 data bytes
64 bytes from 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8: icmp_seq=1 ttl=62 time=6.17 ms
64 bytes from 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8: icmp_seq=2 ttl=62 time=6.21 ms
64 bytes from 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8: icmp_seq=3 ttl=62 time=6.17 ms

--- 2xxx:xxxx:xxxx:100:5054:1cff:fe93:3ea8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 6.172/6.187/6.213/0.092 ms

from Customer Network
Local-Server$ ping6 -c 3 2xxx:xxxx:xxxx:f096:a60:164:0:1
PING 2xxx:xxxx:xxxx:f096:a60:164:0:1(2xxx:xxxx:xxxx:f096:a60:164:0:1) 56 data bytes
64 bytes from 2xxx:xxxx:xxxx:f096:a60:164:0:1: icmp_seq=1 ttl=62 time=6.31 ms
64 bytes from 2xxx:xxxx:xxxx:f096:a60:164:0:1: icmp_seq=2 ttl=62 time=6.28 ms
64 bytes from 2xxx:xxxx:xxxx:f096:a60:164:0:1: icmp_seq=3 ttl=62 time=6.33 ms

--- 2xxx:xxxx:xxxx:f096:a60:164:0:1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 6.280/6.308/6.334/0.068 ms

この通り、疎通できました。


疎通できなかった場合は、、、

  • IPv4/IPv6ともに、各経路上でルーティングが正しく設定されているか
  • トンネルインターフェースにもきちんとIPv6アドレスが振られているか
  • トンネルのソースアドレスが到達可能なIPv4アドレスになっているか

等々を見直すと良いかもしれません。

基本的には、pingでの動作確認であれば、tcpdumpとかで、どこまでICMPパケットが到達しているかわかるので、各経路1つずつでチェックしていくと何か原因がつかめると思います。


まだ続編があるのですが、ちょっと長くなってしまったので、今回はここまで。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


謝辞

今回の試行を行う上で、さくらインターネットさんとCiscoさんのサイトでの6rdの設定例および解説が大変参考になりました。


また、IPv6 on Amazon VPCをやってみる上で、AWS社のソリューションアーキテクトである荒木氏(@)には、有用なアドバイスを頂きました。

この場を借りてお礼申し上げます。



まとめ


マスタリングTCP/IP IPv6編 第2版

マスタリングTCP/IP IPv6編 第2版

2013/09/19

はじめてのAmazon VPC - 2. 外部インターネットと接続する(NATインスタンスを使う)


前回のエントリ「はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する」の続きです。(今更シリーズ)


Amazon VPCでは、各サブネットでのアクセスコントロールを柔軟に設定できたり、自ネットワークからVPNトンネルをはって接続できるなど、よりセキュアなネットワーク構成を意識できることもあり、VPC内で起動したサーバ(Amazon EC2インスタンス)は、場合によっては外部インターネットに出て行くことが出来ないケースがあります。

しかし、サーバから外部の必要なものをダウンロードしたり、外部リポジトリや外部APIアクセスしたい場合、Amazon S3等のVPC外のAWS各サービスに接続したい場合(パブリックネットワークからしかアクセスできない)などもあるでしょう。


もちろん、そこはVPCでの設定次第となりますので、今回は、前回作成したAmazon VPC網内で起動したEC2インスタンスから、外部インターネットに接続する方法を書いてみます。


おさらい

f:id:rx7:20130909185551p:image

前回のエントリで、VPC内にPublic Subnet(パブリックサブネット)とPrivate Subnet(プライベートサブネット)の2つを作成しました。

外部との通信については、それぞれ以下のようなイメージです。


  • Public Subnetでは、デフォルトゲートウェイが、インターネットゲートウェイとなっている
    • Public IP Addressさえ付与されていてかつ、適切なセキュリティグループが設定されていれば外部インターネットとの通信は可能
    • アウトバウンドもインバウンドもOK
  • Private Subnetでは、基本的に外部インターネットとの通信はできない
    • 外部と通信を行うためには、後述のNATインスタンスを介す必要がある

というわけで、上記のPublic/Private Subnetそれぞれについて、オペレーションを含め、詳しく紹介してみます。


Public Subnetにインスタンスを配置する

まずは、Public SubnetにEC2インスタンスを配置するパターンです。

Public Subnetでは、上述の通り、Public IP Address(グローバルIPアドレス)を付与して、セキュリティグループを適切に設定すれば、In/Out双方とも外部インターネットと通信可能となります。


起動時にPublic IP Addressを割り当てる

前回のエントリと同様に、AWS Management Consoleを使ってみます。

ここでも、EC2のインスタンスの詳しい起動手順については(多くの紹介サイトがあるため)割愛します。


まず、Public Subnetのルーティングテーブルを確認します。

AWS Management Console上部の [Services] - [VPC] から、VPCのダッシュボードを開き、サイドメニューから"Route Tables"をクリックします。


f:id:rx7:20130917190445p:image:w480

Public Subnet用のルーティングテーブルには、上記のようにデフォルトルート(0.0.0.0/0)宛が、インターネットゲートウェイ(igw-xxxxxx)となっていることが確認できます。


次に、EC2インスタンスを起動します。


f:id:rx7:20130917181134p:image:w480

起動するAMIを選んだ後に、上部ウィンドウで、インスタンスを配置するサブネットを選択します。

ここでは、"Public Subnet"として設定しているサブネットを選択しましょう。


f:id:rx7:20130917181135p:image:w480

次のウィンドウでは、ネットワークインターフェースが設定できますが、ここで"Auto-assign Public IP"にチェックを入れましょう。

これで、Public IP Addressが自動で付与されます。


f:id:rx7:20130917181136p:image:w480

適切なセキュリティグループを割り当てます。

(↑は、あまり良い例(名前的に)ではありませんが、ここでは検証ってことで、PiblicSubnetという名前で設定していますw)

あとは、そのままEC2インスタンスを起動してしまえばOKです。


次に、Amazon VPCまわりのネットワークACLを確認します。

AWS Management Consoleの上部 [Services] - [VPC] から、VPCのダッシュボードを開き、サイドメニューから"Network ACLs"をクリックしてください。

デフォルトのままだと、ACLが1つだけあって、下記のようになっているかと思います。


f:id:rx7:20130917181137p:image:w480

デフォルトだと、このようにサブネットのACLレベルでは、全て許可されています。特に問題なければこのまま使うなり、適切に設定したりしましょう。


さて、そろそろ先ほど起動したEC2インスタンスがアクティブ(利用可能)になった頃でしょうか。


f:id:rx7:20130917181139p:image:w480

EC2ダッシュボードで起動したインスタンスを選択し、上記のようにPublic DNS(Public IP Address)が割り振られていればOKです。


f:id:rx7:20130917183222p:image:w480

最後に、先ほどインスタンスに割り当てたセキュリティグループ(今回の例だとPublicSubnet)で、アウトバウンド通信のフィルタ状況(Outbound)を確認します。デフォルトだとこの通り、全てのアウトバウンド通信が通過するようになっているので、この状態であれば、もうインスタンスから外部インターネットへの通信ができる状態になっているはずです。


f:id:rx7:20130917181138p:image:w480

ちなみに、外部インターネットからのインバウンド通信も許可する場合は、セキュリティグループのInboundのところを設定しましょう。

上記例は、TCPの80番ポートのみ、どこからでも(0.0.0.0/0)受け付けるように設定しています。

(10.32.0.0/12, 10.96.0.0/16, 10.48.0.0/19 sourceの設定は、私の内部検証環境にあわせたものなので、気にしないでくださいw)


Elastic IPを割り当てる

あまりないとは思いますが、Public Subnetで既に起動されているインスタンスに対して、あとからPublic IP Addressを割り当てたくなった場合はどうするかというと、Elastic IPを割り当てます。

Elastic IPは、まずEC2のダッシュボードを開き、サイドメニューから "Elastic IPs" をクリックします。


f:id:rx7:20130917184541p:image

まだ1度もElastic IPを取得したことがない場合は、上記のような画面だと思います。

"Allocate New Address"をクリックします。


f:id:rx7:20130917184542p:image

確認ウィンドウが出るので、"Yes, Allocate"をクリック。


f:id:rx7:20130917184543p:image:w480

すると、Elastic IP(このように自由に使える固定グローバルIPアドレス)が自分用に払い出されます。

ここで、払い出されたIPアドレスにチェックが入っている(割り当てたいアドレス)のを確認して、"Associate Address"をクリックします。


f:id:rx7:20130917184544p:image

次に、割り当てたいインスタンスID(もしくは割り当てたいネットワークインターフェース)を指定して、"Yes, Associate"をクリックします。

このタイミングで、指定したインスタンスに、先ほど取得したElastic IPが割り当てられているはずです。


f:id:rx7:20130917181139p:image:w480

これがBeforeで、、、


f:id:rx7:20130917184545p:image:w480

これがAfterです。Public DNSの部分に割り振られていることが確認できますね。

これで、外部との通信が可能な状態になっているはずです。


NATインスタンスを利用する

次に、外部インターネットとの通信ができないPrivate Subnetに配置されているインスタンスを、外部通信させるためには、どうすべきかという話です。


f:id:rx7:20130917191301j:image:w480

引用元: http://www.slideshare.net/AmazonWebServicesJapan/nat-20120719


上記は、AWS公式のプレゼン資料から、引用させていただいた画像ですが、上記のようにPublic SubnetにNATインスタンスと呼ばれる仲介役を配置して、Private Subnetから、インターネットにアクセスしてみたいと思います。


NATインスタンス用のセキュリティグループを作成する

まず、事前にNATインスタンス用のセキュリティグループを設定します。

サイドメニューの"Security Groups"をクリックし、"Create Security Group"をクリックします。


f:id:rx7:20130917191605p:image

ここでは、任意の名前と説明を入れるだけです。入力後、"Yes, Create"をクリック。


そこから作成したセキュリティグループを選択すると、その下部からフィルタの設定ができます。

今回はサンプルとして、Private Subnetから、外部の HTTP/HTTPS 接続できるように設定してみたいと思います。


f:id:rx7:20130917192809p:image

まずは、アウトバウンド。今回の例ではHTTP/HTTPSのプロトコルを通過させたいので、80, 443ポート宛は、すべて許可します。


f:id:rx7:20130917192810p:image

次にインバウンド。VPC内のインスタンスからの80, 443ポート宛を受け付けるようにします。

(あとは、NATインスタンスへのSSH接続用等、適宜追加してください。)


NATインスタンスを起動する

NATインスタンスは、普通のEC2インスタンスですが、AWS公式のAMIがあるので、これを使います。


f:id:rx7:20130917191602p:image:w480

次にNATインスタンスを起動します。

EC2でインスタンスをローンチしようとすると、AMIを選択する画面になりますが、ここでAll imagesを検索対象にして、「ami-vpc-nat」の文字列で検索します。

今時点では、↑の3つが該当しましたが、どれを使っても大丈夫そうです。今回は、一番新しいであろう"amazon/amzn-ami-vpc-nat-pv-2013.03.1.x86_64-ebs"(ami-5f840e5e)を選択してみました。


f:id:rx7:20130917191603p:image:w480

間違えないようにPublic Subnetを選択します。


f:id:rx7:20130917191604p:image:w480

先ほども書きましたが、外部インターネットに接続するためには、Public IP Addressが必要なので、ネットワークインターフェースの設定の部分で、"Auto-assign Public IP"にチェックを入れます。

ちなみに、外部インターネットに接続する際に、Source IPを固定アドレスにしたい場合は、Elastic IPを使いましょう


f:id:rx7:20130917191606p:image:w480

セキュリティグループの選択では、先ほど作成したNATインスタンス用のセキュリティグループを選択します。

こんな感じで、EC2でNATインスタンスを作成します。


NATインスタンス/ルーティングの設定

f:id:rx7:20130917191607p:image

まず、EC2のダッシュボードのインスタンス一覧から、先程、起動したNATインスタンスを選択して右クリック(もしくはActionsボタンをクリック)して、"Change Source/Dest Check"をクリックします。

(これは、発信元/宛先が自分のIPアドレス以外の通信を行うための設定。通常は自分のIPアドレス宛/発信のみ処理。)


f:id:rx7:20130917191608p:image

"Yes, Disable"をクリックします。(発信元/宛先が自分のIPアドレスの通信かのチェックを無効に。)


次にPrivate Subnetのルーティングテーブルを設定すべく、VPCのダッシュボードを開き、サイドメニューの"Route Tables"をクリックして、Private Subnetのルーティング設定を開きます。


f:id:rx7:20130917192808p:image:w480

初期設定では、localネットワークくらいしか入ってなかったと思うので、デフォルトルートを先程作成したNATインスタンスに向けます

具体的には、↑の例のように、"0.0.0.0/0"宛を、NATインスタンスのIDに向けて設定します。

(上記設定で、10.32.0.0/12とかVGWに向いているものは、VPNトンネル用なので気にしないでOKです。)


動作確認

これで、

[EC2インスタンス(Private Sunet)] => [NATインスタンス(Public Subnet)] => [インターネット]

といった通信が可能になったはずなので、Private Subnetに配置されているインスタンスから外部インターネット宛に通信してみてください。


PrivateSubnetInstance$ curl http://calculator.s3.amazonaws.com/calc5.html
<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <META http-equiv="content-type" content="text/html; charset=UTF-8" />
        <script>var VersionDir="calc5_20130917";</script>
        <title>Amazon Web Services Simple Monthly Calculator</title>
        <META NAME="keywords" CONTENT="Calculator, calculate, estimate your costs,EC2,S3, Amazon Web Services, Web services,SimpleDB,SQS,RDS,VPC,CloudFront,AWS Premium Support" />
        <META NAME="description" CONTENT="The AWS Simple Monthly Calculator helps customers and prospects estimate their monthly AWS bill more efficiently. Using this tool, they can add, modify and remove services from their 'bill' and it will recalculate their estimated monthly charges automatically. The calculator also shows common customer samples and their usage, such as Disaster Recovery and Backup or Web Application." />

・・・・・省略・・・・・

例えば、グローバルのAmazon S3へリクエストしてみると、こんな感じでレスポンスが返ってきます。


と、こんな感じでAmazon VPC内のインスタンスから外部インターネットへの疎通ができました。

また長くなってしまったので、今日はこの辺まで。(続きは別のエントリにします。)

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



まとめ


Amazon Web Services クラウドデザインパターン 設計ガイド

Amazon Web Services クラウドデザインパターン 設計ガイド

2013/09/11

はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する


ぼちぼちAmazon VPCを触り始めてみました。

今更な感じもしますが、Amazon VPCのPrivate SubnetにHardware VPN(IPsec VPN)を使って接続できる今時点での詳しい手順を残しておこうと思います。(シリーズ化します。多分。)


Amazon VPCの概要は、下記公式サイトの説明に任せますが、簡単に説明すると、Amazon VPCを使うことで、AWSクラウド内にプライベートネットワークを作成することができるので、従来よりネットワークレベルでの細やかなアクセスコントロールを実現できます。

また、VPN接続をサポートしているので、会社やデータセンターと接続することで、プライベートネットワーク内でAWSのリソースをシームレスに扱うことができるようになります。つまり、自社ネットワークのアドレスをAmazon EC2のインスタンスに振ることができる、みたいなイメージです。


前提となる構成

VPCの初期ウィザードで、一番盛り込んだ、Public/Private Subnetを用意し、Private SubnetにはVPNでつなぐパターンを選択してみました。

f:id:rx7:20130909185551p:image


パターンは他も含めると以下の通りです。

  1. 1つのパブリック サブネットのみを持つ VPC
  2. パブリックとプライベート サブネットを持つ VPC
  3. パブリックとプライベート サブネットおよびハードウェア VPN アクセスを持つ VPC
  4. 1つのプライベート サブネットのみ、およびハードウェア VPN アクセスを持つ VPC
http://aws.amazon.com/jp/vpc/faqs/#G4

ちなみに、VPNをはるために利用したルーターは、Cisco社の1921シリーズです。


使えるルーター(VPN)の要件

Amazon VPCに接続するパターンとして、静的ルーティングを使ったVPN接続と、動的ルーティング(要BGP)を使ったVPN接続があります。

今回は、(大掛かりなものでもないので)静的ルーティングを設定して使うことにします。(以降、静的ルーティングでの設定に絞って書きます。)


その際、こちら側でVPCへ接続するために必要となるルーター(カスタマーゲトウェイ)の要件は以下となるみたいです。

  • Pre-shared キーを使用して、IKE セキュリティ接続を確立する
  • トンネルモードで、IPsec セキュリティ接続を確立する
  • AES 128ビット暗号化機能を利用する
  • SHA-1 ハッシュ機能を利用する
  • 「グループ2」モードで、Diffie-Hellman Perfect Forward Secrecy を利用する
  • 暗号化の前にパケットの断片化を実行する
http://aws.amazon.com/jp/vpc/faqs/#C8

尚、(現時点で)以下のデバイスについては、VPN接続に必要な(カスタマーゲートウェイでの)設定ファイルを、AWS側で自動生成してくれます。

  • Cisco ASA 5500 シリーズバージョン 8.2 以降のソフトウェア
  • Cisco ISR(IOS 12.4 以降のソフトウェアを実行)
  • Juniper J シリーズサービスルーター(JunOS 9.5 以降のソフトウェアを実行)
  • Juniper SRX シリーズサービスゲートウェイ(JunOS 9.5 以降のソフトウェアを実行)
  • ScreenOS 6.1 もしくは 6.2(またはそれ以降)を実行する Juniper SSG
  • ScreenOS 6.1 もしくは 6.2(またはそれ以降)を実行する Juniper ISG
  • Microsoft Windows Server 2008 R2 以降のソフトウェア
  • ヤマハ RTX1200 ルーター
http://aws.amazon.com/jp/vpc/faqs/#C9

VPCの作成

では、早速VPCを作成してみましょう。

GUIで簡単にオペレーションするべく、まずはAWS Management Consoleにアクセス(ログイン)して、サービス一覧のところから"VPC"を選択します。

リージョンについては、接続したい(VPCを作成したい)リージョンを選んでおいてください。


f:id:rx7:20130909185552p:image:w480

まず、最初の段階では、全くVPCの設定がされていないはずですので、↑のようなウィザードへ誘導される感じになっています。"Get started creating a VPC"をクリックしましょう。


f:id:rx7:20130909185553p:image:w480

次に、構成パターンとして4通りの内、1つだけ選びます。先ほども書きましたが、以下の4つです。

  1. 1つのパブリック サブネットのみを持つ VPC
  2. パブリックとプライベート サブネットを持つ VPC
  3. パブリックとプライベート サブネットおよびハードウェア VPN アクセスを持つ VPC
  4. 1つのプライベート サブネットのみ、およびハードウェア VPN アクセスを持つ VPC
http://aws.amazon.com/jp/vpc/faqs/#G4

今回は、3つ目のPublic/Private Subnetの両方を作成し、Private SubnetにはVPNでつなぐパターンを選択してみました。


f:id:rx7:20130909185554p:image:w480

さて、ここからはネットワークの設定です。

1つ目は、カスタマーゲートウェイとなる、VPNトンネルを掘るルーターのIPアドレスを入力します。

2つ目、今回は静的ルーティングでの接続なので、"Use static routing"を選択し、下部のテキストボックスには、VPC側から、自ネットワーク側へのルーティングを記載します。つまり、自ネットワークから、AWSのVPC網にアクセスさせたいサーバ等のネットワークセグメントであったり、AWSのVPC網内のサーバ(EC2インスタンス)からアクセスさせたい先(自ネットワークのセグメント)のネットワークを記載します。

ここは、ネットワークアドレス/サブネットマスクを入力して、"Add"をクリックすることで複数追加できます。

全て入力できたら、"Continue"をクリックしましょう。


f:id:rx7:20130909185555p:image:w480

この部分は必要があれば、編集しましょう。

"One VPC with an Internet Gateway"の部分は、VPC側で付与したいネットワークのセグメントを指定します。特にこだわりがない(既存の自ネットワークで使っていない)のであれば、デフォルトのままでもいいと思います。

"Two Subnets"のところでは、VPCネットワーク内で分割すべきサブネットの指定をします。この辺もアクセスコントロールしたい単位とかで、適宜ネットワークを区切りましょう。また、各サブネットをどのAvailability Zoneに配置するかを指定できます。

"One VPN Connection"のところは、先ほどの画面で設定したものが入っているはず。

"Hardware Tenancy"は、VPC網内で動く、Amazon EC2インスタンスでDedicated Instance(ハードウェア占有インスタンス)を利用するかどうかの選択となります。


全て確認(編集)した後、"Create VPC"をクリックします。


f:id:rx7:20130909185556p:image:w480

VPC作成中のダイアログが出ます。しばし待つ。


f:id:rx7:20130909185557p:image:w480

無事、VPCが作成されました。ここで"Download Configuration"をクリックすると、カスタマーゲートウェイのデバイスにあわせた設定ファイルがダウンロードできます。(ので、クリックします。)


f:id:rx7:20130909185558p:image

すると、↑のようなウィンドウが出るので、デバイスのベンダー、機種(シリーズ)、ソフトウェア(OS)等を選択して、"Yes, Download"をクリックすると、設定ファイルがダウンロードできます。


VPNルーターに設定を投入

VPCを作成したら、次はカスタマーゲトウェイとなるルーターに、先ほどダウンロードした設定を投入していきます。

カスタマーゲートウェイからは、AWS側のゲートウェイに2本分のIPsecトンネルをはることになります。トンネル1本分の設定としては、サンプルではありますが実際には、(ちょっと長いですが)以下のようなテンプレートになっています。(Cisco IOS向け、若干マスキングしています)


crypto isakmp policy 200
  encryption aes 128
  authentication pre-share
  group 2
  lifetime 28800
  hash sha
exit
!
crypto keyring keyring-vpn-xxxxxxxx-x
  local-address xxx.xxx.xxx.xxx
  pre-shared-key address 27.0.1.xx key xyzxyzxyzxyzxyzxyzxyzxyzxyzxyzxy
exit
!
crypto isakmp profile isakmp-vpn-xxxxxxxx-x
  local-address xxx.xxx.xxx.xxx
  match identity address 27.0.1.xx
  keyring keyring-vpn-xxxxxxxx-x
exit
!
crypto ipsec transform-set ipsec-prop-vpn-xxxxxxxx-x esp-aes 128 esp-sha-hmac 
  mode tunnel
exit
!
crypto ipsec profile ipsec-vpn-xxxxxxxx-x
  set pfs group2
  set security-association lifetime seconds 3600
  set transform-set ipsec-prop-vpn-xxxxxxxx-x
exit
!
crypto ipsec df-bit clear
!
crypto isakmp keepalive 10 10 on-demand
!
crypto ipsec security-association replay window-size 128
!
crypto ipsec fragmentation before-encryption
!
interface Tunnel1
  ip address 169.254.252.2 255.255.255.252
  ip virtual-reassembly
  tunnel source xxx.xxx.xxx.xxx
  tunnel destination 27.0.1.xx 
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile ipsec-vpn-xxxxxxxx-x
  ip tcp adjust-mss 1387 
  no shutdown
exit
!
ip route 10.96.0.0 255.255.0.0 Tunnel1 track 100
!
ip sla 100
   icmp-echo 169.254.252.1 source-interface Tunnel1
   timeout 1000
   frequency 5
exit
!
ip sla schedule 100  life forever start-time now
!
track 100 ip sla 100 reachability 

AWS Management Consoleからダウンロードした設定ファイルには、IPsecトンネル2本分の設定が入っている(上記サンプルは1本分)ので、2本分設定しちゃいます。

(AWS側のゲートウェイに疎通できるよう、自ネットワーク構成に応じてルーティングの設定は確認してください。)


#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src                state          conn-id status
27.0.1.xx       xxx.xxx.xxx.xxx    QM_IDLE           1001 ACTIVE
27.0.1.yy       xxx.xxx.xxx.xxx    QM_IDLE           1002 ACTIVE

"show crypto isakmp sa"コマンドを実行して、問題なく設定されれば、まず上記のようにISAKMP(鍵交換)のステータスが正常になっているかと思います。今回の例だとstateがQM_IDLE、statusがACTIVEになっていればOKです。


#show crypto ipsec sa 

interface: Tunnel1

〜〜〜〜〜省略〜〜〜〜〜

     inbound esp sas:
      spi: 0x2F74367A(796145274)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2687, flow_id: Onboard VPN:687, sibling_flags 80000040, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4281963/1734)
        IV size: 16 bytes
        replay detection support: Y  replay window size: 128
        Status: ACTIVE(ACTIVE)

〜〜〜〜〜省略〜〜〜〜〜

     outbound esp sas:
      spi: 0xE7B8E672(3887654514)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2688, flow_id: Onboard VPN:688, sibling_flags 80000040, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4281963/1734)
        IV size: 16 bytes
        replay detection support: Y  replay window size: 128
        Status: ACTIVE(ACTIVE)

〜〜〜〜〜省略〜〜〜〜〜

次に"show crypto ipsec sa"コマンドを実行し、IPsecトンネルの状態を確認します。

上記のようにinbound/outbound esp sasの部分に何かしらステータスが表示されていれば、IPsecトンネルが確立されていることになります。


f:id:rx7:20130911155618p:image:w480

AWS Management Consoleの[Amazon VPC] - [VPN Connections]でも上図のようにVPNの接続状況が確認できます。


サーバから疎通確認

さて、トンネルが確立されたところで、自ネットワークのサーバとAWS側のサーバ(EC2)の疎通確認をしてみます。

まず、Amazon EC2のインスタンスを起動してみます。インスタンスの起動方法については、多くの解説サイトが存在するので、詳しくは割愛しますが、インスタンス起動の際に、VPCまわりが関連する部分の設定は以下の通り。


f:id:rx7:20130911180433p:image:w480

EC2インスタンス起動時に、そのインスタンスをVPCのどのサブネットに所属させるかを選択します。(割り当て可能な残りIPアドレス数とかも表示されていますね。)


f:id:rx7:20130911180434p:image:w480

一番下部にネットワークインターフェースの設定をする部分があります。

インターフェースの数や、割り振るIPアドレスの指定(デフォルトでは自動で割り振り)、Public IPを振るかどうかや、エイリアスの指定など。

と、主なところは、こんなところでしょうか。

EC2インスタンスが起動したら、自ネットワーク内のサーバからアクセスしてみましょう。正しく設定されていたら、通信できるはずです。


うまく疎通できない場合

以下のルーティングまわりとかを確認してみるといいかも。

  • 自ネットワークから、VPC(およびそのサブネット)のネットワークセグメントへの通信
  • VPCのネットワークから、自ネットワークセグメントへの通信
    • VPNゲートウェイ(VPN ConnectionsのStatic Routesで設定)
    • VPCのサブネット(Route Tablesで設定)

あとは、ベタに、Network ACLやSecurity Groupsでフィルタされていないかを確認する、あたりでしょうか。


ちょっと長くなったので、今日はこの辺まで。(続きは別のエントリにします。)

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい

AWS公式のプレゼン資料が、概略を掴む資料としてはわかりやすくてオススメでございます。



追記

続きを書きました。



まとめ


Cisco ISR ルータ教科書

Cisco ISR ルータ教科書


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)