先日書いた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で一括管理が正解ということか。
