午前Ⅱは 25 問中 15〜17 問が過去問の再出題で、残り 8 問前後が新規問題。 新規問題の出どころは毎回ほぼ同じなので、そこに絞って作ったオリジナル問題（IPA の過去問ではない。 文言は本番と一致しない）。第 26 問からの 8 問は午後の頻出論点を四肢択一にしたもので、午前Ⅱの実際より難しい。 所要 40 分。知らない用語があった問題は、解説の表を 1 回書き写す。
| 出どころ | 問 | ここで扱うテーマ |
|---|---|---|
| (a) 直近 3〜5 年に普及した規格・サービス | 1〜10 | Wi-Fi 6/6E、WPA3 SAE、QUIC、TLS 1.3、DoH、VXLAN、EVPN、SRv6、SD-WAN |
| (b) 既出テーマの一段深い所 | 11〜16 | BGP ルートリフレクタ・AS_PATH prepend、OSPF DR 選出、VRRP 仮想 MAC、SLAAC、PMTUD |
| (c) 計算問題の数字替え | 17〜19 | TCP スループット、サブネット設計、リンクアグリゲーション |
| (d) 支援士・応用情報からの流用 | 20〜25 | DMARC、FIDO2、ゼロトラスト、MACsec、稼働率、コンテナ |
| (e) 午後レベル（難易度高め） | 26〜33 | 経路集約とヌルルート、LSA タイプと ABR/ASBR、VRRP の復帰順序、IPsec NAT-T、STP の計算、DNS64/NAT64、MSS 書換え、PAC |
本番で当たるのは、このうち 2〜4 問と見ておく。残りの新規問題は知らなくても 「消去法で 2 択まで絞る」で十分。合格基準（15/25）は再出題分だけで届く。 (e) は午前Ⅱの点数より、午後の記述で使う言葉を選択肢から拾う目的。
正解：ウ
OFDMA（直交周波数分割多元接続）が正解。11a/g/n/ac までの OFDM は、1 つのチャネルの 全サブキャリアを 1 台の端末が占有していた。11ax の OFDMA はサブキャリアを RU（リソースユニット）に 分け、複数端末に同時に割り当てる。短いパケットを大量に送る IoT 端末や高密度環境で効く。
CSMA/CA はアクセス制御（衝突回避）で全規格共通、DSSS は 11b の変調、TDMA は携帯電話（2G）の方式。
11ax のほかの新機能も一緒に: 上り MU-MIMO（11ac は下りのみ）、TWT（端末の起床時刻を予約して省電力）、 BSS カラーリング（隣接 AP の同一チャネル干渉を色で識別）、1024QAM。
規格 通称 周波数帯 最大速度 多元接続/技術 新しく入ったもの
11n Wi-Fi 4 2.4 ＋ 5GHz 600M OFDM + MIMO 40MHz、MIMO
11ac Wi-Fi 5 5GHz のみ 6.9G OFDM + MU-MIMO(下り) 80/160MHz、256QAM
11ax Wi-Fi 6 2.4 ＋ 5GHz 9.6G OFDMA + MU-MIMO(上下) OFDMA、1024QAM、TWT、BSS カラーリング
Wi-Fi 6E 2.4 ＋ 5 ＋ 6GHz 9.6G 同上 6GHz 帯（国内は 2022 年に解禁）
11be Wi-Fi 7 2.4 ＋ 5 ＋ 6GHz 46G OFDMA + MU-MIMO 320MHz、4096QAM、MLO(複数帯域の同時利用)
11ad WiGig 60GHz 6.8G ― ミリ波・近距離
正解：エ
Wi-Fi 6E の E は Extended。規格は 11ax のまま、使える周波数帯に 6GHz 帯を追加したもの。 国内では 2022 年 9 月に 5,925〜6,425MHz が解禁された。6GHz 帯は既存機器がいないので混雑が少なく、 DFS（気象レーダ回避）も不要。
11ac は 5GHz 専用で 6GHz には対応しない。60GHz は 11ad（WiGig）。 次の 11be（Wi-Fi 7）も 2.4/5/6GHz の 3 帯域で、MLO（複数帯域を同時に束ねる）と 320MHz 幅が目玉。
正解：ア
WPA2-PSK は、4 ウェイハンドシェイクを盗聴すればパスフレーズをオフラインで総当たりできた （PMK がパスフレーズと SSID だけから決まるため）。WPA3 の SAE（Dragonfly 鍵交換）は、 接続のたびに楕円曲線の鍵交換で PMK を作るので、盗聴データからパスフレーズを検証できず、 1 回の試行ごとに AP との対話が必要になる（オンライン攻撃しかできない）。過去のセッション鍵も漏れない（前方秘匿性）。
WPA3-Personal SAE（Dragonfly）で PMK 生成。その後の 4 ウェイハンドシェイクと CCMP は WPA2 と同じ WPA3-Enterprise 802.1X + RADIUS。192 ビットモード（CNSA）あり Enhanced Open OWE。認証なしの公衆 Wi-Fi でも暗号化（＝選択肢エはこれ、WPA3 とは別物）
イは WPA3-Enterprise、ウは逆（WPA3 は TKIP を禁止）、エは OWE（Enhanced Open）の説明。
正解：イ
QUIC は UDP（443）の上に、再送・輻輳制御・多重化・暗号化（TLS 1.3）を全部自前で実装したプロトコル。 TCP+TLS では 3 ウェイハンドシェイク＋TLS ハンドシェイクで 2〜3 RTT かかるところを 1 RTT（再接続は 0 RTT）で始められる。
HTTP/1.1 TCP 80 / TLS 443 1 コネクション 1 リクエスト（キープアライブで使い回し）
HTTP/2 TCP + TLS 1 コネクションで複数ストリームを多重化。ただし TCP の再送待ちで
全ストリームが止まる（HoL ブロッキング）
HTTP/3 QUIC（UDP 443） ストリームごとに独立して再送するので HoL ブロッキングが起きない。
コネクション ID で識別するため、Wi-Fi→LTE と IP が変わっても継続
設計上の注意点として、ファイアウォールで UDP 443 を閉じていると HTTP/3 が使えず HTTP/2 にフォールバックする。 QUIC はヘッダーまで暗号化するので、中継装置からは中身がほぼ見えない。
正解：エ
TLS 1.3（RFC 8446、2018 年）は「安全でない選択肢を仕様から削った」のが本質。
TLS 1.2 TLS 1.3
鍵交換 RSA / DHE / ECDHE を選択 (EC)DHE のみ（RSA 鍵交換を廃止 → 常に前方秘匿性）
フルハンドシェイク 2 RTT 1 RTT（再開時は 0 RTT も可）
暗号 CBC / RC4 / AEAD が混在 AEAD（AES-GCM, ChaCha20-Poly1305）のみ
ハッシュ MD5 / SHA-1 も可 SHA-256 以上
廃止 ― 圧縮、再ネゴシエーション、静的 RSA/DH、
エクスポート暗号、DSA
証明書の送信 平文 ServerHello 以降は暗号化（証明書も隠れる）
前方秘匿性（PFS）: サーバの秘密鍵が後日漏れても、過去に記録した通信を復号できない性質。 RSA 鍵交換は秘密鍵が漏れると過去の通信も全部解けるので、1.3 で排除された。
正解：ウ
DoH は DNS メッセージを HTTPS の中に入れる。ポートが 443 なので Web と区別がつかず、 企業の DNS フィルタリングや監視を素通りする可能性があるのが運用上の論点。ブラウザ（Firefox・Chrome）が OS の DNS 設定を無視して DoH を使うことがある。
従来の DNS UDP/TCP 53 平文 DoT TCP 853 TLS で暗号化。専用ポートなので「DNS を暗号化している」と分かる（選択肢ア） DoH TCP 443 HTTPS に載せる。Web と見分けがつかない （選択肢ウ） DNSSEC 53 のまま 署名で改ざん検出。暗号化（秘匿）はしない （選択肢イ） ソースポートランダム化 キャッシュポイズニング対策（Kaminsky 攻撃対策） （選択肢エ）
「DoT と DoH は秘匿、DNSSEC は真正性」と役割を分けて覚える。
正解：ア
VXLAN は「L2 over L3」の代表。サーバ仮想化で VM をラック・データセンターをまたいで移動させるには、 同じ L2 セグメントを L3 網の上に延ばす必要があり、そのために作られた。
カプセル化 外側 IP ＋ UDP(宛先 4789) ＋ VXLAN ヘッダー(8 バイト) ＋ 元のイーサネットフレーム 識別子 VNI 24 ビット → 約 1,677 万セグメント（VLAN ID は 12 ビット＝4,094） 終端 VTEP（スイッチまたはハイパーバイザー）。VM からはただの L2 に見える MTU 50 バイト増えるので、下回りの MTU を 1,550 以上（通常ジャンボフレーム）にする
イは Q-in-Q（802.1ad、TPID 0x88a8）、ウは MPLS、エは GRE トンネル。GRE も L2 を運べるが 識別子を持たず、UDP でないので ECMP で分散しにくい。
正解：ウ
初期の VXLAN は、宛先 MAC が未学習のフレームを全 VTEP にマルチキャストして覚える 「フラッド＆ラーン」方式だった。規模が大きくなると無駄なトラフィックが増えるので、 EVPN（Ethernet VPN）が MP-BGP の経路として「この MAC/IP はこの VTEP の配下にいる」を配る。 BGP なのでスケールし、ARP の代理応答（ARP 抑制）もできる。
「VXLAN はデータプレーン、EVPN はコントロールプレーン」の組合せで覚える。 データセンターの Spine-Leaf 構成では、アンダーレイに OSPF か eBGP、オーバーレイに EVPN、が定番。
IGMP スヌーピングはマルチキャストの転送先を絞る機能、LLDP は隣接機器情報の交換、RSTP はループ防止。
正解：イ
SRv6 はソースルーティングの現代版。送信側（入口ルータ）がパケットに「通るべき場所のリスト」 ＝セグメントリストを書き込み、中継ルータはそれを見て次のセグメントへ送るだけ。 中継ルータはパスごとの状態を持たないので、RSVP-TE のような MPLS-TE よりスケールする。
SR-MPLS セグメントを MPLS ラベルで表す（ラベルスタック）。LDP/RSVP が不要になる
SRv6 セグメントを IPv6 アドレスで表し、拡張ヘッダー SRH（Routing Header Type 4）に並べる
IPv6 さえ通れば動く。アドレスの下位ビットに「機能」を埋め込める（End.DX4 など）
アは MPLS（LDP）、ウは 6in4 トンネル、エは MPLS-TE（RSVP-TE）。 国内キャリアのバックボーンで SRv6 採用が進んでいるので、用語として出る可能性が高い。
正解：エ
SD-WAN は「WAN を SDN の考え方で作る」。
コントローラ 全拠点のポリシーを一元設定。拠点機器はゼロタッチで展開 オーバーレイ インターネット＋閉域網（IP-VPN）＋LTE などを IPsec トンネルで束ねる 回線選択 アプリ識別（Microsoft 365 はインターネット直、基幹系は閉域網）、遅延・損失を測って動的に切替 ローカルブレイクアウト クラウド向け通信を本社経由にせず各拠点から直接インターネットへ
SD-WAN と SASE の関係: SASE はこの SD-WAN に、SWG・CASB・ZTNA・FWaaS などのセキュリティ機能を クラウド側で一体提供する枠組み。「ネットワーク＋セキュリティをクラウドで」が SASE、「ネットワークだけ」が SD-WAN。
アは広域イーサネット、イは単なる回線増強、ウは LAN の SDN（OpenFlow）。
正解：イ
iBGP には「iBGP で学習した経路は他の iBGP ピアに広告しない」というループ防止の規則がある。 そのため本来は AS 内の全 BGP ルータをフルメッシュで接続する必要があり、n 台なら n(n−1)/2 本のセッションになる。
ルートリフレクタ(RR) 特定のルータを RR にし、クライアントは RR とだけ iBGP を張る。
RR はクライアントから受けた経路を他のクライアントへ「反射」する。
ループ防止に ORIGINATOR_ID / CLUSTER_LIST 属性を使う
コンフェデレーション AS を複数のサブ AS に分割し、サブ AS 間は eBGP 風につなぐ（もう 1 つの解）
ほかの選択肢: AS_PATH プリペンドは入トラフィックの制御（次問）、ルートダンプニングは フラップする経路を一時的に抑止する機能、MED は隣接 AS に「こちらの入口を使ってほしい」と伝える属性。
正解：ア
BGP の経路制御は「出る方向は自分で決められるが、入る方向は相手が決める」のが大前提。 入トラフィックを減らしたい ISP には、自 AS の経路をわざと魅力のない形で広告するしかない。 その定番が AS_PATH プリペンド（自 AS 番号を 2〜3 回重ねて AS_PATH を長くする）。
属性 方向 誰が見るか 使いどころ LOCAL_PREF 出 自 AS 内（iBGP で配布） 自 AS から出るとき、どの ISP を使うか ← 選択肢イは出方向 MED 入 隣接 AS（1 ホップ先だけ） 同じ隣接 AS に複数の入口があるとき。相手が無視できる AS_PATH 入 インターネット全体 プリペンドで入トラフィックを誘導。最も確実 コミュニティ 入 相手 ISP が対応していれば ISP が用意した値を付けると ISP 側で prepend/LOCAL_PREF 操作
BGP の経路選択順序（覚える範囲）: 1. 最大 WEIGHT（Cisco 独自） → 2. 最大 LOCAL_PREF → 3. 自己生成 → 4. 最短 AS_PATH → 5. ORIGIN → 6. 最小 MED → 7. eBGP ＞ iBGP → 8. IGP メトリック最小 …
正解：ウ
マルチアクセス網で全ルータが互いに隣接関係（adjacency）を結ぶと n(n−1)/2 本になるので、 DR と BDR を選び、他のルータは DR/BDR とだけ LSA を交換する。
選出規則 1. ルータプライオリティ最大（既定 1、0 は候補外）
2. 同値ならルータ ID 最大（ルータ ID はループバックの最大 IP、または明示設定）
非先取り いったん DR が決まると、後から大きいプライオリティのルータが来ても DR は交代しない
（DR が落ちたら BDR が昇格し、新しい BDU を選び直す）← 選択肢エが誤りな理由
マルチキャスト 全 OSPF ルータ → 224.0.0.5 (AllSPFRouters)
DR/BDR 宛て → 224.0.0.6 (AllDRouters)
ポイントツーポイント回線では DR/BDR を選出しない
午後で「DR になるべきルータにプライオリティを高く設定する」「DR にしたくないルータは 0 にする」の形で何度も出ている。
正解：エ
VRRP では端末のデフォルトゲートウェイは仮想 IP アドレスで、端末が ARP で引くと返ってくるのは 仮想 MAC アドレス 00-00-5E-00-01-{VRID}（IPv6 は 00-00-5E-00-02-{VRID}）。この MAC は その時点のマスターが使うので、マスターが代わっても端末側は何も変えなくてよい。
切替時に新マスターがやること
1. 仮想 MAC でフレームを受け取り始める
2. Gratuitous ARP（仮想 IP → 仮想 MAC）を送り、スイッチの MAC アドレステーブルを自ポートに書き換える
（端末の ARP キャッシュではなく、スイッチの学習テーブルを更新するのが目的）
VRRP 広告 マスターだけが 224.0.0.18 へ IP プロトコル番号 112 で 1 秒ごと（既定）
プライオリティ 1〜254、既定 100。仮想 IP を実 IP として持つルータは 255。大きい方がマスター
Master down 広告が 3 回途切れる（約 3 秒）とバックアップが昇格。preempt は既定で有効
ア: ICMP リダイレクトは経路の案内で、ゲートウェイの切替手段ではない。 イ: 端末は VRRP 広告を解釈しない。ウ: スイッチはフレームの宛先 MAC を書き換えない。
正解：イ
IPv6 のアドレス設定は、RA のフラグで 3 通りに分かれる。
方式 アドレス DNS サーバなど RA フラグ サーバの状態管理 SLAAC RA のプレフィックス＋自分で作る ID RA の RDNSS option M=0 O=0 なし SLAAC + ステートレス DHCPv6 同上 DHCPv6 で取得 M=0 O=1 なし ステートフル DHCPv6 DHCPv6 が払出し DHCPv6 で取得 M=1 あり（IPv4 の DHCP と同じ） インタフェース ID の作り方: MAC から EUI-64（古い）、または乱数（RFC 7217 / プライバシー拡張。今の既定） DAD: 作ったアドレスを NS（近隣要請）で問い合わせ、NA が返らなければ使用開始（ARP ではなく ICMPv6） デフォルトゲートウェイは DHCPv6 では配れない。常に RA の送信元（リンクローカル）
「デフォルトゲートウェイは DHCPv6 で配れない」は午後でも使う。 エは ARP と書いた時点で誤り（IPv6 に ARP はなく NDP）。
正解：ア
IPv6 では中継ルータはフラグメントしない（IPv4 との大きな違い）。分割するのは送信元だけで、 そのために送信元は経路 MTU 探索（PMTUD）を必ず行う。
IPv4 ルータが分割できる（DF=1 なら破棄して ICMP Type 3 Code 4 "Fragmentation needed"）
IPv6 ルータは分割しない。破棄して ICMPv6 Type 2 "Packet Too Big"（MTU 値つき）を返す
送信元はその MTU でフラグメント拡張ヘッダーを付けて再送
最小 MTU IPv4 は 576、IPv6 は 1,280 オクテット（どのリンクも 1,280 以上を保証）
運用上の落とし穴: ファイアウォールで ICMPv6 を全部止めると Packet Too Big が届かず、 大きいパケットだけが黒穴に落ちる（PMTUD ブラックホール）。「ICMPv6 Type 2 は通す」が鉄則。 IPv6 over IPv4 トンネルや VXLAN で MTU が縮む場面で起きやすい。
正解：イ
TCP は ACK が返るまでウィンドウサイズ分しか送れない。つまり 1 RTT あたり最大でウィンドウ 1 個分。
スループット上限 ＝ ウィンドウサイズ ÷ RTT
＝ 65,535 バイト × 8 ビット ÷ 0.1 秒
＝ 524,280 ビット/秒 ÷ 0.1
＝ 5,242,800 ビット/秒 ≒ 5.2 Mビット/秒
ア 0.66 は ×8 を忘れた値（655,350 バイト/秒を「M ビット」と読み違え）
ウ 52 は RTT を 10 ミリ秒で計算した値
エ 524 は ÷0.1 を ×100 にした値
結論: 回線が 1 Gビット/秒でも、ウィンドウ 64 KB・RTT 100 ms なら 1 本の TCP は 5 Mビット/秒しか出ない。 これがウィンドウスケールオプション（RFC 7323、最大 1 GB まで拡大）が要る理由で、 海外拠点間・衛星回線・クラウド間転送の「遅い」の原因として午後にも出る。 必要ウィンドウ＝帯域×RTT（帯域遅延積）: 1 Gビット/秒 × 0.1 秒 ＝ 12.5 MB。
正解：ウ
手順は 2 段。「ホスト部は何ビット必要か」→「残りが拠点数」。
1. 500 台 ＋ ネットワークアドレス ＋ ブロードキャスト ＝ 502 以上のアドレスが必要 2^8 − 2 = 254 × 足りない （/24） 2^9 − 2 = 510 ○ 足りる → ホスト部 9 ビット → プレフィックス長 32 − 9 = /23 2. /16 から /23 を切り出すと、サブネット部は 23 − 16 = 7 ビット → 2^7 = 128 拠点 /22 でも収容できるが 1,022 台分で無駄が多く、拠点数は 64 に減る（設問は「最も多くなる」） /24・/25 は 500 台が入らない
設問の「最も多く」「最も少ない無駄」「最も集約範囲が狭い」は全部ぴったりの境界を聞いている。 令和5年 問12 の集約（/18）も同じで、2 のべき乗の境界を 2 進数で確かめるのが最短。
正解：エ
リンクアグリゲーションは「フロー単位で振り分ける」。1 つの TCP フロー内でフレームの順序が入れ替わると TCP が再送してしまうので、同じフローは同じ物理リンクに固定する（ハッシュで決める）。
帯域 合計は 2 Gビット/秒だが、1 フローの上限は 1 Gビット/秒（選択肢アは誤り）
多数のフローがあって初めて分散が効く。ハッシュが偏ると片寄る
振分けキー 送信元/宛先 MAC、IP、L4 ポートの組合せ（機器で選択）
LACP IEEE 802.3ad → 現在は 802.1AX。LACPDU で両端が合意して束ねる。
active（自分から送る）/ passive（相手の LACPDU を待つ）。passive 同士では束ならない
スタティック LACP を使わず固定で束ねる。片側の設定ミスやケーブル誤接続をループとして検出できない
スイッチ跨ぎ 通常は同一スイッチ。異なるスイッチに跨ぐには スタック または MC-LAG（vPC 等）が必要（選択肢イは誤り）
ウのような「1 フレームずつ交互（ラウンドロビン）」は順序逆転を起こすので通常は使わない。
正解：ア
SPF（選択肢イ）と DKIM（選択肢ウ）は「正当なサーバから来たか」を検証するが、 利用者に見える From ヘッダー（ヘッダー From）とは別のドメインで通ってしまう穴があった。 DMARC はその穴を塞ぐ仕組み。
アライメント SPF の検証対象（エンベロープ From）／DKIM の署名ドメイン（d=）が、
ヘッダー From のドメインと一致（または同一組織ドメイン）しているか
ポリシー _dmarc.example.jp TXT "v=DMARC1; p=reject; rua=mailto:..."
p=none（監視のみ）→ quarantine（迷惑メールへ）→ reject（受信拒否）の順に強化するのが定石
レポート rua（集計）・ruf（失敗詳細）で、自ドメインを騙る送信の実態が分かる
2024 年〜 Gmail / Yahoo が大量送信者に DMARC 必須化。企業で導入が急増 → 出題の動機
エは S/MIME。送信ドメイン認証（SPF/DKIM/DMARC）は「サーバ間」、S/MIME は「利用者間」。
正解：ウ
FIDO2 は公開鍵暗号によるチャレンジレスポンス。サーバに置くのは公開鍵だけで、秘密鍵は認証器（スマホ・PC の TPM・セキュリティキー）から出ない。
登録 認証器がサイトごとに鍵ペアを生成。公開鍵と「どのオリジン（https://example.jp）用か」をサーバに登録
認証 サーバがチャレンジを送る → ブラウザがアクセス中のオリジンを認証器に渡す
→ 認証器は そのオリジン用の秘密鍵 で署名
偽サイト https://examp1e.jp には対応する鍵がない／オリジンが違うので署名が作れない ← フィッシング耐性の本体
生体 指紋・顔は 認証器のロック解除 に使うだけ。サーバには送らない（選択肢イは誤り）
パスキー FIDO2 の秘密鍵を Apple/Google/Microsoft のアカウント経由で端末間に同期できるようにしたもの
ア（SMS OTP）はリアルタイムフィッシング（中継型）で突破される。エはサーバ側の保存対策で、フィッシングとは無関係。
正解：イ
「境界の内側＝安全」を捨てるのがゼロトラスト。クラウド利用とテレワークで「内側」が消えたこと、 境界を突破された後の横展開（ラテラルムーブメント）を止められなかったことが背景。
原則（NIST SP 800-207） 全てのリソースへのアクセスは、場所によらずセッション単位で認証・認可する 認可は 利用者ID ＋ 端末の健全性（EDR・OS パッチ・証明書）＋ 振る舞い を動的に評価 最小権限。アプリ単位で許可（ネットワーク全体を開ける VPN との違い） 全通信を監視・記録し、継続的に評価 実装部品 IdP（ID 基盤・MFA）／ ZTNA（アプリ単位の接続。VPN の置き換え）／ EDR ／ SWG・CASB ／ マイクロセグメンテーション
アは従来の境界防御そのもの、ウは境界防御の強化、エは暗号化の話で「誰に何を許すか」を決めていない。
正解：エ
MACsec は「有線 LAN の WPA2」。スイッチ間やスイッチと PC の間の1 リンクを L2 で暗号化する。 中継スイッチは一度復号して（VLAN タグや宛先 MAC を見て転送し）次のリンクで再暗号化するのでホップバイホップ。
層 技術 保護範囲 主な用途 L2 MACsec 隣接機器間（1 リンク） データセンター内・ビル間ダークファイバ・フロアスイッチ〜PC L3 IPsec ルータ間〜エンド間 拠点間 VPN、リモートアクセス L4〜 TLS アプリのセッション Web、メール 無線 WPA2/WPA3 端末〜AP 無線 LAN（MACsec の無線版に相当） MACsec の鍵: 802.1X-2010 の MKA（MACsec Key Agreement）で配布。CAK（事前共有または EAP で導出）→ SAK を生成 フレーム: 宛先/送信元 MAC は平文、その後ろに SecTAG（EtherType 0x88E5）＋暗号化ペイロード＋ICV
アは IPsec、イは TLS、ウは WPA2/WPA3。「どの層で、どこからどこまで」で 4 つを並べて覚える。
正解：ウ
並列（どちらか動けばよい） 1 − (1 − 0.9) × (1 − 0.9) = 1 − 0.01 = 0.99 直列（両方動く必要がある） 0.99 × 0.99 = 0.9801 → ウ ア 0.81 = 0.9 × 0.9（並列を直列と勘違い） イ 0.891 = 0.9 × 0.99（A を 1 台で計算） エ 0.99 = 回線 B を忘れた、または並列部分だけ
式は 2 つだけ。直列＝掛ける、並列＝「全部止まる確率」を 1 から引く。 ネットワークでは「冗長化した FW ペア → 単一の回線 → 冗長化したサーバ」のような直並列混在で出る。 一番弱い直列要素（ここでは回線 0.99）がボトルネックになる、という読み方もできる。
正解：ア
仮想マシン（ハイパーバイザー型） コンテナ 隔離の単位 ハードウェア → ゲスト OS ごと プロセス（名前空間・cgroups） カーネル VM ごとに別 ホストと共有（Linux コンテナは Linux カーネル上） 起動 分〜数十秒（OS ブート） 秒以下 イメージ GB 単位 MB 単位。Dockerfile で再現可能 隔離の強さ 強い 弱め（カーネルの脆弱性で突破されうる） 運用 vSphere, Hyper-V, KVM Docker ＋ Kubernetes（オーケストレーション）
イは仮想マシンの説明で、コンテナはホストと同じカーネルしか使えない（Windows で Linux コンテナを動かす Docker Desktop は、 裏で Linux VM を 1 つ動かしている）。ウはエミュレータ（QEMU など）、エはベアメタルの誤った説明。
ネットワーク視点の論点: コンテナは IP が頻繁に変わるので、Kubernetes の Service（仮想 IP）や サービスメッシュ（サイドカーで mTLS）が出てくる。午後で CNI・Service・Ingress が出たら、この図に戻る。
正解：ア
令和3年 午後Ⅰ問2 と令和7年 午後Ⅱ問1 で問われた、集約とセットで必ず出る論点。
10.1.2.5 宛てのパケットが上流から R に届く（上流は /22 の集約しか知らない）
ヌルルートなし R の経路表: 10.1.0.0/24, 10.1.1.0/24, 0.0.0.0/0 → 上流
→ 10.1.2.5 はデフォルトに一致 → 上流へ → 上流は /22 で R へ → … TTL が尽きるまでループ
ヌルルートあり R の経路表に 10.1.0.0/22 → Null0 を追加
→ 10.1.2.5 は /22 (Null0) が /0 より長一致 → 破棄（ICMP 到達不能を返す）
→ 10.1.0.5 は /24 が /22 より長一致 → 正常に転送（ヌルルートの影響なし）
多くの実装では集約経路を設定すると Null0 経路が自動生成される（BGP の aggregate、OSPF の area range など）。 記述で問われたら「集約範囲内の存在しない宛先へのパケットが、デフォルトルートによって上流との間でループするのを防ぐため」。 ウは条件付き広告の話で別機能。エは副次的効果にすぎない。
正解：イ
令和3年 午後Ⅰ問2・令和6年 午後Ⅰ問2 の論点。「誰が、どの範囲に、何を流すか」を表で持つ。
Type 名称 生成するルータ 流れる範囲 中身 1 ルータ LSA 全ルータ エリア内 自分のリンクとコスト 2 ネットワーク LSA DR エリア内 そのセグメントに接続するルータ一覧 3 ネットワーク集約 LSA ABR 他エリアへ 他エリアのプレフィックス（距離ベクトル的に要約） 4 ASBR 集約 LSA ABR 他エリアへ ASBR の所在 5 AS 外部 LSA ASBR 全エリア(スタブ除く) 再配布した外部経路 7 NSSA 外部 LSA NSSA 内の ASBR NSSA 内 ABR が Type 5 に変換して外へ出す ABR = 複数エリアに属するルータ（必ずバックボーン エリア 0 に接する） ASBR = 外部経路を再配布するルータ（静的経路・BGP・RIP など） スタブエリア Type 5 を入れない。代わりに ABR がデフォルトルートを Type 3 で流す トータリースタブ Type 3 も入れない（デフォルトルートだけ） NSSA スタブだがエリア内に ASBR を置ける（Type 7）
午後では「ABR で経路集約（area range）するとエリア間の LSA 数が減り、エリア内の障害が他エリアの SPF 再計算を起こさなくなる」まで書けると満点。
正解：ウ
令和5年 午後Ⅱ問1・令和7年 午後Ⅰ問1 で問われた。
何が起きるか
L3SW1 が起動 → VRRP は数秒で立ち上がる（プライオリティ 120 ＞ 100 なので即マスターに復帰）
→ 端末のデフォルト GW 宛てトラフィックは L3SW1 へ
→ しかし OSPF の隣接確立・LSDB 同期・SPF 計算はまだ（数十秒）→ L3SW1 の経路表に上流経路がない
→ パケットは捨てられる（ブラックホール）
対策
preempt delay マスターへの復帰を N 秒（OSPF 収束より長く）遅らせる
トラッキング 上流インタフェース or 特定経路の存在を条件にプライオリティを増減。
経路がなければプライオリティを 120 → 90 に下げ、L3SW2 がマスターのまま
preempt 無効 復帰しても自動では戻らない（手動で戻す運用）
ア・イは切替えを速くする話で、順序の問題は解決しない。エは同値にすると IP アドレスの大きい方がマスターになるだけで、 やはり経路収束前に取り得る。記述なら「OSPF の経路が収束する前に L3SW1 がマスターになり、上流への経路を持たないままパケットを受け取って破棄するから」。
正解：エ
ESP（IP プロトコル番号 50）にはポート番号がないので、複数端末を 1 つのグローバル IP に多重化する NAPT は ESP を通せない（どの内側ホスト宛てか区別できない）。解決策が NAT トラバーサル（NAT-T、RFC 3948）。
IKE（UDP 500） NAT-D ペイロードで、自分の IP:ポートのハッシュを交換 → 途中で書き換わっていれば NAT ありと判定 NAT あり 以後の IKE と ESP を UDP 4500 に載せる（ESP in UDP）。NAT は UDP のポートで多重化できる キープアライブ NAT のテーブルが消えないように、定期的に空の UDP 4500 を送る AH が NAT を越えられない理由: AH は IP ヘッダー（送信元 IP）まで含めて認証するので、NAT で書き換わると検証に失敗 ESP トンネルモードは外側 IP だけ書き換わるので、UDP に包めば中身は無傷
ファイアウォールの許可ルールは「UDP 500、UDP 4500、（NAT がない場合）ESP」の 3 つ。午後で穴埋めになる。
正解：ウ
手順は 3 段。「ルートブリッジ」→「各スイッチのルートポート」→「各リンクの指定ポート」。残ったポートがブロッキング。
1. ルートブリッジ ブリッジ ID（プライオリティ＋MAC）が最小 → SW1（4096）
ルートブリッジの全ポートは指定ポート（転送）
2. ルートポート 各スイッチで、ルートへのパスコストが最小のポート（1 台に 1 つ）
SW2: 直接 SW1 へ（コスト 4） vs SW3 経由（8） → SW1 側
SW3: 直接 SW1 へ（コスト 4） vs SW2 経由（8） → SW1 側
3. 指定ポート 各リンクで 1 つ。SW2-SW3 間のリンク:
両者のルートパスコストは 4 で同じ → ブリッジ ID が小さい SW2 側が指定ポート
4. 残り SW3 の SW2 側 = ルートポートでも指定ポートでもない → ブロッキング（RSTP では代替ポート）
結果: SW3 → SW2 の通信は SW1 を経由する。設計では「ルートにしたいコアスイッチのプライオリティを最小（0 や 4096）にし、 セカンダリを次に小さく設定する」。既定値 32768 のまま放置すると MAC アドレスの小さい古い機器がルートになる、が午後の定番の指摘。 パスコスト: 10M=100、100M=19、1G=4、10G=2（802.1D-1998 の短い値）。
正解：ア
平成25年 問9・弱点補強で落とした「トランスレーション」の具体例。DNS64 と NAT64 は必ずセット。
1. 端末 → DNS64: www.example.jp の AAAA は？
2. DNS64 → 権威: AAAA なし。A = 203.0.113.10 を取得
3. DNS64 → 端末: AAAA = 64:ff9b::203.0.113.10（= 64:ff9b::cb00:710a）を合成して返す
4. 端末 → NAT64: 宛先 64:ff9b::cb00:710a の IPv6 パケット
5. NAT64: プレフィックス 64:ff9b::/96 を剥がして IPv4 203.0.113.10 宛てに変換（送信元は NAT64 の IPv4 プール）
戻りは逆変換。ステートフル NAT（NAPT）なので IPv4 側からは始められない
限界: アプリが IPv4 アドレスを直接書いている（IP リテラル）と DNS64 を通らず失敗 → 端末側に CLAT を置く 464XLAT で補う
DNSSEC 検証している端末は合成 AAAA を偽物と判定する
イはトンネル（6in4 の逆）の話で、トランスレーションではない。ウ・エは仕組みとして存在しない。 携帯キャリア網（IPv6 シングルスタック化）で実際に使われているので、出題の動機がある。
正解：イ
症状は典型的な PMTUD ブラックホール。原因と対策を分けて書けるようにする。
原因
IPsec トンネルは 1 パケットあたり 50〜70 オクテット増える（新 IP 20 ＋ ESP ヘッダー・IV・トレーラ・ICV）
端末は MTU 1,500 で DF ビット付きの 1,500 オクテットのパケットを送る
ルータは分割できず破棄し ICMP Type 3 Code 4（要分割）を返す
→ ファイアウォールが ICMP を落とす → 端末は MTU を下げられず再送を繰り返す
小さいパケット（ping、短い HTTP）は 1,500 未満なので通る ← 「大きいものだけ止まる」の理由
対策（ICMP を通せない前提）
MSS クランプ ルータが TCP SYN の MSS オプションを書き換える（例: 1,360）。
両端のホストは「相手の MSS」と信じて小さいセグメントを送るので、分割も ICMP も不要
TCP にしか効かない（UDP の大きなパケットは別途対処）
端末の MTU を下げる 全端末の設定変更が必要で現実的でない
アは逆効果（トンネルの実効 MTU はもともと 1,500 未満）。ウは AH でもヘッダーは増え、暗号化もされない。 エはウィンドウとセグメント長は別物。記述なら「ルータで TCP SYN の MSS 値を書き換え、トンネルのオーバヘッドを含めても MTU を超えない大きさのセグメントを送らせる」。
正解：エ
令和5年 午後Ⅱ問1・令和6年 午後Ⅰ問3 で問われた。PAC はブラウザ（クライアント）側で動く、が全て。
PAC の例
function FindProxyForURL(url, host) {
if (isPlainHostName(host) || dnsDomainIs(host, ".example.co.jp")) return "DIRECT";
if (isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0")) return "DIRECT";
return "PROXY proxy.example.co.jp:8080; DIRECT"; // プロキシが落ちていたら直接
}
配布方法
手動 ブラウザに PAC の URL（http://proxy.example.co.jp/proxy.pac）を設定。グループポリシーで配る
WPAD（自動検出） DHCP オプション 252 で URL を通知、または DNS で wpad.<ドメイン> を引かせて http://wpad.../wpad.dat を取る
→ 偽の wpad ホストを立てられると全通信を奪われる（WPAD の既知のリスク。社内 DNS に wpad を予約しておく）
落とし穴
dnsResolve() をたくさん書くと要求ごとに名前解決が走り遅い
PAC の配布サーバが落ちると、ブラウザは既定で直接接続に落ちる（プロキシ必須の環境では外に出られなくなる）
ア〜ウは PAC の置き場所が全部違う。ウは透過プロキシ（WCCP など）の説明で、PAC は不要になる方式。