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接続し以下のような設定を行います。
[Webサーバインスタンスの起動]
それでは動作確認用に適当なインスタンスを非公開用セグメントで起動します。
インスタンス起動後は外部接続の動作確認を行い、Apacheをインストールしました。
[ブラウザから動作確認]
Vyattaに割り当てたElastic IPにポート8080番を指定してアクセスすると以下のようにWebサーバに転送されました。

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

[投入を予定していたDHCP関連の設定]

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ヘッダをログに出力する設定にはなっていないので、以下のように設定ファイルを修正しました。 nginxは以下のようにデフォルトでログに出力する設定になっています。 以下の通り無事に確認出来ました。(アクセス元IP=>221.221.221.221 CloudLoadBalancerのIP=>10.183.252.25)
※アクセス元IPは適当な数字に置換しています

■Apacheでの確認 ■nginxでの確認 ログのフォーマットはデフォルトのままで分かりずらいですが、そこはご愛嬌という事で。