目次
ご挨拶
お疲れさまです、寺井です。
普段よく使用するSSMの一機能であるSession Managerにおいて、想定外の設定ミスで手間取ってしまったため、備忘録としてブログに残しておこうと思います。
経緯と課題
NAT Gatewayを経由したパブリックなインターネットを介さずに、AWSのサービスエンドポイントと疎通する検証のために、まずはSSMのSession Managerでインスタンスに接続しようとしたところで躓きました…。
よくあるSSM接続のトラブルシューティングは全て確認済。
EC2がSSMを実行するための適切な権限が付与されたIAMロールの割り当て
- ［AmazonSSMManagedInstanceCore］AWSマネージドポリシーをアタッチ
VPCエンドポイント(Interface)
- [com.amazonaws.ap-northeast-1.ssm], [com.amazonaws.ap-northeast-1.ssmmessages]の2つを対象のEC2が設置されているプライベートサブネット内に作成
- 対象のVPCでは「DNS名を有効化」がオンになっている状態
- リソースポリシーは設定無し（全て許可）
443ポートによる各所セキュリティグループの設定
- EC2：アウトバウンド すべてのポート・送信先
- VPCエンドポイント：インバウンド 属しているVPC CIDR範囲からの443ポート
「はいはい、いつものやつね」と確認を進めていたのですが、どれを確認しても問題は見受けられず頭を抱えました。
結論
まずはこちらのVPC詳細画面をご覧ください。
お分かりいただけただろうか……………………………
結論、VPCの名前解決(DHCPオプションセット)に問題がありました😕
本来デフォルトの設定のままであれば、DHCPオプションセットには『Amazon Provided DNS (現：Amazon Route 53 Resolver)』 が割り当てられています。
Amazon Provided DNSは作成したVPCの内部（VPC CIDRアドレス +2）からアクセスできるため、パブリックなインターネットに出ることなく、プライベートサブネット内での名前解決が可能になります。
今回は別の検証の兼ね合いで、別のパブリックDNSを参照させるために、DHCPオプションセットを変更していたことから発生した問題でした。😋
NAT Gatewayを設置していないプライベートサブネットからのトラフィックがパブリックDNSへ到達せず、SSMのエンドポイントの名前解決に失敗していたようです。
完全に想定外でした…。
調査
以降は問題解決に至った経緯をつらつらと載せていきます。
OSは「Amazon Linux 2023」を使用しています。（SSMエージェントがインストール済）
今回はSSMのトラブルシュートに焦点を当ててますので、EC2の起動方法やその他設定周りに関しては言及していません。
パブリックサブネットに設置した踏み台EC2からSSH接続
同VPC内のパブリックサブネットに踏み台サーバを設置して、プライベートサブネットのEC2にSSHアクセスして調査します。
◯各インスタンスのプライベートIP
- 踏み台サーバのプライベートIP：10.0.15.220
- 接続先サーバのプライベートIP：10.0.132.208
SCP等で接続用の秘密鍵を設置し、対象のサーバにSSH接続します。
$ chmod 600 {秘密鍵のパス}
$ ssh -i {秘密鍵のパス} ec2-user@10.0.132.208SSMエージェントの状態を確認
$ sudo systemctl status amazon-ssm-agent
● amazon-ssm-agent.service - amazon-ssm-agent
Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-05-20 02:19:56 UTC; 2h 14min ago
Main PID: 1594 (amazon-ssm-agen)
Tasks: 9 (limit: 1060)
Memory: 22.5M
CPU: 557ms
CGroup: /system.slice/amazon-ssm-agent.service
mq1594 /usr/bin/amazon-ssm-agent
May 20 03:07:05 ip-10-0-132-208 amazon-ssm-agent[1594]: caused by: Post "https://ssm.ap-northeast-1.amazonaws.com/": dial tcp: lookup ssm.ap-northeast-1.amazonaws.com on 8.8.4.4:53: read udp 10.0.132.208:34921->8.8.4.4:53: i/o timeout
May 20 03:07:05 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:07:05 INFO [Registrar] sleeping for 34.68333333333333 minutes before retrying registration
May 20 03:41:46 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:41:46 INFO [EC2Identity] Checking disk for registration info
May 20 03:41:46 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:41:46 INFO [EC2Identity] No registration info found for ec2 instance, attempting registration
May 20 03:41:46 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:41:46 INFO [EC2Identity] Found registration keys
May 20 03:41:46 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:41:46 INFO [EC2Identity] Checking write access before registering
May 20 03:41:46 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:41:46 INFO [EC2Identity] Registering EC2 instance with Systems Manager
May 20 03:42:34 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:42:34 ERROR [Registrar] failed to register identity: error calling RegisterManagedInstance API: RequestError: send request failed
May 20 03:42:34 ip-10-0-132-208 amazon-ssm-agent[1594]: caused by: Post "https://ssm.ap-northeast-1.amazonaws.com/": dial tcp: lookup ssm.ap-northeast-1.amazonaws.com on 8.8.4.4:53: read udp 10.0.132.208:40670->8.8.4.4:53: i/o timeout
May 20 03:42:34 ip-10-0-132-208 amazon-ssm-agent[1594]: 2024-05-20 03:42:34 INFO [Registrar] sleeping for 80.91666666666667 minutes before retrying registration『ssm.ap-northeast-1.amazonaws.com』の名前解決のために『8.8.4.4:53』にアクセスしようとしてタイムアウトエラーが発生してますね…。
名前解決してみる
$ dig
; <<>> DiG 9.16.48-RH <<>>
;; global options: +cmd
;; connection timed out; no servers could be reached当然ですが到達しませんでした。
修正
VPCのDHCP オプションセットを変更
対象のVPCを選択 →VPC の設定を編集 →デフォルト(※)のDHCP オプションセットに変更
※ドメインネームサーバーが「AmazonProvidedDNS」となっているもの
インスタンスのDNS設定を再読み込み
インスタンスを再起動するだけでOKでした。
停止～開始は必要ないみたいですね。（ﾍｪ~
(再)名前解決
$ dig
; <<>> DiG 9.16.48-RH <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49304
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 20 IN NS b.root-servers.net.
. 20 IN NS c.root-servers.net.
. 20 IN NS d.root-servers.net.
. 20 IN NS e.root-servers.net.
. 20 IN NS f.root-servers.net.
. 20 IN NS g.root-servers.net.
. 20 IN NS h.root-servers.net.
. 20 IN NS i.root-servers.net.
. 20 IN NS j.root-servers.net.
. 20 IN NS k.root-servers.net.
. 20 IN NS l.root-servers.net.
. 20 IN NS m.root-servers.net.
. 20 IN NS a.root-servers.net.
;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Mon May 20 07:32:14 UTC 2024
;; MSG SIZE rcvd: 239無事10.0.0.2(AmazonProvidedDNS)で名前解決が成功しました！👏
SSMエージェントのステータスチェック
$ systemctl status amazon-ssm-agent
● amazon-ssm-agent.service - amazon-ssm-agent
Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-05-20 07:32:04 UTC; 1min 8s ago
Main PID: 1576 (amazon-ssm-agen)
Tasks: 18 (limit: 1060)
Memory: 58.4M
CPU: 315ms
CGroup: /system.slice/amazon-ssm-agent.service
tq1576 /usr/bin/amazon-ssm-agent
mq1623 /usr/bin/ssm-agent-worker
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [EC2Identity] EC2 registration was successful.
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [amazon-ssm-agent] Registration attempted. Resuming core agent startup.
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [CredentialRefresher] credentialRefresher has started
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [CredentialRefresher] Starting credentials refresher loop
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO EC2RoleProvider Successfully connected with instance profile role credentials
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [CredentialRefresher] Credentials ready
May 20 07:32:04 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:04 INFO [CredentialRefresher] Next credential rotation will be in 29.999991199883333 minutes
May 20 07:32:05 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:05 INFO [amazon-ssm-agent] [LongRunningWorkerContainer] [WorkerProvider] Worker ssm-agent-worker is not running, starting worker process
May 20 07:32:05 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:05 INFO [amazon-ssm-agent] [LongRunningWorkerContainer] [WorkerProvider] Worker ssm-agent-worker (pid:1623) started
May 20 07:32:05 ip-10-0-132-208 amazon-ssm-agent[1576]: 2024-05-20 07:32:05 INFO [amazon-ssm-agent] [LongRunningWorkerContainer] Monitor long running worker health every 60 secondsSSMエージェントのステータスも問題なさそうです。😌
マネジメントコンソールのSSM接続画面からも対象のインスタンスが確認できました💪
余談
完全に余談ですが、パブリックサブネットにあるEC2からエンドポイント名を名前解決したときの挙動って、エンドポイントの有り無しで変わるのかな？と思って試してみました。
パブリックな解決 or プライベートな解決 どっちが勝つんでしょうか？🤔
VPCエンドポイントがないとき
$ dig +short ssm.ap-northeast-1.amazonaws.com.
52.119.221.73
$ dig +short ssm.ap-northeast-1.amazonaws.com.
99.77.58.18当然ですけどパブリックIPが帰ってきますよね。
2つのIPで冗長化されているみたいでした。
VPCエンドポイントがあるとき
$ dig +short ssm.ap-northeast-1.amazonaws.com.
10.0.10.235プライベートIPが返されました！
ちゃんと優先して使用されるようですね。
よくよく考えたら、ロンゲストマッチでインターネット向けの経路（0.0.0.0/0 -> IGW）より、エンドポイント向けの経路（10.0.0.0/16 -> local）が優先されたってことでしょうか。
感想
気づいたらなんてことはないんですけど、完全に死角で結構な時間を費やしてしまいました…。
これからはもっと視野を広く確認すべきだなぁと実感しました。
ありがとうございました！👏
好きなこと：音楽、猫、お酒、ゲーム、効率化
経歴：テレビ業界AD → 通信回線販売代理店 → IT関連職業訓練 → 株式会社ディーネット