ネットワークスペシャリスト 2015年 午後1 問01
シングルサインオンの導入に関する次の記述を読んで、設問1~4に答えよ。
A社は、新興の広告代理店である。A社ではここ数年、業務の拡大傾向が続き、営業システムや広告システムなど、PCのWebブラウザからアクセスされるWebアプリケーションを導入してきた。これらのWebアプリケーションの利用者認証は、それぞれ個別に行っている。しかし、この方法は利用者の利便性が低いことから、情報システム課に改善の要望が出されていた。
そこで、情報システム課のB課長は利用者からの改善要望を踏まえ、全ての社内Webアプリケーションの認証を共通化するために、シングルサインオン(以下、SSOという)の導入を考えた。SSOを導入すると、利用者は一度の認証操作で複数のシステムの利用が可能となる。
〔SSOの導入〕
情報システム課は、A社の全システムにSSOを本格導入する前に、試験的に営業システムと広告システムにSSOを導入することにした。そこで、B課長が要件をとりまとめ、ネットワーク担当のC氏に検討を指示した。その指示の内容を次に示す。
・PCからアクセスされる、営業システムと広告システムを対象範囲として、SSOを可能にする。
・SSOサーバは、障害に備えて負荷分散装置(以下、LBという)によって二重化を行う。
・LBは、DSR(Direct Server Return)方式を使用する。
・関連するシステムのURLを、表1のように設定する。


C氏が検討したA社のシステム構成を、図1に示す。

