ネットワークスペシャリスト 午後Ⅱ 公式回答と答え合わせ
問１を選択 配点はTACのものを流用
| 設問 | 小問 | 自分の解答 | 解答例（公式） | 正誤 | 配点 |
| 1 | あ | i1 | i1 | ○ | 2.0 |
| い | NAT | NAT | ○ | 2.0 | |
| う | i3 | i3 | ○ | 2.0 | |
| え | Flow-Mod | Flow-Mod | ○ | 2.0 | |
| お | p8 | controller | × | 2.0 | |
| か | Packet-Out | Packet-Out | ○ | 2.0 | |
| き | OFS2 | OFS2 | ○ | 2.0 | |
| く | p9 | p9 | ○ | 2.0 | |
| 2 | (1)け | v2 | v2 | ○ | 2.0 |
| (1)こ | なし | なし | ○ | 2.0 | |
| (1)さ | m2 | m2 | ○ | 2.0 | |
| (1)し | m3 | m3 | ○ | 2.0 | |
| (1)す | i4 | i4 | ○ | 2.0 | |
| (2) | ②、⑧、⑨、⑩ | ②、⑧、⑨、⑩ | ○ | 4.0 | |
| (3) | ETH_TYPEがARPのプロトコル番号 | ETH_TYPEがARPのイーサネットタイプに等しい | ○ | 4.0 | |
| (4) | RT-1宛てのARP Reply | 外部NWのRT-1と新FWの通信 | ○ | 4.0 | |
| (5)せ | p6 | p6 | ○ | 2.0 | |
| (5)そ | なし | なし | ○ | 2.0 | |
| (5)た | m1 | m1 | ○ | 2.0 | |
| (5)ち | m5 | m2 | × | 2.0 | |
| (6) | Push-VLAN Set-Fileld VLAN_VID=v2 Output(p7) |
Push-VLAN Set-Fileld VLAN_VID=v2 Output(p7) |
○ | 4.0 | |
| 3 | (1)つ | CNAME | CNAME | ○ | 2.0 |
| (2) | ns1.asha.example.com. | webtest.asha.example.com | × | 3.0 | |
| (3) | ns1.bshacdn.example.net. | weblive.asha.example.com | × | 3.0 | |
| (4) | DNSメッセージの送信元IPアドレスを管理するISPと通知されたDNSクライアント情報が特定したとき | DNSクライアントとDNSフルリゾルバがネットワーク上で離れた位置にある場合 | × | 4.0 | |
| (5)要因① | 一斉配信によるWebサーバの処理負荷 | Web-Bのサーバ処理能力不足 | ○ | 4.0 | |
| (5)要因② | 一斉配信で発生する通信による帯域圧迫 | 機械とWeb-B間の通信遅延 | ○ | 4.0 | |
| 4 | (1) | 転用した業務サーバがWebシステム内で負荷分散されるようにLBを設定変更する | 転用後の業務サーバのIPアドレスをLBの振り分け先に追加しておく | ○ | 4.0 |
| (2)置換前 | webtest IN A i1 | weblive IN A i6 | × | 3.0 | |
| (2)置換後 | weblive IN A i1 | weblive IN A i1 | ○ | 3.0 | |
| (3)要因① | SDNのライブマイグレーションによるサーバ切替えができること | 転用する業務サーバの物理配線の変更が不要である | × | 4.0 | |
| (3)要因② | B社ISPの高速転送経路を切替え時に利用できること | 管理ソフトウェアを用いて社員だけで対応できる | × | 4.0 | |
| (4) | B社クラウドサービスが提供する国外拠点と国内拠点間のバックボーン速度の調査 | CDN,ISP,Iaas環境の構築と切替えに関する、APIサービスとDNSを使った手順 | × | 4.0 | |
| (5)利点① | 災害による本拠点とバックアップ拠点の同時罹災の可能性が低い | 国外で利用するので、国内の広域災害の影響を回避できる | ○ | 4.0 | |
| (5)利点② | バックアップ拠点とのデータ転送にB社APIサービスを利用できること | B社CDNなどを使い、通常時と同じ品質を保つことができる | △ | 4.0 |
設問１と２ まあ、想定どおり。
設問２（４）はARPReplyのことを指しているんじゃないだろうか。
設問４（４）何やら盛りだくさん詰め込んだ感じの公式回答だ。
設問４（５）B社のサービスをバックアップとのレプリケーションとかに利用できるという解釈で部分点くらいもらえないだろうか・・
自己採点 67～69 ／100 くらい？ただし、設問１と２のSDNの小問が２点配点だったらの話し。
総じてOpenFlowプロトコルの動作はおおむね理解できていたが、SDNそのもののサービスの活用方法に関してはまだまだ勉強が必要のようだ。
DNSに関してはお察し・・・ キャッシュサーバとコンテンツサーバの名前解決に関する位置関係の問題は実は平成16年午後Ⅱ問２でも出題されていたんだと後で分かった。
発表は今週水曜日（１２月２０日）。どうなることやら。
ネットワークスペシャリスト 午後Ⅰ 公式回答と答え合わせ
配点はTACの予想配点
問１
| 設問 | 設問内容 | 自分の解答 | 解答例（公式） | 正誤 | 配点 |
| 1 | ア | SHA-1 | SHA-1 | ○ | 3.0 |
| イ | 1.2 | 1.2 | ○ | 3.0 | |
| ウ | ClientHello | ClientHello | ○ | 3.0 | |
| エ | ServerHello | ServerHello | ○ | 3.0 | |
| オ | リバースプロキシ | リバースプロキシ | ○ | 3.0 | |
| 2 | (1)暗号化① | 共有鍵を安全に配送 | 鍵交換 | × | 3.0 |
| (1)暗号化② | 転送データの暗号化 | 認証 | × | 3.0 | |
| (1)ﾊｯｼｭ | 転送データの完全性の検証 | メッセージ認証 | × | 3.0 | |
| (2) | 顧客の開発環境に内部LANのサブネットを割り当てること | 顧客システムは，様々なプロトコルを利用している。 | × | 4.0 | |
| (3) | vNIC | vNIC | ○ | 4.0 | |
| 3 | カ | 内部LAN | 内部LAN | ○ | 2.0 |
| キ | DMZ | DMZ | ○ | 2.0 | |
| ク | 172.16.0.0/16 | 172.16.0.0/16 | ○ | 2.0 | |
| ケ | 202.y.44.2 | 202.y.44.2 | ○ | 2.0 | |
| 4 | (1) | ②、③、④、⑤ | ②、③、④、⑤ | ○ | 3.0 |
| (2) | ある顧客のPCから自社の開発環境を踏み台にした他社の開発環境及び開発LANへの通信 | 顧客システム構築ネットワークから他社の顧客システム構築ネットワークへの通信 | △ | 4.0 | |
| (3) | ⑥ | ⑥ | ○ | 3.0 |
設問３と設問４（１）はTACが正しかった模様
設問４（２）開発LANが余分だから減点だろう
自己採点 33～35／50 かな？
問３
| 設問 | 設問内容 | 自分の解答 | 解答例（公式） | 正誤 | 配点 |
| 1 | ア | NAPT | NAPT | ○ | 3.0 |
| イ | PSK | 事前共有鍵 | ○ | 3.0 | |
| ウ | AS | AS | ○ | 3.0 | |
| エ | TCP | TCP | ○ | 3.0 | |
| オ | ICMP | ICMP | ○ | 3.0 | |
| カ | echo reply | echo reply | ○ | 3.0 | |
| 2 | (1) | グローバルIPアドレスでカプセル化しているから | 暗号化対象の通信がグローバルIPアドレスの範囲だから | ○ | 5.0 |
| (2) | 送信時はパケット分割、受信時はパケット再構築の処理をする | フラグメントとリアセンブルの処理が発生する | ○ | 5.0 | |
| 3 | (1) | L社サーバセグメントが増設された際に、K社側のネットワーク機器の設定変更が不要な点 | BGPによって回線断や機器障害を検知し、トラフィックを迂回できる | × | 5.0 |
| (2) | OSPFの経路情報を送信しない | Helloパケットを出さない。 | △ | 4.0 | |
| (3) | 大きく | 大きく | ○ | 3.0 | |
| (4) | K社内で利用する経路情報はOSPFとなるようなコスト値を設定する | eBGPからOSPFへの再配布及びeBGPへ再配布しない | × | 5.0 | |
| 4 | 目的 | L社クラウドサービス側のVPNルータの障害も検知するため | ネットワーク接続の冗長性が失われたことを検知するため | × | 5.0 |
設問３（１）ここでは障害発生時の迂回経路としてのBGPの利点を書くべきだったのか・・
設問３（２）「経路情報を送信しない」⊆「Helloパケットを出さない」かなぁと減点
自己採点 31～33 ／ 50 かな？
以上から、午後Ⅰは 64～68 ／ 100 で辛うじて通過している感触。
当日は比較的時間が余り、見直しに15分くらい充てることができたので、
もしかしたら80点位とれるかと踏んでいたが、結果はそうでもなかったようだ。
問１設問２ VPNの種類の捉え間違い（SSL-VPNと通常のVPNと混同）が痛い。
問３設問３ BGPは直前にやった予想問題集で表面的に演習してみたが、根本的な部分をまだ理解できていないようだった。
ネットワークスペシャリスト 午後Ⅱ
問１を選択しました。
| 設問 | 自分の解答 | 解答例（アイテック） | 解答例（TAC） | |
| 1 | あ | i1 | i1 | i1 |
| い | NAT | NAT | NAT | |
| う | i3 | i3 | i3 | |
| え | Flow-Mod | Flow-Mod | Flow-Mod | |
| お | p8 | controller | controller | |
| か | Packet-Out | Packet-Out | Packet-Out | |
| き | OFS2 | OFS2 | OFS2 | |
| く | p9 | p9 | p9 | |
| 2 | (1)け | v2 | v2 | v2 |
| (1)こ | なし | なし | なし | |
| (1)さ | m2 | m2 | m2 | |
| (1)し | m3 | m3 | m3 | |
| (1)す | i4 | i4 | i4 | |
| (2) | ②、⑧、⑨、⑩ | ②、⑧、⑨、⑩ | ②、⑧、⑨、⑩ | |
| (3) |
ETH_TYPEがARPの プロトコル番号 |
ETH_TYPEがARPの プロトコル番号 |
ETH_TYPEがARPを表す 0806に等しいパケット |
|
| (4) | RT-1宛てのARP Reply | RT-1と新FW間の通信 |
新FWからRT-1への ARP Reply |
|
| (5)せ | p6 | p6 | p6 | |
| (5)そ | なし | なし | なし | |
| (5)た | m1 | m1 | m1 | |
| (5)ち | m5 | m2 | m2 | |
| (6) | Push-VLAN Set-Fileld VLAN_VID=v2 Output(p7) |
Push-VLAN Set-Fileld VLAN_VID=v2 Output(p7) |
Push-VLAN Set-Fileld VLAN_VID=v2 Output(p7) |
|
| 3 | (1)つ | CNAME | CNAME | CNAME |
| (2) |
ns1.asha.example .com. |
webtest.asha.example .com |
webtest.asha.example .com |
|
| (3) |
ns1.bshacdn.example .net. |
weblive.asha.example .com |
weblive.asha.example .com |
|
| (4) | DNSメッセージの送信元IPアドレスを管理するISPと通知されたDNSクライアント情報が特定したとき | DNSフルリゾルバよりもDNSライアントの方がエッジサーバに近い場合 | 問い合わせてきたキャッシュサーバと問合せ元の機械が異なるアドレスブロックに存在する場合 | |
| (5)要因① |
一斉配信によるWebサーバの処理負荷 |
Webサーバの負荷増大に伴う処理遅延 |
機械からWeb-Bまでの経路の長さ |
|
| (5)要因② | 一斉配信で発生する通信による帯域圧迫 | 伝送遅延によるレスポンスの悪化 |
大量の同一リクエストの処理による高負荷 |
|
| 4 | (1) | 転用した業務サーバがWebシステム内で負荷分散されるようにLBを設定変更する | Web-A3とWeb-A4のIPアドレスをLBの処理振り分け先として登録する。 | 転用後の業務サーバのIPアドレスをLBに振り分け先として追加登録する。 |
| (2)置き換え前 | webtest IN A i1 | weblive IN A i6 | weblive IN A i6 | |
| (2)置き換え後 | weblive IN A i1 | weblive IN A i1 | weblive IN A i1 | |
| (3)要因① | SDNのライブマイグレーションによるサーバ切替えができること | OFCのソフトウェアでLANの構成変更が可能なこと | 物理的な配線変更を行わずに構成変更を実施できる。 | |
| (3)要因② | B社ISPの高速転送経路を切替え時に利用できること | ベンダに依存せず，自社要員で構成変更ができること | ベンダへの委託を行わずに自社運用要員のみで作業できる。 | |
| (4) | B社クラウドサービスが提供する国外拠点と国内拠点間のバックボーン速度の調査 | DNS-Aの機能を海外に準備し，名前解決ができるようにする。 | DNS-Aのゾーンファイルを書き換え，本運用時のAレコードのIPアドレスをB社国外のものに変更する。 | |
| (5)利点① | 災害による本拠点とバックアップ拠点の同時罹災の可能性が低い | 国内が全て被災してもサービスが継続できる。 | 本運用モードと同じ構成で利用することができる。 | |
| (5)利点② | バックアップ拠点とのデータ転送にB社APIサービスを利用できること | 自社設備よりもリソースの追加が容易である | 高負荷が予想される期間，B社のCDNを適用できる。 |
設問１、２のSDNはじっくりパケットを追っていけばなんとか解答できた設問が多かったが時間がかかった。設問２を解答終えた段階でのこり70分。
設問３ DNS関連のところは正直いって適当に解答。
設問４(3)SDNの利点：実は問題文の冒頭にあることを後になって気づき愕然
(4)ネットワークの準備があいまいすぎて出題意図を読み取れず。
(5)国外拠点をバックアップに持つことのメリット：同時罹災のリスク回避以外は思いつかなかった。
自己採点 55～63 ／100 くらい
設問１，２のSDNの穴埋めの配点はどのくらいなのか気になる。おそらく１点かな？
ネットワークスペシャリスト 午後Ⅰ
ずいぶん経ってしまいましたが、去る10月15日に受験したネットワークスペシャリスト試験の午後Ⅰと午後Ⅱの解答はこんな感じでした。
午後Ⅰ 問１と問３を選択
問１
| 設問 | 自分の解答 | 解答例（アイテック） | 解答例（TAC） | |
| 1 | ア | SHA-1 | SHA-1 | SHA-1 |
| イ | 1.2 | 1.2 | 1.2 | |
| ウ | ClientHello | ClientHello | ClientHello | |
| エ | ServerHello | ServerHello | ServerHello | |
| オ | リバースプロキシ | リバースプロキシ | リバースプロキシ | |
| 2 | (1)暗号化ｱﾙｺﾞﾘｽﾞﾑ① | 共有鍵を安全に配送 | 鍵交換 | 鍵交換 |
| (1)暗号化ｱﾙｺﾞﾘｽﾞﾑ② | 転送データの暗号化 | 署名 | 認証 | |
| (1)ﾊｯｼｭｱﾙｺﾞﾘｽﾞﾑ | 転送データの完全性の検証 | メッセージ認証 | 証明書の署名付与と検証 | |
| (2) | 顧客の開発環境に内部LANのサブネットを割り当てること | 顧客システムは、利用されるプロトコルが様々であること | 様々なサーバ機器で構築され，様々なプロトコルを利用する。 | |
| (3) | vNIC | vNIC | vNIC | |
| 3 | カ | 内部LAN | 開発LAN | 内部LAN |
| キ | DMZ | DMZ | DMZ | |
| ク | 172.16.0.0/16 | 172.16.10.0/24 | 172.16.0.0/16 | |
| ケ | 202.y.44.2 | 202.y.44.2 | 202.y.44.2 | |
| 4 | (1) | ②、③、④、⑤ | ②、③、④ | ②、③、④、⑤ |
| (2) | ある顧客のPCから自社の開発環境を踏み台にした他社の開発環境及び開発LANへの通信 | 異なる顧客システム構築ネットワーク間の通信 | 顧客システム構築ネットワークから他社の顧客システム構築ネットワークへのアクセス | |
| (3) | ⑥ | ⑥ | ⑥ |
設問２(1)と(2)はSSL-VPNとL2フォワーディングを完全に勘違いしていた
設問３と設問４はアイテックとTACで微妙に解答が割れている・・
自己採点 24～30／50 くらい？
問３
| 設問 | 自分の解答 | 解答例（アイテック） | 解答例（TAC） | |
| 1 | ア | NAPT | NAPT | NAPT |
| イ | PSK | 事前秘密共有鍵 | 事前共有鍵 | |
| ウ | AS | AS | AS | |
| エ | TCP | TCP | TCP | |
| オ | ICMP | ICMP | ICMP | |
| カ | echo reply | echo reply | echo reply | |
| 2 | (1) | グローバルIPアドレスでカプセル化しているから | 双方ともグローバルIPアドレスを使用しているから。 | IP in IPで元のIPヘッダはカプセル化されているから |
| (2) | 送信時はパケット分割、受信時はパケット再構築の処理をする | パケットを分割する処理と分割されたパケットを再構成する処理 | ESPヘッダ等を付加し，IPフラグメンテーションを行う。 | |
| 3 | (1) | L社サーバセグメントが増設された際に、K社側のネットワーク機器の設定変更が不要な点 | VPNルータ故障時に自動的に経路を切り替えることができるから。 | ネットワーク構成の変更時や障害発生時に自動的にルーティングテーブルが変更される。 |
| (2) | OSPFの経路情報を送信しない | OSPFパケットを送受信しない。 | Helloパケットを自ら送信しない。 | |
| (3) | 大きく | 大きく | 大きく | |
| (4) | K社内で利用する経路情報はOSPFとなるようなコスト値を設定する | OSPFルータから受け取った経路情報は，再度OSPFルータに広告しない。 | eBGPが学習した経路情報のみをOSPFに再配布する。 | |
| 4 | 目的 | L社クラウドサービス側のVPNルータの障害も検知するため | VPNa2又はVPNb2に至るまでの経路の正常性を確認するため。 | VPNトンネルの障害発生時に即座にスタンバイに切り替えるため |
設問２(1) やや苦し紛れ。「IPアドレスの観点で」でいうとアイテックが正答な気がする。
設問３(4)は正直いうとお手上げだったため、適当に解答
設問４内部からのVPNルータの監視だけでは、VPNルータの外側の障害時に切り替えができないと思っていたが、うまく解答がまとめられず。
自己採点 35～40／50 くらい？
