Y 社は，産業機械の製造会社であり，本社の他に，工場と 3 か所の営業所がある。Y 社の先進的な技術によって製造された製品は，顧客から高い評価を受けている。この優位性を維持するために，Y 社ではこれまで，知財情報，個人情報などの安全な管理に注力してきた。
Y 社では，製品の設計，開発及び外注先・顧客との情報交換に，電子メール（以下，メールという）を活用している。Y 社のネットワークシステム構成を，図1に示す。
図1 Y 社のネットワークシステム構成
全社（本社，工場及び営業所）のネットワーク，サーバ及び PC のメンテナンスは，管理セグメントの管理 PC を使用して行われている。各営業所には，当該営業所の営業所員が使用する PC とファイルサーバが設置されている。管理 PC を含む全社で使用されている PC（以下，全社の PC という）からインターネット上の Web サーバ，FTP サーバへのアクセスは，プロキシサーバを介してだけ可能である。本社と工場にはメールサーバが設置され，本社社員と営業所員は本社メールサーバで，工場社員は工場メールサーバで，メールの送受信を行っている。
メールの転送経路を，表1に示す。
表1 メールの転送経路
最近，特定の企業，官公庁などを標的にして，その組織が保有する知財情報，個人情報などの重要な情報を窃取又は破壊する，標的型メール攻撃が増加してきた。この状況に対応するために，Y 社では，標的型メール攻撃の対策を行うことにした。そこで，情報システム部の M 部長は，セキュリティ担当の S 主任とネットワーク担当の N 主任に，対策案の検討を指示した。
S 主任と N 主任は，対策案の検討に先立ち，今後の進め方について打合せを行った。そのときの会話の一部を，次に示す。
S 主任：標的型メール攻撃に対しては，マルウェアの侵入を防ぐ入口対策だけではなく，社内の LAN に侵入したマルウェアの活動を抑えたり，活動を発見しやすくしたりする対策（以下，出口対策という）も必要になっているようだ。N 主任には，ネットワークでの入口対策と出口対策を検討してもらって，私は，サーバと PC に必要なマルウェア対策と運用規程を見直すことにする。
N 主任：了解した。検討後に対策案を持ち寄って，実施する対策について話し合おう。
N 主任は，S 主任との打合せの後，部下の J 君に，標的型メール攻撃の手法の調査と対策案の検討を指示した。
〔標的型メール攻撃の手法と対策案〕
J 君は，標的型メール攻撃の手法の調査と対策案の検討を行った。
標的型メール攻撃の多くは，ソーシャルエンジニアリング手法で収集した攻撃対象者の情報を基に，（ア）攻撃対象者と関係がありそうな組織，機関及び実在の人物を装ったメールを送り付けてくる手法をとる。送り付けられたメールには，悪意のあるコード，マルウェアが埋め込まれたファイルが添付されていたり，マルウェアが仕込まれた Web サイトへのリンク先を示す a が本文に記載されていたりする。
社内に侵入したマルウェアは，インターネット上の攻撃者のサーバとの通信路となるバックドアを開設して，攻撃基盤を構築することが多い。HTML で作成されたコンテンツの送受信用プロトコルである b によってバックドアの通信が行われた場合，業務での通信との区別が困難である。マルウェアは，攻撃基盤を構築した後，システム内部への侵入を行い，拡散，重要情報の窃取，破壊などを行う。
SMTP では，送信者が，自分自身のメールアドレスを容易に詐称することができる。しかし，送信元の MTA 又は MUA が稼働するサーバ又は PC に設定されている c を書き換えることは困難である。そこで，（イ）ドメインを比較するだけでも，送信者のメールアドレスが詐称されているかどうかが，ある程度判別できる。
J 君は，ネットワークにおける出口対策には，プロキシサーバでの対策と社内の LAN での対策が有効と考えた。プロキシサーバでの対策として，既設のプロキシサーバを，認証機能と，HTTPS で暗号化されたデータを復号する機能とをもつ機種に交換する。認証機能によって，マルウェアによるプロキシサーバ経由の通信を困難にさせるだけでなく，取得できるログの情報が増える。復号機能によって，SSL/TLS（以下，SSL という）通信でも，受信したデータ中に不適切な言葉や文字列などが含まれていたとき，その通信を遮断する d や，Web サーバからダウンロードされるファイルに対するウイルスチェックなどの，セキュリティ対策が行えるようになる。
社内の LAN での対策としては，図1中の L3SW1 にパケットフィルタリングを設定して，業務に不要な通信を遮断する。
J 君は，これらの検討結果を N 主任に報告した。そのときの N 主任と J 君の会話の一部を，次に示す。
N 主任：SPF は入口対策として，容易に導入できそうだな。
J 君：はい。機器の交換とか，新たな機器の導入は必要ありません。
N 主任：出口対策も効果がありそうだ。しかし，プロキシサーバが SSL を終端できると中間者攻撃が可能になってしまうので，復号機能の実現方法を調べてくれないか。パケットフィルタリングについては，具体的に検討してみなさい。
J 君：分かりました。早速，調査・検討してみます。
〔プロキシサーバの復号機能の実現方法〕
まず，J 君は，プロキシサーバの復号機能の実現方法について調査した。
PC は，Web サーバとの間で SSL 通信を行うときには，プロキシサーバ宛てに connect 要求を送信する。復号機能をもたない既設のプロキシサーバの場合，受信した connect 要求に含まれる接続先サーバとの間で，指定された宛先ポート番号に対して TCP コネクションを確立する。その後，プロキシサーバは PC に connect 応答を送信して，それ以降に受信した TCP データをそのまま接続先に転送する，e 処理の準備が整ったことを知らせる。
図3に示したように，PC からの connect 要求を受信したプロキシサーバは，まず，①〜③の手順で Web サーバとの間で SSL セッションを開設し，更に PC との間でも，④〜⑥の手順で SSL セッションを開設する。このとき，⑤で，プロキシサーバは，サブジェクト（Subject）に含まれるコモン名（CN：Common Name）に，サーバ証明書1と同じ情報をもたせたサーバ証明書2を生成して，PC 宛てに送信する。PC はサーバ証明書2を検証し，認証できたときに⑥が行われ，SSL セッションが開設される。ここで，PC がサーバ証明書2を正当なものと判断してプロキシサーバを認証するためには，PC に，（エ）サーバ証明書2を検証するのに必要な情報を保有させる必要がある。
なお，仮に，図3中の⑤で，プロキシサーバが Web サーバから取得したサーバ証明書1を PC に送信した場合，PC によるプロキシサーバの認証は成功する。しかし，（オ）⑥において，プリマスタシークレット（Premaster Secret）の共有に失敗するので，このような方法で SSL セッションを開設することはできない。
調査の結果，J 君は，プロキシサーバの復号機能の実現方法を確認できたので，次のステップとして，社内の LAN におけるセグメント間のパケットフィルタリングについて検討した。
表4 ポート A に設定するパケットフィルタリングルール表5 ポート B に設定するパケットフィルタリングルール
J 君は，全ての調査・検討が終了した後，プロキシサーバの復号機能の実現方法と，パケットフィルタリングルールの内容を N 主任に説明した。説明を聞いた N 主任は，プロキシサーバの復号機能については中間者攻撃に対して安全であることを了解した。しかし，パケットフィルタリングルールの内容については，（カ）表4にルールの漏れが一つあるので，項番1，2の間に追加するよう指示した。
〔入口対策と出口対策の実施項目〕
N 主任は，J 君の報告を基に対策案をまとめ，実施に移す対策（以下，実施策という）について S 主任と打合せを行った。そのときの N 主任と S 主任の会話を，次に示す。
N 主任：ネットワークでの入口対策と出口対策の案をまとめた。入口対策としては，SPF を導入する。出口対策としては，既設のプロキシサーバを認証機能と復号機能をもつ機種に交換し，L3SW1 にパケットフィルタリングを設定する。
S 主任：分かった。私の方では，サーバ，PC 及び FW でのマルウェア対策の実施状況について調査したところ，ウイルス対策ソフトの運用とセキュリティパッチの適用は，運用規程どおり実施されていた。また，FW では，社内の LAN からインターネットへの不必要な通信の遮断設定が適切に行われていた。しかし，不審なメールへの対応と，社内に侵入したマルウェアの活動を発見するためのログの検査が，適切には行われていなかった。今後，不審なメールへの対応に関する規程を定め，ログの検査方法・検査内容を見直すことにする。
N 主任：プロキシサーバの交換で，マルウェアの活動を発見しやすくなるな。
S 主任：そうだな。プロキシサーバで利用者認証を行えば，マルウェアによるバックドアの通信路の開設を困難にできるだけでなく，バックドアの通信が発見しやすくなる。セキュリティチームで，認証効果を高めるための全社の PC への対策と，プロキシサーバのログの定期的な検査を行うことにする。
N 主任：それでは，2 人の検討結果をまとめて，M 部長に提案しよう。
N 主任と S 主任は，検討結果を基に，次の 6 項目から成る標的型メール攻撃に対する実施策をまとめ，M 部長に提出した。
ソーシャルエンジニアリング手法で収集した攻撃対象者の情報を基に，（ア）攻撃対象者と関係がありそうな組織，機関及び実在の人物を装ったメールを送り付けてくる手法をとる。送り付けられたメールには，悪意のあるコード，マルウェアが埋め込まれたファイルが添付されていたり，マルウェアが仕込まれた Web サイトへのリンク先を示す a が本文に記載されていたりする。
関係のありそうな組織や実在の人物を装うのは，受信者に警戒を解かせ，メールの中の仕掛けに自分から手を触れさせるためである。仕掛けは本文が挙げる二つ，マルウェアが埋め込まれた添付ファイルと，マルウェアが仕込まれた Web サイトへのリンクである。したがって誘導したい行動は，添付ファイルを開くことと，リンク先にアクセスすることになる。
SMTP では，送信者が，自分自身のメールアドレスを容易に詐称することができる。しかし，送信元の MTA 又は MUA が稼働するサーバ又は PC に設定されている c を書き換えることは困難である。そこで，（イ）ドメインを比較するだけでも，送信者のメールアドレスが詐称されているかどうかが，ある程度判別できる。
詐称しやすい情報と詐称しにくい情報を突き合わせる，という発想である。詐称しやすいのは送信者のメールアドレス（そのドメイン部分）で，詐称しにくいのは送信元 MTA の IP アドレス（空欄 c）である。IP アドレスは DNS の逆引きなどで所属するドメインが分かるので，その二つのドメインが一致するかを見れば，なりすましをある程度見抜ける。
字数の詰め方（50字）。比較する二つを「A と，B」の形で並べる。解答例は「メール送信元の MTA の IP アドレスが所属するドメインと，送信者のメールアドレスのドメイン」（44字）である。講評は，詐称が可能な情報と困難な情報の区別が付いていない誤答が多かったとしている。ヘッダの From とエンベロープの MAIL FROM のように，どちらも送信者が自由に書ける情報どうしを比べても判別には役立たない。
本文中の下線（ウ）について，Y 社には 3 台のメールサーバがあるが，その中でメール中継サーバの IP アドレスを記述する理由を，30 字以内で述べよ。
解答例
社外に送信されるメールの送信元IPアドレスになるから
解説
本文の根拠
〔標的型メール攻撃の手法と対策案〕
Y 社で SPF を導入するときは，DMZ の社外向け DNS サーバに，（ウ）メール中継サーバの IP アドレスを記述した SPF レコードを追加することになる。
表1
宛先 社外 は PC → 本社メールサーバ → メール中継サーバ → 社外。
図2
④ メールサーバ1は，SPF レコードに登録されたメールサーバの IP アドレスを基に，受信したメールの正当性を検査する。
SPF レコードには，そのドメインのメールを送り出してよいサーバの IP アドレスを登録する（RFC 7208）。受信側は，SMTP で接続してきた相手の IP アドレスがそこに載っているかを調べる。表1のとおり，Y 社から社外へのメールは本社・工場のどちらから出したものも，最後はメール中継サーバから社外に送られる。社外の受信サーバから見た送信元 IP アドレスは，常にメール中継サーバのアドレスである。本社メールサーバと工場メールサーバはプライベート IP アドレスで，社外と直接やり取りしない。
根拠は表1の「社外」宛ての経路で，いずれも「→ メール中継サーバ → 社外」で終わっている。図2④が，受信側が照合するのは SPF レコードに登録された IP アドレスだと述べている。
字数の詰め方（30字）。「社外から見た送信元 IP アドレスである」ことを書く。解答例は「社外に送信されるメールの送信元 IP アドレスになるから」（26字）である。講評は，本文を読めば前提知識が無くても解けたと述べている。
Y 社で SPF を導入するとき，社外向け DNS サーバへの SPF レコードの追加とともに，SPF による認証処理を実施することになる。その認証処理を実施させるサーバ名を，図1中の名称で答えよ。また，認証処理を正しく行うには，そのサーバでなければならない理由を，30 字以内で述べよ。
〔サーバ名〕解答例
メール中継サーバ
〔理由〕解答例
社外からY社宛てに送信されたメールを直接受信するから
解説
本文の根拠
表2
メール中継サーバ：用途 社外から Y 社宛てに送信されるメールの中継，Y 社から社外宛てに送信されるメールの中継，アクセス元 社外，本社メールサーバ。
表1
送信元が社外の場合：宛先 本社，営業所 は 社外 → メール中継サーバ → 本社メールサーバ。
図2
④ メールサーバ1は，SPF レコードに登録されたメールサーバの IP アドレスを基に，受信したメールの正当性を検査する。
SPF の検査は，SMTP で接続してきた相手の IP アドレスを，送信者のドメインの SPF レコードと照合するものである（RFC 7208）。社外からのメールを最初に受け取るのはメール中継サーバで，その時点では接続元が社外の送信サーバそのものである。本社メールサーバや工場メールサーバで検査すると，接続元はメール中継サーバ（や本社メールサーバ）になり，本来の送信元の IP アドレスが見えない。したがって認証処理はメール中継サーバで行う。
根拠は表1・表2である。社外からのメールは必ず「社外 → メール中継サーバ」と入り，表2でメール中継サーバのアクセス元に「社外」がある。図2④で照合に使うのは送信側メールサーバの IP アドレスである。
字数の詰め方（理由30字）。社外からのメールを「直接」受け取ることを書く。解答例は「社外から Y 社宛てに送信されたメールを直接受信するから」（26字）である。「DMZ にあるから」だけでは，なぜ検査が正しく行えるのかにつながらない。
既設のプロキシサーバは，connect 要求を受けると Web サーバとの TCP コネクションを張り，その後は受け取った TCP データを中身を見ずにそのまま転送する（トンネリング）。SSL のハンドシェイクもこのトンネルの中を素通りするので，SSL セッションは PC と Web サーバの間に直接できる。プロキシサーバは暗号化されたデータを運ぶだけで，SSL の当事者にはならない。
PC はサーバ証明書を，その発行者の署名をたどって，自分が信頼するルート証明書に行き着くかで検証する（RFC 5280 の証明書パス検証）。サーバ証明書2はプロキシサーバがその場で生成したものなので，公的な認証局の署名は無い。プロキシサーバ自身が認証局として署名するので，PC がそれを信頼するには，プロキシサーバのルート証明書を信頼済みとして PC に入れておく必要がある。
なお，仮に，図3中の⑤で，プロキシサーバが Web サーバから取得したサーバ証明書1を PC に送信した場合，PC によるプロキシサーバの認証は成功する。しかし，（オ）⑥において，プリマスタシークレット（Premaster Secret）の共有に失敗するので，このような方法で SSL セッションを開設することはできない。
RSA 鍵交換の SSL/TLS（TLS 1.2 まで。RFC 5246）では，クライアントがプリマスタシークレットを生成し，受け取ったサーバ証明書の公開鍵で暗号化してサーバに送る。サーバは対応する秘密鍵で復号して，両者で同じプリマスタシークレットから共通鍵を作る。PC にサーバ証明書1を渡すと，PC は Web サーバの公開鍵で暗号化する。その秘密鍵は Web サーバしか持っていないので，プロキシサーバは復号できず，共有に失敗する。
根拠は下線（オ）の「⑥において，プリマスタシークレットの共有に失敗する」で，⑥は図3の共通鍵生成の段階である。サーバ証明書1は Web サーバのものであり，プロキシサーバの持ち物ではない。
③管理 PC については，上記①，②の他に，他のセグメントの PC 及びサーバへのリモート接続と疎通テストのための通信を許可する。
TCP のコネクションは，開始側が SYN=1，ACK=0 のセグメントを送って始まる（RFC 9293，旧 RFC 793）。項番3はこれを部署1から管理セグメント宛てに禁じるので，部署1の PC から管理 PC に向けてコネクションを始めることはできない。一方，項番4は残りの TCP（ACK が立ったもの）を許可するので，管理 PC が部署1の PC に向けて始めたコネクションの応答は通る。つまり，管理 PC からのリモート接続は通し，逆向きの接続は止める。
根拠は図4③である。管理 PC から他のセグメントへのリモート接続は許可するが，部署1の PC から管理 PC へのアクセスは表2・表3の業務用通信に無いので許可しない。
字数の詰め方（70字）。向きごとの許否を対にして書く。解答例は「部署1の PC から管理 PC に対して確立する TCP コネクションは禁止するが，逆方向に確立する TCP コネクションは許可する。」（59字）である。講評は，制御内容を理解していても適切に説明できていない解答が多かったとしている。「SYN パケットを禁止する」のように設定の言い換えで終えず，どちら向きのコネクションが許され，どちら向きが禁じられるかを書く。
交換後のプロキシサーバは，認証機能と復号機能をもつ。認証機能によって，アクセスした利用者が誰かがログに残る。マルウェアは利用者の ID とパスワードを知らないので，認証を求められて失敗を繰り返し，その記録がマルウェアの活動の手掛かりになる。復号機能によって，これまで中身の見えなかった SSL 通信の内容も記録できるようになる。解答例はこの二つの観点を別解として挙げている。
字数の詰め方（60字）。何の通信で，どんな情報が取れるかを書く。解答例は「社外の Web サーバとの間の SSL で暗号化された通信においても，認証された利用者と通信内容が取得できる。」（51字）と「プロキシサーバの認証に連続して失敗したことが記録されたログから，マルウェアの活動と推測できる情報が取得できる。」（55字）で，どちらか一つを書けばよい。
A 社では，VoIP 対応電話システム（以下，IPT システムという）を販売しているが，今後，A 社で設備を保有し，サービスとして提供したいと考えている。サービス提供時には，IPT システム用電話機（以下，IPTEL という）を利用企業に設置し，それ以外の IPT システム用機器を A 社センタに設置する形態を想定している。IPT システム担当部門の K 君は，最近のネットワーク技術に詳しい T 君の支援を受けながら，IPT システムのサービス化に向けて，実現性の検討を開始した。
〔サービス用 IPT システムの構成〕
図1は，K 君が T 君に示したサービス用 IPT システムの全体構成案である。
図1 サービス用 IPT システムの全体構成案
図1は，ある企業グループに属する利用企業1と利用企業2が，サービス用 IPT システムを利用する場合の構成を示している。利用企業1と利用企業2の内部ネットワークは，グループ内で重複しないプライベート IP アドレスを使用している。利用企業内の拠点間通話は内線通話として処理される。
ロガーは，通話を録音するサーバである。ロガー1及びロガー2は，それぞれ利用企業1用及び利用企業2用である。IP-PBX は，その機能を利用企業ごとに独立して利用できるマルチテナント機能をもち，利用企業1と利用企業2で共用する。ロガー及び IP-PBX は，それぞれの仮想サーバで動作させる。利用企業の拠点と A 社間は，VPN で接続する。
利用企業の社員が，出張などで拠点外のモバイル環境にいても，サービス用 IPT システムが使えるようにする。このために，モバイル環境のソフトフォン（PC 上で動作するソフトウェアで実現する電話機能）を，内線電話機として利用できるようにする。モバイル環境の PC から A 社への接続に当たっては，セキュリティ確保のために接続 PC ごとに認証を行う。
A 社の IPT システムは，RFC 3261 で規定された SIP（Session Initiation Protocol）に準拠している。K 君は，IPT システムについては経験が浅い T 君に，概要を説明することにした。次は，K 君が T 君に説明した内容についてまとめたものである。
SIP は，ユーザエージェントと呼ばれる端末（以下，UA という）間で，セッションの生成，変更，切断を行うプロトコルである。SIP では，セッション上でやり取りされるデータそのものについては規定していない。生成したセッション上で，どのような通信を行うかは，SIP を使う上位のアプリケーションが，通信相手とのネゴシエーションによって決定する。このとき，セッション生成の過程でのやり取りには，RFC 4566 で規定された SDP（Session Description Protocol）が用いられる。したがって，アプリケーションが，SIP によって制御されたセッションでデータをやり取りする場合，音声データだけなら電話，テキストだけなら a，音声と動画を組み合わせることでビデオ会議，というように，幅広い応用の可能性がある。音声データを転送する場合の一般的なプロトコルは，RFC 3550 で規定された b であり，そのトランスポート層のプロトコルには，リアルタイム性を重視し，再送制御を行わない c が使われる。
UA の識別には，sip:[email protected]（xxx は利用者識別子）のような URI（Uniform Resource Identifier）形式が使われる。SDP のセッション生成情報には，接続相手の URI，自分の URI と IP アドレス，使用するコーデックなどの通信に必要な情報が用いられる。
セッションは，通信を行う UA 間で直接やり取りして生成することもできるが，規模の大きな組織の場合は利用者が多く，URI の登録に手間が掛かるので，①セッションの生成を仲介するサーバを設置する。このサーバは SIP サーバと呼ばれ，図1のサービス用 IPT システムでは，IP-PBX がその役割を果たしている。
SIP で使われるメッセージは，d 形式で記述されるので，判読しやすい。
〔IPT システムの概要〕
IP-PBX は，VoIP-GW を経由して通信事業者の公衆 IP 電話網と接続する。VoIP-GW は，両側の SIP 制御の実装上の差異を吸収して整合性をとる。
従来，A 社では，IP-PBX システムに影響を与えない録音の方法を採用していた。この方法は，音声の通信経路にあるスイッチに，音声パケットが通過するポートのフレームをミラーポートに出力するように設定し，ミラーポート出力フレームを，ロガーの NIC で直接受ける方式である。この方式を，パッシブ方式と呼ぶ。
ミラーポート出力フレームを，仮想サーバで動作するロガーに取り込む場合には，単純にミラーポートを物理サーバの NIC に接続する方式だと，ミラーポートごとに NIC が必要となり，NIC 搭載数が限られる環境では使いにくい。
ロガーは，音声パケットを収集するための専用の仮想 NIC と，運用・保守に使用する仮想 NIC の二つの仮想 NIC をもち，それぞれが異なる仮想スイッチに接続する。
K 君が考えた方法は，ミラーポート出力フレームを仮想サーバで動作するロガーに転送するための VLAN を定義し，物理サーバの NIC と L2SW はトランク接続にする方法である。具体的には，L2SW の別々の VLAN に属するポート3とポート6に，それぞれ異なるミラーポート出力フレームを入力して仮想スイッチに転送した後，宛先となるロガーに振り分ける。今回使用した仮想スイッチでは，接続する仮想サーバの MAC アドレスは仮想化のための仕組みで把握しているので，通過するフレームによる MAC アドレスの学習は行わない。ミラーポート出力フレームを取り込むために，仮想スイッチに接続する⑤ロガーの仮想 NIC と仮想スイッチの接続ポート間で，適切な動作をさせる。
なお，図4の構成で使用している L2SW は，VLAN 単位に独立した MAC アドレステーブルをもつ仕様になっている。したがって，VLAN が異なれば同じ MAC アドレスが学習されても問題がない。
K 君がこの構成で実験したところ，期待するフレームがロガーに転送されていないことが分かった。そこで，原因を調べるために，T 君とともに次のような点について検討した。
スイッチの設定の不具合の可能性もあり得るので，サーバと L2SW 間のフレームをモニタして調べることにした。K 君は，図4の（A）と（B）の位置で通過するフレームをモニタしてみた。すると，VoIP-GW が送受信したフレームを，（A）では確認できたが，（B）ではミラーリングしたそれらのフレームの通過が確認できなかった。相談を受けた T 君は，L2SW の MAC アドレステーブルがどのような状態であるかを調べるよう指示した。その結果を見た T 君は，⑥L2SW のポート3に流入するフレームの送信元 MAC アドレスと宛先 MAC アドレスの組合せに着目して原因を説明し，対応策を示した。
したがって，アプリケーションが，SIP によって制御されたセッションでデータをやり取りする場合，音声データだけなら電話，テキストだけなら a，音声と動画を組み合わせることでビデオ会議，というように，幅広い応用の可能性がある。音声データを転送する場合の一般的なプロトコルは，RFC 3550 で規定された b であり，そのトランスポート層のプロトコルには，リアルタイム性を重視し，再送制御を行わない c が使われる。
UA の識別には，sip:[email protected]（xxx は利用者識別子）のような URI（Uniform Resource Identifier）形式が使われる。
〔サービス用 IPT システムの構成〕
セッションは，通信を行う UA 間で直接やり取りして生成することもできるが，規模の大きな組織の場合は利用者が多く，URI の登録に手間が掛かるので，①セッションの生成を仲介するサーバを設置する。
〔IPT システムの概要〕
IPT システムでは，UA は起動後，自分の利用者識別子，自分の IP アドレスを含む登録メッセージを SIP サーバに送信し，初期登録をする。
UA どうしが直接セッションを作るには，相手の URI と IP アドレスの対応を各 UA が知っていなければならない。SIP サーバを置くと，各 UA は起動時に自分の利用者識別子と IP アドレスを SIP サーバに登録する（REGISTER，RFC 3261）。発信側は相手の URI を書いた INVITE を SIP サーバに送り，SIP サーバは登録内容から URI に対応する IP アドレスを求めて，その UA に INVITE を送る。これが仲介の具体的な動作である。
IP-PBX 配下の IPTEL を識別するための 050 電話番号は，公衆 IP 電話網の通信事業者から割り当てられる。通信事業者の公衆 IP 電話網の中にも SIP サーバが存在するので，VoIP-GW は，②両方の SIP ネットワークに対して UA として振る舞う特殊な UA である B2BUA（Back-to-Back User Agent）になる。
〔IPT システムの概要〕
IPT システムでは，UA は起動後，自分の利用者識別子，自分の IP アドレスを含む登録メッセージを SIP サーバに送信し，初期登録をする。
B2BUA は，二つの SIP ネットワークのそれぞれに対して UA として振る舞う。UA は起動後に SIP サーバへ初期登録するので，VoIP-GW は両側の SIP サーバに登録しなければならない。公衆 IP 電話網の側の SIP サーバは「公衆 IP 電話網の SIP サーバ」，A 社側で SIP サーバの役割を果たすのは IP-PBX である。登録しておくと，公衆 IP 電話網から 050 番号宛ての呼が VoIP-GW に届き，VoIP-GW はそれを IP-PBX に渡せる。
根拠は下線②の「両方の SIP ネットワークに対して UA として振る舞う」と，「IP-PBX がその役割（SIP サーバ）を果たしている」という〔サービス用 IPT システムの構成〕の記述である。図2でも INVITE は公衆 IP 電話網の SIP サーバ → VoIP-GW → IP-PBX と渡されている。
間違えやすい点。「全て答えよ」なので二つとも書く。IPTEL や VoIP 対応電話機は登録先ではなく，登録する側の UA である。名称は本文の「公衆 IP 電話網の SIP サーバ」「IP-PBX」を使う。
設問2(2)50字以内
本文中の下線③に示す問題の原因を，図3を参考にして，50 字以内で述べよ。
解答例
アドレス変換対象外のSIPメッセージ内に送信者のプライベートIPアドレスが含まれている。
解説
本文の根拠
〔IPT システムの概要〕
インターネット網を経由して，SIP を使った通話を行う場合，企業内のプライベート IP アドレスの UA と外部とを接続するために，アドレス変換を行う必要がある。このときに，③標準的な NAT 装置では，通話セッションが生成できないという問題が発生する。
図3
SIP ヘッダ：Via: SIP/2.0/UDP（発信元の IP アドレス）:5060;branch=（省略），
図3
Contact: <sip:050yyyy5678@（発信元の IP アドレス）>，
図3
c=IN IP4（発信元の IP アドレス），
標準的な NAT 装置は，IP ヘッダ（と TCP・UDP ヘッダ）のアドレスとポート番号だけを書き換える。ところが図3のとおり，SIP メッセージの中身（Via，Contact ヘッダや SDP の c= 行など）にも発信元の IP アドレスが書かれている。NAT はここを書き換えないので，相手にはプライベート IP アドレスが伝わる。相手はそのアドレスに応答や RTP を送ろうとするが，インターネットからは届かないので，通話セッションが生成できない。
根拠は「図3を参考にして」という指示で，図3の網掛けに「発信元の IP アドレス」が SIP ヘッダとボディの何か所にも現れる。本文は，SDP のセッション生成情報に「自分の URI と IP アドレス」が含まれるとも述べている。
字数の詰め方（50字）。「アドレス変換の対象外の場所に，プライベート IP アドレスが入っている」ことを書く。解答例は「アドレス変換対象外の SIP メッセージ内に送信者のプライベート IP アドレスが含まれている。」（44字）である。講評は正答率が低かったとし，メッセージの内容がセッション生成にどう使われるかの理解を求めている。
今回使用した仮想スイッチでは，接続する仮想サーバの MAC アドレスは仮想化のための仕組みで把握しているので，通過するフレームによる MAC アドレスの学習は行わない。ミラーポート出力フレームを取り込むために，仮想スイッチに接続する⑤ロガーの仮想 NIC と仮想スイッチの接続ポート間で，適切な動作をさせる。
ミラーポート出力フレームの宛先 MAC アドレスは，VoIP-GW や通話相手のもので，ロガーのものではない。仮想スイッチは接続する仮想サーバの MAC アドレスを知っているので，通常はロガー宛て以外のフレームをロガーのポートに出さない。NIC も自分宛て以外のフレームを捨てる。そこで，仮想スイッチのそのポートには該当 VLAN の全てのフレームを出力させ，ロガーの仮想 NIC は宛先に関係なく全てを取り込む（いわゆるプロミスキャスモード）ようにする。
根拠は，仮想スイッチが「仮想サーバの MAC アドレスは仮想化のための仕組みで把握している」という記述である。宛先 MAC アドレスで振り分けるので，他人宛てのミラーフレームはそのままではロガーに届かない。
字数の詰め方（60字）。スイッチ側の出力と NIC 側の取込みの両方を書く。解答例は「仮想スイッチのポートに該当する VLAN の全てのフレームを出力し，仮想 NIC 側でそれらを全て取り込む動作」（51字）である。講評は設問3の正答率が低かったとしている。片側だけでは，出しても捨てられる，または取り込もうにも届かない。
その結果を見た T 君は，⑥L2SW のポート3に流入するフレームの送信元 MAC アドレスと宛先 MAC アドレスの組合せに着目して原因を説明し，対応策を示した。
図4
注記1 ポート2は，ポート1を通過するフレームのミラーフレーム出力ポートである。
ポート1のミラーには，VoIP-GW が送ったフレーム（送信元 VoIP-GW，宛先 X）と受けたフレーム（送信元 X，宛先 VoIP-GW）の両方が入る。これがポート2からケーブルでポート3（VLAN 802）に流れ込むと，L2SW は送信元 MAC アドレスを学習するので，VoIP-GW の MAC アドレスも X の MAC アドレスも「ポート3の先にある」と登録してしまう。すると，次に流れ込むフレームの宛先 MAC アドレスもポート3側にあることになり，L2SW は入ってきたポートと同じポートが宛先だとしてフレームを捨てる（フィルタリング）。そのためポート7を通って（B）に出ていかない。対応策は，ポート3で MAC アドレスの学習をしないようにすることで，未学習の宛先としてフラッディングされ，VLAN 802 のトランク（ポート7）へも出ていく。
根拠は（A）では見えて（B）では見えないという観察と，下線⑥の「送信元 MAC アドレスと宛先 MAC アドレスの組合せ」である。ミラーフレームでは，あるフレームの宛先が別のフレームの送信元になる。
字数の詰め方（各50字）。状態は「宛先 MAC アドレスがポート3側にあると登録されている」，対応策は「ポート3で学習を抑止する」を書く。解答例は状態42字，対応策41字である。講評は，ミラーフレームの送信元 MAC アドレスを出力ポートの MAC アドレスと誤解した解答が散見されたとしている。ミラーポートはフレームを複製して出すだけで，送信元 MAC アドレスは元のままである。
本文中の下線⑧において，生成された仮想 NIC に対してどのような IP アドレスが付与される必要があるかを，35 字以内で述べよ。
解答例
サービス提供用内部LANのネットワークに属するIPアドレス
解説
本文の根拠
〔外部接続用機器群の検討〕
SSL-VPN 装置では，モバイル環境の PC からのアクセスに対し，トークンを利用した利用者認証を行っている。認証された PC は，⑧新たな仮想 NIC を生成し，レイヤ2のトンネルを通して，サービス提供用内部 LAN との通信が可能になる。
レイヤ2のトンネルで結ばれると，PC の仮想 NIC はサービス提供用内部 LAN に直接つながった NIC と同じ扱いになる。同じレイヤ2のネットワーク（同じセグメント）にいる機器と，ルータを介さずに通信するには，そのネットワークのアドレス範囲に属する IP アドレスが必要である。PC の実 NIC のアドレス（出張先で付けられたもの）とは別に，仮想 NIC にはサービス提供用内部 LAN の IP アドレスを割り当てる（SSL-VPN 装置が DHCP などで払い出すのが一般的である）。
根拠は「レイヤ2のトンネルを通して，サービス提供用内部 LAN との通信が可能になる」という記述である。レイヤ2でつながる先のネットワークのアドレスが要る。
字数の詰め方（35字）。どのネットワークに属するアドレスかを書く。解答例は「サービス提供用内部 LAN のネットワークに属する IP アドレス」（29字）である。「グローバル IP アドレス」や「プライベート IP アドレス」だけでは，どのネットワークのものかが決まらない。
