令和4年度 春期 午後Ⅱ

本文の根拠

〔SSL-VPN 技術調査とテレワーク環境への適用〕

TLS プロトコルのセキュリティ機能は，暗号化，通信相手の認証，及び ［ ア ］ である。

〔SSL-VPN 技術調査とテレワーク環境への適用〕

［ イ ］ 方式の SSL-VPN は，動的にポート番号が変わるアプリケーションプログラムでも社内のノードへのアクセスを可能にする。

〔SSL-VPN 技術調査とテレワーク環境への適用〕

ポートフォワーディング方式の SSL-VPN は，社内のノードに対して TCP 又は UDP の任意の ［ ウ ］ へのアクセスを可能にする。

〔SSL-VPN クライアント認証方式の検討〕

サーバの RSA ［ エ ］ 鍵で暗号化してサーバに送付することで共通鍵の共有を実現する

〔SSL-VPN 技術調査とテレワーク環境への適用〕

SSL-VPN 装置が RDP だけで利用されることを踏まえ，SSL-VPN の接続方式は ［ オ ］ 方式とする。

〔SSL-VPN クライアント認証方式の検討〕

TLS1.3 で規定されている鍵交換方式は，［ カ ］，ECDHE，PSK の3方式である。

ア：TLS が提供する安全性は，盗聴を防ぐ暗号化，相手が本物かを確かめる認証，そして途中でデータが書き換えられていないかを確かめる改ざん検知（完全性の保証）の3つである。TLS1.3 ではこの改ざん検知を AEAD の認証タグが担う。

イ：SSL-VPN の3方式の残り1つは L2 フォワーディング方式である。リバースプロキシ方式は Web アプリケーション（HTTP）だけ，ポートフォワーディング方式は決まった TCP/UDP のポートだけを中継するのに対し，L2 フォワーディング方式はクライアントに仮想的な NIC を作ってイーサネットフレームごと運ぶので，途中でポート番号が変わるアプリケーションでも通せる。ウ：ポートフォワーディング方式は，クライアント側の待受けポートと社内ノードの特定のポートを対応付けて転送する方式なので，「任意のポート」へのアクセスとなる。

エ：電子証明書に載っているのは所有者の公開鍵であり，RSA 鍵交換ではクライアントがサーバ証明書の公開鍵でプリマスタシークレットを暗号化する。空欄の後ろに「鍵」が続くので「公開」だけを書く。オ：本文は RDP（TCP の 3389 番ポート）だけを通すと決めており，図2でも SSL-VPN クライアントが localhost:3389 で待ち受けて中継している。これはポートフォワーディング方式の動作そのものである。カ：TLS1.3（RFC 8446）で使える鍵交換は，有限体の Diffie-Hellman をエフェメラル（一時的）な鍵で行う DHE，楕円曲線版の ECDHE，事前共有鍵の PSK である。ECDHE と並べてあるので，楕円曲線でない方の DHE が入る。「DH」だけでは本文が問題にしている静的 DH と区別できない。

本文の根拠

〔SSL-VPN 技術調査とテレワーク環境への適用〕

TLS1.3 では AEAD（Authenticated Encryption with Associated Data）暗号利用モードの利用が必須となっており，①セキュリティに関する二つの処理が同時に行われる。

AEAD（RFC 5116）は，名前のとおり「認証付き暗号」である。1回の処理で，平文の暗号化と，暗号文（と関連データ）に対する認証タグの計算を同時に行う。受信側はタグを検証してから復号するので，改ざんされたデータは復号前に捨てられる。TLS1.2 までは暗号化（CBC など）とメッセージ認証（HMAC）を別々に組み合わせる方式が使えたが，TLS1.3 は AES-GCM や ChaCha20-Poly1305 などの AEAD だけを使う。

本文は下線①で「二つの処理」とだけ言い，名前は Authenticated Encryption にそのまま表れている。Encryption が暗号化，Authenticated がメッセージ認証（改ざん検知）に当たる。

間違えやすい点。「通信相手の認証」ではない。AEAD が確かめるのはメッセージが改ざんされていないことであり，相手が誰かの確認は証明書と署名の役目である。①②はどちらの順で書いてもよい。

本文の根拠

〔SSL-VPN 技術調査とテレワーク環境への適用〕

TLS プロトコルで用いられる電子証明書の形式は，X.509 によって定められている。

〔SSL-VPN 技術調査とテレワーク環境への適用〕

認証局（以下，CA という）によって発行された電子証明書には，②証明対象を識別する情報，有効期限，［ エ ］ 鍵，シリアル番号，CA のデジタル署名といった情報が含まれる。

X.509 証明書（インターネットでの使い方は RFC 5280）では，証明の対象（証明書の所有者）を識別する名前を Subject フィールドに入れる。発行した CA の名前は Issuer フィールドで，これと対になっている。

本文は X.509 の形式であると述べた上で，証明書に含まれる情報を並べている。有効期限（Validity），公開鍵（SubjectPublicKeyInfo），シリアル番号（serialNumber），CA の署名（signatureValue）と並ぶ中で，「証明対象を識別する情報」が Subject に当たる。

間違えやすい点。「フィールド名を答えよ」なので，「所有者名」「識別名（DN）」のような中身の説明ではなく，フィールドの名前 Subject を書く。Issuer は発行者の名前なので逆になる。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

③SSL-VPN 装置はクライアント証明書を基にして接続元の身元特定を行う。

〔テレワーク環境導入方針〕

情報セキュリティの観点から，SSL-VPN アクセスのための認証は，個人ごとに事前に発行したクライアント証明書を用いて行う。

〔SSL-VPN クライアント認証方式の検討〕

新しいクライアント証明書が必要なときは，利用者の公開鍵と秘密鍵を生成し，公開鍵から証明書署名要求（CSR）を作成して，CA サービスへ提出する。

証明書そのものは公開情報で，誰でも写しを送れる。身元の決め手になるのは，証明書に載った公開鍵と対になる秘密鍵を，本人しか持っていないことである。TLS1.3 のクライアント認証では，クライアントが Certificate（図3の(Ⅷ)）で証明書を送った後，CertificateVerify（(Ⅸ)）でそれまでのハンドシェークの内容に秘密鍵で署名する（RFC 8446）。SSL-VPN 装置は証明書の公開鍵でこの署名を検証できれば，相手がその秘密鍵の持ち主，つまり証明書の本人だと判断できる。

