2011年10月10日月曜日

Vyattaを使ってAmazon VPC内に独自NAT環境を作る

このブログでクラウド関連の話題というと、ほとんどRackspace Cloudばかりなのですが…
今回のエントリは珍しくAWSをテーマにしてみたいと思います。
Twitterを見ているとVyattaが最近アツく、個人的にも書籍を購入したのでAmazon VPCと連携させたいです。
AWSではVPCネットワークから外部へ接続するためのNATアドレッシングインスタンスが提供されておりますが、こちらをVyattaに置き換えて使ってみるという事です。
今回はNATを構成するだけですが、Vyattaは機能が豊富で様々な可能性をVPCに付け加える事が出来そうです。
ちなみに先日Vyatta社からアナウンスされた6.3のAMIはSubscription Editionということなので、今回はVyatta Core6.1のAMIを使用しています。



[ネットワーク構成]

[VPCの設定]
VPC内にはVyattaを起動する公開サブネットと、Webサーバを起動する非公開サブネットの2つを用意します。

[Vyattaインスタンスを起動]
今回はこちらのAMIを使用し、インスタンス起動後にはSouce/Dest. CheckをDisableとします。
この設定はVyattaインスタンスを起動後にインスタンスを選択して、右クリックのメニューから変更が出来ます。
VPC内でElastic IPを取得してVyattaインスタンスに割り当てる事も忘れずに!
このIPを使用してWebサーバは通信をします。

[ルートテーブル]
Management Console(VPC)のRoute Tableメニューで公開用/非公開用のルートテーブルを設定します。
公開用サブネットはデフォルトルートがインターネットゲートウェイとなり、非公開用はVyattaインスタンスのinstance-idを指定します。

[セキュリティグループ]
Vyattaに割り当てるセキュリティグループは、Webサーバからの必要な通信をブロックしなければ自由に設定可能です。
また、VPCで設定可能なネットワークACLも同じように自由に使えました。

[Vyattaインスタンスの設定]
起動したVyattaインスタンスにSSH接続し以下のような設定を行います。
  1. ■ホスト名の設定  
  2. $ configure   
  3. [edit]  
  4. # set system host-name vyatta61  
  5. # commit   
  6. # exit  
  7.   
  8. ■時刻の設定  
  9. $ configure   
  10. [edit]  
  11. # set system time-zone Asia/Tokyo   
  12. # commit   
  13. # exit  
  14. $ show date   
  15.   
  16. ■NAT設定(内部から外部への変換)  
  17. $ configure   
  18. [edit]  
  19. # set service nat rule 10 outbound-interface eth0    
  20. # set service nat rule 10 source address 10.0.2.0/24  
  21. # set service nat rule 10 type masquerade   
  22. # commit   
  23.   
  24. ■NAT設定(外部からの8080番ポートを内部へ変換)  
  25. # set service nat rule 20 destination port 8080  
  26. # set service nat rule 20 inbound-interface eth0   
  27. # set service nat rule 20 inside-address address 10.0.2.100  
  28. # set service nat rule 20 protocol tcp  
  29. # set service nat rule 20 type destination   
  30. # commit   
  31. # save  
  32.   
  33. ■NAT設定確認  
  34. # show service nat   
  35. rule 10 {  
  36. outbound-interface eth0  
  37. protocol tcp  
  38. source {  
  39. address 10.0.2.0/24  
  40. }  
  41. type masquerade  
  42. }  
  43. rule 20 {  
  44. destination {  
  45. port 8080  
  46. }  
  47. inbound-interface eth0  
  48. inside-address {  
  49. address 10.0.2.100  
  50. }  
  51. protocol tcp  
  52. type destination  
  53. }  
[Webサーバインスタンスの起動]
それでは動作確認用に適当なインスタンスを非公開用セグメントで起動します。
インスタンス起動後は外部接続の動作確認を行い、Apacheをインストールしました。
  1. ■NAT動作確認インスタンス起動  
  2. $ ping google.co.jp  
  3. $ sudo yum -y install httpd  
  4. $ sudo vi /etc/httpd/conf/httpd.conf   
  5. 136 Listen 8080  
  6. $ sudo chkconfig --level 2345 httpd on  
  7. $ sudo /etc/rc.d/init.d/httpd start  
  8. $ sudo vi /var/www/html/index.html  
[ブラウザから動作確認]
Vyattaに割り当てたElastic IPにポート8080番を指定してアクセスすると以下のようにWebサーバに転送されました。

※おまけ
実はこの構成でVPCのDHCP Options Setを無効にしてDHCPサーバも動かそうとしたのですが、VPCもブロードキャストの通信がサポートされてないという事なので断念しました(汗)

