応用情報技術者 2013年 秋期 午後 問04
ネットワーク障害調査に関する次の記述を読んで、設問1~4に答えよ。
P社は、ペット用品のインターネット通信販売業者である。本社事業所内に調達部、総務部、販売部、企画部があり、約80名の社員で商品の企画・調達・配送などの業務を行っている。通信販売のシステムは、他社が運営するショッピングサイトを活用しており、自社で制作した販売用Webページをインターネット経由でショッピングサイトにアップロードして商品を販売している。
社員が業務で使用するPCと、ファイル共有のために使用しているファイルサーバ(以下、FSという)は、購入後数年を経ており、社員からは“処理速度が遅い。”という声が上がっている。そこで、全てのPCとFSをリプレースすることにした。リプレースは、総務部情報システム課のQ君が担当することになった。
〔本社事業所のネットワーク構成〕
Q君は、PCとFSのリプレースに当たり、現在の本社事業所のネットワーク構成の調査を行った(図1)。

本社事業所内のPCからブラウザを用いてWebページにアクセスする場合には、プロキシサーバを経由する。また、電子メールの送受信はメールサーバを利用して行っており、PCとメールサーバとの間の通信は、本社事業所内の通信であるので、通信路の暗号化やSMTP認証は利用していない。PCは一度設置したら移設することは少ないので、DHCPは利用していない。インターネットやDMZから各部のFSにアクセスできないようにファイアウォールを設置している。ネットワーク機器は適切に設定がされており、障害などは発生していない。また、リプレース後もネットワーク構成やネットワーク機器の設定変更は行わない。
〔PCとFSの設定〕
Q君は、約80台のPCと各部のFSの設定作業を3名の情報システム課員だけで行うことは不可能と判断し、設定ガイドを作成して、各部で任命されているIT係に部内のPCの設定作業の説明を依頼した。IT係は、部内の各PCに割り当てるIPアドレスを決定した後、設定ガイドの内容を部員に説明し、PCの設定をPCの使用者自身で行ってもらうように依頼した。また、各部に設置するFSについては、PCと同様にログインを行って設定画面から設定が可能であるので、IT係に設定してもらうことにした。
図2に調達部向け設定ガイドを示す。他の部にも同様の設定ガイドを作成した。

〔トラブル事象1〕
PCのリプレース後に、総務部のR君から“ショッピングサイトにアクセスできない。”との連絡があり、Q君がトラブル調査を実施した。
Q君は、総務部内の他のPCからショッピングサイトにアクセスを試み、正常にアクセスできることを確認した。次に、R君のPCからプロキシサーバへ正しく通信できることを確認するために、R君のPCからeコマンドを用いてx.y.z.103宛てにICMPパケットを送信し、正常に応答があることを確認した。
次にQ君は、fコマンドを用いて、gの名前解決(FQDNからIPアドレスを調べる)を試みたところ、エラーとなった。このことから、R君のPCのhの設定に誤りがあることを特定した。その誤りを訂正し、R君のPCからショッピングサイトに正常にアクセスできることを確認した。
〔トラブル事象2〕
総務部のS君から、“先週の調達状況の確認をしようとしたところ、調達部のFSにアクセスできない。”との連絡があり、Q君がトラブル調査を実施した。
Q君は、S君のPCと同様に、自分のPCからも調達部のFSにアクセスできないことを確認した。また、調達部のPCからは調達部のFSに正常にアクセスできることを確認した。Q君は、S君のPCからtracerouteコマンドを用いて、調達部のFSへのアクセス確認を行った。tracerouteコマンドの実行結果を図3に示す。

