2012年3月25日日曜日

"Route 53"のルーティング系の設定(simple/weighted/latency)

スズキです。

CDPの新パターン"Weighted Transition"に触発され、そのパターンの
主役となるプロダクト"Route 53"のルーティング系機能をあ、らためて試してみました。

まず、"Route 53"には下記のように三種類のルーティングに関する機能(Routing Policy)
が用意されています。

▼simple
普通のDNSの振る舞いです。同一DNS名にAレコードを複数登録することで、
DNSラウンドロビンが実現されます。

▼weighted
DNS名に対するターゲット(IP/DNS名)の選択に重みをつけることができ、
DNSラウンドロビンよりも柔軟にアクセス分散させることが可能です。

▼latency
DNS名に対するターゲット(IP/DNS名)の選択を一番レイテンシーが低い場所にします。
同一DNS名にリージョンが違う複数のEC2を登録した場合、アクセス元から
一番近くの(レイテンシーが低い)EC2が選択されます。

ということで、実際に、"AWS Management Console"で試してみます。

▼simple(DNSラウンドロビン)

"Routing Policy"を"simple"にして一つのDNS名に対して、
複数のIPアドレスを設定してみます。


問題なく登録されました。


次は別のレコードセットとして、上記と同じDNS名に対してIPアドレスと設定してみます。


すると"すでにDNS名は存在している"とエラーになってしまいます。

"simple"では一つのDNS名を複数のレコードセットで設定することはできないようです。


▼weighted

"Routing Policy"を"weighted"にして一つのDNS名に対して、
一つのIPアドレスを設定してみます。


問題なく設定されました。(当然ですが...)


次に上述のDNSラウンドロビンのように、一つのDNS名に対して
複数のIPアドレスを設定してみます。


すると今度は"weighted"ではIPアドレスは一つしか登録できない"
とエラーになってしまいます。

"weighted"では"simple"とは逆に、一つレコードセットに
複数のIPアドレスは設定できないようです。


ということで、同じDNS名に対して別のレコードセットで、
今度は一つのIP設定で再度登録してみます。


今度は上述のDNSラウンドロビンとは逆に、登録できてしまいました。

"weighted"では一つのレコードセットには一つのIPアドレスしか設定できず、
重みを付けて複数IPアドレスを設定するには別のレコードセットとして登録する
必要があるようです。


▼latency

"Routing Policy"を"latency"にして一つのDNS名に対して、
複数のIPアドレスを(いきなり)設定してみます。



すると今度も"weighted"同様、"IPアドレスは一つしか登録できない"
とエラーになってしまいます。

"latency"も"simple"とは逆に、一つレコードセットに複数のIPアドレスは
設定できないようです。


なので同様に、一つのIPアドレスで試してみます。


"weighted"同様、問題なく登録できることがわかります。

同じDNS名に対して複数のIPアドレスを登録する場合も、
一つのIPアドレスが設定されている複数のレコードセットを登録することになります。


▼確認

ということで、今までの設定で"Route 53"は下記のようになりました。


実際に"nslookup"コマンドで確認してみます。

まずは"simple"からです。

$ nslookup simple.suz-lab.com ns-1074.awsdns-06.org
...
Name: simple.suz-lab.com
Address: 192.168.1.1
Name: simple.suz-lab.com
Address: 192.168.1.2

$ nslookup simple.suz-lab.com ns-1074.awsdns-06.org
...
Name: simple.suz-lab.com
Address: 192.168.1.2
Name: simple.suz-lab.com
Address: 192.168.1.1

まさにDNSラウンドロビンとして振舞っていることがわかります。

次に"weighted"です。

$ nslookup weighted.suz-lab.com ns-1074.awsdns-06.org
...
Name: weighted.suz-lab.com
Address: 192.168.2.2

$ nslookup weighted.suz-lab.com ns-1074.awsdns-06.org
...
Name: weighted.suz-lab.com
Address: 192.168.2.2

$ nslookup weighted.suz-lab.com ns-1074.awsdns-06.org
...
Name: weighted.suz-lab.com
Address: 192.168.2.1

