カーネルデータパスクイズ

このクイズでは、リンクローカル範囲のインターセプト、iptablesの競合、conntrackの動作に関するカーネル層の仕組みを確認します。

多肢選択問題

1. Latticeによるリンクローカル範囲の使用が「リンクローカルの意味に厳密には従っていない」と説明されるのはなぜですか？
   • A) 実際にはパブリックIPアドレスである
   • B) 169.254.0.0/16は通常ルーティング不能だが、LatticeトラフィックはVPC内のingressエンドポイントに到達する必要があるため、インフラがそこへ誘導する
   • C) IPv4のみがサポートされている
   • D) DNSでこの範囲を解決できない

回答を表示

回答: B) 169.254.0.0/16は通常ルーティング不能だが、LatticeトラフィックはVPC内のingressエンドポイントに到達する必要があるため、インフラがそこへ誘導する

解説: Latticeはリンクローカル範囲を本来の「ルーティング不能アドレス」という意味では使いません。「インフラがインターセプトする」という信号として範囲を再利用しています。 パケットは実際にVPC内のingressエンドポイントへ到達する必要があります。同じ理由から、IPv6ではリンクローカル（fe80::/10）ではなく、ルーティング可能なULA（fd00:ec2:80::/64）を使います。リンクスコープでは不十分です。

2. SidecarメッシュとLatticeトラフィックが競合するのは、カーネル内のどの位置ですか？
   • A) ノードのnet namespaceにあるPOSTROUTING
   • B) Podのnet namespaceにあるOUTPUTフック。Lattice宛てのトラフィックも送信方向のため、REDIRECTルールに一致する
   • C) NICドライバーのリングバッファー
   • D) ノードのルーティングテーブル

回答を表示

回答: B) Podのnet namespaceにあるOUTPUTフック。Lattice宛てのトラフィックも送信方向のため、REDIRECTルールに一致する

解説: メッシュのinitコンテナは、Podのnet namespace内にiptablesルールを設定して、送信トラフィックをすべてEnvoyのポートへREDIRECTします。Lattice宛ての通信も送信方向なのでルールに一致しますが、Envoyは自身のクラスタ設定から169.254.171.xを見つけられず、失敗します。netfilterルールはnet namespaceごとに適用されるため、競合はPod内で発生します。

3. インターセプトされたリクエストはどのように診断すべきですか？
   • A) カーネルパニックを引き起こす
   • B) 実際のEnvoy送信ポリシー、ルート、エラーを調べる。不明な宛先は転送または拒否される可能性がある
   • C) Podが直ちにCrashLoopBackOffに入る
   • D) kube-proxyが警告を記録する

回答を表示

回答: B) 実際のEnvoy送信ポリシー、ルート、エラーを調べる。不明な宛先は転送または拒否される可能性がある

解説: プロキシログでリクエストが確認できても、プロキシを通過したことが分かるだけで、特定の失敗原因が証明されたわけではありません。直ちに失敗すると決めつけず、選択されたバイパスや署名の動作を確認してください。

4. 例外CIDRを登録したのに「ときどき」失敗します。最も可能性が高い原因は何ですか？
   • A) ルールの順序が間違っている
   • B) IPv6範囲（fd00:ec2:80::/64）が抜けている。デュアルスタックではIPv6で接続するクライアントもインターセプトされる
   • C) Podが再起動されていない
   • D) Security Groupルールが不足している

回答を表示

回答: B) IPv6範囲（fd00:ec2:80::/64）が抜けている。デュアルスタックではIPv6で接続するクライアントもインターセプトされる

解説: デュアルスタッククラスターでIPv4だけを除外すると、AAAAレコードを受け取ってIPv6で接続するクライアントは引き続きインターセプトされます。「ときどき失敗する」という症状が特徴的なのは、DNS応答の順序とクライアントのアドレス選択に左右されるためです。Cも実際に起こり得る原因ですが、その場合はそのPodで一貫して失敗し、「ときどき」とはなりません。

5. egressプロキシ方式ではUIDベースの例外ルールが必須なのはなぜですか？
   • A) セキュリティポリシーでプロキシを非特権UIDで実行する必要がある
   • B) プロキシが署名して送信するパケットもLattice範囲宛てのため、UID例外がないと自身へREDIRECTされてループする
   • C) SigV4署名にはUID情報が含まれる
   • D) conntrackはUIDでエントリを区別する

回答を表示

回答: B) プロキシが署名して送信するパケットもLattice範囲宛てのため、UID例外がないと自身へREDIRECTされてループする

解説: プロキシが出力する署名済みパケットも169.254.171.x宛てです。UID例外がなければ再びREDIRECTルールに一致し、ループします。そのため、プロキシは専用UID（参照実装では101）で実行し、そのUIDからのトラフィックはnetfilterのownerマッチ（-m owner --uid-owner）によってRETURNします。プロキシコンテナのrunAsUserとiptablesのUIDは一致させる必要があります。 マニフェストをカスタマイズするとき、ここが最も壊れやすい連携箇所です。

6. egressプロキシ方式は、共有ライブラリ方式よりconntrackの負荷が大きくなるのはなぜですか？
   • A) プロキシが接続を長く保持する
   • B) Podのnet namespace内にあるREDIRECTはDNATであり、元に戻すための追跡が必要になるうえ、プロキシからLatticeへの接続もエントリを追加する
   • C) プロキシもUDPを使う
   • D) プロキシがconntrackのタイムアウトを増やす

回答を表示

回答: B) Podのnet namespace内にあるREDIRECTはDNATであり、元に戻すための追跡が必要になるうえ、プロキシからLatticeへの接続もエントリを追加する

解説: 署名プロキシでは、ローカル側とアップストリーム側に接続区間が作られます。接続プーリングやnamespace/NATの構成によって追跡コストは変わります。ノードテーブルの使用量が必ず一定量増えると決めつけず、Pod/ノードのテーブルとeBPFマップを調べてください。

7. パケットキャプチャで何が分かりますか？
   • A) conntrackが枯渇している
   • B) 送信元/受信先、方向、インターフェイス、namespaceを踏まえてキャプチャを解釈し、他の証拠と関連付ける必要がある
   • C) qdiscでパケットがドロップされた
   • D) Latticeの認証に失敗した

回答を表示

回答: B) 送信元/受信先、方向、インターフェイス、namespaceを踏まえてキャプチャを解釈し、他の証拠と関連付ける必要がある

解説: 受信前に拒否されたインバウンドパケットは、受信側では確認できません。アウトバウンドパケットは、外部のSGにドロップされる前に送信側で見える場合があります。応答が見つからないだけでは、SGによる拒否を証明できません。

8. 「一部のノードでだけLatticeへの呼び出しが失敗する」というパターンから何が分かりますか？
   • A) Latticeサービスの設定ミス
   • B) ノードの状態が一致していない。SGの差異、カーネルバージョンの混在、conntrack設定、時刻同期、Podの再起動状況を確認する
   • C) 認証ポリシーの設定ミス
   • D) DNSの伝播遅延

回答を表示

回答: B) ノードの状態が一致していない。SGの差異、カーネルバージョンの混在、conntrack設定、時刻同期、Podの再起動状況を確認する

解説: 全面的な障害なら設定や認証が疑われますが、ノード単位の障害ならノード状態の不一致が疑われます。 候補として、ノードグループごとのSGの違い、kernel-default AMIによる6.1/6.18カーネルの混在、ブートストラップのタイミングによって異なるconntrack設定、x-amz-dateの5分スキューを引き起こす時刻同期、既存Podへ反映されていないannotation変更があります。「一部のノード」というパターン自体が調査範囲を絞ります。