〔SSOについての検討〕
C氏はHTTPを用いたSSOの方式と認証処理シーケンスについて検討した。SSOの方式を分類すると、SSOで利用したいサーバにエージェントと呼ばれるソフトウェアモジュールをインストールして実現するエージェント方式と、SSOサーバにおいて全ての通信の中継を行う ア 方式がある。C氏は、エージェント方式の検討を行い、エージェント方式を採用することにした。
エージェント方式におけるSSO認証処理のシーケンスは、次のとおりである。
① PCからWebアプリケーションサーバに、サービス要求を行う。
② Webアプリケーションサーバ内のエージェントは、サービス要求内のCookieに認証済資格情報(以下、アクセスチケットという)が含まれているか確認する。含まれていなければ、サービス要求はSSOサーバへ イ される。
③ SSOサーバからPCに、認証画面を送る。
④ PCからSSOサーバに、UserIDとPasswordを送出する。
⑤ SSOサーバは、UserIDとPasswordから利用者のアクセスの正当性を確認したら、アクセスチケットを発行して、Cookieに含めて応答を返す。サービス要求は、Webアプリケーションサーバへ イ される。
⑥ Webアプリケーションサーバ内のエージェントは、SSOサーバにアクセスチケット確認要求を送り、SSOサーバは、確認して応答を返す。
⑦ Webアプリケーションサーバは、⑥の応答によって利用者のアクセスの正当性が確認できる場合、Webアプリケーション画面を送出する。
エージェント方式におけるSSO認証処理のシーケンスの①〜⑦を図示すると、図2のようになる。
〔SSOサーバの動作確認〕
C氏は、図1と同等構成の検証環境を本番環境とは別に用意し、SSOサーバを構築した。また、営業サーバと広告サーバには、エージェントのインストールを行った。
検証環境を構築した後、動作確認として営業システムへのアクセスを行ったところ、認証画面が表示されるところまでは想定どおり動作したが、UserIDとPasswordを正しく入力しても、営業システムの画面に遷移せず、SSOとして正しく動作しなかった。原因を調査したところ、SSOサーバから送出されるHTTP応答パケットのウヘッダフィールドに、Domain属性が付与されていないからであった。
そこで、表1中のURL情報を参照して、SSOサーバの設定項目中の(Ⅰ)CookieのDomain属性を設定した 。その結果、営業システムと広告システムにおいてSSOが正しく動作するようになった。
SSOでCookieを用いる場合、Cookieが漏えいしたときにセキュリティの問題が生じる。そこで、(Ⅱ)Cookieが平文でネットワークを流れないように、表1中のサーバから返される全てのページをSSL/TLS対応ページに変更した。
〔負荷分散に関する設定と動作確認〕
C氏は、検証環境において、図1と同じように、LBをSW2に接続してVIPアドレスと負荷分散ポリシを設定するとともに、PCからsso.a-sha.example.jpへの認証リクエストの宛先がこのVIPアドレスとなるように、エサーバに設定を行った。SSOサーバをDSR方式で負荷分散するときのLBの動作の要点を次に示す。
(1) PCからSSOサーバへのリクエストは、LBに設定されたVIPアドレスに送られ、LBは当該リクエストを負荷分散ポリシに従って、SSOサーバ1又はSSOサーバ2に転送する。
(2) 振り分け先については、TCPコネクション確立のためのSYNパケットがPCから届いた時点で、決定される。
(3) 振り分け先として決定されたSSOサーバにリクエストパケットが転送されるが、このリクエストパケットの宛先アドレスはVIPアドレスのままである。
要点(2)の動作から、DSR方式のLBは(III)Cookieなどのレイヤ7の情報を基にして振り分け先サーバを選定するような方式には対応できないことに注意する必要がある。
要点(3)の動作から、SSOサーバは、自IPアドレスと異なるVIPアドレス宛てのパケットを受信しなければならない。そこで、VIPアドレスを付与したオインタフェースをSSOサーバに設定することにした。
C氏がオインタフェースをSSOサーバに設定した後にLBを再起動したところ、(IV)IPアドレス重複エラーが検知された。そこで、このエラーの原因を調査し、(V)SSOサーバにARP関連の設定を加えて対処した。この対処によってエラーが解消され、想定どおりに動作することが確認された。
その後、A社は、営業システムと広告システムを対象範囲とするSSOシステムを正式に導入することにした。
設問1:
問題文を見る本文中のア〜オに入れる適切な字句を答えよ。
模範解答
ア:リバースプロキシ
イ:リダイレクト
ウ:Set-Cookie
エ:内部 DNS
オ:ループバック
解説
解答の論理構成
-
[問題文]では、SSOの方式に関して
「SSOサーバにおいて全ての通信の中継を行う ア 方式がある。」
と記載されています。SSOサーバがクライアントとWebアプリケーションの間に立って転送処理を行う代表的方式は“リバースプロキシ方式”です。したがってア=リバースプロキシとなります。 -
エージェント方式のシーケンス②・⑤で
「サービス要求はSSOサーバへ イ される。」
「サービス要求は、Webアプリケーションサーバへ イ される。」
とあり、HTTPで別サーバへ遷移させる処理は“リダイレクト”です。よってイ=リダイレクトです。 -
動作確認時の不具合説明で
「SSOサーバから送出されるHTTP応答パケットのウヘッダフィールドに、Domain属性が付与されていない」
とあります。Cookieをブラウザに渡すヘッダは“Set-Cookie”なのでウ=Set-Cookieです。 -
VIPへ名前解決させる設定箇所として
「PCからsso.a-sha.example.jpへの認証リクエストの宛先がこのVIPアドレスとなるように、エサーバに設定を行った。」
と明記されています。名前解決を担当するのは“内部DNSサーバ”であるためエ=内部DNSです。 -
DSR方式ではバックエンドサーバにもVIPを持たせ、OSが自分宛パケットとして扱う必要があります。その際、実インタフェースに割り当てるとARP応答競合が起こるため、通常はARPを出さない“ループバックインタフェース”を使います。本文にも
「VIPアドレスを付与したオインタフェースをSSOサーバに設定することにした。」
とあるのでオ=ループバックです。
これらより模範解答は
ア:リバースプロキシ
イ:リダイレクト
ウ:Set-Cookie
エ:内部 DNS
オ:ループバック
ア:リバースプロキシ
イ:リダイレクト
ウ:Set-Cookie
エ:内部 DNS
オ:ループバック
誤りやすいポイント
- エージェント方式とリバースプロキシ方式の混同。どちらもSSO実現手段ですが、通信が必ずSSOサーバを経由するか否かが決定的な違いです。
- イを「フォワード」や「転送」と答えてしまう誤答。HTTPの“Location”ヘッダを伴うブラウザ側遷移はリダイレクトが正解です。
- Cookieヘッダの種類。送信時は“Cookie”、サーバ応答時は“Set-Cookie”である点に注意が必要です。
- DSRではVIPを実インタフェースに割り当てるとARP競合が発生するため、ループバック+ARP無効設定が定番対策になります。
- DNSを“DHCPサーバ”と誤解するケース。名前解決とIP配布は別機能です。
FAQ
Q: DSR方式を採用したのはなぜですか?
A: レイヤ4でNATを行わず応答はサーバから直接クライアントへ返すため、スループットが高くSSOサーバのSSL/TLS終端性能をフルに発揮できるからです。
A: レイヤ4でNATを行わず応答はサーバから直接クライアントへ返すため、スループットが高くSSOサーバのSSL/TLS終端性能をフルに発揮できるからです。
Q: CookieのDomain属性を設定しないと何が問題なのですか?
A: ブラウザはDomain属性がないCookieを発行サーバのFQDNにだけ送ります。本問では“sso.a-sha.example.jp”で発行されたCookieが“eigyou.a-sha.example.jp”へ送られず、チケット確認が失敗します。
A: ブラウザはDomain属性がないCookieを発行サーバのFQDNにだけ送ります。本問では“sso.a-sha.example.jp”で発行されたCookieが“eigyou.a-sha.example.jp”へ送られず、チケット確認が失敗します。
Q: SSL/TLS化すればCookieは必ず安全ですか?
A: 通信経路は暗号化できますが、盗用された端末内のCookieやXSSによる抜き取りは防げません。Secure属性とHttpOnly属性の併用が推奨されます。
A: 通信経路は暗号化できますが、盗用された端末内のCookieやXSSによる抜き取りは防げません。Secure属性とHttpOnly属性の併用が推奨されます。
関連キーワード: シングルサインオン, リバースプロキシ, リダイレクト, Cookie, DSR
設問2:
問題文を見る図2中の⑥で確認が行われるアクセスチケットは、PCに対して発行されたものである。PCはどの時点でアクセスチケットを得るかを、図2中の①〜⑦の番号で答えよ。
模範解答
⑤
解説
解答の論理構成
- 質問の主語は「アクセスチケットを得るPC」です。したがって、PCがCookie内にアクセスチケットを受け取るタイミングをシーケンス①〜⑦から探します。
- 【問題文】には次の記述があります。
⑤ SSOサーバは、UserIDとPasswordから利用者のアクセスの正当性を確認したら、アクセスチケットを発行して、Cookieに含めて応答を返す。
ここで「発行して」「Cookieに含めて応答を返す」と明記されています。PCはSSOサーバからの「応答」を受信する側なので、この時点で初めてアクセスチケットを保持します。 - 以上より、PCがアクセスチケットを得るのは図2の番号「⑤」です。
誤りやすいポイント
- ⑥と混同する
- ⑥は「Webアプリケーションサーバ内のエージェント」がSSOサーバへ確認要求を送るフェーズであり、PCは関与しません。
- ②でCookieを送出すると考える
- ②は「Cookieに認証済資格情報が含まれていなければ」リダイレクトされる場面です。まだアクセスチケットは存在していません。
- 「発行」と「確認」の区別
- ⑤が「発行」、⑥が「確認」です。動詞を意識すると取り違えを防げます。
FAQ
Q: アクセスチケットはどこに保存されますか?
A: 【問題文】「Cookieに含めて応答を返す」とあるとおり、PCのブラウザが保持するCookieに保存されます。
A: 【問題文】「Cookieに含めて応答を返す」とあるとおり、PCのブラウザが保持するCookieに保存されます。
Q: ④で資格情報を送った直後にチケットが発行されるのでは?
A: ④は送信のみで発行はまだ行われません。SSOサーバが受信・認証した後、⑤で発行しCookieに載せて返送します。
A: ④は送信のみで発行はまだ行われません。SSOサーバが受信・認証した後、⑤で発行しCookieに載せて返送します。
Q: ⑦ではCookieが再送信されていますか?
A: はい。PCは ⑤ で受け取ったCookieを保持しているため、その後のアクセス(⑦ など)で同じCookieを送信し、シングルサインオンが成立します。
A: はい。PCは ⑤ で受け取ったCookieを保持しているため、その後のアクセス(⑦ など)で同じCookieを送信し、シングルサインオンが成立します。
関連キーワード: Cookie, アクセスチケット, エージェント方式, リダイレクト, 認証シーケンス
設問3:〔SSOサーバの動作確認〕について、(1)、(2)に答えよ。
問題文を見る(1)本文中の下線(Ⅰ)で、CookieのDomain属性として設定した具体的なドメイン名を答えよ。
模範解答
a-sha.example.jp
解説
解答の論理構成
- 問題文は、CookieによるSSOが失敗した原因を「SSOサーバから送出されるHTTP応答パケットのウヘッダフィールドに、Domain属性が付与されていない」と述べています。
- Domain属性は、複数サブドメイン間でCookieを共有させるために設定します。
- 表1には以下のURLが示されています。
- 3つすべてのホスト名に共通し、かつサブドメイン部分(sso., eigyou., koukoku.)を除いた最上位の一致部分は「a-sha.example.jp」です。
- 従って、Cookieを3サーバ間で共有させるにはDomain属性に「a-sha.example.jp」を設定するのが妥当です。
- これにより、SSOサーバで発行したCookieが営業サーバ・広告サーバにも送信され、シーケンス⑤以降が正しく進行します。
- 以上から、(Ⅰ) で設定すべき具体的ドメイン名は「a-sha.example.jp」となります。
誤りやすいポイント
- 「.example.jp」までしか指定せず、サブドメインが広すぎて外部サイトにもCookieが送られる設定にしてしまう。
- 「sso.a-sha.example.jp」のように発行元ホストをそのまま指定し、営業サーバ・広告サーバにCookieが送信されずSSOが成立しなくなる。
- ハイフンを含む「a-sha」を「asha」などとタイプミスし、ドメインが一致しない。
FAQ
Q: Domain属性に先頭のドット「.a-sha.example.jp」を付ける必要はありますか?
A: RFC6265では先頭ドットの有無で動作は変わりません。設問は「具体的なドメイン名」を問うているので「a-sha.example.jp」で十分です。
A: RFC6265では先頭ドットの有無で動作は変わりません。設問は「具体的なドメイン名」を問うているので「a-sha.example.jp」で十分です。
Q: CookieのPath属性は変更しなくてもよいのですか?
A: 本問はドメイン間共有が課題であり、Pathは各Webアプリケーションのルート “/” で共通と仮定できます。Pathが相違しない限り追加設定は不要です。
A: 本問はドメイン間共有が課題であり、Pathは各Webアプリケーションのルート “/” で共通と仮定できます。Pathが相違しない限り追加設定は不要です。
Q: SSL/TLSを導入した際はSecure属性も必須ですか?
A: 設問中に「(Ⅱ)Cookieが平文でネットワークを流れないように…SSL/TLS対応ページに変更」とあるため、実装段階ではSecure属性を付加するのが推奨です。
A: 設問中に「(Ⅱ)Cookieが平文でネットワークを流れないように…SSL/TLS対応ページに変更」とあるため、実装段階ではSecure属性を付加するのが推奨です。
関連キーワード: Cookie, Domain属性, サブドメイン, シングルサインオン, RFC6265
設問3:〔SSOサーバの動作確認〕について、(1)、(2)に答えよ。
問題文を見る(2)本文中の下線(Ⅱ)について、その対策を行っても、予期しなかったコネクションを介して、WebブラウザからCookieが平文で、ネットワーク上に意図せず流れてしまう可能性がある。これを防ぐために、SSOサーバがCookieを発行するときに実施すべき方策を、25字以内で述べよ。
模範解答
CookieにSecure属性を付ける。
解説
解答の論理構成
- 本文では「(Ⅱ)Cookieが平文でネットワークを流れないように、表1中のサーバから返される全てのページをSSL/TLS対応ページに変更した」と対策を実施しています。
- しかしHTTPS化だけでは、ユーザが誤ってHTTPでアクセスした場合や内部でリダイレクトが発生した場合に、ブラウザがCookieを自動送信し、再び「平文でネットワークを流れ」る恐れがあります。
- これを防ぐには、ブラウザ側に「このCookieは暗号化通信 (HTTPS) でしか送信してはいけない」という制約を与える必要があります。
- Cookieにその制約を与える標準的手段が、HTTP応答ヘッダ “Set-Cookie” に「Secure」属性を付加することです。
- したがって、SSOサーバがCookieを発行するときに実施すべき方策は「CookieにSecure属性を付ける」となります。
誤りやすいポイント
- HTTPS化だけで十分だと考え、「Secure属性」を失念する。HTTPでの誤アクセス時に漏えいリスクが残る点を見逃しやすいです。
- 「HttpOnly属性」と混同し、JavaScriptからの盗難対策と勘違いする。設問は通信路上の平文漏えいを問題にしています。
- サーバ側でHTTPポートを閉じれば良いと安易に判断し、実運用で発生するリダイレクトや外部リンク経由のアクセスを考慮しない。
FAQ
Q: Secure属性を付けてもブラウザは必ずHTTPSだけで送信しますか?
A: はい。Secure付きCookieはブラウザ仕様によりHTTPSでしか送信されません。HTTPでのリクエスト時には自動的に付与されないため漏えいが防げます。
A: はい。Secure付きCookieはブラウザ仕様によりHTTPSでしか送信されません。HTTPでのリクエスト時には自動的に付与されないため漏えいが防げます。
Q: HttpOnly属性も合わせて設定すべきですか?
A: JavaScriptによる盗難対策として有効ですが、今回の設問は“平文で流れる”ことへの対策が主題なので、Secure属性が必須事項です。
A: JavaScriptによる盗難対策として有効ですが、今回の設問は“平文で流れる”ことへの対策が主題なので、Secure属性が必須事項です。
Q: サイト全体をHTTPSにリダイレクトすれば漏えいしませんか?
A: リダイレクト前の最初のHTTPリクエストにCookieが付いてしまう可能性があります。Secure属性でブラウザ側を縛ることが確実です。
A: リダイレクト前の最初のHTTPリクエストにCookieが付いてしまう可能性があります。Secure属性でブラウザ側を縛ることが確実です。
関連キーワード: Secure属性, HTTPS, Cookie, セッション管理, 暗号化通信
設問4:〔負荷分散に関する設定と動作確認〕について、(1)〜(3)に答えよ。
問題文を見る(1)本文中の下線(Ⅲ)の理由を、30字以内で述べよ。
模範解答
SYNパケットにはレイヤ7情報が含まれていないから
解説
解答の論理構成
- 問題文では、DSR方式のLBの動作要点として
「(2) 振り分け先については、TCPコネクション確立のためのSYNパケットがPCから届いた時点で、決定される。」
と明示しています。 - SYNパケットはTCPヘッダしか持たず、HTTPヘッダのようなアプリケーション層(レイヤ7)の情報は搭載しません。
- したがって、LBは「Cookieなどのレイヤ7の情報」を受け取る前に振り分け先を決めてしまうため、
問題文の下線部(Ⅲ)で示された「Cookieなどのレイヤ7の情報を基にして振り分け先サーバを選定するような方式には対応できない」となります。 - 以上より、理由は「SYNパケットにはレイヤ7情報が含まれていないから」となります。
誤りやすいポイント
- SYNパケットにHTTPヘッダが載ると誤解し、L7情報も取得可能と考えてしまう。
- DSR方式でも後続パケットで再判定できると想定し、初期SYNでの固定を見落とす。
- Cookie自体がTLSで暗号化されればLBも読めると混同し、層の違いを意識しない。
FAQ
Q: DSR方式でもHTTPヘッダを基に振り分けるロードバランサはありますか?
A: DSRは基本的にL4ロードバランスです。L7振り分けを行う場合はNAT方式やリバースプロキシ方式が用いられます。
A: DSRは基本的にL4ロードバランスです。L7振り分けを行う場合はNAT方式やリバースプロキシ方式が用いられます。
Q: TLS終端をLBで行えばCookieベースの振り分けは可能ですか?
A: LBでTLS終端すればHTTPヘッダを解釈できますが、その場合は「DSR方式」ではなく「リバースプロキシ方式」など別方式になります。
A: LBでTLS終端すればHTTPヘッダを解釈できますが、その場合は「DSR方式」ではなく「リバースプロキシ方式」など別方式になります。
Q: SYNパケット後のACK以降で振り分けを変更する実装はありますか?
A: 一部の高度な製品にはありますが、問題文のDSR方式ではSYN受信時に振り分けを固定する前提です。
A: 一部の高度な製品にはありますが、問題文のDSR方式ではSYN受信時に振り分けを固定する前提です。
関連キーワード: DSR方式, SYN, レイヤ7, Cookie, 負荷分散
設問4:〔負荷分散に関する設定と動作確認〕について、(1)〜(3)に答えよ。
問題文を見る(2)本文中の下線(Ⅳ)で、IPアドレス重複エラー検知に用いられるARPの名称を答えよ。
模範解答
Gratuitous ARP又は GARP
解説
解答の導き方
設問は本文中の下線(Ⅳ)「IPアドレス重複エラーが検知された」に関して、その重複検出に用いられるARPの名称を答えることです。本文の状況とAR Pの動作を順を追って考えると答えに到達できます。
-
事象の確認
本文では「VIPアドレスを付与したオインタフェースをSSOサーバに設定した後にLBを再起動したところ、(IV)IPアドレス重複エラーが検知された」とあります。つまり、インタフェースにIP(VIP)を割り当てた直後か、ネットワーク上でそのIPに関して通知・確認が行われ、重複が検出されたことが分かります。 -
重複検出に使われる仕組みの把握
ネットワークで「自分のIPアドレスの存在を他に通知し、同一IPの使用有無を確認する」ために送られる無要求のARPがあり、これが重複検出に用いられます。一般にこの無要求のARPは「Gratuitous ARP」と呼ばれます。 -
動作の具体例(本文の構成に対応させて)
- SSOサーバがVIPを付与したインタフェースを立ち上げると、通常そのホストは自発的に無要求のARPを送信してネットワークに「このIPは自分のものです」と通知します。
- 既に同じVIPを別の装置(ここではLBや別のサーバ)が宣言していると、これに対する応答や別のARPメッセージにより重複が明らかになり、OSやネットワークスタックが「IPアドレス重複エラー」を検知します。
- 以上の動作は本文の「(IV)IPアドレス重複エラーが検知された」「(V)SSOサーバにARP関連の設定を加えて対処した」と整合します。
-
用語の明示(解答)
この用途に使われるARPは「Gratuitous ARP又はGARP」です。 -
実装差の注意点(重要)
Gratuitous ARPは「自発的(無要求)のARP」を指しますが、実装によって挙動は異なります。具体的には、送信側が自分のIPを送信元・宛先ともに設定したARP要求(送信元IP=宛先IP)で送る実装や、送信側が自分のIPを送信元にしたARP応答をブロードキャストする実装のいずれもあり得ます。いずれの形式でも目的は「自分のIPを通知し、同一IPの存在を検出する」ことです。
以上の流れから、本文の状況に対して適切な名称はGratuitous ARP又はGARPであると導けます。
誤りやすいポイント
- GARPは「ARP要求でも応答でもない」と断定する誤り。実装により要求形式または応答形式のどちらでも送られるため、どちらとも断定しないこと。
- GARPとARPプローブを混同する誤り。ARPプローブ(アドレス取得前の確認)とGARP(既に割り当てたIPの通知)は目的や送信時の挙動が異なる。
- 重複検知を必ずスイッチ(L2機器)が行うと考える誤り。多くはホスト側(OS)のARP処理で検出・警告される。
- DSR構成なのでサーバ側はVIPに無関係だと誤解する点。DSRではサーバ側でもVIPを扱う(受信する)ため、サーバ側でもVIPに関するARP通知や検出が必要になる。
FAQ
Q: GARPを受信した側は必ず競合(重複)と判断しますか?
A: いいえ。受信側の挙動は実装依存です。既にそのIPを自身で持っており、かつ送信元MACが異なれば重複と判断して警告することが多いですが、単にARPキャッシュを更新する実装もあります。
A: いいえ。受信側の挙動は実装依存です。既にそのIPを自身で持っており、かつ送信元MACが異なれば重複と判断して警告することが多いですが、単にARPキャッシュを更新する実装もあります。
Q: ARPプローブとはどう違いますか?
A: ARPプローブは新しく使おうとするアドレスが空いているかを確認する目的で送るパケットで、Zero-configurationや一部の自動設定で用いられます。GARPは既に割り当てたIPの存在を通知・周知するために送る点で目的が異なります。
A: ARPプローブは新しく使おうとするアドレスが空いているかを確認する目的で送るパケットで、Zero-configurationや一部の自動設定で用いられます。GARPは既に割り当てたIPの存在を通知・周知するために送る点で目的が異なります。
Q: 本文の「SSOサーバにARP関連の設定を加えて対処した」は具体的にどんな対処ですか?
A: 代表的な対処例としては、サーバのARP応答の振る舞いを制御する(例:OSのarp_announce/arp_ignore等の設定変更)ことで、VIPを付与した際に誤検出や不必要な応答を抑える方法があります。問題文の記述と一致する一般的な対処です。
A: 代表的な対処例としては、サーバのARP応答の振る舞いを制御する(例:OSのarp_announce/arp_ignore等の設定変更)ことで、VIPを付与した際に誤検出や不必要な応答を抑える方法があります。問題文の記述と一致する一般的な対処です。
関連キーワード: Gratuitous ARP、ARPプローブ、ARPキャッシュ、VIP、DSR
設問4:〔負荷分散に関する設定と動作確認〕について、(1)〜(3)に答えよ。
問題文を見る(3)本文中の下線(Ⅴ)の対処について、SSOサーバに対してどのような設定を行ったか。40字以内で述べよ。
模範解答
VIPアドレスに対するARPリクエストに応答しないように設定する。
解説
解答の論理構成
- DSR方式ではVIPを 「LB」 が外部に提示し、実サーバはMACアドレスを公開しないのが前提です。本文には
「要点(3)の動作から、『SSOサーバは、自IPアドレスと異なるVIPアドレス宛てのパケットを受信しなければならない』」
とあります。 - そのためC氏は 「VIPアドレスを付与した…インタフェースをSSOサーバに設定」 しましたが、LB再起動後に
「(IV)IPアドレス重複エラーが検知された」。 - 重複の典型的原因は、VIPに対するARP要請にLBとSSOサーバの両方が応答してしまうことです。本文も
「SSOサーバにARP関連の設定を加えて対処した」
と明示しています。 - よって解決策は、SSOサーバ側でVIPのARP応答を抑止し、LBのみがVIPのMACを返すようにすることになります。
- 以上から、「VIPアドレスに対するARPリクエストに応答しないように設定する」が求められる設定です。
誤りやすいポイント
- 「IPアドレス重複エラー」から 静的ARPエントリ を連想し、LB側設定と誤解する。実際はSSOサーバの沈黙が解になります。
- ループバック/仮想NICをVIPに設定しただけで満足し、ARP抑止を忘れる。
- DSRを NAT型ロードバランサ と混同し、「ARPはLBが全部代行する」と早合点する。
FAQ
Q: ARP応答を止めてもSSOサーバはVIP宛てパケットを受信できますか?
A: はい。DSRではロードバランサがL2内で宛先MACを実サーバのMACに書き換えるため、ARP応答が不要でも届きます。
A: はい。DSRではロードバランサがL2内で宛先MACを実サーバのMACに書き換えるため、ARP応答が不要でも届きます。
Q: ARP応答抑止はOS依存ですか?
A: 依存します。Linuxならarp_ignore=1 arp_announce=2など、Windowsならnetsh interface ipv4 set interface unicastrespond=disabledなどの方法があります。
A: 依存します。Linuxならarp_ignore=1 arp_announce=2など、Windowsならnetsh interface ipv4 set interface unicastrespond=disabledなどの方法があります。
Q: VIPへのICMP Echo要求にSSOサーバは応答しますか?
A: ARPを遮断するとMACアドレスが得られないため届きません。運用監視はLB宛てに実施するのが一般的です。
A: ARPを遮断するとMACアドレスが得られないため届きません。運用監視はLB宛てに実施するのが一般的です。
関連キーワード: DSR, VIP, ARP, 負荷分散, Cookie




