平成21年度秋期ネットワークスペシャリスト午後I 問3

ネットワークスペシャリスト試験
この記事は約8分で読めます。

今日は、平成21年度秋期ネットワークスペシャリスト午後I 問3を解こうと思います。

問題文および模範解答(解答のみ、解説はありません)は下のリンクからどうぞ。
※IPAのサイトで公開されているPDFにリンクしています

問題文はこちら】【模範解答はこちら

各問解説

設問1

(1)

問題文には『(ii)には、リクエスト元のIPアドレスに基づいて行うレイヤ3方式や、Webページにアクセスしたユーザに関する情報を保持する [ イ ] に埋め込まれた、セッションIDに基づいて行うレイヤ7方式などがある』とあります。『セッションID』という言葉から、これはセッションについての説明だと判ります。

HTTPは本来、1度のクライアントからのリクエストに対して、サーバが1度のレスポンスを返すという1往復のやりとりだけで完結するプロトコルです。たとえ同じクライアントから同じサーバに対して連続してリクエストを行うとしても、それらのリクエストは完全に独立した存在であり、複数のリクエストを跨いでデータを保持することができません。

しかしWebアプリケーションの高機能化により、複数のリクエストでデータを共有する必要が出てきました。そこで考案されたのがセッションです。

多くのセッションの実装では、サーバ側でデータを保持し、それをクライアントと関連付けることによってデータの共有を実現しています。このクライアントの関連付けには、クライアントのIPアドレスを記録する方法(レイヤ3方式)や、セッション開始時に生成するユニークなID(セッションID)をクライアントに記憶させ、次回のリクエストにセッションIDを添付させる方法(レイヤ7方式)があります。

前者のレイヤ3方式は、原理は簡単ですが、NAPTのように複数のクライアントが共通のIPアドレスを使用するネットワークや、動的にアドレスが割り当てられる環境での長期間利用・一部のモバイル環境などセッション継続中にクライアントのIPアドレスが変更されてしまうような場合には使用できないという欠点があります。問題文中に『eシステムを利用するPCにはIPアドレスが固定設定されているので』とあるのはこのためです。

後者のレイヤ7方式では、クライアントにセッションIDを記憶させるためにCookieが使用されます。Cookieはサーバからクライアントに送信された小容量のデータをブラウザが記録する仕組みで、記録したデータは次回同じサーバに対してリクエストを送信する際にヘッダに添付して送信されます。

以上より、(ア)はセッション、(イ)はCookieとなります。

(2)

問題文には『(iii)には、レイヤ3、レイヤ4及びレイヤ7の各レイヤで稼働状況を監視する方式がある。eシステムのサービスポートの稼働状況を監視するために、レイヤ4方式を利用することにした。』とあります。レイヤ4とはネットワークのOSI参照モデルのトランスポート層のことであり、ここに該当するプロトコルにはTCPやUDPがあります。『サービスポートの稼働状況』とあることから、(明記されていませんがおそらくTCPで)該当するポートに対して接続・コネクションの確立が可能かどうかでサービスの稼働を確認するものと思われます。

(3)

問題文には『社内のPCを三つのブロックに分け、各ブロックのPCごとに、異なったeSVRのホスト名を指定させる』とあります。つまりたとえばブロック1はeSVR1、ブロック2はeSVR2、ブロック3はeSVR3を使用するように指定しておくわけです。LBが正常に動作している場合は『DNSで、三つのホスト名に一つのVIPを対応づける』となっています。このVIPとはLBに割り当てられた仮想IPアドレスで、10.10.0.1であることが図から判ります。つまり通常は、各PCブロックごとに指定されたホスト名とは関係なく、LBで分散されてeSVR1~eSVR3のいずれかにアクセスすることになると思われます。

LBが故障した場合は、社内のPCの各ブロックごとに指定されているホスト名の通り、eSVR1~eSVR3にアクセスするように設定すれば良いでしょう。そのためにはDNSで、三つのホスト名それぞれに3台のサーバのIPアドレスを設定すればよいことになります。

(4)

②はソースNAT機能を利用しない理由を述べています。ソースNAT機能については、問題文では『PCからVIPあてに送信されたパケットの、送信元IPアドレスをLBの実アドレスに変換してeSVRに転送する』と説明されています。この機能を利用すると、eSVRのアクセスログには、アクセス元として各PCではなくLBの実アドレスが記録されてしまいます。よって『取得できなくなる情報』とは『サーバに接続したPCのIPアドレス』です。

設問2

(1)

トラフィックモニタを接続したのが本社LAN上であることに注意しながら考えてみます。

項番1のフレームは、送信元IPアドレスが 172.16.0.1、宛先IPアドレスが 10.10.0.1 であることから、ネットワーク構成図中の表より、PC-y1 から LB へ送信されたものであることが判ります。PC-y1 から送信されたフレームは、ルータ1 を経由して本社LANに入るので、本社LAN上で観察されるフレームでは送信元MACアドレスはルータ1のものになります。よって、[ a ] に当てはまるのは HRTMAC です。また宛先MACアドレスはLBのものになります。よって、[ b ] に当てはまるのは LBMAC です。