Q君は調査結果を基に、原因となっていた設定の誤りを特定した。その誤りを訂正し、S君のPCから調達部のFSに正常にアクセスできることを確認した。
〔FSの利用状況確認画面の利用〕
リプレースの1か月後、企画部のIT係のT君から、“FSの説明書に、Webブラウザを用いてFSの利用状況確認ができるとの記述がある。しかし、①自席のPCからWebブラウザを用いて、説明書に記述のとおり企画部のFSにアクセスしてみたが、利用状況確認ページが表示できなかった。”との連絡があった。なお、T君のPCや企画部のFSは、設定ガイドのとおり設定されており、FS内ファイルの読み書きは可能であった。
その後、T君はQ君から連絡された設定変更を行い、FSの利用状況確認ページを表示できるようになった。
設問1:図2中のa~dについて(1)、(2)に答えよ。
(1)a、bに入れる、調達部のPCに設定可能なIPアドレスの範囲を、接続できるPCの台数が最大となるように答えよ。
模範解答
a:172.16.1.1
b:172.16.1.252
解説
解答の論理構成
-
サブネットの把握
図2「ネットマスク : 255.255.255.0」とあるので、CIDR 表記は /24 です。
/24 では 2^(32−24)=256 個の IP アドレスが用意されます。 -
予約アドレスの除外
同図に
・「デフォルトゲートウェイ : 172.16.1.254」
・「IP アドレス : 172.16.1.253」(FS 用)
が明記されています。
また /24 のネットワークでは
・ネットワークアドレス 172.16.1.0
・ブロードキャストアドレス 172.16.1.255
もユーザ機器には割り当てられません。 -
PC に割り当てられる範囲
予約済みアドレス 172.16.1.0, 172.16.1.253, 172.16.1.254, 172.16.1.255 を除いた残りが PC 用となります。
したがって最小は 172.16.1.1、最大は 172.16.1.252 です。 -
“接続できるPCの台数が最大となるように” との要求
上記範囲をそのまま提示すると、ホスト部 1〜252 の 252 台が使用可能であり最大となります。 -
結論
〔 a 〕=「172.16.1.1」
〔 b 〕=「172.16.1.252」
誤りやすいポイント
- ブロードキャストアドレス 172.16.1.255 を PC に割り当ててしまう。
- 「172.16.1.254 はデフォルトゲートウェイだが、空いているから使ってもよい」と誤認。
- /24 を /25 と読み違え、アドレス総数を 128 と誤計算。
- FS 用 172.16.1.253 の存在を見落とす。
FAQ
Q: 172.16.1.0 を PC に設定すると何が起こりますか?
A: ネットワークアドレスはルーティング情報の識別に使われるため、通信が正常に行えません。
A: ネットワークアドレスはルーティング情報の識別に使われるため、通信が正常に行えません。
Q: アドレスを 172.16.1.252 までではなく 172.16.1.253−1=172.16.1.252 で止める理由は?
A: 「172.16.1.253」は FS 用に固定されているため、PC 用に使用すると FS と IP が重複し通信不能になります。
A: 「172.16.1.253」は FS 用に固定されているため、PC 用に使用すると FS と IP が重複し通信不能になります。
Q: 将来 PC が 252 台を超えたらどうすべきですか?
A: サブネットマスクを /23 などに変更してホスト部を拡張するか、別セグメントを増設してルーティングします。
A: サブネットマスクを /23 などに変更してホスト部を拡張するか、別セグメントを増設してルーティングします。
関連キーワード: サブネットマスク、ブロードキャストアドレス、デフォルトゲートウェイ、CIDR
設問1:図2中のa~dについて(1)、(2)に答えよ。
(2)c、dに入れる適切な字句を答えよ。なお、dについては、ウェルノウンポート番号を答えよ。
模範解答
c:172.16.0.101
d:25
解説
解答の論理構成
-
DNS サーバの IP 確認
- 【問題文】には「DNSサーバ nsp1.p.example.jp 172.16.0.101」と明記されています。
- 図2「DNS サーバ」欄の〔 c 〕は、PC が名前解決に用いるこの IP を指定する箇所です。
- したがって〔 c 〕=「172.16.0.101」となります。
-
SMTP サーバのポート番号確認
- PC は「SMTP認証は利用していない」と書かれており、特別な Submission ポート(587)や SMTPS(465) を使う条件は提示されていません。
- メールサーバは一般的な「SMTP サーバ」とだけ記載され、暗号化・認証なしで使う設定です。
- 標準的な SMTP のウェルノウンポート番号は「25」です。
- よって〔 d 〕=「25」となります。
以上より
c:172.16.0.101
d:25
c:172.16.0.101
d:25
誤りやすいポイント
- 「内部通信=暗号化不要」とあるため、Submission ポート「587」を選んでしまうミス。内部利用であっても標準 SMTP に従うので「25」が正解です。
- DNS サーバの IP を DMZ 内のグローバルアドレス(例:x.y.z.101)と取り違える誤答。内部向けガイドでは必ず「172.16.0.101」を指定します。
- ポート番号問題で「POP(110)」「IMAP(143)」と混同するケース。設問は SMTP サーバのポートを問うています。
FAQ
Q: DNS サーバは DMZ 内に置くのが普通では?
A: 外向け(権威)DNS と内部向け DNS を分離する構成もあります。本社業務ネットワークでは内部用の「172.16.0.101」が用意されており、それを PC が参照します。
A: 外向け(権威)DNS と内部向け DNS を分離する構成もあります。本社業務ネットワークでは内部用の「172.16.0.101」が用意されており、それを PC が参照します。
Q: Submission ポートを使わず 25 番のままでも問題ないのですか。
A: 社内 LAN 上でのみ配送し、SMTP 認証を要求しない方針なので 25 番で運用してもセキュリティポリシ上の問題が生じない前提です。
A: 社内 LAN 上でのみ配送し、SMTP 認証を要求しない方針なので 25 番で運用してもセキュリティポリシ上の問題が生じない前提です。
Q: DNS の FQDN「nsp1.p.example.jp」と「mail.p.example.jp」を hosts ファイルに書けば DNS サーバは不要ですか。
A: 80 台すべての PC に静的エントリを管理する手間と整合性リスクが大きく、可用性・保守性を考えると DNS サーバを使う方が適切です。
A: 80 台すべての PC に静的エントリを管理する手間と整合性リスクが大きく、可用性・保守性を考えると DNS サーバを使う方が適切です。
関連キーワード: DNS, SMTP, ウェルノウンポート、IPアドレス、名前解決
設問2:〔トラブル事象1〕について(1)、(2)に答えよ。
(1)本文中のe、fに入れる適切なコマンドを解答群の中から選び、記号で答えよ。
解答群
ア:arp
イ:ifconfig
ウ:netstat
エ:nslookup
オ:ping
カ:route
模範解答
e:オ
f:エ
解説
解答の論理構成
-
問題文は、プロキシサーバへの疎通確認として
“R君のPCからeコマンドを用いてx.y.z.103宛てにICMPパケットを送信”
と述べています。ICMP エコー要求/応答で疎通を確認する代表的なコマンドは ping です。
⇒ e = オ(ping) -
その後、名前解決を試す操作として
“Q君は、fコマンドを用いて、gの名前解決(FQDNからIPアドレスを調べる)を試みた”
とあります。FQDN から IP アドレスを問い合わせる代表的なコマンドは nslookup です。
⇒ f = エ(nslookup) -
解答群との照合
- オ:ping → ICMP エコーで疎通確認
- エ:nslookup → DNS への名前問い合わせ
いずれも記述内容と合致します。
誤りやすいポイント
- “ICMP パケットを送信”の記述を見落とし、arp や netstat を選んでしまう。
- nslookup と dig を混同し、解答群に無い dig を頭に浮かべて迷う。
- 疎通確認=traceroute と短絡的に考え、Hop 解析用コマンドを当てはめてしまう。
FAQ
Q: ping ではポート番号の確認はできないのでは?
A: 本問の目的はプロキシサーバとの物理・ネットワーク層レベルの到達性確認です。アプリケーション層の 8080/TCP を直接調べているわけではありません。
A: 本問の目的はプロキシサーバとの物理・ネットワーク層レベルの到達性確認です。アプリケーション層の 8080/TCP を直接調べているわけではありません。
Q: nslookup の代わりに host コマンドでも名前解決は可能?
A: 可能ですが、問題文が示す代表的な対話型 DNS 問合せコマンドは nslookup です。解答群にも host は含まれていません。
A: 可能ですが、問題文が示す代表的な対話型 DNS 問合せコマンドは nslookup です。解答群にも host は含まれていません。
Q: Windows と Linux でコマンド名は変わらない?
A: ping と nslookup はどちらの OS でも同一名称で利用できます。試験問題は OS 非依存の汎用コマンドを採用しています。
A: ping と nslookup はどちらの OS でも同一名称で利用できます。試験問題は OS 非依存の汎用コマンドを採用しています。
関連キーワード: ICMP, DNS, プロキシ、名前解決、疎通確認
設問2:〔トラブル事象1〕について(1)、(2)に答えよ。
(2)本文中のいて答えよ。g、hに入れる適切な字句を図1中の字句を用
模範解答
g:プロキシサーバ
h:DNSサーバ
解説
解答の論理構成
- “総務部内の他のPCからショッピングサイトにアクセスを試み、正常にアクセスできることを確認した。”
─ ネットワーク機器やショッピングサイト自体に障害はないと判断できます。 - “R君のPCからeコマンドを用いてx.y.z.103宛てにICMPパケットを送信し、正常に応答があることを確認した。”
─ R君のPCと“x.y.z.103”との IP レベルの疎通は正常です。
─ 図1より“x.y.z.103”の下には“プロキシサーバ”と記載されています。 - “fコマンドを用いて、gの名前解決(FQDNからIPアドレスを調べる)を試みたところ、エラーとなった。”
─ 名前解決対象は先ほど通信を確認した“プロキシサーバ”のはずです。
したがって g には図1の字句“プロキシサーバ”が入ります。 - “このことから、R君のPCのhの設定に誤りがあることを特定した。”
─ 名前解決に失敗した原因は DNS 参照先の設定ミスが最も典型的です。
─ 図1に“DNSサーバ”が描かれており、これを正しく参照できなければ FQDN から IP アドレスへ変換できません。
─ よって h は“DNSサーバ”となります。
以上より
g:プロキシサーバ
h:DNSサーバ
g:プロキシサーバ
h:DNSサーバ
誤りやすいポイント
- “proxy.p.example.jp” など FQDN をそのまま g に書いてしまう
→ 設問は“図1中の字句を用”と指示しており、機器名“プロキシサーバ”が正解です。 - 名前解決失敗から“デフォルトゲートウェイ”の誤設定と結論づける
→ ping で “x.y.z.103” へ到達できているため、ルーティングは正常です。 - “メールサーバ”と混同して DNS 設定を見落とす
→ FQDN 変換はどのサービスでも DNS を利用します。
FAQ
Q: ping が通っているのにブラウザだけ失敗する原因は何ですか?
A: ブラウザは URL 内のホスト名を IP アドレスへ変換するため DNS を利用します。DNS 設定が誤っていると ping(IP 指定)は成功しても、ブラウザ(FQDN 利用)は失敗します。
A: ブラウザは URL 内のホスト名を IP アドレスへ変換するため DNS を利用します。DNS 設定が誤っていると ping(IP 指定)は成功しても、ブラウザ(FQDN 利用)は失敗します。
Q: DNS だけでなく hosts ファイルで設定しても良いですか?
A: 小規模で緊急対応なら可能ですが、運用面では全 PC の hosts を維持するのは非現実的です。ネットワーク全体で正しい“DNSサーバ”を設定する方が安全です。
A: 小規模で緊急対応なら可能ですが、運用面では全 PC の hosts を維持するのは非現実的です。ネットワーク全体で正しい“DNSサーバ”を設定する方が安全です。
Q: プロキシの FQDN が引けなくても IP 直書きでブラウザを設定すれば解決しますか?
A: 一時的には動きますが、運用変更や IP 変更時に再度トラブルになります。組織としては DNS 解決が正常に動作する状態を維持すべきです。
A: 一時的には動きますが、運用変更や IP 変更時に再度トラブルになります。組織としては DNS 解決が正常に動作する状態を維持すべきです。
関連キーワード: DNS, プロキシ、名前解決、ICMP, FQDN
設問3:
〔トラブル事象2〕について、どの設定項目の設定誤りが原因か。想定されるものを二つ挙げ、それぞれ20字以内で述べよ。
模範解答
①:調達部FSのデフォルトゲートウェイ
②:調達部FSのネットマスク
解説
解答の論理構成
-
事象の整理
- 相談内容は“先週の調達状況の確認をしようとしたところ、調達部のFSにアクセスできない。”
- 調査結果で「調達部のPCからは調達部のFSに正常にアクセスできることを確認した。」とあります。
- つまり【同一サブネット内】では通信可、【別サブネット(総務部など)】からは不可という状態です。
-
traceroute の結果から推測
- 図3では、総務部側からの traceroute が途中で “* * *” となり応答が途絶えています。
- 最後に応答した IP は調達部側セグメント直前のルータであり、その先(FS からの応答)が戻って来ていません。
-
考えられる原因
- FS 自体は LAN 内の PC からの要求には応えているので、インターフェース設定(IP アドレス)は正しい。
- しかし、異なるサブネットから届いたパケットに対し【戻りのパケット】を正しくルーティングできていない。
- この症状は以下 2 つの設定誤りで典型的に発生します。
① 「デフォルトゲートウェイ」が誤っており、外部サブネットへ返送できない。
② 「ネットマスク」が誤っており、FS が自ネットワーク範囲を誤認し ARP 要求を出し続けてしまう。
-
結論
- 設問は「どの設定項目の設定誤りが原因か。想定されるものを二つ挙げよ。」と求めています。
- よって回答は
①「調達部FSのデフォルトゲートウェイ」
②「調達部FSのネットマスク」
誤りやすいポイント
- traceroute の“* * *”をファイアウォール遮断と早合点する。今回は“調達部のPCからは正常”という条件から FW は無関係です。
- 「ルータが壊れている」と考えてしまう。最後に応答したルータまでは到達しているため、ルータ側ではなくFS側設定が疑わしいです。
- “クライアント PC の設定ミス”に目が行く。複数部門の PC で同じ症状が出た時点で PC 側の誤設定は考えにくく、共有先(FS)を先に疑うべきです。
FAQ
Q: なぜ FS だけが原因と断定できるのですか?
A: 「調達部のPCからは正常」という事実がネットワーク機器やルータの設定をほぼ否定します。遠隔サブネットからの戻り経路だけが失われているため、FS の L3 設定が最有力です。
A: 「調達部のPCからは正常」という事実がネットワーク機器やルータの設定をほぼ否定します。遠隔サブネットからの戻り経路だけが失われているため、FS の L3 設定が最有力です。
Q: ネットマスク誤りとゲートウェイ誤りはどう見分けますか?
A: 同一セグメント外アドレスに対して FS が ARP ブロードキャストを出しているならネットマスク誤り、ARP を出さずそもそもパケットを生成しないならゲートウェイ誤りが濃厚です。
A: 同一セグメント外アドレスに対して FS が ARP ブロードキャストを出しているならネットマスク誤り、ARP を出さずそもそもパケットを生成しないならゲートウェイ誤りが濃厚です。
Q: こうした設定ミスを防ぐ方法は?
A: 初期導入時にテンプレート設定ファイルを用意しコピー展開する、設定後に ping/traceroute で外部サブネット疎通テストを義務付けることで防止できます。
A: 初期導入時にテンプレート設定ファイルを用意しコピー展開する、設定後に ping/traceroute で外部サブネット疎通テストを義務付けることで防止できます。
関連キーワード: デフォルトゲートウェイ、サブネットマスク、ルーティング、traceroute
設問4:
本文中の下線①について、T君のPCからWebブラウザを用いてFSの利用状況確認ページが表示できなかった理由を35字以内で述べよ。
模範解答
プロキシサーバ経由でFSにアクセスしようとしたから
解説
解答の論理構成
- ブラウザの通信経路
– 【問題文】に「本社事業所内のPCからブラウザを用いてWebページにアクセスする場合には、プロキシサーバを経由する。」とあるように、PCのブラウザは初期状態で必ずプロキシを使います。 - 例外設定が無い
– 図2の設定ガイドには「プロキシ例外設定: なし(全 URL でプロキシサーバを利用)」と明記されています。したがって内部サーバ宛ての HTTP リクエストも proxy.p.example.jp へ転送されます。 - FS は社内 LAN 上
– 企画部 FS の IP は 172.16.4.253(図1の各部 FS は 172.16.x.253)で、DMZ 外の社内ネットワークに属します。DMZ のプロキシサーバからはファイアウォールを越えて当該 FS へ到達できません。 - 以上より、T君のブラウザは「利用状況確認ページ」を proxy.p.example.jp 経由で取得しようとして失敗した、と論理的に導けます。
- よって解答は「プロキシサーバ経由でFSにアクセスしようとしたから」となります。
誤りやすいポイント
- 「FS が HTTP を公開していない」と誤解しがちですが、問題文にはサービス非対応とは書かれていません。
- DNS や IP アドレス設定を疑い、ネットワーク経路の問題に気付かないケースがあります。
- 「プロキシ例外設定」を見落とし、ユーザが直接アクセスしていると錯覚するパターンが多いです。
FAQ
Q: 社内サーバへはプロキシを使わない運用にすべきですか?
A: 内部サーバは直接アクセスさせる方が一般的です。必要なら「172.16..」や「*.p.example.jp」などを例外に追加します。
A: 内部サーバは直接アクセスさせる方が一般的です。必要なら「172.16..」や「*.p.example.jp」などを例外に追加します。
Q: プロキシサーバから内部ネットワークへルーティングすれば解決しますか?
A: 可能でもセキュリティ上の意図(DMZ 内から内部へのアクセス遮断)と矛盾するため、通常は許可しません。
A: 可能でもセキュリティ上の意図(DMZ 内から内部へのアクセス遮断)と矛盾するため、通常は許可しません。
Q: ブラウザ自動設定(WPAD など)を用いればこの問題は避けられますか?
A: 適切に PAC ファイルを用意し、内部向け URL を DIRECT にすれば回避できます。
A: 適切に PAC ファイルを用意し、内部向け URL を DIRECT にすれば回避できます。
関連キーワード: プロキシサーバ、DMZ, ファイアウォール、例外設定、イントラネット


