Network Load Balancer の接続問題の原因を特定する方法を教えてください。

所要時間3分

クライアントが TCP 接続を確立できない理由や、TCP 接続が断続的にリセットされたり、予期しない切断が発生したりする理由を知りたいです。

簡単な説明

Network Load Balancer の接続の問題には、接続タイムアウト、TCP リセット (RST) パケット、断続的な接続障害などがあります。問題の原因を特定するには、Amazon CloudWatch メトリクス、Amazon Virtual Private Cloud (Amazon VPC) フローログ、アクセスログ、およびパケットキャプチャを確認してください。

解決策

CloudWatch メトリクスを確認して接続リセットの原因を特定する

CloudWatch コンソールを開き、以下の Network Load Balancer のメトリクスを確認します。

ActiveFlowCount
NewFlowCount
PortAllocationErrorCount
SecurityGroupBlockedFlowCount_Inbound_TCP
**注: ** セキュリティグループなしで Network Load Balancer を作成した場合、このメトリクスは使用できません。代わりに Amazon VPC フローログを使用して、拒否された接続を特定してください。
TCP_ELB_Reset_Count
TCP_Client_Reset_Count
TCP_Target_Reset_Count

TCP リセットメトリクスで、リセットがクライアント側またはターゲット側から発生したことが示されている場合、問題の原因はロードバランサーではありません。次の操作を実行します。

ターゲット上のアプリケーションまたはサーバーを調査します。アプリケーションログを確認して、アプリケーションが予想されるポートで接続を受け入れることを確認します。
CPU、メモリ、オープンファイルディスクリプタなどのリソース使用率を確認してください。
クライアント側のリセットについては、クライアントアプリケーションのタイムアウト設定を確認してください。また、接続プールの設定と、クライアントおよび Network Load Balancer 間のネットワークパスも確認してください。

Amazon VPC フローログを有効にして分析する

クライアントからのトラフィックが Network Load Balancer に到達するかどうかを確認し、拒否された接続を特定するには、Amazon VPC フローログを使用します。フローログを作成するには、以下の手順を実行します。

Amazon Elastic Compute Cloud (Amazon EC2) コンソールを開きます。
[ネットワークインターフェイス] に移動し、Network Load Balancer 名でフィルタリングします。
Network Load Balancer の Elastic Network Interface (ENI) を入手してください。
Network Load Balancer で Amazon VPC フローログを有効にします。
Amazon CloudWatch Logsに発行する ENI のフローログを作成します。発行先には、Amazon Simple Storage Service (Amazon S3)、または Amazon Data Firehose も指定できます。
[ログレコードの形式] で [カスタム形式] を選択します。次に、以下のフローログフィールドを選択して TCP 接続の詳細情報を取得します: account-id、action、bytes、dstaddr、dstport、end、flow-direction、interface-id、log-status、packets、pkt-dstaddr、pkt-srcaddr、protocol、srcaddr、srcport、start、subnet-id、tcp-flags、type、version および vpc-id。

フローログがデータを収集したら、REJECT ステータスのレコードをチェックして、ネットワークアクセスコントロールログ (ネットワーク ACL) のセキュリティグループがトラフィックをブロックしていないかどうかを確認します。また、tcp-flags フィールドに以下のビットマスク値のみの TCP 接続状態が表示されていることを確認してください。

SYN、値 2
SYN-ACK、値 18
FIN、値 1
RST、値 4

RST フラグの付いたレコードを探して、クライアントまたはターゲットが接続のリセットを開始したかどうかを確認します。次に、srcaddr フィールドと flow-direction フィールドを比較して、リセットがクライアント側のトラフィックから発生したのか、ターゲット側のトラフィックから発生したのかを判断します。

使用可能なフィールドと TCP フラグ値の詳細については、「フローログレコード」を参照してください。TCP フラグシーケンスを示すレコードの例については、「フローログレコードの例」を参照してください。

詳細な接続分析に Network Load Balancer のアクセスログと CloudWatch Logs を使用する

Network Load Balancer は、Amazon VPC フローログを補完する TLS リスナー用のレガシーおよび CloudWatch ロギングオプションを提供します。

レガシーアクセスログは、圧縮されたログファイルを Amazon S3 バケットに保存します。レガシーアクセスログを有効にするには、「Enable access logs for your Network Load Balancer」を参照してください。

CloudWatch ログインテグレーションは、Apache Parquet 形式で CloudWatch Logs、Firehose、または Amazon S3 にアクセスログを配信します。CloudWatch ログを有効にするには、「CloudWatch logs for your Network Load Balancer」を参照してください。

注: どちらのログオプションも TLS リスナーでのみ使用できます。TCP リスナーと UDP リスナーには、Amazon VPC フローログと CloudWatch メトリクスを使用してください。

Network Load Balancer のアクセスログをトラブルシューティングに使用するには、以下の操作を行います。

TLS ネゴシエーション失敗

