Google CloudがPrivate Service ConnectベースのGKEクラスタの接続タイムアウト調査を紹介、challenge ACKの破棄を特定

公開：2026年11月2日

CodeCampが提供するDX人材育成が可能なプログラミングやITが学べる公開講座

Google Cloudは、Private Service ConnectベースのGKEクラスタで起きた接続タイムアウトを調査しました。2026年2月から3月のこの事例では、USPSの変更でchallenge ACKが破棄され、古い状態を消す流れが壊れたことで接続タイムアウトに至りました。^[1]

この記事では、Podからkube-apiserverまでの経路と、challenge ACKの破棄の仕組みを解説します。USPS変更のロールバック後の状況と、Private Service ConnectベースのGKEクラスタでPod接続がi/o timeoutになる場合の照合項目も扱います。

Private Service ConnectベースのGKEクラスタの接続タイムアウト事例
パケットキャプチャを含む調査の内容
USPS変更のロールバック後の変化
Private Service ConnectベースのGKEクラスタのPod接続事例との照合

Private Service ConnectベースのGKEクラスタの接続タイムアウト事例

Private Service ConnectベースのGKEクラスタでは、PodのAPI呼び出しはローカル接続のように見えても長い経路を通ります。2026年2月から3月の事例では、USPSの変更によるchallenge ACKの破棄が、古い状態を消す流れを壊し、接続タイムアウトにつながりました。^[1]

kube-apiserverへの経路

Private Service ConnectベースのGKEクラスタでは、例えばPodが制御プレーン向けに1.2.3.4:443へ接続する場合、このIPは仮想エンドポイントです。接続は制御プレーンへ直接届かず、Googleのネットワーク基盤が途中で受け取る仕組みです。

図1　Podからkube-apiserverまでの経路

Podの接続は、Worker Node、PSC NAT+Proxy、ILB、KCP VM NICを経てkube-apiserverへ届きます。途中でPrivate Service ConnectエンドポイントのNATとinternal passthrough Network Load Balancerを通ります。

KCP VMのEnvoyは、kube-apiserverプロセスの手前で動くローカルプロキシです。Private Service Connectは新しい接続ごとにproxy protocolヘッダを付け、kube-apiserverは実際のクライアントIPを確認できます。

challenge ACKの役割

challenge ACKは、RFC 5961が定めるTCPのセキュリティの仕組みです。サーバーは既存の接続や閉じて間もない接続の状態に一致するSYNをそのまま受け入れず、challenge ACKを返します。

図2　challenge ACKの本来の流れ

TCP接続が終了したあとも、サーバー側はシーケンス番号を短時間覚えている場合があるためです。その直後に同じ送信元ポートと宛先ポート（同じ5-tuple）で新しい接続が届くと、カーネルからは古い接続の残りや攻撃者の注入に見える可能性があります。

FIN_WAIT_2のサーバーが古い接続のシーケンス番号を載せたchallenge ACKを返すと、正当なクライアントは接続が古いと認識してRSTを送り、状態を消します。状態が消えたあと、サーバーが次のSYNを通常どおり受け入れるのが本来の流れです。

Python研修一覧はこちら

目的に合うPython研修を一覧形式から探したい方は、ぜひご利用ください。

Python研修を比較する

Java研修一覧はこちら

目的に合うJava研修を一覧形式から探したい方は、ぜひご利用ください。

Java研修を比較する

PHP研修一覧はこちら

目的に合うPHP研修を一覧形式から探したい方は、ぜひご利用ください。

PHP研修を比較する

新入社員研修

目的に合う新入社員研修を一覧形式から探したい方は、ぜひご利用ください。

新入社員研修を比較する

全ての研修からも探したい方はこちら

USPS変更による破棄

USPSの変更は、Private Service Connectのproxy protocol処理にある正当なセキュリティ問題の修正でした。影響の一部として、USPSは接続確立の途中で「invalid ACK」と分類したパケットを破棄するようになりました。

図3　USPS変更の前後で変わった点

USPSがinvalid ACKと分類したのは、最初のSYN-ACKの送信前に届くACKです。challenge ACKもSYNへの応答として新しいハンドシェイクの完了前にサーバーから届くため、USPSには無効に見え、通知なく破棄されました。

challenge ACKの仕組みは、challenge ACKが通る場合に働きます。USPSの変更は、GKEのTCPスタックが古い状態の消去に依存していた流れを壊しました。

NATで5-tupleが衝突する理由

Private Service ConnectはNATを使い、1つの公開エンドポイントを多数のクライアントPodで共有します。別のノードや別の名前空間のPodでも、NAT後は同じ送信元ポートを使う場合があります。

図4　GKEでchallenge ACKが増える要因

Private Service ConnectベースのGKEクラスタでは5-tupleの衝突が高い頻度で起き、challenge ACKは直接接続よりはるかに多く発生しました。challenge ACK自体は以前から存在しており、USPSの変更が新たに加えたのは破棄の動作でした。

パケットキャプチャを含む調査の内容

Google Cloudの調査には、パケットキャプチャを分析する系統がありました。その間に別のチームは、Private Service Connect基盤の内部指標を調べました。^[1]

Wiresharkのパケット列

