電子の密林を開拓する

AWS EC2 で AmazonLinux を OS として起動し、その上で Java アプリケーションを動作させ、ローカルPCから リモートデバッグをしようとしたのですが…。
ローカルPCからデバッグ用のポートを接続するために ssh の port forwarding を利用したところ、ウマク接続できませんでした。

1時間ほど悩んで、/etc/ssh/sshd_config に port forwarding の設定が無いのではないか…と思い付き、確認してみるとビンゴでした…。

以下のようになれば正解らしいです。
$ sudo cat /etc/ssh/sshd_config  \
     | fgrep -i AllowAgentForwarding

AllowAgentForwarding yes
設定したら、以下のように反映させます。
$ sudo /etc/init.d/sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
ローカルPCから ssh port forwarding を有効にして ssh 接続するには、以下のようにします。
$ ssh -L 9999:localhost:9999 -l ec2-user  ~.amazonaws.com
この例では ローカルPC の ポート9999 を ssh 接続先サーバから見て localhost:9999 へ接続(port forwarding)します。ウマク設定出来ている場合、ローカルPC側のnetstat で以下のようになるはずです。この例は windows7のcygwin で実行しています。
$ netstat -avn | grep ':9999'
  TCP    127.0.0.1:9999         0.0.0.0:0              LISTENING
  TCP    [::1]:9999             [::]:0                 LISTENING
上側が IPv4 で、下側が IPv6ですね…。

これで、ローカルPCの 9999 が、ssh 接続先の localhost:9999 と同じように利用できます。


なぜ AmazonLinux では ssh portforwarding がデフォルトでOFFなのか分かりませんが…。コレって sshd の標準設定なんでしたっけ???

AWS とはあんまり関係ありませんが、参考まで…。



前回の「AWSでVPCを作る」の続きです。
今回は、作成した VPC 環境を破棄する、後片付けの手順になります。


・消去の順番
消去/破棄する順番に特に意味があるわけではありませんが…。
ルーティングやgateway を破棄してしまうと、VPC内部にアクセスできなくなってしまいます。
そのため、先に、VPC内のインスタンスを破棄し、その後、ルーティングテーブル、Gateway、EIP、VPC…と破棄していくことにします。
インスタンスの shutdown 時に、他のサーバと通信してデータを保存する…とかあったら困るので。



・EC2の破棄
特に何も言うことは無く、EC2インスタンスを shutdown して terminate させます。
# インスタンスをSTOPさせる
$ ec2-stop-instances  i-f3e1f0f0
INSTANCE        i-f3e1f0f0      running stopping

# TerminationProtection を無効にする
$ ec2-modify-instance-attribute \
     i-f3e1f0f0 \
     --disable-api-termination false

disableApiTermination   i-f3e1f0f0      false

# インスタンスをTERMINATEさせる
$ ec2-terminate-instances i-f3e1f0f0
INSTANCE        i-f3e1f0f0      stopped terminated

# インスタンスの状態を確認
$ ec2-describe-instances i-f3e1f0f0
RESERVATION     r-e95723ea      488224276535
INSTANCE        i-f3e1f0f0      ami-20ad1221                    terminated      innerkey        0               t1.micro        2013-03-14T09:13:51+0000 ap-northeast-1a aki-ec5df7ed                    monitoring-disabled                                     ebs                                      paravirtual     xen                     default false


・ルーティングテーブルの破棄
# ルーティングテーブル一覧確認
$ ec2-describe-route-tables
ROUTETABLE      rtb-eac9f783    vpc-e8c9f781
ROUTE   local           active  192.168.1.0/24          CreateRouteTable
ROUTE   igw-7b350c12            active  0.0.0.0/0               CreateRoute
ASSOCIATION     rtbassoc-edc9f784       main

# 0.0.0.0/0 に対するルーティングを削除
$ ec2-delete-route \
     rtb-eac9f783 \
     --cidr 0.0.0.0/0

RETURN  true

# 削除結果の確認
$ ec2-describe-route-tables
ROUTETABLE      rtb-eac9f783    vpc-e8c9f781
ROUTE   local           active  192.168.1.0/24          CreateRouteTable
ASSOCIATION     rtbassoc-edc9f784       main

