【徹底解説】ネットワークスペシャリスト令和5年度 春期 午後Ⅱ問2

本記事では、ネットワークスペシャリスト(ネスペ)試験の令和5年度午後Ⅱ問2について、筆者の所感なども交えて解説していきます。
なお、画像や解答例は全てIPA（独立行政法人情報処理機構）から引用しております。

令和5年度春期 ネットワークスペシャリスト（NW）午後Ⅱ
令和5年度春期 ネットワークスペシャリスト（NW）午後Ⅱ 解答例

---

私は普段、左門至峰先生の「ネスペ」シリーズで学習を行っています。
午後Ⅰ・午後Ⅱのみにフォーカスを当て、とても丁寧に、そして詳細に解説されています。
より深い知識を求める方、ネットワークスペシャリスト試験を徹底的に対策したい方におすすめです。

---

本設問の概要について

事務用品を販売するY社は、インターネットを通じて会員企業向けに通信販売を行っています。
提供しているECサイトの処理能力を増強するためのネットワーク設計と、アカウント管理負荷増加に伴う認証連携技術(SSO)の導入について検討する内容となっています。

認証連携技術として、SAML2.0とケルベロス認証が登場します。
ただ、本設問ではSAML2.0とケルベロス認証の知識がなくても解けるよう工夫されていました。

それでは全体像を掴んでいただくため、本設問のシナリオを掲載します。

IPAの解答例について

設問		解答例		予想 配点
設問1		a	NS	3
		b	MX	3
		c	100.α.β.1	2
		d	100.α.β.3	2
		e	192.168.1.1	2
		f	192.168.1.3	2
設問2	(1)	コモンメイトURLのドメイン名が異なるから		5
	(2)	L3SW,FWz,L2SW		4
設問3	(1)	g	アップ	3
		h	アウト	3
	(2)	1台故障時にも、ECサイトの応答速度の低下を発生させないため		5
	(3)	i	100.α.β.2	2
		j	192.168.1.2	2
		k	192.168.1.4	2
設問4	(1)	機種	LB	2
		呼称	仮想IPアドレス	3
	(2)	(自身の)IPアドレス		4
	(3)	FWzからLB		3
	(4)	ECサーバに、アクセス元PCのIPアドレスを通知するため		5
	(5)	既設ECサーバにインストールされているサーバ証明書と秘密鍵のペアを、LBに移す。		6
設問5	(1)	TCPコネクションが再設定されるたびに、ポート番号が変わる可能性があるから		5
	(2)	サーバからの応答に含まれるCookie中のセッションIDが、セッション管理テーブルに存在しない場合		6
	(3)	サービスが稼働しているかどうか検査しないから		5
設問6	(1)	アクセス元の購買担当者が所属している会員企業の情報		5
	(2)	Idpの公開鍵証明書		4
	(3)	IdPの鍵を所有していないから		4
	(4)	①	信頼関係のあるIdPが生成したものであること	4
		②	SAMLアサーションが改ざんされていないこと	4

筆者の解答時間（参考）

参考までに、私は解答に1時間13分かかりました。
見直し時間を含めると、試験当日はこれくらいの時間で解きたいですね。

それでは解説に入っていきましょう！

設問１

（見出しなし）

DNSのゾーン情報に関する穴埋め問題です。
図2を掲載します。

大前提として、項番1〜6はインターネット上に公開しているゾーン情報、項番7〜12はY社内向けのゾーン情報です。

また、空欄(c)〜(f)で利用するため、表1のFWzに設定されている静的NATも掲載しておきます。

（a）

まずは空欄(a)から見てみましょう。
項番2は「ns.example.jp.」、項番8は「ns.y-sha.example.lan.」とあります。
「ns」とあることから、ネームサーバであることがわかります。

ネームサーバのタイプは「NS」で表記します。

（b）

空欄(b)は「mail.example.jp.」、「mail.y-sha.example.lan.」とあります。
メールサーバであることが分かるため、タイプは「MX」となります。

（c）

次に空欄(c)を見てみましょう。
空欄(c)はAレコードであることからIPv4アドレスが入り、「ns」とあることからDNSサーバであることがわかります。

DNSサーバであること、およびインターネット向けのゾーン情報であることから、表1より「100.α.β.1」であることがわかります。

（d）

空欄(d)もインターネット向けのゾーン情報の中にあります。
「mail」とあることからメールサーバであることがわかります。
また、表1よりSMTPのプロトコルであることから、「100.α.β.3」となります。

（e）