本文では，クライアント証明書は個人ごとに発行され，鍵ペアは利用者ごとに生成される。公開鍵は CSR にして CA に送るが，秘密鍵は外に出ない。だから証明書で「個人」を特定できる。

40字に収める。解答例は「クライアント証明書の公開鍵に対する秘密鍵は本人しか保有していないから」で34字。要素は「証明書の公開鍵と対の秘密鍵」「本人だけが持つ」の2つ。「証明書は CA が発行したものだから」だけでは，証明書を盗んで送る成りすましを防げる理由にならない。

採点講評（IPA）

設問3は，TLSプロトコルのベースとなっているPKI技術の基本や，クライアント証明書による認証の基本を問う問題であるが，(1)，(4)の正答率が低かった。基本的な事柄を理解していないと思われる解答が散見されたが，これらの技術は安全なネットワークの構築のために重要なので，正確に理解してほしい。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

TLS プロトコルのネゴシエーション中に，④クライアント証明書が SSL-VPN 装置に送信され，SSL-VPN 装置で検証される。

〔SSL-VPN クライアント認証方式の検討〕

セキュリティ会社である S 社が SaaS として提供する第三者認証局サービス（以下，CA サービスという）を利用する。

証明書の検証は，証明書に付いた CA のデジタル署名を，その CA の公開鍵で確かめることから始まる。CA の公開鍵は CA 自身の証明書（最上位ならルート証明書）に入っており，検証する側はこれを信頼の起点（トラストアンカー）としてあらかじめ持っていなければならない（RFC 5280 の証明書パス検証）。

本文では，クライアント証明書を発行するのは S 社の CA サービスである。したがって SSL-VPN 装置には，S 社の CA のルート証明書（中間 CA があればその証明書も）を入れておく必要がある。

間違えやすい点。インストールするのは「クライアント証明書」や「利用者の公開鍵」ではない。利用者ごとの情報を前もって全部配るのではなく，発行元の CA を信頼することで，どの利用者の証明書でも検証できるようにする仕組みである。「SSL-VPN 装置のサーバ証明書」も，自分が名乗るためのもので，相手の検証には使わない。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

⑤SSL-VPN 装置からサーバ証明書が個人 PC に送られ，個人 PC で検証される。

〔SSL-VPN 技術調査とテレワーク環境への適用〕

インターネットのような公開ネットワーク上などで安全な通信を可能にする。

サーバ証明書の検証は，接続先が本物のサーバであることの確認（サーバ認証）である。個人 PC はインターネットを通って SSL-VPN 装置に接続するので，DNS の書換えや経路の乗っ取りで偽の装置に誘導されるおそれがある。証明書を検証しなければ，偽の SSL-VPN 装置と TLS セッションを張ってしまい，その上を通る業務の画面操作やデータが攻撃者に渡る。

本文の下線④はクライアント側の認証，下線⑤はその逆向きのサーバ側の認証で，TLS の相互認証になっている。④が「装置が利用者を確かめる」なら，⑤は「利用者が装置を確かめる」である。

35字に収める。解答例は「なりすまされたSSL-VPN装置へ接続してしまうリスク」で27字。「なりすまし」「偽の SSL-VPN 装置（接続先）」「そこへ接続してしまう」を入れる。「盗聴されるリスク」だけでは，暗号化で防ぐリスクと区別がつかない。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

クライアント側でランダムなプリマスタシークレットを生成して，サーバの RSA ［ エ ］ 鍵で暗号化してサーバに送付することで共通鍵の共有を実現する，RSA 鍵交換方式がある。

〔SSL-VPN クライアント認証方式の検討〕

⑥秘密鍵が漏えいしてしまったときに不正に復号されてしまう通信のデータの範囲が大きいという問題

RSA 鍵交換では，プリマスタシークレットがサーバの公開鍵で暗号化されて流れる。攻撃者が暗号化された通信を記録しておけば，後でサーバの秘密鍵が漏えいしたとき，記録した通信のプリマスタシークレットを復号でき，そこから共通鍵を導いて過去の通信を全部読める。静的 DH も，長く使い続ける DH の鍵が漏れれば同じことになる。

TLS1.3 の DHE・ECDHE は，セッションごとに使い捨ての鍵で鍵交換を行い，使い終わった鍵を捨てる。証明書の秘密鍵は署名（認証）にしか使わないので，それが漏れても過去の通信の共通鍵は求められない。これを前方秘匿性（Forward Secrecy）という。つまり RSA 鍵交換などで余分に復号されてしまうのは，漏えいより前の通信である。

25字に収める。解答例は「秘密鍵が漏えいする前に行われた通信のデータ」で21字。設問が指定する“秘密鍵”“漏えい”を使い，「漏えいする前」という時間の範囲を書く。「漏えい後の通信」はどの方式でもなりすましの危険があり，差にならない。

採点講評（IPA）

設問3は，TLSプロトコルのベースとなっているPKI技術の基本や，クライアント証明書による認証の基本を問う問題であるが，(1)，(4)の正答率が低かった。基本的な事柄を理解していないと思われる解答が散見されたが，これらの技術は安全なネットワークの構築のために重要なので，正確に理解してほしい。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

新しいクライアント証明書が必要なときは，利用者の公開鍵と秘密鍵を生成し，公開鍵から証明書署名要求（CSR）を作成して，CA サービスへ提出する。

〔SSL-VPN クライアント認証方式の検討〕

⑦CSR の署名を検証して

CSR（PKCS #10，RFC 2986）は，証明書にしてほしい公開鍵と名前を入れ，それに対応する秘密鍵で署名したものである。署名するのは利用者の秘密鍵，検証するのは CSR の中に入っている利用者の公開鍵になる。CA はこの検証で，申請者が公開鍵に対応する秘密鍵を確かに持っていること（鍵の所持の証明）と，CSR が途中で書き換えられていないことを確かめる。

本文の用語は「利用者の公開鍵と秘密鍵」である。設問は「本文中の用語を用いて」とあるので，この言い方に合わせて書く。

間違えやすい点。CA の秘密鍵・公開鍵ではない。CA の秘密鍵を使うのは，検証の後で CA が証明書に署名するときである。CSR の段階では CA はまだ何も署名しておらず，利用者が自分の鍵ペアを持っていることを確かめているだけである。

