NetworkACLを使った構成でオンプレミスとの通信で特殊な挙動で特定の通信が出来なかったケースの共有です。
【事象】
・特定のEC2からオンプレミスの特定IPに通信が出来ない
・オンプレミスのサーバへTCP及びUDPの通信が間欠で通信できない
【原因】
TransitGatewayアタッチメント経由での通信がNACLで制限されていた
【環境】
・DirectConnect及びTrasnitGateway所持アカウント(DX集約アカウント)
・TrasnitGatewayアタッチメント付与アカウント(アカウントA)
アカウントAはプライベートサブネットaz-aとプライベートサブネットaz-c、パブリックサブネット×2(未使用)で構成され、プライベートサブネットaz-cをデプロイ検証用のクローズネットワークとしてNACLでオンプレミス、プライベートサブネットaz-aとの通信を制限していた。
当該事象が発生していたEC2はプライベートサブネットaz-aに所属
TrasnitGatewayアタッチメントはプライベートサブネットa-zとプライベートサブネットaz-cに所属
構成図
【ハマリポイント】
オンプレミス→DirectConnect→DirectConnectGateway→TrasnitGateway→TrasnitGatewayアタッチメントの通信でプライベートサブネットaz-aへのルーティングでもプライベートサブネットaz-cのTransitGatewayアタッチメントを経由して通信して通信の制限がされていた。
上記の仕様はドキュメントには公開されておらず、AWSサポートに問い合わせをして判明しました。
てっきりプライベートサブネット#1への通信はプライベートサブネットaz-aのTrasitGatewayアタッチメントを通っている認識でした。
ラウンドロビンなどでどちらからのTrasnitGatewayアタッチメントを経由しているなどの通信ロジックは非公開とのことでした。
ハマった要因としてはすべて通信出来るわけではなく、送信元サブネットの特定範囲(例えば192.168.1.0/24の場合は前半の120までは通信できて120以降はNGなど)のEC2が通信出来ない、オンプレミス先の通信も特定のIPのみ通信出来ないという事象であった為NACLでの制限ではなくオンプレミス側のFW装置などで通信が止まっていると思い込みをしてしまったことにあります。
tracerouteもDirectConnectルータで止まっていた(169.254.xx.xxのDirectConnect用のIPではなくルータの実IP)のでオンプレミス側を疑ってしまった。
【対策】
対策としてはTrasitGatewayアタッチメントの専用サブネットを作成してNACLなどの制限をかけるサブネットと分ける。VPCのサブネット間はNACLで許可する。でした。
完全に通信できなくなるわけではなく特定のIPだけつながらない、IP重複・MACアドレス重複時のような通信が欠落するような場合はNACLで止まっていないか確認してみてください。
VPC flow logsにはTGW経由だとTGWに付与されるENIのIPが表示されるみたいなのでTGW経由の通信を確認する場合はVPCフローログのカスタム形式として、「pkt-srcaddr」と「pkt-dstaddr」を追加で取得した方が良さそうです。
今回検証用にサーバのコピーを作成してアウトバウンド通信を制御する必要がありましたのでNACLを利用しましたが、予期せぬ通信制御が行われてしまい本来行いたかった制御が出来なかったためセキュリティグループのアウトバウンド制御に切り替えをしました。
動作確認用にDirectConnect経由で通信する必要がありましたので本番VPCを利用しましたが完全に閉じた検証ができる場合はVPCを分けるほうがシンプルかつ影響が少なくて良いと思います。
NACLを利用する場合、Amazon Provided DNSなどのAWSリソースへの通信も制御されてしまいますのでNACLをどうしても利用したい場合は詳細な設計を行う必要がありますのでご注意ください。
参考リンク
ネットワーク ACL とトランジットゲートウェイの動作
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-nacls.html