重みに従ったIPアドレスが帰ってくることがわかります。

最後に"latency"です。

東京から"nslookup"すると、"ap-northeast-1"に指定した
IPアドレスが返ってきます。

$ nslookup latency.suz-lab.com ns-1074.awsdns-06.org
...
Name: latency.suz-lab.com
Address: 192.168.3.1

シンガポールから"nslookup"すると、今度はちゃんと"ap-southeast-1"に指定した
IPアドレスが返ってくることがわかります。

$ nslookup latency.suz-lab.com ns-1074.awsdns-06.org
...
Name: latency.suz-lab.com
Address: 192.168.3.2

今回はすべてAレコード(IPアドレス指定)で試してきましたが、"weighted"や"latency"は
CNAMEやTXT、そしてALIASでも利用できます。

新しいCDPの予感...
--------
http://www.suz-lab.com/

2012年3月24日土曜日

"AWS Direct Connect (DX)"のLOA-CFA(Letter of Authorization and Customer Facility Assignment)

スズキです。

以前、下記で紹介したとおり"AWS Direct Connect (DX)"の
申し込みまでを行いました。
"AWS Direct Connect (DX)"を申し込んでみた
これは「AWS Direct Connect Getting Started Guide」で紹介している、
下記のフェーズの「Subimit Connection Request」にあたります。


そして、LOA-CFA(Letter of Authorization and Customer Facility Assignment)
のメール待ちだったのですが、届きまいた!

> We have reserved your 1G AWS Direct Connect port(s) in Equinix TY2.

"Equinix TY2"の1Gポートを予約しました。

> Attached please find the LOA-CFA(s) for your cross connect request.

添付にLOA-CFAがあります。

> Here's what you should do next.

以下に従って手続きしてください。

> 1.
> Submit the attached LOA-CFA(s) to the colocation provider with
> your cross connect request.

添付のLOA-CFAを"Equinix TY2"の接続要求を行う際に提出して下さい。

> If you are working with an AWS Direct Connect Solution Provider
> to connect, please provide them a copy of the LOA to facilitate
> the cross connect process. Include the AWS Ticket number(s).

"AWS Direct Connect Solution Provider"にお願いしている場合は、
彼らにもLOA-CFAを提出してください。(AWS Ticket number? が含まれています)

> You can find information on requesting cross connects in the
> "Requesting Cross-Connects at AWS Direct Connect locations"
> section of the AWS Direct Connect Getting Started Guide.

"AWS Direct Connect Getting Started Guide"の
"Requesting Cross-Connects at AWS Direct Connect locations"に
"Equinix TY2"の接続要求に関する情報が載っています。

> 2.
> Reply to this email with the colocation provider's tracking number.

このメールにデータセンターのトラッキング番号?を返信して下さい。

> 3.
> After the colocation provider confirms the cross connect is established,
> email xxx@xxx.xxx to set up your Logical Connection(s) with the
> information specified in the "Create a Logical Connection" section of
> the AWS Direct Connect Getting Started Guide.

"Equinix TY2"が接続の確立を確認したら、xxx@xxx.xxx(AWS)に
論理接続のための情報をメールして下さい。 論理接続のための情報は
"AWS Direct Connect Getting Started Guide"の
"Create a Logical Connection"に記載されています。

> Billing for AWS Direct Connect port hours will begin once a logical
> connection is available or on Mon Apr 16 00:00:00 UTC 2012, whichever
> occurs first.

DXの課金は一体でも論理接続が行われたら、または、4/16(月)の16:00(UTC)から
開始されます。

> Note: The cross connect must be completed within 30 days or this
> LOA-CFA(s) will expire. If the cross connect is not established within
> 30 days, please email xxx@xxx.xxx

接続が30日以内に完了しない場合、このLOA-CFAは期限切れになります。もし、30日以内に
接続が確立できない場合は、xxx@xxx.xxx(AWS)にメールして下さい

実際の添付されたLOA-CFAはこんな感じです。


ということで、次は"Equinix TY2"に接続要求(Requesting Cross-Connects)です!