本文の根拠

〔SSL-VPN クライアント認証方式の検討〕

証明書失効リストは，失効した日時と⑧クライアント証明書を一意に示す情報のリストになっている。

〔SSL-VPN 技術調査とテレワーク環境への適用〕

有効期限，［ エ ］ 鍵，シリアル番号，CA のデジタル署名といった情報が含まれる。

証明書失効リスト（CRL，RFC 5280）には，失効した証明書ごとにシリアル番号と失効日時（と失効理由などの拡張）が並ぶ。シリアル番号は発行した CA がその CA の中で重複しないように振る番号なので，発行者（CRL の発行元の CA）とシリアル番号の組で証明書を一意に決められる。

本文でも，電子証明書に含まれる情報として「シリアル番号」が挙がっている。CRL は証明書の中身をまるごと載せるのではなく，この番号だけで失効した証明書を指す。

間違えやすい点。「利用者 ID」や「Subject」ではない。同じ利用者に証明書を再発行すれば Subject は同じになるので，古い証明書だけを失効させる目印にならない。

本文の根拠

〔テレワーク環境構成の検討〕

SSL-VPN 装置の⑨ユーザテーブルは，SSL-VPN 接続時の処理に必要な情報が含まれるテーブルであり，仮想 PC の起動時に自動設定される。

図3の動作(6)

(6) SSL-VPN 装置は，⑩ユーザテーブルを検索して得られる IP アドレスを用いて，NAT テーブルのエントリを作成する。

表1 仮想 PC

利用者ごとに仮想 PC があらかじめ割り当てられており，IP アドレスは静的に割り当てられている。

〔SSL-VPN クライアント認証方式の検討〕

K 社においては，社員番号を利用者 ID としてクライアント証明書に含めることにする。

SSL-VPN 装置の仕事は，接続してきた利用者を認証し，その利用者の仮想 PC へ RDP を中継することである。そのためには「この利用者の仮想 PC はどの IP アドレスか」が分かる対応表が要る。これがユーザテーブルで，利用者 ID と仮想 PC の IP アドレスを組にしたものである。

本文のつながりを追う。(6)ではユーザテーブルを検索して IP アドレスを得て，NAT テーブル（VIP 宛てを仮想 PC に DNAT するための表）を作る。得られるのは仮想 PC の IP アドレスである。一方，検索に使える手掛かりは，クライアント証明書に含めた利用者 ID（社員番号）である。表1のとおり仮想 PC は利用者ごとに割り当てられ IP アドレスは固定なので，仮想 PC が起動した時点で「利用者 ID と IP アドレスの組」を登録できる。

40字に収める。解答例は「VDI利用者の利用者IDとその利用者の仮想PCのIPアドレスの組」で32字。「利用者 ID」と「仮想 PC の IP アドレス」の両方と，それが対になっていることを書く。クライアント IP（IP アドレスプールから割り当てる方）と混同しないこと。

本文の根拠

図3の動作(3)

(3) SSL-VPN 装置は，クライアント証明書による認証を行う。

〔SSL-VPN クライアント認証方式の検討〕

K 社においては，社員番号を利用者 ID としてクライアント証明書に含めることにする。

図3

SSL-VPN クライアントから SSL-VPN 装置へ (Ⅷ) Certificate，(Ⅸ) CertificateVerify，(Ⅹ) Finished。

ユーザテーブルは利用者 ID から仮想 PC の IP アドレスを引く表なので，検索のキーは利用者 ID である。SSL-VPN 装置が利用者 ID を知る手段は，接続時に送られてくるクライアント証明書しかない（本文は社員番号を利用者 ID として証明書に含めると決めている）。

図3で，クライアント証明書が SSL-VPN 装置に届くのは，クライアントが送る Certificate メッセージ (Ⅷ) である。(Ⅴ) も Certificate だが，こちらは SSL-VPN 装置から送るサーバ証明書で向きが逆。TLS1.3 では，サーバが (Ⅳ) CertificateRequest で証明書を求め，クライアントが (Ⅷ) で証明書，(Ⅸ) で秘密鍵による署名を返す（RFC 8446）。

25字に収める。解答例は「クライアント証明書から得られる利用者ID情報」で22字。「どこから」（クライアント証明書）と「どの情報」（利用者 ID）の両方を書く。タイミングは (Ⅷ)。署名の検証まで済むのは (Ⅸ) だが，設問は情報を「得る」タイミングを問うている。

本文の根拠

〔ネットワーク冗長化の検討〕

通常は，M 社と N 社の広域イーサネットの両方を利用する。

〔ネットワーク冗長化の検討〕

その回線速度と接続トポロジは現行の M 社広域イーサネットと同等とする。

OSPF は宛先までのコストが最小の経路を選ぶ。M 社側と N 社側でコストに差があれば，片方だけが使われ，もう片方は障害時の予備として遊んでしまう。コストを等しくすると同じコストの経路が複数できて，ECMP でトラフィックを両方に振り分けられる。

本文の冗長化の方針に「通常は，M 社と N 社の広域イーサネットの両方を利用する」とある。これを OSPF で実現する手段が，図4で両方の広域イーサネット側のポートを同じ 50 にそろえたコスト設定である。N 社の回線速度とトポロジを M 社と同等にしたことも，両方を同じ重みで使う前提になっている。

30字に収める。解答例は「M社とN社の広域イーサネットの両方を利用すること」で24字。「冗長化するため」「障害に備えるため」だけでは，コストを変えて主・副の構成にしても達成できるので，ECMP を使う目的にならない。「両方を同時に（通常時から）使う」ことを書く。

本文の根拠

〔ネットワーク冗長化の検討〕

⑫L3SW11 のルーティングテーブル上には，サーバセグメントへの同一コストの複数の経路が確認できる。

図4

L2SW13 と L2SW14 はそれぞれ L3SW11 と L3SW12 の両方に接続し，L3SW11・L3SW12 の L2SW13・L2SW14 側のポートのコストはすべて 50。

図4

L3SW31 と L3SW32 はそれぞれテレワークサーバセグメントとサーバセグメントの両方に接続し，そのポートのコストはすべて 20。

図4

注記 図中の L3SW のポートの数値は，OSPF のコストを示す。