空欄(e)はY社内向けのゾーン情報の中にあります。
「ns」とあることから、表1より「192.168.1.1」が入ります。

（f）

空欄(f)も社内向けのゾーン情報の中にあり、「mail」とあることから「192.168.1.3」 が入ります。

---

正解をまとめると以下の通りです。

設問２

（１）

アクセスするURLのFQDNが「ecsv.y-sha.example.lan」とあることから、Y社内の運用PCからECサーバにアクセスしたものと考えられます。
なぜエラーが表示されるのでしょうか？

[ECサイトに関連するシステムの構成,運用及びセッション管理方法]に以下のように記載があります。

証明書は1つであり、マルチドメインに対応していないため、コモン名は1つしか設定できません。
証明書のコモン名は会員企業向けである「ecsv.example.jp」であると考えられるため、「ecsv.y-sha.example.lan」でアクセすると、証明書のコモン名とURLのFQDNの不一致により警告が表示されてしまうのです。

よって、解答例は以下の通りです。

（２）

運用PCからECサーバ宛のパケットがどの機器を経由するのか問われています。
必ず正解していただきたい問題です。

[ECサイトに関連するシステムの構成,運用及びセッション管理方法]に以下のような記述がありあます。

「.lan」はLAN内で利用されるドメインなので、インターネットは経由しません。
運用PC→ECサーバへの経路を書き込むと以下のようになります。

よって、経由する機器は以下の通りです。

設問３

ECサーバが処理能力不足となったため、その対応策を検討していきます。
サーバの拡張に伴うネットワーク機器の構成変更・影響について取り上げているセクションです。

（１）

(g),(h)の箇所を見てみましょう。

ECサーバの増強策として、2つの方式を検討しています。
一般的に、サーバを増強する方式としてスケールアップ方式とスケールアウト方式があります。

両者の違いを記載します。

「ECサイトを停止せずにECサーバの増強を行える」とあるため、空欄(h)は(スケール)アウトが入ります。
空欄(g)には(スケール)アップが入ります。

後に出てくる構成図を見るとECサーバが複数記載されているので、スケールアウト方式が採用されたことは明らかですね。

（２）

下線②を見てみましょう。

2台で十分な処理能力をもつことができるものの、3台構成とした理由を問われています。
設問には「将来のアクセス数については考慮しない」と但し書きがあります。

2台構成とした場合、もしそのうちの1台が故障してしまったらどうなるでしょうか？
1台での稼働となり、再び処理能力不足に陥ってしまいますね。
3台構成とすると、そのうちの1台が故障しても2台で十分な処理能力を維持できます。

よって、正解例は以下の通りです。

---

ちなみに、私は故障ではなくメンテナンスに着目して解答してしまいました。
少し趣旨からずれているため、不正解だったのではないかと思います。

（３）

表2と図5を掲載します。

LBにて、送信元IPアドレスの変換(ソースNAT)を行うパターンと行わないパターンで、送信元・宛先IPアドレスがどのように変化するかを問われています。

まず図4より、LBの物理IPアドレスには「192.168.1.4」が設定されています。
また、表1のFWzに設定している静的NATは変更されていないと考えられるため、LBの仮想IPアドレスは「192.168.1.2」が設定されています。(元々はECサーバの物理IPアドレスでした)

FWzでの静的NATにプラスして、LBにてソースNATを行わないパターンを見ていきます。

LBにてソースNATは行わないため、グローバルIPアドレスである「200.a.b.c」がずっと利用されていることがわかります。

続いて、ソースNATを行うパターンを見ていきましょう。こちらも同様にFWzでの静的NATも記載しています。

LBの物理IPアドレスである「192.168.1.4」をソースNAT用のIPアドレスで利用しています。

上記の図より、正解は以下の通りです。

設問４

（１）

下線③は以下のように記載されています。

項番5と項番11のリソースレコードに指定する機器、また指定する”特別なIPアドレス”は何かを問われています。

ここで思い出していただきたいのが、表1のECサーバに関する、FWzのNAT変換設定です。
今回の構成変更で、このNAT変換には特に触れられていません。
つまり、構成変更前後でNAT変換設定は変わらないのです。

構成変更前ではECサーバのIPアドレスとして「192.168.1.2」を指定していました。
構成変更後では、設問3 (3)より、「192.168.1.2」はLBを指定していると解説しました。
よって、項番5と項番11で示す機器はLBとなります。

また、”特別なIPアドレス”とは何でしょうか？
答えは表2のすぐ上に記載されています。