"CloudPack"じゃなく、"cloudpack"にならないかなー...
--------
http://www.suz-lab.com/

2012年3月20日火曜日

"Kyoto Tycoon (memcached plugin)"を"CentOS 6.2"にインストール

スズキです。

"CentOS 6.2"(下記AMI)に
SUZ-LAB謹製 CentOS AMI (6.2.1 64bit ap-northeast-1)
"Kyoto Tycoon (memcached plugin)"をインストールして、起動してみました。

まずは、"Kyoto Cabinet"のインストールです。
# cd /usr/local/src
# curl -OL http://fallabs.com/kyotocabinet/pkg/kyotocabinet-1.2.72.tar.gz
# tar xvzf kyotocabinet-1.2.72.tar.gz
# cd kyotocabinet-1.2.72
# ./configure 
# make
# make install

次に、"Kyoto Tycoon"のインストールです。
# cd /usr/local/src
# curl -OL http://fallabs.com/kyototycoon/pkg/kyototycoon-0.9.53.tar.gz
# tar xvzf kyototycoon-0.9.53.tar.gz
# cd kyototycoon-0.9.53
# ./configure
# make
# make install

そして、起動スクリプトを用意します。
※"memcached plugin"がきくように調整しています。
# cp /usr/local/src/kyototycoon-0.9.53/lab/ktservctl /etc/init.d/ktserver
# diff /usr/local/src/kyototycoon-0.9.53/lab/ktservctl /etc/init.d/ktserver 
4a5,6
> # chkconfig:   - 80 20
> # description: Kyoto Tycoon - KVS Database
17,20c19,22
< #miscopts="-oat"
< #ulogdir="$basedir/ulog"
< #ulim=1g
< #sid=1
---
> miscopts="-plsv /usr/local/libexec/ktplugservmemc.so -plex \"port=11211#opts=f\""
> ulogdir="$basedir/ulog"
> ulim=1g
> sid=1
24c26
< dbname="$basedir/casket.kch#bnum=2000000#msiz=128m#dfunit=8"
---
> dbname="$basedir/casket.kch"

準備が整ったら、"Kyoto Tycoon"を起動してみます。
# /etc/init.d/ktserver start
Starting the server of Kyoto Tycoon
Executing: ktserver -port 1978 -tout 30 -th 8 -dmn -pid /var/ktserver/pid -log /var/ktserver/log -ls -ulog /var/ktserver/ulog -ulim 1g -sid 1 -plsv /usr/local/libexec/ktplugservmemc.so -plex "port=11211#opts=f" /var/ktserver/casket.kch
Done

"memcached"として機能しているか確認します。
# telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats 
STAT pid 3367
STAT uptime 34
STAT time 1332253290
STAT version KyotoTycoon/0.9.53
STAT pointer_size 64
STAT curr_connections 1
STAT threads 16
STAT curr_items 0
STAT bytes 12589240
STAT db_apow 3
STAT db_bnum 2097169
STAT db_chksum 188
STAT db_count 0
STAT db_dfunit 0
STAT db_flags 1
STAT db_fmtver 5
STAT db_fpow 10
STAT db_frgcnt 0
STAT db_ktcapcnt -1
STAT db_ktcapsiz -1
STAT db_ktopts 0
STAT db_librev 9
STAT db_libver 16
STAT db_msiz 67108864
STAT db_opts 0
STAT db_path /var/ktserver/casket.kch
STAT db_realsize 12589240
STAT db_realtype 48
STAT db_recovered 0
STAT db_reorganized 0
STAT db_size 12589240
STAT db_trimmed 0
STAT db_type 48
STAT set_hits 0
STAT set_misses 0
STAT get_hits 0
STAT get_misses 0
STAT delete_hits 0
STAT delete_misses 0
STAT incr_hits 0
STAT incr_misses 0
STAT decr_hits 0
STAT decr_misses 0
STAT cmd_set 0
STAT cmd_get 0
STAT cmd_delete 0
STAT cmd_flush 0
END

最後に、自動起動するよに設定しておきます。
# chkconfig --add ktserver
# chkconfig ktserver on

予想以上に、あっさりできました!
--------
http://www.suz-lab.com/