Network Load Balancer のアクセスログの tls_cipher フィールドと tls_protocol_version フィールドには、暗号スイートと TLS バージョンが表示されます。これらのフィールドの値が「-」の場合、ネゴシエーションが完了する前に TLS ハンドシェイクが失敗したことを示します。ハンドシェイクが失敗した場合は、TLS リスナーのセキュリティポリシーが、クライアントが必要とする TLS バージョンと暗号スイートをサポートしていることを確認してください。Network Load Balancer が受け入れる TLS バージョンと暗号をテストするには、クライアント側から以下の openssl コマンドを実行します。

openssl s_client -connect Network Load Balancer_DNS_NAME:443 -tls1_2

接続に失敗した場合は、-tls1_3 などの異なる TLS バージョンを試して、クライアントと Network Load Balancer が共有するバージョンを確認してください。次に、リスナーのセキュリティポリシーを更新します。

接続レベルのエラー

Network Load Balancer のアクセスログの tls_handshake_time フィールドは、TLS ハンドシェイク遅延の問題を特定するのに役立ちます。tls_handshake_time が異常に大きい値であり、かつ「-」ではない場合、TLS ハンドシェイクは完了しているものの、時間がかかったことを意味します。ハンドシェイクに時間がかかる場合、証明書チェーン検証の遅延や、クライアント側での TLS ネゴシエーションの遅さといった問題が特定できる可能性があります。tls_handshake_time が「-」と表示されている場合、TLS ハンドシェイクは行われなかったか、失敗したということです。クライアントが TCP 接続を確立したことを確認し、リスナーの証明書とセキュリティポリシーの設定を確認します。

クライアント IP アドレスとの関連づけ

Network Load Balancer アクセスログの client_port フィールドは、特定のクライアント接続を追跡するのに役立ちます。このフィールドでログをフィルタリングして、問題が特定のクライアントに影響するのか、それともすべてのクライアントに影響するのかを判断します。問題が特定のクライアントにのみ影響する場合は、それらのクライアントのネットワークパスと TLS 構成を調べてください。すべてのクライアントが影響を受ける場合、問題は Network Load Balancer リスナーの設定またはターゲットにある可能性があります。client_port 値を Amazon VPC フローログおよび CloudWatch メトリクスと相互参照します。

CloudWatch Logs インテグレーションでは、CloudWatch Logs Insights クエリを使用してトラフィックパターンをリアルタイムで分析し、モニタリング用のメトリクスフィルターを作成します。

詳細については、「Access logs for your Network Load Balancer」と「CloudWatch logs for your Network Load Balancer」を参照してください。

パケットキャプチャ分析を実行する

クライアントとターゲットの両方で同時にパケットキャプチャを実行して、接続のリセット動作を確認し、接続切断を開始している側を特定します。

クライアント側で、以下の tcpdump コマンドを実行します。

tcpdump -ni any host NLB_IP -w client_capture.pcap

注: NLB_IP を Network Load Balancer の IP アドレスに置き換えます。

ターゲット側でターゲットに表示されるソース IP アドレスは、クライアント IP 保存を有効にしたかどうかによって異なります。クライアント IP の保存を有効にした場合、ターゲットはクライアントの元の IP を参照します。

クライアント IP アドレスでフィルタリングするには、以下の tcpdump コマンドを実行します。

tcpdump -ni any host CLIENT_SOURCE_IP -w target_capture.pcap

注: CLIENT_SOURCE_IP をクライアントの IP アドレスに置き換えてください。

クライアントの IP 保存をオフにすると、ターゲットには Network Load Balancer のプライベート IP アドレスが表示されます。

Network Load Balancer の Network Load プライベート IP アドレスでフィルタリングするには、以下の tcpdump コマンドを実行します。

tcpdump -ni any host NLB_PRIVATE_IP -w target_capture.pcap

注: NLB_PRIVATE_IP を Network Load Balancer のプライベート IP アドレスに置き換えます。

キャプチャ内の送信元 IP アドレスとフロー方向を確認して、どちら側が接続切断を開始するかを判断するには、以下の操作を行います。

FIN パケットを確認して、接続が正常に終了していることを確認します。どちら側が最初の FIN を送信したかを確認して、接続を終了するエンドポイントを特定します。
RST パケットを確認して、異常な接続終了が発生していないか調べます。ターゲットがリクエストを受信した直後に RST を送信すると、アプリケーションは接続を拒否するかクラッシュします。
再送信を確認して、クライアントとターゲットの間のネットワークパスでドロップされているパケットを特定します。
クライアント側のキャプチャでは完全なリクエストが表示され、ターゲット側のキャプチャでは応答がないことを確認します。ターゲットアプリケーションが応答しないか、ファイアウォールがリターントラフィックをブロックしていないかを確認します。
クライアント側のキャプチャを両側から比較します。両方のキャプチャで同じパケットの交換が正しく行われている場合は、アプリケーションの動作やリソースの使用率など、ターゲット側の要因を調査します。キャプチャが異なる場合は、2 つのキャプチャポイント間のネットワークパスに問題がある可能性があります。