OSPF の経路コストは，宛先までに通る各ルータの出力インタフェースのコストの合計である（RFC 2328）。L3SW11 からサーバセグメントへは，まず L3SW11 自身の広域イーサネット側のポート（50）から出る。L2SW13―M 社広域イーサネット―L2SW34 は L2 でつながった1つのセグメントなので，その先の L3SW31 か L3SW32 に直接届き，そこからサーバセグメント側のポート（20）で出る。合計 50＋20＝70。

経路の数は，出口が M 社側（L2SW13）と N 社側（L2SW14）の2通り，サーバセグメントへの入口のルータが L3SW31 と L3SW32 の2通りで，2×2＝4。どれもコスト70なので同一コストの経路が4本になる。ベンダの仕様「最大で四つの同一コストルートまでサポートする」にも収まる。

間違えやすい点（講評でもコストの正答率が低かった）。コストは出力側のポートだけを数える。L3SW31 の広域イーサネット側の 50 は，L3SW31 から出ていく向きのコストなので，L3SW11 から見た経路には入らない。50＋50＋20＝120 としないこと。

採点講評（IPA）

設問5は，OSPFの等コスト経路の経路選択やVRRPと合わせた冗長経路に関する問題であるが，(2)のうち，コストの正答率が低かった。OSPFによる経路制御やVRRPと組み合わせた経路冗長化はよく利用されるので，理解を深めてほしい。

本文の根拠

〔ネットワーク冗長化の検討〕

パケットモードの場合，パケットごとにランダムに経路を選択し，フローモードの場合は，送信元 IP アドレスと宛先 IP アドレスからハッシュ値を計算して経路選択を行う。

〔ネットワーク冗長化の検討〕

P 主任は，K 社の社内の PC と業務サーバ間の通信における⑬通信品質への影響を考慮して，フローモードを選択することにした。

パケットモードでは，同じ通信のパケットでも1つずつ別の経路に振られる。M 社と N 社の回線は遅延が同じとは限らないので，後に送ったパケットが先に着く「順序の逆転」が起きる。TCP は順序が乱れると重複 ACK を返し，それが続くと送信側は喪失と判断して再送したり送信量を絞ったりするので，スループットが落ちる。

フローモードは送信元 IP アドレスと宛先 IP アドレスのハッシュ値で経路を決めるので，同じ PC と業務サーバの間のパケットは常に同じ経路を通る。1つの通信の中では順序が保たれる。

35字に収める。解答例は「フローモードはパケット到着順序の逆転が起こりにくいから」で27字。要点は「パケットの順序の逆転（順序入れ替わり）が起きにくい」こと。「同じ経路を通るから」だけでは，それが品質にどう効くかが抜ける。

本文の根拠

〔ネットワーク冗長化の検討〕

また，フローモードでも⑭複数回線の利用率がほぼ均等になると判断した。

図4

L2SW11・L2SW12 には複数の PC が接続している。

〔現行のネットワーク構成〕

サーバセグメントに設置された業務サーバに，社内の PC からアクセスして各種業務を行っている。

フローモードは送信元と宛先の IP アドレスの組ごとに経路を固定するので，組の数が少なければ特定の回線に偏る。逆に，組の数が十分に多ければ，ハッシュ値は経路の数だけの区分にほぼ均等に散らばり，回線の利用率もならされる。

K 社では本社・支社の多数の PC がそれぞれ業務サーバにアクセスする。送信元 IP アドレスは PC の数だけ，宛先も業務サーバの数だけあるので，組み合わせは十分に多い。だからハッシュ値が偏らず，フローモードでも利用率はほぼ均等になると判断できる。

45字に収める。解答例は「送信元IPアドレスと宛先IPアドレスから計算したハッシュ値が偏らないから」で36字。設問は「ECMP の経路選択の仕様に照らして」とあるので，仕様の言葉（送信元・宛先 IP アドレスから計算するハッシュ値）を使って「偏らない（均等に分散する）」ことを書く。

本文の根拠

〔ネットワーク冗長化の検討〕

図5において，L3SW31 と L3SW32 で VRRP を構成し，L3SW31 が VRRP マスタとなるように優先度を設定する。

〔ネットワーク冗長化の検討〕

これによって，a 又は b のインタフェースでリンク障害が発生した場合でも，業務サーバから PC へのトラフィックの分散が損なわれないと考えた。

図5

L3SW31 の L2SW34 側のインタフェースが a，L2SW35 側のインタフェースが b である。

業務サーバは VRRP の仮想 IP アドレスをデフォルトゲートウェイにするので，PC への戻りのトラフィックは VRRP マスタの L3SW31 がすべて受ける。a（M 社側）か b（N 社側）のリンクが切れると，L3SW31 はもう片方の広域イーサネットしか使えず，M 社と N 社への分散ができなくなる。

そこで a・b の状態をトラッキング（監視）し，障害を検知したら L3SW31 の VRRP の優先度を下げる。優先度が L3SW32 より低くなれば，L3SW32 がマスタになる（RFC 5798 では優先度の高いバックアップがマスタを奪う Preempt が既定で有効）。L3SW32 は両方の広域イーサネットにつながっているので，ECMP による分散が続く。

40字に収める。解答例は「インタフェースの障害を検知した時にL3SW31のVRRPの優先度を下げる。」で37字。“優先度”を使い，「障害検知時」「L3SW31 の」「優先度を下げる」の3つを書く。「L3SW32 がマスタになる」は結果であり，それだけでは設定による動作（優先度の変化）が書けていない。

本文の根拠

〔サーバ仮想化技術を利用した AP の構成〕

ホストサーバでは，サーバ仮想化を実現するためのソフトウェアである ［ ア ］ が動作する。

〔サーバ仮想化技術を利用した AP の構成〕

サーバセグメントでは複数の AP が動作するので，VRRP の識別子として AP ごとに異なる ［ イ ］ を割り当てる。

〔サーバ仮想化技術を利用した AP の構成〕

VRRP の規格では，最大 ［ ウ ］ 組の仮想ルータを構成することができる。

〔サーバ仮想化技術を利用した AP の構成〕

AP ごとに，コンテンツ DNS サーバにリソースレコードの一つである ［ エ ］ レコードとして VRRP で利用する仮想 IP アドレスを登録し，FQDN と IP アドレスの紐付けを定義する。

ア：物理サーバの上で複数の仮想マシンを動かすためのソフトウェアはハイパーバイザである。CPU・メモリ・NIC などを仮想化して，AP 仮想サーバ（ゲスト OS）それぞれに割り当てる。