Too many authentication failures for root

スズキです。

近頃、MACのsshで下記のようなエラーが出力され、ログインできなくなってしまいました。

$ ssh -i suz-lab_ap-northeast-1.pem -l root ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
Received disconnect from xxx.xxx.xxx.xxx: 2: Too many authentication failures for root

とりあえず、下記のようなファイルを用意することで解決しました。

$ cat /Users/suzuki/.ssh/config
IdentitiesOnly yes

急にどうしたんだろう...
--------
http://www.suz-lab.com/

2012年3月15日木曜日

"AWS Direct Connect (DX)"を申し込んでみた

スズキです。

下記より申し込みことができます。
AWS Direct Connect

こちらの申し込みボタンをクリックすると、


次のようなフォームがあらわれます。


主な入力内容は下記のとおりです。

▼AWS Direct Connect Location you want to use
使いたいDXの場所(データセンター)

...
Equinix Tokyo (TY2)
...

当然、日本のデータセンターである"Equinix Tokyo (TY2)"を選択します。

▼Will you need an AWS Direct Connect Solutions Provider to assist you
in establishing connectivity between your office, datacenter, or other
colocation enviornment to the AWS Direct Connect location selected above?
上記のデータセンターとオフィスや自分たちのデータセンター、そしてその他の場所との
接続を手伝ってくれるソリューションプロバイダーが必要ですか?

Yes / No : 漢なら「No」でしょう。

Please note, if you select "Yes" to the question above,
Amazon will provide your contact information to our
AWS Direct Connect network solution providers.
もし「Yes」を選択したら、Amazonはあなたの連絡先を、
そのソリューションプロバイダーに提供します。

▼Port Size (ポートのサイズ)

1 Gbps / 10 Gbps : さすがに「1 Gbps」を選択しました。

▼Number of ports (ポートの数)

One / Two : 今回は「One」ですが、早い段階で冗長化のため、もう1ポート欲しいですね。

AWS recommends customers maintain a pair of like-sized redundant ports.
Please specify your desired port configuration.
(Please note, per Port fees apply.)
AWSは冗長化のため同じ大きさの2つのポートを持つことを、おすすめします。

これで「送信」ボタンをクリックすると下記のようなメーセージが表示されて、
申し込み終了です。


Your request to configure an AWS Direct Connect connection
has been submitted to AWS. We will email you with additional
information about how to complete your AWS Direct Connect setup.
For most customers, you should expect an email within one business day.
Thank you for your patience.

要約すると、
  • DXの設定を完了するための追加情報をメールするよ。
  • メールは1営業日くらいで届くと思うよ。
といった感じでしょうか?

明日、どんなメールが来るんだろう?
--------
http://www.suz-lab.com

2012年3月9日金曜日

JAWS-UG-Saga勉強会#4の発表用資料

スズキです。

@kaz_gotoCloud Days Osaka 2012 に出席しているため、JAWS-UG-Saga勉強会#4
cloudpackの中の人として僕のが参加します。

発表資料は下記となります


今回は、事例のAWSの使い方として、最近発表されたCDP(クラウドデザインパターン)
盛り込んでみました。(実際のパターン集はこちらのWikiです)

それでは、佐賀の皆さま、よろしくお願いします。
--------
http://www.suz-lab.com/

2012年3月8日木曜日

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(SSH編)

スズキです。

下記のようにログインユーザー(認証)をOpenLDAPで管理し、
ログインできるようになりましたが、
CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(OpenLDAP編)

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(NSS編)

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(PAM編)
SSHに関しては、まだログインすることができません。

SSHでもログインするには、下記のように"password-auth"にも、
LDAPを利用するように調整剃る必要があります。

# cat /etc/pam.d/password-auth
auth        required      pam_env.so
auth        required      pam_tally2.so deny=6
auth        sufficient    pam_unix.so try_first_pass nullok
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     [default=bad success=ok user_unknown=ignore authinfo_unavail=ignore] pam_ldap.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow remember=4
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so
session     sufficient   pam_mkhomedir.so skel=/etc/skel/ umask=0022

