Cloud Native Operations

日本語

한국어
English
简体中文
Español

日本語

한국어
English
简体中文
Español

Appearance

基礎: リンクローカルと SNI のクイズ ​

このクイズでは、リンクローカル/ULA アドレス指定、SNI の動作、Lattice のプロトコルサポートについて理解度を確認します。

選択問題 ​

  1. VPC Lattice サービスの DNS 名が解決するアドレス範囲について、正しい説明はどれですか？
    • A) IPv4 の 169.254.171.0/24 と IPv6 の fe80::/10 は、どちらもリンクローカルである
    • B) IPv4 の 169.254.171.0/24 はリンクローカルだが、IPv6 の fd00:ec2:80::/64 はリンクローカルではなく、Unique Local Address (ULA) である
    • C) どちらの範囲も、グローバルに一意なパブリックアドレスである
    • D) IPv6 はサポートされない
回答を表示

回答: B) IPv4 の 169.254.171.0/24 はリンクローカルだが、IPv6 の fd00:ec2:80::/64 はリンクローカルではなく、Unique Local Address (ULA) である

解説: IPv4 範囲は 169.254.0.0/16 (RFC 3927、リンクローカル) に含まれますが、IPv6 範囲はリンクローカルの fe80::/10 ではありません。RFC 4193 の ULA 範囲 fc00::/7 内にある fd00:ec2:80::/64 です。RFC 6724 では、リンクローカルアドレスのスコープはリンクとされています。ULA のアドレススコープはグローバルですが、グローバルなインターネット到達性ではなく、プライベートルーティング用です。非推奨のサイトローカルアドレスのクラスでもありません。これらのアドレス分類だけでは、AWS の特殊な Lattice ingress 実装は説明できません。

  1. Lattice のアドレス範囲はどのように解釈すべきですか？
    • A) IP アドレスを節約するため
    • B) AWS に記載されたサービス固有のアドレス指定を使い、プレフィックスをリンクローカルインターセプトの一般的な定義に拡張しない
    • C) IPv4 アドレスの枯渇に対処するため
    • D) クライアントが宛先を明示的に認識できるようにするため
回答を表示

回答: B) AWS に記載されたサービス固有のアドレス指定を使い、プレフィックスをリンクローカルインターセプトの一般的な定義に拡張しない

解説: サービス固有の経路と関連付けによって到達性が決まります。ULA はリンクローカルでも、非推奨のサイトローカルクラスでもありません。アドレスのスコープとルーティング上の到達性は異なります。

  1. 共存環境で Lattice 宛てのリクエストが Envoy ログに表示されます。次に何を確認すべきですか？
    • A) Lattice のクォータ超過
    • B) メッシュのインターセプトと、構成済みのアウトバウンド経路/署名ポリシーが失敗の原因かを確認する
    • C) Gateway API CRD のバージョン不一致
    • D) Target Group のプロトコル設定ミス
回答を表示

回答: B) メッシュのインターセプトと、構成済みのアウトバウンド経路/署名ポリシーが失敗の原因かを確認する

解説: Envoy ポリシーには、不明な宛先を拒否するものと転送するものがあります。ルールとログを調べ、選択したバイパスまたは転送の設計をテストしてください。共存するだけで必ず失敗するわけではありません。

  1. 安定したサービス ID と認可を実現するには、宛先 IP だけでは不十分なのはなぜですか？
    • A) 宛先 IP は暗号化され、代替手段がない
    • B) IP だけに依存せず、サービスを認識する ID、DNS/リクエストの関連付け、レビュー済みのネットワークルールを使う
    • C) Flow Logs が無効になるため、有効にすれば解決する
    • D) VPC CNI が IP を再利用するため、IP 割り当てポリシーを変えれば解決する
回答を表示

回答: B) IP だけに依存せず、サービスを認識する ID、DNS/リクエストの関連付け、レビュー済みのネットワークルールを使う

解説: サービス ID は、サービスごとに安定した CIDR のセキュリティ境界ではありません。認証ポリシー、サービスログ、リクエスト ID と組み合わせれば、ネットワークの証拠も有用です。SG の変更にはレビュー済みの IaC を使ってください。

  1. SNI と ECH の違いについて正しい説明はどれですか？
    • A) 初期の TLS 設計に残った脆弱性である
    • B) 通常の TLS は証明書を選択するために SNI を公開する。ECH は別の設計だが、Lattice の TLS passthrough はサポートしない
    • C) パフォーマンス向上のため SNI の暗号化を省略した
    • D) ファイアウォールを通過できるように、意図的に公開した
回答を表示

回答: B) 通常の TLS は証明書を選択するために SNI を公開する。ECH は別の設計だが、Lattice の TLS passthrough はサポートしない

解説: TLS passthrough には、SNI と一致するカスタムドメインが必要です。AWS はその場合 ECH/ESNI を明示的に除外しています。平文の SNI が常に避けられないとも、Lattice のサポート状況が不明にすぎないとも説明しないでください。

  1. VPC Lattice における raw TCP について正しい説明はどれですか？
    • A) AWS ネットワークでは TCP プロトコルをサポートしていない
    • B) サービスリスナーには raw TCP がありませんが、TCP のリソース設定/リソースゲートウェイは、別のサポート対象モデルです
    • C) NLB が既に同じ機能を提供するため、重複する
    • D) セキュリティ規制で平文通信は禁止されている
回答を表示

回答: B) サービスリスナーには raw TCP がありませんが、TCP のリソース設定/リソースゲートウェイは、別のサポート対象モデルです

解説: 製品全体として数学的に不可能だと説明しないでください。別のリソース接続アクセスモデル、コントローラーのサポート、ルーティング要件を比較してください。h2c gRPC を任意の raw TCP として分類しないでください。

  1. HTTPS リスナーと TLS Passthrough のトレードオフについて正しい説明はどれですか？
    • A) TLS Passthrough はあらゆる点で優れている
    • B) Passthrough はエンドポイント TLS を維持できますが、HTTP SigV4 ID を検査できない。匿名のネットワークコンテキストポリシーは別の制御である
    • C) どちらのリスナーでも、復号せずに暗号化された HTTP SigV4 ヘッダーを認証できる
    • D) HTTPS リスナーは SNI を参照できない
回答を表示

回答: B) Passthrough はエンドポイント TLS を維持できますが、HTTP SigV4 ID を検査できない。匿名のネットワークコンテキストポリシーは別の制御である

解説: 失われるのは、認証された HTTP ID と L7 検査であり、認証ポリシーのすべてではありません。リスナーとエンドポイントの制御を明示的に選択してください。バックエンド HTTPS が暗号化されていても、Lattice がターゲット証明書を検証するとは限りません。

ドキュメントに質問する

Enter で送信、Shift+Enter で改行します。