イ・ウ：VRRP（バージョン3は RFC 5798）では，同じセグメントの複数の仮想ルータを VRID（Virtual Router Identifier）で区別する。VRID は 8 ビットで 1〜255 の値をとるので，1つのセグメントに作れる仮想ルータは最大 255 組である。本文はサーバセグメントに AP の数だけ VRRP の組ができると述べているので，AP ごとに異なる VRID を割り当てる必要がある。VRID は仮想 MAC アドレス（IPv4 なら 00-00-5E-00-01-{VRID}）の末尾にもなる。

エ：FQDN と IPv4 アドレスを対応付けるリソースレコードは A レコードである。表1の仮想ルータのアドレスは 192.168.0.16 で IPv4 なので，AAAA ではない。間違えやすい点として，ウは「組」の数を問うているので 256 ではない（VRID 0 は使わない）。

本文の根拠

〔サーバ仮想化技術を利用した AP の構成〕

①可用性を確保するために，VRRP を構成する2台の AP 仮想サーバは，異なるホストサーバに収容するように設計する。

図2

ホストサーバ：複数の AP 仮想サーバを収容する物理サーバ

〔現行のネットワーク構成〕

AP ごとに2台の AP サーバで冗長構成としている。

VRRP で2台の AP 仮想サーバを組にするのは，片方が止まってももう片方で AP を続けるためである。ところが AP 仮想サーバは物理サーバであるホストサーバの上で動くので，2台を同じホストサーバに載せると，そのホストサーバの故障や保守停止で2台が同時に止まる。冗長構成の意味が無くなる。

図2でも，AP0 の AP0a はホストサーバ a，AP0b はホストサーバ b と，組になる AP 仮想サーバを別々のホストサーバに置いている。現行でも AP ごとに2台の物理サーバで冗長化しているので，仮想化しても同じ水準を保つための設計である。

40字に収める。解答例は「ホストサーバが停止した場合，AP仮想サーバが2台とも停止する。」で31字。「ホストサーバの停止（障害）」という原因と，「2台とも（同時に）停止する」という結果を書く。「単一障害点になる」でも意味は通るが，何が止まるかまで書く方が確実である。

本文の根拠

〔サーバ仮想化技術を利用した AP の構成〕

また，②マスタとして動作している AP 仮想サーバが停止すると，バックアップとして動作している AP 仮想サーバがマスタに切り替わる。

〔サーバ仮想化技術を利用した AP の構成〕

2台の AP 仮想サーバでは，冗長構成をとるために VRRP バージョン3を動作させる。

VRRP のマスタは，自分が動いていることを知らせる VRRP アドバタイズメントを一定間隔（Advertisement_Interval，既定1秒）でマルチキャストする。バックアップはこれを受信するたびにタイマをリセットし，決められた時間（Master_Down_Interval＝アドバタイズ間隔の3倍＋Skew_Time）のあいだ受信が無ければ，マスタが停止したと判断して自らマスタになる（RFC 5798）。

本文は下線②で切替えが起きることだけを述べ，その判定方法は書いていない。VRRP バージョン3を使うと明記されているので，規格どおりの判定条件を答える。

50字に収める。解答例は「バックアップが，VRRPアドバタイズメントを決められた時間内に受信しなくなる。」で39字。要素は「VRRP アドバタイズメント（広告）」「一定時間受信しない」の2つ。講評はこの設問の正答率が低かったと述べている。「マスタから応答が無い」「ping が通らない」のように，VRRP が実際に使う仕組みと違う書き方にしないこと。

採点講評（IPA）

設問1(3)は，正答率が低かった。VRRPは可用性確保のためによく利用される技術であり，動作原理について正確に理解してほしい。

本文の根拠

〔コンテナ仮想化技術を利用した WebAP の構成〕

WebAP コンテナは，仮想ルータの上で動作する NAPT 機能と TCP や UDP のポートフォワード機能を利用して，PC や共用 DB サーバなどといった外部のホストと通信する。

〔コンテナ仮想化技術を利用した WebAP の構成〕

③複数ある全ての仮想ブリッジセグメントには，同じ IP アドレスを割り当てる。

図4

(ⅱ) の箇所で通信が確認できる HTTP 接続要求パケット：192.168.0.98，54382，192.168.0.112，8000／192.168.0.98，34953，192.168.0.112，8001。

仮想ブリッジセグメントのアドレスは，コンテナサーバの中だけで使うアドレスである。外へ出る通信は仮想ルータの NAPT で送信元がコンテナサーバの IP アドレスに変わり，外から入る通信はコンテナサーバの IP アドレスとポート番号宛てに届いてから，ポートフォワードでコンテナのアドレスに変換される。サーバセグメントや PC から見えるのはコンテナサーバの IP アドレスだけで，172.16.0.0/24 のアドレスは外に出ない。

図4でも，共用リバースプロキシが送る (ⅱ) の宛先は 192.168.0.112（コンテナサーバ a）で，172.16.0.16 に変わるのは仮想ルータを過ぎた (ⅲ) だけである。各コンテナサーバの仮想ルータが別々に変換するので，どのコンテナサーバの中で同じアドレスを使っても衝突しない。家庭のルータの内側で同じ 192.168.1.0/24 を使っても困らないのと同じ理屈である。

40字に収める。解答例は「外部ではコンテナサーバに付与したIPアドレスが利用されることはないから」で35字。要点は「外部から見えるのはコンテナサーバの IP アドレス（仮想ブリッジセグメントのアドレスは外に出ない）」こと。「プライベートアドレスだから」だけでは，サーバセグメントもプライベートアドレスなので理由にならない。

本文の根拠

〔コンテナ仮想化技術を利用した WebAP の構成〕

④ヘッダフィールド情報から WebAP を識別し，WebAP が動作する WebAP コンテナへ HTTP リクエストを振り分ける。

表4

AP0 の行：（設問のため省略）の列は ap0.u-sha.com

図4

(ⅰ) の箇所で通信が確認できる HTTP 接続要求パケット：192.168.145.68，30472，192.168.0.98，80／192.168.145.154，31293，192.168.0.98，80。