これで無事、SSHでも OpenLDAPに登録したユーザー情報でログイン出来るようになります。

下記で紹介している公開鍵認証でも同様です。
SSHで公開鍵認証

とりあえず、一区切り。。。
--------
http://www.suz-lab.com

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(PAM編)

スズキです。

下記でOpenLDAPとNSSまでの準備ができました。
CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(OpenLDAP編)

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(NSS編)

最後にPAMの設定です。

まずは、"pam_ldap.conf"です。

# cat /etc/pam_ldap.conf 
...
host localhost
base dc=suz-lab,dc=com
...

最後に、"system-auth"です。

# cat /etc/pam.d/system-auth
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so
session     optional      pam_mkhomedir.so skel=/etc/skel umask=077

これでOpenLDAPに登録したユーザー(パスワード)でログインできるはずです。
(初回ログイン時はホームディレクトリも作成されます)

次はSSH編です。がんばろう。。。
--------
http://www.suz-lab.com

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(NSS編)

スズキです。

下記でOpenLDAPの起動とログインユーザーの登録までできたので、
CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(OpenLDAP編)
今回はNSS(nsswitch.conf)関係の設定です。

まずは、LDAPと連動できるように下記のパッケージをインストールします。

# yum -y install nss-pam-ldapd


次に"nslcd"の設定をします。"nslcd"はLDAPに問い合わせを行うデーモンプログラムです。
("nss-pam-ldapd"に含まれています)

設定ファイルは下記の通りです。

# cat /etc/nslcd.conf 
...
uri ldap://localhost/
base dc=suz-lab,dc=com
...
base   group  ou=group,dc=suz-lab,dc=com
base   passwd ou=user,dc=suz-lab,dc=com
base   shadow ou=user,dc=suz-lab,dc=com
...

そして、起動します。

# chkconfig nslcd on
# /etc/init.d/nslcd start

この状態で、NSS(nsswitch.conf)がLDAPを利用するように設定します。

# cat /etc/nsswitch.conf 
...
passwd:     files ldap
shadow:     files ldap
group:      files ldap
...

これでLDAPで名前解決(認証)が行えるようになりました。

次の記事で"pam_ldap"部分を調整して完成です。がんばろう。。。
--------
http://www.suz-lab.com/

CentOS6.2のログインユーザー(認証)をOpenLDAPで管理(OpenLDAP編)

スズキです。

よくある話ですが、CentOS6.2でいろいろ試行錯誤したのでまとめておきます。

この記事ではOpenLDAPサーバを起動し、
ログインユーザーを登録するところまで進めてみます。

まずは必要パッケージのインストールです。

# yum -y install openldap-servers
# yum -y install openldap-clients

次に設定です。

# rm -rf /etc/openldap/slapd.d
# rm -rf /var/lib/ldap/*
# cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.conf
# cat /etc/openldap/slapd.conf
...
suffix          "dc=suz-lab,dc=com"
rootdn          "cn=Manager,dc=suz-lab,dc=com"
rootpw          secret
...

今回は、オンラインで設定を変更できる設定データベースを利用しないようにしています。
("slapd.d"を削除して"slapd.conf"で設定)

そして、OpenLDAPを起動して接続テストです。

# chkconfig slapd on
# /etc/init.d/slapd start
# ldapsearch -x -D "cn=Manager,dc=suz-lab,dc=com" -w secret
...

OpenLDAPが問題なく起動したら、ログインユーザーの登録です。

まずは、"user"と"group"を作成します。("organizationalUnit"の作成)

# cat schema.ldif 
dn: dc=suz-lab,dc=com
objectClass: dcObject
objectClass: organization
dc: suz-lab
o: suz-lab

dn: ou=user,dc=suz-lab,dc=com
objectclass: organizationalUnit
ou: user

dn: ou=group,dc=suz-lab,dc=com
objectclass: organizationalUnit
ou: group

# ldapadd -x -D "cn=Manager,dc=suz-lab,dc=com" -w secret -f schema.ldif
adding new entry "dc=suz-lab,dc=com"
adding new entry "ou=user,dc=suz-lab,dc=com"
adding new entry "ou=group,dc=suz-lab,dc=com"