Google Cloudは、KCP VMのNICであるPIGvインターフェースとkube-apiserverコンテナ内部で、パケットを同時に取得しました。PodのSYNはKCP VMのNICに届いていましたが、TCPハンドシェイクの2段階目のSYN-ACKではなく、以前の接続に属するACKが返っていました。

図5　パケットキャプチャで確認された内容

プロトコル解析ツールWiresharkの次の記録は、送信元ポート53426が再利用された際に観測された、失敗したハンドシェイクの抜粋です。

# 2 minutes later, same port 53426 is reused for a new connection
09:13:44  10.0.13.77    53426 →  10.117.0.2    443   [SYN] Seq=1498 ← NEW connection
           (expected: SYN-ACK)
           (received: ACK Seq=1498 Ack=1025 — belongs to PREVIOUS stream)
09:13:44  10.0.13.77    53426 →  10.117.0.2    443   [SYN] Retransmit...
09:13:44  10.0.13.77    53426 →  10.117.0.2    443   [SYN] Retransmit...
                                                    → eventually: i/o timeout

公式資料からの抜粋：When the Kubernetes API went silent: A three-layer networking mystery（Part two: Tracing the ghost in the wire / What the packets revealed）。対象版・範囲：2026年2月から3月の事例。

上記のパケット列では、ポート53426のSYNにSYN-ACKではなく前の接続のACKが返り、SYNの再送の末にi/o timeoutへ至っています。Wiresharkはこのストリームに「TCP Port numbers reused」という表示を付けていました。

Python基礎・実践(Django)

企業・法人向けのPython研修では、基礎から応用まで体系的に学べます。

Python研修の詳細

DX社員研修

企業・法人向けのDX研修では、実務に繋がるリスキリングでITレベルを向上させます。

DX研修の詳細

Javaエンジニア育成研修

企業・法人向けのJavaエンジニア育成研修では、Javaの基礎から応用まで確実に習得できます。

Java研修の詳細

新卒・新入社員向け研修

企業・法人に新入社員・新卒社員に向けたプログラミング研修を提供しています。

新入社員研修の詳細

コードキャンプのIT研修を全て見る

KCP VMに残った接続状態

KCPサーバーがFIN,ACKを送り、クライアントはFIN,ACK、続いてACKで応答しました。KCPサーバーはFIN,ACKより先にACKを受け取り、FIN,ACKにACKを返さずACKの再送を続け、RSTでも状態は消えませんでした。

図6　KCPサーバーとクライアントのパケット順序

KCP VMは、数分前に終わった別の接続に属するACKを新しいSYNへ返していました。古い接続も同じ送信元ポート53426を使っており、KCP VMはこの接続を完全には手放していませんでした。

Andromedaの指標の急増

Google Cloudの別のチームは、Private Service Connect基盤、特にUSPSの内部指標を調べました。USPSは、Private Service Connect接続のNATやproxy protocolヘッダ付与を担うGoogleのソフトウェアスイッチ層です。

図7　invalid ACK破棄の指標の変化

Googleのネットワーク基盤Andromedaの指標Proxy protocol drop: invalid ACK packetは、数か月横ばいでした。その後の2026年2月に、影響を受けたeurope-westリージョンにわたり毎秒数件へ急増しました。

急増の時期と一致するのは、USPSのバージョンロールアウトです。このバージョンには、別のバグを修正する変更が含まれていました。

USPS変更のロールバック後の変化

Google Cloudは2月にUSPSの変更をロールバックし、challenge ACKを破棄せず通す以前の動作へ戻しました。Proxy protocol drop: invalid ACK packetの発生率が基準の水準へ向けて下がったのは、ほぼ直後でした。^[1]

図8　USPS変更のロールバック後の状況

利用企業は、2026年3月上旬までに、影響を受けたすべてのクラスタの回復を確認しました。タイムアウトエラーも発生しなくなりました。

Google Cloudはこのロールバックを修正ではなく応急処置と位置付け、システムが意図せず依存していた動作を戻したものとしています。KCP VMがFIN_WAIT_2に2分以上留まった理由はロールバックの時点で答えが出ておらず、調査はPart 3へ続きました。

Private Service ConnectベースのGKEクラスタのPod接続事例との照合

Private Service ConnectベースのGKEクラスタでPodの接続がi/o timeoutになる場合に、編集部が整理した照合項目は、以下の通りです。

接続：Private Service Connectベースか／時期：2026年2月から3月上旬に重なるか／地域：影響を受けたeurope-westリージョンか／応答：パケットキャプチャ取得時、SYNに以前の別の接続の場違いなACKが返るか／表示：パケットキャプチャ取得時、WiresharkにTCP Port numbers reusedが出るか／扱い：一致してもchallenge ACKの破棄が原因と決めず切り分けに使う

応答と表示の項目は、パケットキャプチャを取得できる場合の確認点です。項目が一致しても、challenge ACKの破棄が原因とは決めず、切り分けの材料として扱うのがよいでしょう。

2026年2月の事例では、影響を受けたeurope-westリージョンでProxy protocol drop: invalid ACK packetが急増しました。europe-west以外のリージョンで同じ症状がある場合も、地域名で無関係と判断せず、SYNへの応答を確かめるのがよいでしょう。^[1]

出典