HTTP/1.1 のリクエストには，アクセス先のホスト名を入れる Host ヘッダフィールドが必ず付く（定義は RFC 9110，HTTP/1.1 で必須とするのは RFC 9112）。Web ブラウザで http://ap0.u-sha.com/ を開けば Host: ap0.u-sha.com が送られる。1つの IP アドレスとポートで複数のサイトを受ける名前ベースの仮想ホストや，リバースプロキシの振り分けはこの値を使う。

図4の (ⅰ) を見ると，どの AP 宛てのリクエストも宛先は 192.168.0.98 の 80 番で，IP アドレスやポート番号では AP を区別できない。それでも振り分けられるのは，表4で「設問のため省略」とされた列に ap0.u-sha.com・ap1.u-sha.com という FQDN が入っているからで，これを Host ヘッダの値と照らし合わせている。

15字に収める。解答例は「ホストヘッダフィールド」で11字。講評はこの設問の正答率が低かったと述べている。「URL」「リクエストライン」は近いが，設問はヘッダフィールドを問うている。「User-Agent」「Referer」は AP の識別には使えない。

採点講評（IPA）

設問2(2)は，正答率が低かった。HTTPのヘッダフィールド情報のうち，ホストヘッダフィールドを用いてアプリケーションを識別する技術はリバースプロキシでよく利用される。HTTPプロトコルの特徴を踏まえ理解を深めてほしい。

本文の根拠

PC と AP0 の通信の例(2)

(2) PC は DNS を参照して，ap0.u-sha.com の接続先 IP アドレスとして ［ オ ］ を取得する。

表2

共用リバースプロキシ：192.168.0.98/22。

PC と AP0 の通信の例(5)

(5) 共用リバースプロキシは宛先 IP アドレスが 192.168.0.112，宛先ポート番号が ［ カ ］ 番宛てへ通信を開始する。

表4

WebAP コンテナ AP0a の振り分け先は 192.168.0.112:8000

オ：PC は WebAP コンテナに直接つながず，共用リバースプロキシに HTTP リクエストを送る。したがって DNS に登録しておく ap0.u-sha.com のアドレスは共用リバースプロキシのアドレスで，表2から 192.168.0.98 である。図4の (ⅰ) でも PC からのパケットの宛先は 192.168.0.98 の 80 番になっている。

カ：共用リバースプロキシは表4の振り分けルールに従い，AP0 のリクエストを AP0a（192.168.0.112:8000）か AP0b（192.168.0.113:8000）へ送る。(5) の宛先は 192.168.0.112 なので AP0a で，ポート番号は 8000。図4の (ⅱ) の1行目（宛先 192.168.0.112，8000）とも合う。

間違えやすい点。カを 80 としないこと。80 は PC から共用リバースプロキシへの宛先ポート（(3)）と，仮想ルータで変換した後のコンテナのポート（(ⅲ)）で，コンテナサーバ宛ての段階では AP ごとに違う 8000・8001 が使われる。

本文の根拠

PC と AP0 の通信の例(6)

(6) 仮想ルータは宛先 IP アドレスが 192.168.0.112，宛先ポート番号が ［ カ ］ 番宛てへの通信について，⑤ポートフォワードの処理によって宛先 IP アドレスと宛先ポート番号を変換する。

表3

WebAP コンテナ（AP0a）：172.16.0.16/24。

図4

(ⅲ) の箇所で通信が確認できる HTTP 接続要求パケット：192.168.0.98，54382，172.16.0.16，80／192.168.0.98，34953，172.16.0.17，80。

ポートフォワード（静的な宛先 NAT）は，外側のアドレスとポートの組を，内側の特定のホストのアドレスとポートの組に書き換える。仮想ルータは 192.168.0.112:8000 宛ての通信を，AP0a の WebAP コンテナのアドレスとポートに変換する。

変換後の宛先は，表3から AP0a の 172.16.0.16，ポートは Web サーバの標準の 80 番である。図4で (ⅱ) の 1行目（送信元ポート 54382，宛先 192.168.0.112:8000）と同じ送信元ポートをもつ (ⅲ) の1行目を見ると，宛先が 172.16.0.16，80 に変わっていることで確かめられる。

間違えやすい点。変換で変わるのは宛先だけで，送信元（192.168.0.98，54382）はそのまま残る。宛先 IP アドレスに仮想ルータ自身の 172.16.0.1 を書かないこと。

本文の根拠

〔コンテナ仮想化技術を利用した WebAP の構成〕

WebAP コンテナは，仮想ルータの上で動作する NAPT 機能と TCP や UDP のポートフォワード機能を利用して，PC や共用 DB サーバなどといった外部のホストと通信する。

〔コンテナ仮想化技術を利用した専用 AP の構成〕

⑥PC や共用 DB サーバなどといった外部のホストとの通信の際に，仮想ルータのネットワーク機能を使用しても専用 AP が正常に動作することを確認する必要があると考えています。

〔コンテナ仮想化技術を利用した専用 AP の構成〕

専用 AP は TCP/IP を使った独自のプロトコルを利用するので，HTTP 通信を利用する WebAP と比較して，通信の仕方に不明な点が多いと感じた。

コンテナが外部と通信するときに仮想ルータが使う機能は，本文が WebAP コンテナについて述べている2つ，NAPT 機能（コンテナから外へ出る通信の送信元の変換）とポートフォワード機能（外から入る通信の宛先の変換）である。専用 AP コンテナも同じ構成なので，同じ2つの機能を通ることになる。

AP サーバで動いていたときは，専用 AP は自分の IP アドレスとポート番号でそのまま通信していた。コンテナにすると，途中でアドレスとポートが書き換わる。独自プロトコルの中には，通信データの中に自分の IP アドレスやポート番号を書き込んだり，サーバ側から別のコネクションを張り返したりするものがあり（FTP のアクティブモードが典型例），こうした AP はアドレス変換を通すと正しく動かない。本文が「通信の仕方に不明な点が多い」と懸念しているのはこの点である。

間違えやすい点。「仮想ブリッジ」は L2 でフレームを中継するだけで，アドレスを書き換えないので確認の対象にならない。①②はどちらの順で書いてもよい。

本文の根拠

〔コンテナ仮想化技術を利用した専用 AP の構成〕

それと，⑦同じポート番号を使用する専用 AP が幾つかあるので，これらの専用 AP に対応できる負荷分散機能をもつ製品が必要になります。

〔現行のネットワーク構成〕

TCP/IP を使った独自のプロトコルを利用して PC からアクセスされる AP（以下，専用 AP という）もある。

