ネットワークスペシャリスト 2017年 午後1 問03

解答の論理構成

1. ア の導出
   • 問題文では「PC 及びサーバからインターネットへの Web閲覧などの通信は、FW で IP アドレスとポート番号の変換処理である ア を行う」と記載されています。
   • IP アドレスに加えポート番号も同時に変換する方式は Network Address Port Translation、すなわち「NAPT」です。
     ⇒ ア：NAPT
2. イ の導出
   • フェーズ1で「両方の機器であらかじめ、イ と呼ばれる同じ鍵を共有する方式を利用する」と明示されています。
   • IPsec IKE フェーズ1で双方が同一の秘密鍵をあらかじめ共有する方式は “事前共有鍵 (Pre-Shared Key, PSK)” です。
     ⇒ イ：事前共有鍵
3. ウ の導出
   • BGP は「特定のルーティングポリシで管理されたルータの集まりを示す ウ の間で、経路情報の交換を行う」とあります。
   • BGP が経路交換を行う単位は Autonomous System、略称「AS」です。
     ⇒ ウ：AS
4. エ の導出
   • BGP 接続では「トランスポートプロトコルの一つである エ のポート179番を使用」すると記載されています。
   • ポート番号179を使うトランスポート層プロトコルは Transmission Control Protocol、「TCP」です。
     ⇒ エ：TCP
5. オ の導出
   • ping は「オ の echo request パケットを監視対象に送り」とあります。
   • ping の実体は Internet Control Message Protocol、「ICMP」です。
     ⇒ オ：ICMP
6. カ の導出
   • echo request に対応して返されるのは「カ パケット」。
   • ICMP で echo request に対して返るメッセージは “echo reply” です。
     ⇒ カ：echo reply

誤りやすいポイント

• ア を “NAT” とだけ答えてしまう
  IP アドレスだけを変換する NAT と、ポート番号も変換する NAPT を区別する必要があります。
• イ を “共有鍵” とだけ書く
  フェーズ1で求められるのは “事前共有鍵” であり、単なる共有鍵では減点対象です。
• エ で “UDP” を選ぶ
  OSPF、RIP などは UDP を使いますが、BGP はコネクション指向の TCP を利用します。
• オカ をセットで混同
  echo request／echo reply の用語を逆に記入すると失点します。

FAQ

解答の論理構成

• 本文は、VPN ルータ間のトンネルについて「L 社クラウドサービスの VPN ルータと K 社 NW の VPN ルータでは、互いのグローバル IP アドレスを利用して、RFC 1853 に記載されている IP in IP を用いて、トンネルが構成される。」と明記しています。
• つまり暗号化対象となるパケットの送信元・宛先 IP は既に“グローバル IP アドレス”であり、この IP 情報をそのままネットワーク上で見せても問題になりません。
• IPsec でトンネルモードを選ぶと、新たな外側 IP ヘッダを追加してしまいオーバーヘッドが大きくなります。今回のようにヘッダを隠蔽する必要がない場合は、既存ヘッダを温存し余分なヘッダを付けないトランスポートモードが合理的となります。
• したがって「暗号化対象の通信がグローバル IP アドレス間の通信だから」という結論になります。

誤りやすいポイント

• 「IP in IP でトンネルを張る＝必ず IPsec もトンネルモード」と早合点しやすい点。IP ヘッダの秘匿が不要ならトランスポートモードでも可です。
• 「グローバル IP アドレスなら安全」と誤認してしまう点。秘匿対象がないだけであり、暗号化自体は必要です。
• トランスポートモードは MTU 圧迫が小さい利点を見落としやすい点。ヘッダが増えなければフラグメント発生リスクを抑えられます。

FAQ

解答の論理構成

1. 【問題文】では、VPN トンネルについて
   「②元IP パケットと比較してパケットサイズは大きくなる」
   と明記されています。
2. 同じ段落で
   「トンネルインタフェースでは MTU のサイズを適切な値に設定」
   と指示がありますが、設問条件では「トンネルインタフェースのMTUの値を 1,500 とした場合」となっています。
