EC2環境へのインストール等を行わずに、ALBのヘルスチェック通信が到達していることを確認する

はじめに

想定読者

インターネット向けALBから、プライベートサブネットのEC2に負荷分散したい方
EC2には環境の変更を加えたくない（ミドルウェアインストール等は行いたくない）方
ALBのヘルスチェック通信がEC2に到達していることを確認したいが送信元がどこかわからない方

前提条件

ざっくりこんな感じの構成
- インターネット向けALBを利用
- Amazon Linux EC2（Amazon Linux 2023）をプライベートサブネットに配置
特段の制約が無ければ、EC2にhttpd等をインストールして、ヘルスチェックポートで待ち受けるサービスを起動する、というのが、ヘルスチェック成功という形で確認できるので個人的には比較的簡単な疎通確認方法なのではと思っていますが、構築した環境がお客様への納品物であったり、自社環境であっても商用環境である場合等、ミドルウェアのインストールは避けたいケースもあるかと思います。

条件を満たす方法はいくつかあるかと思いますが、今回は、LinuxやMAC含むUNIX系の多くで標準搭載されている、「tcpdump」コマンドで通信をキャプチャする方法をご紹介します。

確認方法

早速やってみましょう

まずは、ヘルスチェック対象のEC2に接続します。

スーパーユーザーとして「tcpdump」コマンドを実行します。今回確認したいのはヘルスチェックポート（私の環境では、「80」で設定済み）のみなので、「port 80」でフィルターします。「sudo tcpdump port 80」として実行すると、以下のように結果が出力されます。

ヘルスチェック通信が届いていない・・・？

ここで私は、ALBのDNS名か名前解決したIPあたりで結果が拾えると踏んでいたのですが、、、ALBのDNS名でも、IP（hostコマンドで確認）でも、いずれで探してもみつかりませんでした。

結論から言うと、ヘルスチェック通信が対象のEC2に到達していなかったのではなく、 探しているキーワードが間違っていました。 ALB⇔EC2の通信はVPC内通信のため、確認すべきは プライベートIP（プライベートDNS名）ですね。

ネットワークインターフェースからALBのプライベートIPを確認

ALBのプライベートIPはEC2機能の「ネットワークインターフェース」から確認できます。私の環境の場合、プライベートIPは「10.8.1.112」「10.8.0.7」のようです。

tcpdump結果を再確認

改めてtcpdump結果を確認すると・・・・プライベートIP「10.8.1.112」「10.8.0.7」と思しき結果（「ip-10-8-1-112.ap-northeast-1.compute.internal」「ip-10-8-0-7.ap-northeast-1.compute.internal」からターゲットへのhttp通信）が出力されています。

IPを確認

念のため、「ip-10-8-1-112.ap-northeast-1.compute.internal」「ip-10-8-0-7.ap-northeast-1.compute.internal」のIPをhostコマンドで確認します。問題ないですね。これでヘルスチェック通信がEC2に到達していることの確認が取れました！