〔コンテナ仮想化技術を利用した WebAP の構成〕

④ヘッダフィールド情報から WebAP を識別し，WebAP が動作する WebAP コンテナへ HTTP リクエストを振り分ける。

WebAP は HTTP の Host ヘッダで AP を見分けられたので，共用リバースプロキシは1つの IP アドレス・1つのポートで全部を受けられた。専用 AP は独自プロトコルなので，負荷分散装置が中身を読んで AP を見分けることはできない。見分ける手掛かりは IP アドレスとポート番号しかない。

さらに同じポート番号を使う専用 AP が複数あるので，ポート番号でも区別できない。残るのは IP アドレスである。負荷分散装置に AP ごとに別の IP アドレス（仮想 IP アドレス）を持たせ，宛先 IP アドレスで専用 AP を識別して，その AP の専用 AP コンテナへ振り分ければよい。各 AP の FQDN の A レコードをそれぞれのアドレスに向ければ，クライアント側の変更も要らない。

40字に収める。解答例は「複数のIPアドレスを設定し，IPアドレスごとに専用APを識別する仕組み」で35字。「複数の IP アドレスをもつ」ことと「IP アドレスで専用 AP を識別する」ことの両方を書く。「ポート番号で振り分ける」は，同じポートの AP があるという前提に反する。

本文の根拠

〔監視の検討〕

ping 監視は，監視サーバが監視対象の機器に対して ICMP のエコー要求を送信し，一定時間以内に ［ キ ］ を受信するかどうかで，IP パケットの到達性があるかどうかを確認する。

〔監視の検討〕

TCP 接続監視では，監視サーバが監視対象の機器に対して SYN パケットを送信し，一定時間以内に ［ ク ］ パケットを受信するかどうかで，TCP で通信ができるかどうかを確認する。

〔監視の検討〕

URL 接続監視では，監視サーバが監視対象の機器に対して HTTP ［ ケ ］ メソッドでリソースを要求し

キ：ping は ICMP のエコー要求（Echo，タイプ8）を送り，相手はエコー応答（Echo Reply，タイプ0）を返す（RFC 792）。応答が返れば IP で届くことが分かる。

ク：TCP の接続は3ウェイハンドシェークで始まる。SYN を受けた側は，そのポートで待ち受けていれば SYN/ACK（SYN と ACK の両フラグを立てたセグメント）を返す。待ち受けていなければ RST が返るので，SYN/ACK が返るかどうかで TCP のサービスが動いているかが分かる。ケ：リソースを取得する HTTP のメソッドは GET である（RFC 9110）。表5の URL 接続監視の設定値も index.html を取得する形になっている。

間違えやすい点。キは「エコー応答」で，ICMP の「宛先到達不能」などではない。クは「ACK」だけではなく SYN/ACK。ケは「HEAD」でも応答の有無は確かめられるが，本文は「リソースを取得できるかどうか」と書いているので本体を取得する GET になる。

本文の根拠

表5

ping 監視：項番1 共用リバースプロキシ 192.168.0.98，項番2 コンテナサーバ a 192.168.0.112，項番3 コンテナサーバ b 192.168.0.113。

表5

TCP 接続監視：項番4 WebAP コンテナ（AP0a） 192.168.0.112:8000，項番5 WebAP コンテナ（AP0b） 192.168.0.113:8000。

〔監視の検討〕

ping 監視で WebAP コンテナの稼働状態を監視することはできない。

3つの監視は下の層から順に，ping が IP の到達性，TCP 接続監視が TCP のポートの待受け，URL 接続監視が HTTP の応答を見ている。上の層の監視は下の層が通ることを前提にしているので，一番下の層で失敗している監視対象を探せばよい。

項番2はコンテナサーバ a（192.168.0.112）への ping で，これが失敗している。コンテナサーバ a に IP で届かないのだから，その上の AP0a への TCP 接続（項番4，192.168.0.112:8000）も URL 接続（項番7）も当然失敗する。一方，コンテナサーバ b 側の項番3・5・8 は正常で，共用リバースプロキシ経由の項番6も AP0b に振り分けられて正常になる。障害はコンテナサーバ a（本体か NIC・接続）にあると考えられる。

間違えやすい点。「WebAP コンテナ（AP0a）」と答えると，項番2（コンテナサーバ a への ping）の失敗が説明できない。本文のとおり ping ではコンテナの状態は分からず，ping の宛先 192.168.0.112 はコンテナサーバ a そのものである。表5中の字句で答えるので「コンテナサーバ a」と書く。

本文の根拠

表5

URL 接続監視：項番6 共用リバースプロキシ http://ap0.u-sha.com:80/index.html，項番7 WebAP コンテナ（AP0a） http://192.168.0.112:8000/index.html，項番8 WebAP コンテナ（AP0b） http://192.168.0.113:8000/index.html。

表5

TCP 接続監視：項番4 WebAP コンテナ（AP0a） 192.168.0.112:8000，項番5 WebAP コンテナ（AP0b） 192.168.0.113:8000。

〔監視の検討〕

⑧表5のように複数の監視を組み合わせることによって，監視サーバによる障害検知時に，監視対象の状態を推測することができる。

今度は項番2（コンテナサーバ a への ping）が正常なので，コンテナサーバ a までは IP で届いている。失敗しているのは項番4（192.168.0.112:8000 への TCP 接続）と項番7（同じポートへの URL 接続）で，どちらも AP0a の WebAP コンテナに向けた監視である。

192.168.0.112:8000 への通信は，仮想ルータのポートフォワードで AP0a（172.16.0.16:80）に届く。コンテナサーバ a は生きていて，AP0a のポートだけが応答しないので，WebAP コンテナ（AP0a）が停止しているか，そこで HTTP サーバが動いていないと考えられる。AP0b 側の項番5・8 と，AP0b に振り分けられる項番6 は正常なので，共用リバースプロキシや AP0 全体の問題でもない。

間違えやすい点。設問4(2)との違いは項番2が正常かどうかだけである。下の層（ping）が通っていれば，原因はその上にある。表5中の字句で答えるので「WebAP コンテナ（AP0a）」と書く（単に AP0 や AP0a と書くと AP 全体やサーバ名と紛らわしい）。

本文の根拠

表6 項番4

⑨テスト用の PC を用いて動作確認を行う。

表6 項番5