3. IP in IP と IPsec（ESP ヘッダなど）によりカプセル化オーバヘッドが発生するため、元の IP パケット長＋追加ヘッダ長 > 1,500 になります。
4. インタフェース側は 1,500 を超えるパケットをそのまま転送できないため、IP 層は RFC 791 に従い「フラグメンテーション（分割）」を行います。
5. 分割された IP フラグメントは反対側の VPN ルータで「リアセンブル（再構成）」され、初めて復号・カプセル化解除が可能になります。
6. 以上より、「VPN ルータで発生する処理」は「フラグメントとリアセンブル」であると結論できます。

誤りやすいポイント

• Path MTU Discovery が働くと考え、フラグメントせず ICMP を返すと誤解する。DF ビットを設定していない限り、実際には自動フラグメントが行われます。
• 「トランスポートモードだからヘッダは増えない」と判断してしまう。IP in IP で既に外側ヘッダが付加されるため、モードにかかわらずオーバヘッドが存在します。
• 「送信側だけで分割される」と考え、受信側のリアセンブルを忘れる。

FAQ

解答の論理構成

1. 問題文には「静的経路制御、又は BGP を用いた動的経路制御を選択できる。Oさんは、③BGPを用いた動的経路制御を選択した。」とあります。
2. BGP はピアとのセッション状態を監視し、経路が届かなくなると即座に経路情報を撤回します。
3. 今回の構成では「VPNa1 側をアクティブ、VPNb1 側をスタンバイ」として二重化されており、どちらかの回線・機器に障害が発生してももう一方へ自動的に経路が切り替わることが求められます。
4. 静的経路では障害検知・経路切替が人手または追加機能に頼るため、迅速なう回が困難です。
5. よって「BGP によって回線断や機器障害を検知し、トラフィックをう回できる」ことが動的経路制御の利点になります。

誤りやすいポイント

• 「BGP はインターネット向けの大規模 AS 間でしか使わない」と誤解し、社内 VPN でも有効な冗長化手段である点を見落とす。
• 静的経路でもトンネル監視 ICMP などで切替できると考え、切替時間と運用負荷の差を軽視する。
• 「BGP ＝負荷分散」と短絡的に捉え、ここでは主目的が“障害時の自動う回”であることを答えに反映できない。

FAQ

解答の論理構成

1. 問題文では「OSPF のエリア 0 を構成するが、④経路情報の交換を行う必要がないのでパッシブインタフェースとする。」と記述されています。
2. OSPF は隣接ルータと「Hello パケット」を交換して隣接関係を確立し、その後に LSDB（Link State Database）更新を行います。
3. パッシブインタフェースを設定すると、そのインタフェースではルーティングプロトコル用の制御パケット（OSPF では Hello パケット）を送出しません。
4. しかし、そのネットワーク情報自体はルーティングテーブルに載り、他インタフェース経由で広告されます。したがって“経路情報の交換を行う必要がない”という要件を満たします。
5. 以上より「Hello パケットを出さない。」が妥当な記述となります。

誤りやすいポイント

• パッシブインタフェースを「OSPF の広告も一切しない状態」と誤解する。実際には Hello 送信だけを停止し、ネットワーク情報は他インタフェース経由で広報される。
• “受信”も停止すると考えてしまう。受信は行われるが隣接関係を形成しないため受信した Hello も無視される。
• “管理下ネットワークが経路表に載らなくなる”と勘違いし、必要なルート広告が欠落する設定をしてしまう。

FAQ

解答の論理構成

1. 目的の整理
   本文では「VPNa1 側をアクティブ、VPNb1 側をスタンバイ」にしたいと述べています。アクティブ経路は常時利用され、スタンバイ経路は障害時にのみ利用される経路です。
2. 方向別に考慮すべき経路
   I 主任は「通信の方向それぞれについて経路設計を考える必要があります」と説明し、まず「社内から L 社クラウドサービスの方向」を取り上げています。ここで経路選択を行う装置は「L3SW」です。
3. 経路選択の判定基準
   L3SW はルーティングプロトコルとして OSPF を用いており、OSPF では“コストが小さい経路が優先”されます。したがって VPNa1 を優先するには、L3SW が見る VPNa1 までの OSPF コストを VPNb1 までより小さくしておけばよいことになります。