項番2のフレームは、送信元MACアドレスが LBMAC 、宛先IPアドレスが 10.10.10.1 であることから、LB から eSVR1 へ送信されたものであることが判ります。よって [ c ] に当てはまるのはSVR1MAC となります。ところでこのフレームは、項番1のフレームが LB によって eSVR1 に転送されたものだと思われます。そして説明文より、LBが転送の際に送信元IPアドレスをLBの実アドレスに変換するソースNAT機能は使用していません。よって、このフレームの送信元IPアドレスは PC-y1 のIPアドレスのままであり、[ d ] には、172.16.0.1 が当てはまります。

(2)

表1・項番3のフレームに注目すると、送信元IPアドレスが 10.10.10.1 になっています。これは項番1のフレームで PC-y1 が送信したフレームの宛先である 10.10.0.1 とは一致していません。よって、PC-y1 は項番3のフレームが項番1のフレームに対する返信であるとは認識できず、処理が継続されないのです。よって解答は『通信相手ではないサーバからのパケットを受信したこと』となります。

これを解決するためには、PC-y1が受信するパケットの送信元IPアドレスが LB のIPアドレス( 10.10.0.1)になる必要がありますが、その具体的な実現方法は次の(3)にも関わっています。

(3)

(2)での何らかの変更によってPC-y1では正常に通信ができるようになりましたが、PC-x1ではまだ通信ができないという状態です。なぜこのようなことが発生するのか考えてみます。

表2によると、eSVRからPC-x1へ充てたフレームの送信元アドレスが 10.10.10.1、つまりeSVR1のIPアドレスになっています。このため(2)でのPC-y1と同じ問題が生じたのです。では(2)ではどのようにPC-y1での問題を解消したのでしょうか?それは、eSVR1~3のデフォルトゲートウェイ として LB を指定することによって、eSVRからの返送がLBを経由するようにしたのだと考えられます。これにより、(2)における eSVR1 から PC-y1 へのフレーム送信は、

eSVR1 → LB → ルータ1 → ルータ2 → PC-y1

という経路を辿り、その途中LBで送信元IPアドレスを LB のIPアドレス(10.10.0.1)に変更することによって正常に通信できるようになったのでした。

しかしこの方法では、eSVR1 と同じネットワーク上にある PC-x1 への通信ではゲートウェイ(LB)を経由せず直接送信できてしまいます。そのため送信元IPアドレスの変換が行われず、正常に動作しなくなったのです。

PC-x1 に対する通信の場合もLBを経由するようにするには、eSVR1 が PC-x1 を違うネットワークのPCだと認識すればよいのですが、アドレスそのものを変更せずにこれを実現するには、本社LANをサブネットに分割することが考えられます。最初の状態では『本社と営業所のネットワークのIPアドレスは、サブネットを設定せず、それぞれクラスAとクラスBが用いられています』とあります。つまり本社のLANはデフォルトのクラスA(10.0.0.0/8)でネットワーク部8ビットとなっていますが、本社PCのアドレス範囲10.128.1.1~10.128.10.100とeSVR関連サーバのアドレス範囲10.10.10.1~10.10.10.128を異なるサブネットワークとするればよいのです。このためには、eSVRのサブネットマスクの設定をネットワーク部16ビットなどに変更するとよいと思われます。

設問3

(1)

発生している不具合は『配信される音声が聞き取りにくい』『動画が頻繁に停止する』ということなので、動画や音声のパケットのロストや遅延が発生していると思われます。また発生したのは『eシステムの利用拡大によって』ということなので、負荷の増大が原因と思われます。

『eSVRの性能やLANとWANの帯域には問題がない』ともありますので、LBでパケットロストや遅延が発生しているという主旨のことを解答すればよいと思われます。

(2)

問題文中にはDSRとは『eSVRから返送されたパケットを直接PCあてに送信できるようにする機能』である、と書かれています。このためには、設問2の(2)にあったように、eSVRからPCに宛てた返信の送信元IPアドレスがLBの仮想IPアドレス 10.10.0.1 になっていなければなりません。

DSRの動作については、『DSRを機能させると、LBはPCから受信したパケットに変更を加えないで、eSVRあてに転送する。eSVRが受信したパケットの宛先IPアドレスが、ループバックインターフェイスに設定されたIPアドレスと同じときこのIPアドレスがeSVR自身のものとして、eSVRから返送されるパケットに使われる』とあります。つまりeSVRのループバックインターフェイスにLBのVIPと同じ10.10.0.1を設定すれば、eSVRからの返信パケットの送信元アドレスとして10.10.0.1が使用され、処理が継続されることになります。

よって解答は『送信元IPアドレスが仮想IPアドレスに変わったもの』となります。

コメント

タイトルとURLをコピーしました