次に、グループを作成します。これがCentOSのグループとなります。

# cat group.ldif
dn: cn=user,ou=group,dc=suz-lab,dc=com
gidNumber: 2000
objectClass: top
objectClass: posixGroup
cn: user

# ldapadd -x -D "cn=Manager,dc=suz-lab,dc=com" -w secret -f group.ldif 
adding new entry "cn=user,ou=group,dc=suz-lab,dc=com"

最後に、ユーザーを作成します。これがCentOSのユーザーとなります。

# cat user.ldif
dn: uid=suzuki,ou=user,dc=suz-lab,dc=com
objectClass: top
objectClass: posixAccount
objectClass: account
uid: suzuki
cn: suzuki
uidNumber: 2001
gidNumber: 2000
homeDirectory: /home/suzuki
loginShell: /bin/bash
userPassword: suzuki123

# ldapadd -x -D "cn=Manager,dc=suz-lab,dc=com" -w secret -f user.ldif 
adding new entry "uid=suzuki,ou=user,dc=suz-lab,dc=com"

次の記事は、"nss-pam-ldapd"のインストールと設定です。がんばろう。。。
--------
http://www.suz-lab.com/

2012年3月2日金曜日

Squidでの中継をドメイン名(DNS名)でアクセス制限

スズキです。

こちらでNATインスタンスにSquidを導入したのですが、
VPCのNATインスタンスを作ってみる(Squid編)
目的は中継するHTTP(S)のアクセスをドメイン名(DNS名)でアクセス制限するためでした。
("iptables"ではIPアドレスとポートの制限までとなります)

ということで、"www.google.co.jp"のみにアクセスできるようにしてみました。
(設定ファイルは下記のとおりです)

# cat /etc/squid/squid.conf
...
acl google dstdomain www.google.co.jp
http_access allow google
http_access deny all

上記のNATインスタンス(Squid)を利用しているサブネット上のEC2から確認してみます。
※NATインスタンスのIPアドレスは"10.0.0.74"です。

▼プロキシーを設定してHTTPアクセス
# curl -x 10.0.0.74:3128 http://www.google.co.jp/
...
成功!
# curl -x 10.0.0.74:3128 http://xxx.xxx.xxx/
...
失敗!

▼プロキシーを設定してHTTPSアクセス
# curl -x 10.0.0.74:3128 https://www.google.co.jp/
...
成功!
# curl -x 10.0.0.74:3128 https://xxx.xxx.xxx/
curl: (56) Received HTTP code 403 from proxy after CONNECT
失敗!

▼HTTPアクセス(透過プロキシーとして利用)
# curl http://www.google.co.jp/
...
成功!
# curl http://xxx.xxx.xxx/
...
失敗!

ということで、ドメイン名(DNS名)でアクセス制限できていることが確認できました。

何回も言いますがHTTPSは透過型プロキシー(Squid)が利用できません...
--------
http://www.suz-lab.com

VPCのNATインスタンスを作ってみる(Squid編)

スズキです。

下記で"iptables"によるNATインスタンスを作成しました。
VPCのNATインスタンスを作ってみる(iptables編)
しかし"iptables"では、アウトバウンドの制限をIPアドレス/ポート単位でしか
できないので、もう少し高度な制限(DNS名など)を可能とするため、
さらにSquidを経由させることにしました。

まずはSquidのインストールです。

# yum -y install squid
# chkconfig squid on
# chkconfig --list squid
squid           0:off 1:off 2:on 3:on 4:on 5:on 6:off

設定ファイルは下記のようにしています。

# cat /etc/squid/squid.conf
visible_hostname unknown
http_port 3128 transparent
forwarded_for off
cache deny all
http_access allow all
http_access deny all

そしてSquidを起動します。

# /etc/init.d/squid start
squid を起動中: ..                                         [  OK  ]

"iptables"は次のように80番のアクセスを3128番にリダイレクトするようにしておきます。

# iptables -t nat -A PREROUTING -i eth0 -s 0.0.0.0/0 -p tcp --dport 80 -j REDIRECT --to-port 3128