# ルーティングテーブル自体を削除してみるが…
$ ec2-delete-route-table rtb-eac9f783
Client.DependencyViolation: The routeTable 'rtb-eac9f783' has dependencies and cannot be deleted
どうやら、main として VPC に割り当てられているルーティングテーブルは削除できないようですね…。
割り当てを解除してみましょう。
$ ec2-disassociate-route-table rtbassoc-edc9f784
Client.InvalidParameterValue: cannot disassociate the main route table association rtbassoc-edc9f784
むーん。main として割り当てられているルーティングテーブルは、割り当て解除できないようですね…。これは無視しておきましょう。



・Gateway の削除
# Gateway の確認
$ ec2-describe-internet-gateways
INTERNETGATEWAY igw-7b350c12
ATTACHMENT      vpc-e8c9f781    available

# Gateway と VPC の紐づけ解除
$ ec2-detach-internet-gateway \
     igw-7b350c12 \
     --vpc vpc-e8c9f781

RETURN  true

# Gateway の削除
$ ec2-delete-internet-gateway igw-7b350c12
RETURN  true

# 削除結果確認
$ ec2-describe-internet-gateways igw-7b350c12
Client.InvalidInternetGatewayID.NotFound: The internetGateway ID 'igw-7b350c12' does not
EIPが設定されたままなのに、削除できてしまいましたね…。
恐らく、既に EIPと紐づいていたはずの EC2インスタンスが削除されてしまったので、既にGateway と EIP の紐づけが解除されているのでしょう…。



・EIPの削除
EIPの状態を確認してみます。
$ ec2-describe-addresses
ADDRESS 54.249.84.161           vpc     eipalloc-f728119e
既に gateway や EC2 との紐づけは解除されているので、削除(解放)するだけですね…。
$ ec2-release-address \
     --allocation-id eipalloc-f728119e

ADDRESS                         eipalloc-f728119e

$ ec2-describe-addresses
EIPを削除(解放)できました。



・VPCの削除
まずは、VPC内部のサブネットを破棄します。
# VPC確認
$ ec2-describe-vpcs
VPC     vpc-e8c9f781    available       192.168.1.0/24  dopt-ecc9f785   default

# サブネット確認
$ ec2-describe-subnets
SUBNET  subnet-f0c3fd99 available       vpc-e8c9f781    192.168.1.0/24  251     ap-northeast-1a

# サブネットの削除
$ ec2-delete-subnet subnet-f0c3fd99
SUBNET  subnet-f0c3fd99

# サブネット確認
$ ec2-describe-subnets subnet-f0c3fd99
Client.InvalidSubnetID.NotFound: The subnet ID 'subnet-f0c3fd99' does not exist
最後はエラーになっていますが、削除したものを確認しようとしているので 期待通りのエラー内容になります。


次に VPC 自体を破棄しますが……
$ ec2-delete-vpc  vpc-e8c9f781
Client.DependencyViolation: The vpc 'vpc-e8c9f781' has dependencies and cannot be deleted.
VPCが、何かと依存関係にあって削除できないようですね。何でしょうか???


あああー。VPC専用のセキュリティグループを作成した記憶がありますね…。
$ ec2-describe-group --filter 'group-name=vpc_web'
GROUP   sg-1d1e0071     488224276535    vpc_web web in VPC      vpc-e8c9f781
PERMISSION      488224276535    vpc_web ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0       ingress
PERMISSION      488224276535    vpc_web ALLOWS  tcp     80      80      FROM    CIDR    0.0.0.0/0       ingress
PERMISSION      488224276535    vpc_web ALLOWS  all                     TO      CIDR    0.0.0.0/0       egress
たしかに残っています。これを削除してみましょう。
$ ec2-delete-group vpc_web
Client.InvalidParameterValue: Invalid value 'vpc_web' for groupName. You may not reference Amazon VPC security groups by name. Please use the corresponding id for this operation.

$ ec2-delete-group sg-1d1e0071
RETURN  true
名前指定では削除できなくて、自動付与された識別子でしか指定できないのはメンドクサイですが、一応セキュリティグループは消去できました。
では、VPC自体を削除してみましょう。
$ ec2-delete-vpc  vpc-e8c9f781
VPC     vpc-e8c9f781

