★AWS上でのiptables

私のサーバでは、一部のサービスをJP Regionからの接続に限るため、iptablesを使ってます。

EC2のセキュリティグループを使わない理由は…

$ sudo iptables -L -n | wc -l
4235

ルールの最大数はデフォルト50、申請しても250ですから、とても無理なのです。1つのインスタンスに複数のセキュリティグループ割り当てられるとはいえ、何かトラブルが起きそうな予感しかしないですし…

なんでそんなにルール数が多くなるかというと、APNICが公開しているIPの割当表から、JPだけを許可するルールを生成しているからですね。

TCP wrapperで行うことも考えたのですが、dovecot等のアプリが対応してなかったこと、逆引きはやろうと思えば.jpを名乗るのは容易いこと、で、今回はTCP Wrapper案はパスしました。

まあ、変換して INPUT rule を作るのは何のトラブルもなく…

トラブルは OUTPUT のほうで起きました。

今回サーバでは、ホントにサーバとしか使わないので、通常時にサーバ側からコネクション貼るのは SMTP のみです。(通常時以外でも、メンテ時に yum updateのコネクション程度です)。そこで

# sudo iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# sudo iptables -P OUTPUT DROP

こうやって、sshが繋がることを確認。

再起動

……あれ？　繋がらない

昨日の日記のやりかたで、設定を戻して、iptables の設定をくまなく見てみる。何もない…

3way handshake の設定がきちんとできているか不安になってきました。OUTPUT の policy が ACCEPT だった時には動いていたので、INPUT のルールは間違っていない。ということは SYN を受け取って、ACK/SYN を返せていないのではないか、という疑問をいだきます。

こうやって設定すれば動くのかなぁ？

再起動

……繋がらない

(5ループほど略 orz)

iptables -A OUTPUT -j LOG してみたところ、判明しました。(送信側アドレス書き換えてます)

IN= OUT=eth0 SRC=123.456.78.90 DST=169.254.169.254 LEN=60 TOS=0x00 PREC=0x00 TTL=255 ID=40017 DF PROTO=TCP SPT=52896 DPT=80 WINDOW=26883 RES=0x00 SYN URGP=0

……何だよこのアドレス……

もちろん169.254なので LINKLOCAL-RFC3927-IANA-RESERVED です。Amazonが持っているに決まってます。

検索してみたところ、こんなヘルプページが見つかりました。

どうも、このIPアドレスに対してHTTP requestを行うと、何やらいろいろ情報が取れるようです。ドキュメントには取得だけが書いてありますが、そのほかの隠し仕様があるかはわかりません。

というわけで、予想です。

AWSの各インスタンスは、起動時に 169.254.169.254 にアクセスし、インスタンスの起動ビーコンを送っている。これが確認できたら、AWS側でFWをあける。ビーコンが確認できなければFWが閉じたままになるので、上記の試行で接続できなかった。

まあ、FWとしては正しい設定の気もします。(どこにもドキュメント無さそうなのが問題ではありますが。あるいは私の探し方が悪いか…)

実際に以下の設定を追加したら、きちんと起動され、sshも繋がるようになりました。(実際にはhttpsとsmtpも同時に許可設定しました)

# sudo iptables -A OUTPUT -p tcp --dport http -j ACCEPT

………何回もサーバ止めて再起動してたせいで、Elastic IP Addressの未使用期間として課金されました。助けてママン；；