これで、HTTPの通信をSquid経由で調整(DNS名での制限など)ができるようになりました。

でも、HTTPSには通用しない...
--------
http://www.suz-lab.com

2012年3月1日木曜日

VPCのNATインスタンスを作ってみる(iptables編)

スズキです。

下記でNATインスタンスを実験する環境ができたので、
VPCのNATインスタンスを作ってみる(環境準備編)
今回は"iptables"を利用して、実際にNATインスタンスとして動作するようにしてみます。

以下、NATインスタンス上での作業です。

まずは、IPv4の転送が有効になるように、カーネルパラメータ
(net.ipv4.ip_forward)を設定(0 → 1)します。

# cat /etc/sysctl.conf
...
# Controls IP packet forwarding
#net.ipv4.ip_forward = 0
net.ipv4.ip_forward = 1
...

そして、その設定を反映します。

# sysctl -p
net.ipv4.ip_forward = 1
...

その後、下記のように"iptables"でIPマスカレードの設定をします。
(ここまででNATインスタンスとして機能します)

# /sbin/iptables -t nat -A POSTROUTING -o eth0 -s 0.0.0.0/0 -j MASQUERADE

念のためIPマスカレードの設定を保存して、次回起動時にも有効になるようにします。

# /etc/init.d/iptables save
iptables: ファイアウォールのルールを /etc/sysconfig/iptable[  OK  ]中: 

このときの"iptables"の設定状態は下記のとおりです。

# iptables --list -t nat
...
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            
...

NATインスタンスが完成したら、TESTインスタンスから接続確認です。

下記でHTTPの通信がNATインスタンス経由で成功していることがわかるはずです。

# curl www.suz-lab.com
...

下記でSSHの通信がNATインスタンス経由で成功していることがわかるはずです

# ssh -i key.pem -l root xxx.xxx.xxx.xxx
...

NATインスタンス経由の通信をIPアドレスやポートで制限する場合は、
iptablesなどでも出来ますが、セキュリティグループや"Network ACLs"で
行ったほうがお手軽だと思います。

下記はセキュリティグループでHTTPとHTTPSのみNATインスタンス経由
で通信できるようにしています。


次は、さらにSquidもからめていきます!
--------
http://www.suz-lab.com

VPCのNATインスタンスを作ってみる(環境準備編)

スズキです。

まずは、NATインスタンスを配置するサブネットを用意します。
このサブネットのルーティングは下記のように"0.0.0.0/0"が
"Internet Gateway"に向くようにしておきます。


そして、このサブネット上にNATインスタンスにするEC2インスタンスを立ち上げ、
他の宛先のトラフィックも受け付けるため、下記のように"Source / Dest Check"を
Disableにします。



"Source / Dest Check"をDisableにするときは、対象をインスタンスかENIか
選択することになりますが、今回はインスタンスを対象にしています。
(といってもインスタンスにデフォルトでついているENIが対象となる)


次に、上記のNATインスタンスを利用するサブネットを用意します。
このサブネットのルーティングは下記のように"0.0.0.0/0"が
NATインスタンスに向くようにします。





下記のように"0.0.0.0/0"がNATインスタンスに向くサブネットができたので、
このサブネット内のインスタンスから、NATインスタンスを経由する
実験が可能な環境ができたことになります。


次回は実際に、"SUZ-LAB謹製 CentOS AMI"をNATインスタンスを調整していきます。
--------
http://www.suz-lab.com

SUZ-LAB謹製 CentOS AMI (6.2.1 64bit ap-northeast-1)

スズキです。

下記をアップデートしました。
SUZ-LAB謹製 CentOS AMI (6.0.5 64bit ap-northeast-1)
AMIを「suz」で検索してもらえれば、
811118151095/suz-lab_ebs_centos-core-x86_64-6.2.1
として見つかるはずです。

アップデート内容は下記の32bitのものと同じになります。
SUZ-LAB謹製 CentOS AMI (6.2.1 32bit ap-northeast-1)

Enjoy!
--------
http://www.suz-lab.com