Simpline BlogNetwork ACLでハマった話

先日書いたNATインスタンス経由での通信に続き、Network ACLでハマったので、記録を残そうかと。

Network ACLはステートレス

はい。応答の通信も評価の対象になるのですよね。ちゃんと推奨される設定も確認していたのです。今回はLinux環境だったので、Ephemeralポートは32768～61000であることも理解はしていたつもりでした。

NTPで同期できない

そんなVPC環境でLinuxサーバをばんばん立てていたら、NTPが同期できていないことが発覚。123/udpのOutboundは開放していたけど、UDPの応答通信のことを何も考えていなかったと気付いて調査開始。tcpdumpしながら、ntpdateを叩いてみた。

# tcpdump port 123 -nn
(SRC IP).123 > (DST IP).123
(DST IP).123 > (SRC IP).123

NTPはソースポートも123を使うということを初めて知った。ということで、戻りの通信用に123/udpのInboundも許可して問題解決。ちなみにステートフルなSecurity GroupではInboundの開放は必要ありません。

DNSも同じかと思いきや

53/udpのOutboundしか開放していなかったので、DNSも同じように調査。

# tcpdump port 53 -nn
(SRC IP).42520 > (DST IP).53
(DST IP).53 > (SRC IP).42520
(SRC IP).50316 > (DST IP).53
(DST IP).53 > (SRC IP).50316
(SRC IP).42408 > (DST IP).53
(DST IP).53 > (SRC IP).42408

あれ。DNSのソースポートはEphemeralを使うのか。Ephemeralポート/udpのInboundも許可設定が必用そうだなと、思ったのだけど。

VPC用DNSはNetwork ACL開放不要

開放しなくても名前解決できている？どうやらAWSさんが裏で上手いことやってくれているようです。公式なドキュメント等は見つけられなかったけど、VPC用のDNS（VPC CIDRブロック+2）に対してはNetwork ACLで明示的な開放をしなくても動作上は問題無かった。

ということで独自DNSを使う場合はEphemeralポート/udpのInboundも開放が必要。SNMPの161/udpも同じように確認したら、Ephemeralポートをソースに使うようなので、とりあえず開放でも良いのかなと。というか、Network ACLでは余計なことはせずに、FirewallはSecurity Groupで一括管理が正解ということか。