答えは仮想IPアドレスです。
仮想IPアドレスである「192.168.1.2」をLBに設定して、LBは受け取ったパケットを3つのECサーバに振り分けるのですね。

（２）

下線④は下線③と同じ場所にありました。

既設ECサーバの設定で、二つの情報を変更すると記載されています。
ひとつはホスト名で、もうひとつを問われています。
これは図4のサーバ増強後のリソースレコードを見ていくと解くことができます。

ここで注目していただきたいのが、既設ECサーバに関するAレコードです。
ホスト名が「ecsv」→「ecsv1」に変わっています。
また、IPアドレスも「192.168.1.2」→「192.168.1.5」に変わっています。

よって、既設ECサーバで変更となる設定は、ホスト名とIPアドレスであるということがわかります。

（３）

下線⑤を見てみましょう。

新しい構成において、ソースNATを行わない場合、既設ECサーバに設定しているデフォルトゲートウェイをどの機器からどの機器のIPアドレスに変更するのかを問われています。

まず、現在の構成ではデフォルトゲートウェイはどの機器を指定しているのでしょうか？
図1のDMZ上にL3機器はFWzしかないため、デフォルトゲートウェイとしてFWzを設定しています。

では、サーバ増強後はどの機器をデフォルトゲートウェイに指定するのでしょうか？
正解から言うと、デフォルトゲートウェイとして指定する機器はLBとなります。(と言うよりLBしかないですよね)

なぜLBを指定することになるのかも解説します。
ヒントは設問３ (3)で示したパケットの中身に隠されています。

図中の(ⅳ)に注目ください。
(ⅳ)は既設EC→LBの通信ですが、宛先IPアドレスが「200.a.b.c」となっています。

これはインターネット上のIPアドレスなので、セグメントが異なる宛先に送信しているパケットです。
このままではLBを経由せず、デフォルトゲートウェイに指定しているFWzにパケットを送出してしまいます。
LBにパケットを送出するため、LBをデフォルトゲートウェイにする必要があるのです。

（４）

下線⑥は以下のように記述されています。（少し前の記述から掲載します）

ソースNATを行う場合のX-Forwarded-For(XFF)フィールドを追加する目的を問われています。
XFFフィールドとは、クライアントの元々のIPアドレスを伝えるためのIPヘッダです。
これを知っているだけで本設問は解答することができます。

これだけでは味気ないので、もう少し解説を続けます。
なぜLBにてXFFを用いて元々のクライアントのIPアドレスを通知する必要があるのでしょうか？
[ECサイトに関連するシステムの構成,運用及びセッション管理方法]に以下のような記述かあります。

今回のようにソースNATを行う設定とした場合、ECサーバに記録されるIPアドレスが全てLBのものとなってしまいます。
その理由は設問３ (3)の図を見ることで確認することができます。

(ⅱ)と(ⅲ)に着目してください。
(ⅱ)では送信元IPアドレスが「200.a.b.c」となっていますが、(ⅲ)では「192.168.1.4(LBの物理IPアドレス)」となっています。

ECサーバから見ると、送信元IPアドレスが全て192.168.1.4となっているため、アクセス元のIPアドレスを正確にログを記録できません。
そのためLBは、XFFフィールドにクライアントの(グローバル)IPアドレスである「200.a.b.c」を指定し、ECサーバに通知するのですね。

（５）

下線⑦を掲載します。

増設したECサーバにはサーバ証明書はインストールせず、既設ECサーバのサーバ証明書を流用し、LBにインストールします。
かなり簡単にですが、一般的なTLS通信の流れを記載します。

①サーバがクライアントにサーバ証明書を送る
　・公開鍵付きのサーバ証明書をクライアントに送る
②クライアントが共通鍵を生成する
　・クライアントはランダムな共通鍵を生成
　・生成した共通鍵をサーバの公開鍵で暗号化し、サーバに送信する
③サーバは秘密鍵で復号する
　・サーバは秘密鍵で復号し、共通鍵を取り出す

以上がTLS通信の流れです。
よって実施する作業内容は、サーバ証明書と秘密鍵をLBに移す作業が必要となります。

設問５

（１）

下線⑧はセッション維持機能の中に記載があります。
IPアドレスとポート番号の組み合わせで行うセッション維持機能について、再接続されるとセッションが維持できなくなる理由を問われています。

これは一般的な知識で解くことができます。
TCPコネクションを再接続した場合、切断前に利用していたポート番号が再利用されるとは限りません。
そのため、再接続して送信元のポート番号が変わってしまうと異なるセッションとしてみなされ、セッションの維持ができなくなってしまいます。

