Simpline BlogNATインスタンスとNetwork ACL

NATインスタンス経由でPrivateサブネットからインターネットにyum update等ができるNetwork ACL設定をしようとして上手く行かずに手間取った。笑われそうだけど。

間違ったNetwork ACL

こんな設定で通信可能なのではないかと考えた。下記は誤った設定例だけど、SSHログイン用の設定等は見易くする為、省略。切り分けの為、Security Groupは一旦ALL Allowのままでテスト。

• Private用Network ACL（誤り）

• Public用Network ACL

通信テスト（失敗）

Private SubnetにLaunchしたEC2から「yum updateinfo」をしてみた。

PRIV# yum clean all && yum updateinfo
Loaded plugins: priorities, update-motd, upgrade-helper
Cleaning repos: amzn-main amzn-updates
Cleaning up everything
Loaded plugins: priorities, update-motd, upgrade-helper
Could not retrieve mirrorlist http://repo.ap-northeast-1.amazonaws.com/latest/main/mirror.list error was
12: Timeout on http://repo.ap-northeast-1.amazonaws.com/latest/main/mirror.list: (28, 'Connection timed out after 10001 milliseconds')

なぜか接続できないので、updateinfo中に通信状況を確認してみた。

PRIV# netstat -ant | grep :80
tcp 0 1 xxx.xxx.xxx.xxx:56069 54.231.224.50:80 SYN_SENT

SYNパケットを投げたまま待ちになっている？？？しかも通信先はNATではなく、yum repositoryになっている？？？

ということで、NACLが適切ではないのでは？と修正をしてみたのでした。

Private用Network ACL修正版

ということで、Private用Network ACLを下記のように修正してみた。yumの通信先をNAT想定の「（VPC CIDR）」からInternet環境想定の「0.0.0.0/0」にしたら上手く行ったのでした。

• Private用Network ACL（修正版）

ということは、Public用Network ACLの80ポート許可設定が不要では？と思ったけど、Allow設定を削除したらyum updateはできなくなった。Security GroupのOutboundは通常ALL Allowしてしまうのだけど、同じ挙動になるのだろうか。余裕があるときに。

ちなみに戻りのパケット用のハイポート開放はOSが限定されていればもう少し絞れる。お世話になりっぱなしのこちらで復習。

ネットワークは難しいです。