DNS レコードを書き換え，AP サーバから WebAP コンテナへ切り替える。

〔サーバ仮想化技術を利用した AP の構成〕

PC にインストールされている Web ブラウザ及び専用クライアントソフトウェアは，DNS の ［ エ ］ レコードを参照して接続する AP の IP アドレスを決定する。

動作確認（項番4）は DNS 切替え（項番5）より前に行う。この時点で DNS の A レコードはまだ AP サーバを指しているので，普通の PC で http://ap0.u-sha.com/ を開くと，移行前の AP サーバにつながってしまう。WebAP コンテナを試すには，テスト用の PC だけが FQDN を新しいアドレス（共用リバースプロキシの 192.168.0.98）に解決するようにしなければならない。

そのための手段が hosts ファイルである。多くの OS は名前解決のときに DNS より先に hosts ファイルを参照するので，AP の FQDN と共用リバースプロキシの IP アドレスを書いておけば，その PC だけが新しい構成に接続する。共用リバースプロキシは Host ヘッダで振り分けるので，IP アドレスを直接打ち込むのではなく FQDN のまま接続できることも大事である。

40字に収める。解答例は「APのFQDNとIPアドレスをPCのhostsファイルに記載する。」で33字。「hosts ファイル」「FQDN と IP アドレス（移行先）」を書く。「DNS を書き換える」は項番5そのもので，全利用者に影響する。

本文の根拠

表6 項番7

⑩停止して問題ないことを確認した後に AP サーバを停止する。

〔移行手順の検討〕

同じ動作をするので，DNS レコードの書換えが反映されるまでの並行稼働期間中，AP サーバと WebAP コンテナ，どちらにアクセスが行われても問題ありません。

DNS レコードを書き換えても，すぐに全員が新しいアドレスへ移るわけではない。キャッシュ DNS サーバや PC が古い A レコードをキャッシュしている間は，AP サーバへのアクセスが続く。この並行稼働期間中に AP サーバを止めると，まだ古いアドレスを使っている利用者の通信が切れてしまう。

本文の会話でも，並行稼働期間中は「どちらにアクセスが行われても問題ありません」と，両方が動いていることを前提にしている。だから AP サーバを止める前に，AP サーバへの PC からのアクセスが無くなった（全員が WebAP コンテナへ移った）ことを，AP サーバのアクセスログや通信量などで確かめる。

40字に収める。解答例は「APサーバに対するPCからのアクセスがなくなっていることを確認する。」で34字。「AP サーバへのアクセスが無い」ことを書く。「WebAP コンテナが正常に動作していること」は項番4の動作確認や監視で済んでいることで，AP サーバを止めてよい理由の決め手にはならない。

本文の根拠

〔移行手順の検討〕

並行稼働期間を短くするために DNS 切替えの事前準備は何があるかな。

〔移行手順の検討〕

⑪あらかじめ，DNS の TTL を短くしておく方が良いですね。

〔現行のネットワーク構成〕

キャッシュ DNS サーバは，社員が利用する PC やサーバからの問合せを受け，ほかの DNS サーバへ問い合わせた結果，得られた情報を応答する。

DNS のリソースレコードの TTL（Time To Live）は，そのレコードをキャッシュしてよい時間（秒）である（RFC 1035）。キャッシュ DNS サーバは，コンテンツ DNS サーバから得た A レコードを TTL の間だけ保持し，その間は問い合わせても新しい値を取りに行かない。TTL が長いままレコードを書き換えると，古い値が残る時間も長くなり，並行稼働期間が延びる。

そこで切替えの前に TTL を短くしておく。すると U 社のキャッシュ DNS サーバがキャッシュを保持する時間が短くなり，書換え後すぐに古い値が消えて新しい値を取り直す。事前に短くしておくのは，変更前の長い TTL で既に配られたキャッシュが切れるのを待つ必要があるからである。

40字に収める。解答例は「キャッシュDNSサーバのDNSキャッシュを保持する時間が短くなる。」で33字。設問の「何が」は「キャッシュ DNS サーバの DNS キャッシュの保持時間」，「どのように」は「短くなる」。「DNS の問合せが増える」も起きることだが，並行稼働期間を短くする理由として答えるべきはキャッシュの保持時間である。

本文の根拠

〔移行手順の検討〕

WebAP コンテナ2台で構成する場合は，⑫次の3パターンそれぞれで AP の動作確認を行います。

〔移行手順の検討〕

一つ目は，全ての WebAP コンテナが正常に動作している場合，二つ目は，2台のうち1台目だけ WebAP コンテナが停止している場合，最後は，2台目だけ WebAP コンテナが停止している場合です。

表6 項番1

コンテナサーバ上に WebAP コンテナを構築する。

表6 項番2

WebAP コンテナに合わせて振り分けルールの設定を行う。

動作確認（項番4）は，その前に行った作業が正しくできたかを確かめる場である。前の作業は，項番1の WebAP コンテナの構築と，項番2の共用リバースプロキシの振り分けルールの設定（項番3の監視登録は，本文の最後の「障害検知の結果から，正しく監視登録されたことの確認」で別に確かめている）。

両方動いている状態だけで試すと，どちらか1台に振り分けられて AP が動いたとしても，もう1台が正しく構築されているかは分からない。1台目だけ止めれば2台目だけで，2台目だけ止めれば1台目だけで AP が動くかを確かめられるので，2台それぞれが正しく構築されたことが確認できる。また，止めた方がヘルスチェックで振り分け先から外れ，残った方へ振り分けられることから，振り分けルールとヘルスチェックの設定が正しいことも確認できる。

各35字に収める。解答例は「WebAPコンテナ2台が正しく構築されたことを確認するため」（29字）と「共用リバースプロキシの設定が正しく行われたことを確認するため」（30字）。講評は，共用リバースプロキシの動作確認だけに着目した解答が多かったと述べている。2つめを「振り分けができること」「ヘルスチェックが働くこと」と書くのはよいが，1つめのコンテナの構築の確認を落とさないこと。①②はどちらの順で書いてもよい。

採点講評（IPA）

設問5(4)は，正答率が低かった。本問の動作確認を行う目的は，移行手順に記載の作業が正しく行われたことを確認するためである。共用リバースプロキシの動作確認だけに着目した解答が散見された。本文中に示された状況をきちんと読み取り，正答を導き出してほしい。