応用情報技術者 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)a、bに入れる、調達部のPCに設定可能なIPアドレスの範囲を、接続できるPCの台数が最大となるように答えよ。
模範解答
a:172.16.1.1
b:172.16.1.252
解説
解答の論理構成
-
予約アドレスの除外
同図に
・「デフォルトゲートウェイ : 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
(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)に答えよ。
問題文を見る模範解答
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, ファイアウォール、例外設定、イントラネット