解答例は以下の通りです。

（２）

LBが管理するセッション管理テーブルに新たなレコードを追加するのはどのような場合かを問われています。
文中の記載より、セッション管理テーブルはセッションIDと振り分けサーバからなる表形式のようなものだとイメージしてください。

まずセッション管理の方法ですが、[ECサイトに関連するシステムの構成,運用及びセッション管理方法]に記載されています。

ECサーバはCookieにセッションIDを書き込んでレスポンスを返します。
このCookieは、Webブラウザ(クライアントPC)ではなくサーバが作成すると言うことを念頭においてください。
つまりLBは、ECサーバからのレスポンスに含まれているセッションIDを取得し、セッション管理テーブルを更新しているのです。

シーケンス図を作成してみました。

⑤のシーケンスに注目してください。
LBは、ECサーバのレスポンスに含まれているセッションIDを確認し、セッション管理テーブルに存在しなければ登録を行います。

よって、解答例は以下の通りです。

（３）

下線⑩を見てみましょう。

ECサーバの監視方法について、レイヤー3及びレイヤー4では適切な監視が行えない理由を問われています。
ネスペ試験では定番中の定番な設問ですね。

それぞれの監視方法について解説します。

レイヤー	監視方法	内容	特徴
L3	ping(ICMP Echo)	IP到達性の確認	OSの稼働確認
L4	TCPヘルスチェック	指定ポート(TCP/80,443など)が利用できるか確認	指定ポートの待受確認
L7	HTTPヘルスチェック	HTTPリクエストを送信し、応答を確認(例：200 OK)	サービスの稼働確認

レイヤー3及びレイヤー4ではサービスの稼働確認までは行えません。
よって、解答例は以下のようになります。

設問６

ここからはSAML認証を利用したSSO(シングルサインオン)について出題されます。
SAMLについての知識がなくても解答できるよう工夫されていました。

文中に示されているシーケンス図を掲載しておきます。

（１）

まずは下線⑪を見てみましょう。

(ⅱ)のシーケンスについての記載です。
ECサーバがリダイレクト応答する際に必要とする情報について問われています。

「リダイレクト」と聞いて、URI(またはIPアドレス)が思い浮かぶかと思います。
おそらくですが、ECサーバは会員企業を特定する情報と、IdPのURIを紐づけて管理していると考えられます。

そのため、(ⅰ)の段階で会員企業の情報が特定できれば、おのずとリダイレクト先のURIが取得できることとなります。

（２）

下線⑫も(ⅱ)に記載があります。

IdPが作成したデジタル署名は、手順(ⅷ)にて作成されます。
そのデジタル署名を検証するにあたり、必要な情報を問われています。

手順(ⅷ)を掲載します。

記述の通り、IdPがデジタル署名を作成してSPに送信します。
このデジタル署名は、IdPの秘密鍵にて作成されます。
SP(ECサーバ)はIdPが作成したデジタル署名を検証するため、SPにIdPの公開鍵証明書を登録しておく必要があるのです。

（３）

下線⑬を見てみましょう。

下線⑬で取り出したSTを、PCが改ざんできない理由を問われています。
ヒントは手順(ⅵ)に記載されています。

KDCが発行したSTは、IdPの共通鍵で暗号化します。
このIdPの共通鍵をPCは保有していないため、STを復号することができません。
つまり、PCはSTを改ざんできないと言うことになります。

（４）

下線⑭は手順(ⅸ)に記載されています。

PCから送られたデジタル署名をSPが検証することにより、SAMLアサーションに対しどのような検証が行なえるかを問われています。

一般的に、デジタル署名を検証すると以下の3点が検証できます。
①本人の署名であること（真正性）
②改ざんされていないこと（完全性）
③否認されないこと（否認防止）

信頼関係のあるIdPの公開鍵で検証することにより、SAMLアサーションがIdPにより作成されたものであることが確認できます。(真正性)
また同時にSAMLアサーションが改ざんされていないことも確認できます。

よって、解答例は以下の通りです。

まとめ

本設問はLBを用いたECサーバの冗長化、また利用者増加にともなうSSO(シングルサインオン)について問われた問題でした。

LB導入に伴うネットワークの構成変更や聞き慣れないSAML認証が登場しました。
ただ、基本的なネットワークの知識やセキュリティの知識があれば解けた問題も多かったのではないかと思います。

これからも解説記事を書いていきますので、どうぞよろしくお願いします。