4. コスト設定の具体的方法
   O さんの発言を引用すると
   「VPNb1 側のコストを VPNa1 側と比べて A とします。」
   ここでアクティブ経路（VPNa1）が選択されるためには、スタンバイ側（VPNb1）のコストを意図的に“高く”設定する必要があります。
   つまり、空欄 A には「大きく」を入れるのが妥当です。
5. 結論
   A に入る適切な字句は
   「大きく」
   となります。

誤りやすいポイント

• 「スタンバイ側は障害時に使う＝コストを小さくしておく」と逆に考えてしまう。OSPF では小さいコストが優先されるため、スタンバイ側は“大きい”コストを設定します。
• OSPF の“コスト”と他プロトコルの“メトリック”や“管理距離”を混同する。管理距離は異種プロトコル間の優先度、OSPF コストは同一プロトコル内での最短経路判定です。
• アクティブ／スタンバイの切替は BGP パス属性で行うと誤解する。本文の方向「社内 → クラウド」は L3SW が OSPF で経路を学習しているため、BGP 属性ではなく OSPF コストが決定要因です。

FAQ

解答の論理構成

1. 【問題文】では「VPNa1 と VPNb1 では、OSPF と BGP の間で経路情報の再配布を行う。」とあり、二つのプロトコル間で相互にルートを受け渡す構成です。
2. さらに下線⑤として「経路のループを防止する経路制御」が必要と明記されています。
3. 何もしない場合、
   • eBGPで受信した“クラウド側サーバセグメント”の経路
   • → OSPFへ再配布
   • → OSPF経由で別のVPNルータへ渡る
   • → 再びeBGPへ再配布
     という流れで同一経路が“行って戻る”循環が起こります。
4. ループを断つ最もシンプルな方法は、①でeBGP→OSPFへ流した経路を②でOSPF→eBGPへ逆戻りさせないフィルタを適用することです。
5. よって「eBGP から OSPF へ再配布された経路を再び eBGP へ再配布しない。」が適切な経路制御となります。

誤りやすいポイント

• OSPF パッシブインタフェース設定（④）は「OSPF での隣接関係抑止」であり、BGP↔OSPFループ対策とは別物です。
• iBGP ループ防止（AS_PATH 変化しない問題）と混同しやすいですが、本設問は“eBGP→OSPF→eBGP”の再配布ループが論点です。
• MED や AS_PATH 長での優先度調整は“到達経路選択”であり、ループ防止策ではありません。

FAQ

解答の論理構成

1. 【問題文】は下線部⑥で、
   「二つある VPN トンネルがそれぞれ正常に動作しているかを常に確認する」
   と述べています。ここで注目すべき語は「それぞれ正常」「常に確認」です。
2. 本システムでは、VPN トンネルを
   「VPNa1 ⇔ VPNa2」と「VPNb1 ⇔ VPNb2」の二系統で構成し、
   VPNa1 側をアクティブ、VPNb1 側をスタンバイとする冗長構成を採っています。
3. 冗長構成の目的は、どちらか一方が故障しても通信を継続できる可用性の確保です。しかし一方が故障すると、通信そのものは生きていても“冗長性”は失われます。
4. そこで ping 監視を (e)・(f) の両トンネル先端に向けて行い、各トンネルの到達性を独立して判定します。
5. 判定結果により「冗長構成が維持されている／失われた」を即時に把握できるため、解答は
   「ネットワーク接続の冗長構成が失われたことを検出するため」
   となります。

誤りやすいポイント

• 「通信断の検出」が目的だと早合点しやすい
  → 一系統が生きていれば通信は継続するため、監視の主眼は“冗長性の喪失”です。
• MTU・MSS などトンネル設定の技術的課題と混同する
  → 監視項目は単純な到達性(ping)であり、パケットサイズ最適化とは別問題です。
• アクティブ／スタンバイの切替機構を答えてしまう
  → 設問は「監視の目的」を問うており、切替方法自体は対象外です。

FAQ