[投入を予定していたDHCP関連の設定]
  1. ■DHCP設定  
  2. Amazon VPCの標準機能ではなくVyattaルータの設定で行います  
  3. $ configure   
  4. [edit]  
  5. # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24  
  6. # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 start 10.0.1.100 stop 10.0.1.200  
  7. # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 default-router 10.0.1.254  
  8. # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 dns-server 10.0.1.254  
  9. # commit   
  10. # exit  
  11.   
  12. ■DNS設定  
  13. Amazon VPCの標準機能ではなく、Googleが提供しているルータの設定を行います  
  14. $ configure   
  15. [edit]  
  16. # set system name-server 8.8.8.8  
  17. # commit   
  18. # exit  
  19.   
  20. ■DNS転送設定  
  21. $ configure   
  22. [edit]  
  23. # set service dns forwarding listen-on eth0   
  24. # commit   
  25. # exit  

AWSが提供しているNATアドレッシングインスタンスも便利ですが、Vyattaユーザやルータの設定経験がある方はこのような構成にした方が理解しやすい部分もありそうですね。

[参考資料]

2011年10月2日日曜日

MacからRackspace Cloud Filesに接続出来るFTPクライアント


つい先日会社のノートPCが新しくなりました。
ずっとThinkpadユーザーだったのですが…。ありがとうThinkpad、こんにちはMacBook Air

さて、セットアップ中のMBAにFTP(SCP)クライアントは何を使うべきか?と悩みました。
FTPクライアントといっても最近はクラウドストレージをサポートしていのもあるので、そんなタイプを使いたいです。

やっぱり多いですね!Amazon S3に対応しているものは!
そして、少ないですね!Cloud Filesに対応しているのは!

とはいってもアヒルちゃんことCyberduckはきちんとCloud Filesに対応済みなようですよ!
セットアップ&動作確認も以下のように簡単に出来ちゃいました!

起動したらRackspace Cloud Filesがすぐに見つかります。

こんな感じでAPIユーザーとパスワードを入力してログインです。

はい、無事に接続完了です。

適当なメモをアップロードしてみました。

無事にRackspaceの管理画面にも反映されていますね!


しかし…。
Cloud Filesに対応した、よりよいFTPクライアントがあるといいんだけどなぁ。Interarchyもピンとこなかった。
FTPクライアントという形にとらわれすぎだろうか…。

2011年10月1日土曜日

Cloud Load Balancers使用時にアクセス元IPをログ出力するテスト

こんにちはデース。
さて、以前Twitterで以下のようなつぶやきをしました。※どうやらバッチリ誤字してるようですね☆

こんなん
RackspaceのCloud Load Balancersを使用する場合、いわゆるリバースプロキシ型のロードバランサと同じように、分散先のサーバにはロードバランサのIPがアクセス元となります。
すると、本来のアクセス元IPが分からなくなってしまうのですが、リンクの記事によるとCloud Load BalancersもHTTPのX-Forwarded-Forヘッダに対応しており、こちらを取得する事でアクセス元IPを取得出来ます。
気がむいたのでApacheとnginxを使って動作確認をしてみました。
テスト環境は以下の通りです。
  • OS:CentOS5.6(Cloud Serversのimageから起動したもの)
  • Apache:CentOS標準のものをyumでインストール
  • nginx:EPELをリポジトリに追加してyumでインストール
ApacheはデフォルトだとX-Forwarded-Forヘッダをログに出力する設定にはなっていないので、以下のように設定ファイルを修正しました。
  1. # vi /etc/httpd/conf/httpd.conf  
  2.     485 #LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined  
  3.     486 LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined  
nginxは以下のようにデフォルトでログに出力する設定になっています。
  1. # vi /etc/nginx/nginx.conf  
  2.      51     log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '  
  3.      52                       '$status $body_bytes_sent "$http_referer" '  
  4.      53                       '"$http_user_agent" "$http_x_forwarded_for"';  
以下の通り無事に確認出来ました。(アクセス元IP=>221.221.221.221 CloudLoadBalancerのIP=>10.183.252.25)
※アクセス元IPは適当な数字に置換しています

■Apacheでの確認
  1. CloudServersに直接アクセスした場合  
  2. # tail -f /var/log/httpd/access_log   
  3. - 221.221.221.221 - - [01/Oct/2011:03:06:39 +0000] "GET / HTTP/1.1" 200 35 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3"  
  4.   
  5. CloudLoadBalancers経由でアクセスした場合  
  6. # tail -f /var/log/httpd/access_log   
  7. 221.221.221.221 10.183.252.25 - - [01/Oct/2011:03:08:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3"  
■nginxでの確認
  1. CloudServersに直接アクセスした場合  
  2. # tail -f /var/log/nginx/access.log  
  3. 221.221.221.221 - - [01/Oct/2011:03:18:07 +0000] "GET / HTTP/1.1" 200 36 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3" "-"  
  4.   
  5. CloudLoadBalancers経由でアクセスした場合  
  6. # tail -f /var/log/nginx/access.log  
  7. 10.183.252.25 - - [01/Oct/2011:03:19:52 +0000] "GET / HTTP/1.1" 200 36 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3" "221.221.221.221"  
ログのフォーマットはデフォルトのままで分かりずらいですが、そこはご愛嬌という事で。