$ ec2-describe-vpcs vpc-e8c9f781
Client.InvalidVpcID.NotFound: The vpc ID 'vpc-e8c9f781' does not exist
バッチリ消えましたね。


・最後の確認
念のため、AWS Management Console でインスタンスなどの状態を確認しておきましょう。
削除しないまま放置していると、無駄に課金されてしまうので…。



・まとめ
VPCを破棄する場合、以下の順序で処理する。
  1. EC2等のインスタンス
  2. ルーティングテーブル
  3. Gateway
  4. EIP
  5. セキュリティグループ
  6. VPC
RDSなども利用しているのであれば、(サーバー上のコンテンツプログラムの)依存関係に応じてインスタンスを破棄していく必要があります。



今回はここまで…。















今回はCLIでVPC(http://aws.amazon.com/jp/vpc/)を作ってみます。


まず、予習として以下のURLの説明(スライド)をじっくり読みます…。
http://www.slideshare.net/kentamagawa/vpc-aws7
眠くなるのを我慢して丁寧に読むと、なんとなくVPCの概念が理解できる気がしてきました(^^;

とりあえず今回作りたいのは、スライドの説明だと「VPC + Public Subnet」という構成らしいです。



・コマンドを探す
AmazonLinux の /opt/aws/bin/ で ls *vpc* と実行して、VPC関連コマンドを探します。
$ ls -1 /opt/aws/bin/*vpc*
/opt/aws/bin/ec2addvpc
/opt/aws/bin/ec2-create-vpc
/opt/aws/bin/ec2-delete-vpc
/opt/aws/bin/ec2delvpc
/opt/aws/bin/ec2-describe-vpcs
/opt/aws/bin/ec2dvpc
名前からして、ec2-create-vpc、ec2-delete-vpc、ec2-describe-vpcs が、それぞれ VPC作成、VPC破棄、VPC詳細表示…だと思われます。

EC2インスタンスを起動するための ec2-run-instances コマンドヘルプを読むと、VPC内にインスタンスを起動するには SUBNET_ID が必要とのことです。つまり、VPCだけでなく、その内部に作成されたサブネットが必要ということでしょう。
ec2-run-insnstances --help からの抜粋

-s, --subnet SUBNET
     The ID of the Amazon VPC subnet in which to launch the instance(s
Subnet 関連の設定コマンドを探してみます。
$ ls -1 /opt/aws/bin/*subnet*
/opt/aws/bin/ec2addsubnet
/opt/aws/bin/ec2-create-subnet
/opt/aws/bin/ec2-delete-subnet

/opt/aws/bin/ec2delsubnet
/opt/aws/bin/ec2-describe-subnets
/opt/aws/bin/ec2dsubnet
/opt/aws/bin/elb-attach-lb-to-subnets
/opt/aws/bin/elb-detach-lb-from-subnets
/opt/aws/bin/rds-create-db-subnet-group
/opt/aws/bin/rds-delete-db-subnet-group
/opt/aws/bin/rds-describe-db-subnet-groups
/opt/aws/bin/rds-modify-db-subnet-group
Subnet を作ったり破棄したりするだけなら ec2-create-subnet、ec2-delete-subnet、ec2-describe-subnet があれば足りそうです。

先のスライドに従えば、VPCが外部と通信するための Gateway が必要になるはずです。
こちらも探してみましょう。
$ ls -1 /opt/aws/bin/*gate*
/opt/aws/bin/ec2-attach-internet-gateway
/opt/aws/bin/ec2-attach-vpn-gateway
/opt/aws/bin/ec2-create-customer-gateway
/opt/aws/bin/ec2-create-internet-gateway
/opt/aws/bin/ec2-create-vpn-gateway
/opt/aws/bin/ec2-delete-customer-gateway
/opt/aws/bin/ec2-delete-internet-gateway
/opt/aws/bin/ec2-delete-vpn-gateway
/opt/aws/bin/ec2-describe-customer-gateways
/opt/aws/bin/ec2-describe-internet-gateways
/opt/aws/bin/ec2-describe-vpn-gateways
/opt/aws/bin/ec2-detach-internet-gateway
/opt/aws/bin/ec2-detach-vpn-gateway
たくさんありますが、今回作成したいのは Internet Gateway (VPN Gateway ではない)なので、赤色のモノだけ使えば問題ないハズです。

Gateway があるということは、きっとルーティングテーブルが存在するはずです。
$ ls -1 /opt/aws/bin/*route*
/opt/aws/bin/ec2-associate-route-table
/opt/aws/bin/ec2-create-route
/opt/aws/bin/ec2-create-route-table

/opt/aws/bin/ec2-create-vpn-connection-route
/opt/aws/bin/ec2-delete-route
/opt/aws/bin/ec2-delete-route-table

/opt/aws/bin/ec2-delete-vpn-connection-route
/opt/aws/bin/ec2-describe-route-tables
/opt/aws/bin/ec2-disable-vgw-route-propagation
/opt/aws/bin/ec2-disassociate-route-table
/opt/aws/bin/ec2-enable-vgw-route-propagation
/opt/aws/bin/ec2-replace-route
/opt/aws/bin/ec2-replace-route-table-association
/opt/aws/bin/elb-associate-route53-hosted-zone
/opt/aws/bin/elb-disassociate-route53-hosted-zone

他には Network ACL (Network Access Control List) の設定も必要なようですが…。標準では「フルオープン(制限なし)」ということなので、今回は使わなくてもOKでしょう。



・VPC環境作成
VPCを作成するには ec2-create-vpc コマンドを使用し、パラメータとして VPC が利用する IPアドレス範囲を CIDR形式 で渡すようです。そんなに巨大なサーバ群は扱わないので、自宅LANなどで良く使われる 192.168.*.* な IPアドレス範囲で、かつ 8ビットのみ使用することにします。
$ ec2-create-vpc 192.168.1.0/24
VPC     vpc-e8c9f781    pending 192.168.1.0/24  dopt-ecc9f785   default
一瞬待たされますが、アッサリVPCが作成されます。実際に作成が完了したかどうか、ec2-describe-vpcs コマンドで確認してみます。
$ ec2-describe-vpcs
VPC     vpc-e8c9f781    available       192.168.1.0/24  dopt-ecc9f785   default
pending 状態だったものが available になりました。


・VPC内にサブネットを作成する
次は、サブネットを作るのですが…。
Amazonの説明によると「VPCのIPアドレス範囲の内、最初の4つと、最後の1つはAmazonが予約する」ということになっています。最後の一つと言うのは、ブロードキャスト用のことですかね…。最初の4つが何なのか分かりませんが(4つの内、1つはVPC自身を指すアドレスになるのかな?)。なので、サブネットを作成する場合は、あまり小さなものにすると破綻するようです。少なくとも2ビット(4つのIPアドレス)のものは作成できませんね…。
今回はVPC範囲のIPアドレスをすべて1つのサブネットに割り当てることにします。
$ ec2-create-subnet --vpc vpc-e8c9f781 --cidr 192.168.1.0/24
SUBNET  subnet-f0c3fd99 pending vpc-e8c9f781    192.168.1.0/24  251     ap-northeast-1a
ちなみに、VPC範囲に無いIPアドレス帯域を指定すると、エラーになります。つまり、サブネットはVPCが持つIPアドレス範囲の中で作成する必要があり、他の範囲帯のモノを追加するということはできない…ということになります。まぁ、ネットワーク技術者な人からすれば当然の制限なのかもしれませんが、初心者はそんなこと知らないので 試しながら進むわけで…。
# 範囲外のCIDRを指定するとエラーになる例
$ ec2-create-subnet \
     --vpc vpc-e8c9f781 \
     --cidr 10.0.0.0/2
4
Client.InvalidSubnet.Range: The CIDR '10.0.0.0/24' is invalid.
作成したサブネットの状態を確認してみます。
$ ec2-describe-subnets
SUBNET  subnet-f0c3fd99 available       vpc-e8c9f781    192.168.1.0/24  251     ap-northeast-1a
ふつーに作成されていて、特に異常は無さそうです。



・EC2インスタンスとセキュリティグループを作成
次に、EC2インスタンスを VPCサブネット内に作成してみます。いつもの UbuntuOSです…。
$ ec2-run-instances  ami-20ad1221 \
     --key innerkey  \
     --instance-count 1  \
     --instance-type t1.micro  \
     --instance-initiated-shutdown-behavior stop \
     --group web  \
     --subnet subnet-f0c3fd99

Client.InvalidParameterCombination: The parameter groupName cannot be used with the parameter subnet
あれ??? エラーになってしまいました。
gorupNameが指定できないということは…、セキュリティグループが指定できないということでしょうか?

セキュリティグループを作成するための ec2-create-group コマンドのヘルプを見てみると、--vpc という専用オプションがあるようです。どうやら、VPC でセキュリティグループを使用する場合、VPC内専用のモノが必要みたいです。
それでは、VPC専用のセキュリティグループを作成してみましょう。
# VPC用セキュリティグループ vpc_web を作成
$ ec2-create-group \
     vpc_web \
     --vpc vpc-e8c9f781 \
     --description 'web in VPC'

GROUP   sg-1d1e0071     vpc_web web in VPC

# vpc_web に port:80 の着信許可を与えようとするが…
$ ec2-authorize \
     vpc_web \
     --protocol tcp \
     --port-range 80 \
     --cidr '0.0.0.0/0'

Client.InvalidParameterValue: Invalid value 'vpc_web' for groupName. You may not reference Amazon VPC security groups by name. Please use the corresponding id for this operation.

# vpc_web に port:80 の着信許可を与え
$ ec2-authorize \
     sg-1d1e0071 \
     --protocol tcp \
     --port-range 80 \
     --cidr '0.0.0.0/0'

GROUP   sg-1d1e0071
PERMISSION                      ALLOWS  tcp     80      80      FROM    CIDR    0.0.0.0/0       ingress

# vpc_web に port:22 の着信許可を与え
$ ec2-authorize \
     sg-1d1e0071
\
     --protocol tcp \
     --port-range 22 \
     --cidr '0.0.0.0/0'

GROUP   sg-1d1e0071
PERMISSION                      ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0       ingress

# 結果確認
$ ec2-describe-group sg-1d1e0071
GROUP   sg-1d1e0071     488224276535    vpc_web web in VPC      vpc-e8c9f781
PERMISSION      488224276535    vpc_web ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0       ingress
PERMISSION      488224276535    vpc_web ALLOWS  tcp     80      80      FROM    CIDR    0.0.0.0/0       ingress
PERMISSION      488224276535    vpc_web ALLOWS  all                     TO      CIDR    0.0.0.0/0       egress
セキュリティグループを名前で指定できないのには焦りましたが、なんとか port 22,80 を通すように設定したセキャリティグループを作成できました。egress(インスタンスから外に出ていくパケット)の指定はしていないので、無制限になっています。

それでは、作成したVPC用セキュリティグループを適用して、EC2インスタンスを作成してみます。
$ ec2-run-instances  ami-20ad1221 \
      --key innerkey  \
      --instance-count 1  \
      --instance-type t1.micro  \
      --instance-initiated-shutdown-behavior stop \
      --group sg-1d1e0071  \
      --subnet subnet-f0c3fd99

RESERVATION     r-e95723ea      488224276535
INSTANCE        i-f3e1f0f0      ami-20ad1221            ip-192-168-1-61.ap-northeast-1.compute.internal pending innerkey        0                t1.micro        2013-03-14T09:13:51+0000        ap-northeast-1a aki-ec5df7ed                    monitoring-disabled              192.168.1.61    vpc-e8c9f781    subnet-f0c3fd99 ebs                                     paravirtual     xen      sg-1d1e0071     default false
NIC     eni-7b281112    subnet-f0c3fd99 vpc-e8c9f781    488224276535    in-use  192.168.1.61            true
NICATTACHMENT   eni-attach-6393160a     0       attaching       2013-03-14T09:13:51+0000        true
GROUP   sg-1d1e0071     vpc_web
PRIVATEIPADDRESS        192.168.1.61

$ ec2-describe-instances i-f3e1f0f0
RESERVATION     r-e95723ea      488224276535
INSTANCE        i-f3e1f0f0      ami-20ad1221            ip-192-168-1-61.ap-northeast-1.compute.internal running innerkey        0                t1.micro        2013-03-14T09:13:51+0000        ap-northeast-1a aki-ec5df7ed                    monitoring-disabled              192.168.1.61    vpc-e8c9f781    subnet-f0c3fd99 ebs                                     paravirtual     xen      sg-1d1e0071     default false
BLOCKDEVICE     /dev/sda1       vol-533a4d71    2013-03-14T09:13:54.000Z        true
NIC     eni-7b281112    subnet-f0c3fd99 vpc-e8c9f781    488224276535    in-use  192.168.1.61            true
NICATTACHMENT   eni-attach-6393160a     0       attached        2013-03-14T09:13:51+0000        true
GROUP   sg-1d1e0071     vpc_web
PRIVATEIPADDRESS        192.168.1.61



・EIPを確保してEC2インスタンスに割り当てる
EIPを取得して、VPCのEC2インスタンスに割り当ててみます。
$ ec2-allocate-address
ADDRESS 54.249.245.29           standard

$ ec2-associate-address \
     54.249.245.29 \
     --instance
i-f3e1f0f0
Client.InvalidParameterCombination: You must specify an allocation id when mapping an address to a VPC instance
エラーが発生していますが、Allocation ID って何???

ec2-alocate-address --help によると、VPC用のEIPは VPC 専用として確保する必要があるようです。
ec2-alocate-address --help からの抜粋
-d, --domain DOMAIN
     If DOMAIN is specified as 'vpc', the IP address returned can
     be associated with VPC instances.  If this option is not
     specified, the IP address can only be associated with non-VPC
     instances.
EIP を VPC 用として作成しなおし、再度アタッチしてみます。
# 古いEIPを解放
$ ec2-release-address 54.249.245.29
ADDRESS 54.249.245.29

# 再度、VPC用EIPを確保
$ ec2-allocate-address --domain vpc
ADDRESS 54.249.84.161           vpc     eipalloc-f728119e

# EIP を EC2 へ割り当て
$ ec2-associate-address \
    
eipalloc-f728119e  \
     --instance
i-f3e1f0f0
Client.InvalidParameterValue: Invalid value 'eipalloc-f728119e' for PublicIp. Not a valid IPv4 address.
※ allocation id を直接指定するのではなく、--allocation-id オプション経由で指定する必要があるみたいです。

# EIP を EC2 へ割り当て (--allocate-id オプション)
$ ec2-associate-address \
     --allocation-id 
eipalloc-f728119e \
     --instance 
i-f3e1f0f0
Client.Gateway.NotAttached: Network vpc-e8c9f781 is not attached to any internet gateway
あらら…。やっぱりゲートウェイが必要なのですね…。



・Gatewayを作る
VPCを外部と接続するための Gateway を作成します。
$ ec2-create-internet-gateway
INTERNETGATEWAY igw-7b350c12

$ ec2-describe-internet-gateways
INTERNETGATEWAY igw-7b350c12
何も難しいことは無く、すぐに作成できました。
次は、作成したGateway を VPC に接続します。
$ ec2-attach-internet-gateway \
     igw-7b350c12 \
     --vpc vpc-e8c9f781

ATTACHMENT      vpc-e8c9f781    attaching

$ ec2-describe-internet-gateways igw-7b350c12
INTERNETGATEWAY igw-7b350c12
ATTACHMENT      vpc-e8c9f781    available
これも特に難しいことは無いですね…。逆に、何も設定が無いのが不気味です。
Gateway って、こういうモノなんでしたっけ???



・EIPをEC2に割り当てる
$ ec2-describe-addresses
ADDRESS 54.249.84.161           vpc     eipalloc-f728119

$ ec2-associate-address \
     --allocation-id  eipalloc-f728119e \
     --instance  i-f3e1f0f0
ADDRESS         i-f3e1f0f0      eipalloc-f728119e       eipassoc-3d2b1254

$ ec2-describe-addresses
ADDRESS 54.249.84.161   i-f3e1f0f0      vpc     eipalloc-f728119e       eipassoc-3d2b1254       eni-7b281112    192.168.1.61
今回はエラーもなく割り当てできました。グローバルIPであるEIPが、EC2のプライベートIP に紐づけられているようですね…。

Gateway は、EIPとプライベートIPをペアにして管理しているんでしょうかね…。だから、gateway側で「どのEIPを、どのEC2にマッピングするのか」という設定が無いのですね…。まぁ、設定場所が違うだけで、意味的には同じなんでしょうけど…。


・ルーティングテーブルの設定
試してみればわかりますが、EIPを設定しただけでは VPCの外部からEC2へ ssh接続できないようです。
# タイムアウトしてしまって ssh 接続できない例
$ ssh -i ~/.ssh/innerkey.pem  54.249.84.161
ssh: connect to host 54.249.84.161 port 22: Connection timed out
VPC内に作成された EC2インスタンスは直接外部とネット接続できないため、Gateway を経由して接続する必要があります。既に作成済みのEC2インスタンスには EIPを割り当てたので、外部からパケットが着信することは可能と思われますが…。EC2側から応答を返す経路が設定されていないので、それが理由でTCPの通信が成立してしないと思われます。

ここでは、ルーティングテーブルを用意し、VPC内部から外部にパケットを送信できるように設定します。
$ ec2-describe-route-tables
ROUTETABLE      rtb-eac9f783    vpc-e8c9f781
ROUTE   local           active  192.168.1.0/24          CreateRouteTable
既にルーティングテーブルは1つ標準で設定されていて、「VPC内部→VPC内部」のルーティングが設定されています。
これに「VPC内部→(Gateway)→外部」というルーティングを追加してみます。
# 中継器となるゲートウェイの確認
$ ec2-describe-internet-gateways
INTERNETGATEWAY igw-7b350c12
ATTACHMENT      vpc-e8c9f781    available

# VPC外部を宛先とするパケットは、ゲートウェイ経由となるようにルーティング設定する
$ ec2-create-route \
     rtb-eac9f783 \
     --cidr 0.0.0.0/0 \
     --gateway  igw-7b350c12

ROUTE   igw-7b350c12                    0.0.0.0/0

# 結果確認
ec2-describe-route-tables
ROUTETABLE      rtb-eac9f783    vpc-e8c9f781
ROUTE   local           active  192.168.1.0/24          CreateRouteTable
ROUTE   igw-7b350c12            active  0.0.0.0/0               CreateRoute
ASSOCIATION     rtbassoc-edc9f784       main

なぜか、ASSOCIAION ~ main という設定まで追加されてしまいました。
コメントは設定できないので見たままの情報で判断するしかないですが、一応、設定した内容は反映されています。

本当は、ec2-associate-route-table で subnet 側のルーティング設定を割り当てないといけないらしいのですが…。設定しない場合、デフォルトで main がルーティングテーブルとして利用されるそうです。
⇒ 参考:  AWS Route Table Basics



・VPC内のEC2インスタンスへssh接続してみる
今までの設定が正しく完了していれば、ssh でVPC 内のインスタンスに接続できるはずです。
$ ssh -i ~/.ssh/innerkey.pem -l ubuntu 54.249.84.161
何事もなく、ふつーにログインできます!
ためしに、この「VPC内部のEC2インスタンス」から外部にHTTPリクエストを投げてみましょう。
$ curl 'http://exploreaws.doorblog.jp/' | head -n 5
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0<!DOCTYPE html>
<html lang="ja" itemscope itemtype="http://schema.org/Blog">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
バッチリ通信できてますね。



・備考
参考までに使わないNACLですが、状態確認コマンドを使うと こんな風に表示されています。使って無いつもりではありますが、標準で 1つ ACLが作成されています。もっとも、「フルオープン」で設定されているため、使わないのであれば 特に気にしないでも良いのですが。
$ ec2-describe-network-acls
NETWORKACL      acl-ebc9f782    vpc-e8c9f781    default
ENTRY   egress  100     allow   0.0.0.0/0       all
ENTRY   egress  32767   deny    0.0.0.0/0       all
ENTRY   ingress 100     allow   0.0.0.0/0       all
ENTRY   ingress 32767   deny    0.0.0.0/0       all

※egressが内部から外部へ出ていくパケット、ingress がその逆を意味するようです。



これ以上ブログに文字が書けなくなったので、今回はここまで。
後片付けは次回…。

このページのトップヘ