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

解答の論理構成

1. 事前情報
   • 問題文には「A社DNSサーバに、RDATAにIP-w1を設定したAレコードを登録する方式と、RDATAにT社WAFサービスのFQDNを設定したCNAMEレコードを登録する方式がある。」とあります。
   • さらに「T社は、IP-w1を変更する場合があるので、①CNAMEレコードを登録する方式を推奨している。」と明示されています。
2. IPアドレス変更の影響
   • Aレコード採用時はDNSに直接「IP-w1」を書くため、T社がIPを変更するとA社側でも書き換えが必要になります。
   • 一方、CNAME方式ではA社DNSにはFQDNだけを置き、実際のIP解決はT社側のDNSに委ねられます。
3. 導かれる利点
   • したがって、T社が「IP-w1」を変更してもA社DNSの設定はそのままでよく、運用作業が発生しません。
4. まとめ
   • 上記から模範解答「T社がIP-w1を変更しても、A社DNSサーバの変更作業が不要となる。」が導かれます。

誤りやすいポイント

• 「CNAMEは参照先のFQDNが変わらない限り効果がない」と思い込み、IP変更時の運用削減効果を見落とす。
• 「AレコードでもTTLを短くすれば問題ない」と考え、恒常的な設定変更作業コストを軽視する。
• 「CNAMEは名前解決回数が増える＝デメリット」とだけ捉え、本問の“運用面での利点”を答え忘れる。

FAQ

解答の論理構成

• 1. [ア]
  • 問題文では「HTTPリクエストをWebサーバ ア に振り分けるラウンドロビン方式」とあります。
  • ラウンドロビン方式はWebサーバを“順番”に回して割り当てる代表的な方式です。
  • よって [ア] は「順番」です。
• 1. [イ]
  • 「LBとWebサーバ間の通信にHTTPを用い、ポート番号にHTTPのウェルノウンポート番号を用いることにした」と明記されています。
  • HTTPのウェルノウンポート番号は80です。
  • よって [イ] は「80」です。
• 1. [ウ]
  • 表1では「成功時のHTTPレスポンス」を指定させています。
  • Webサーバが正常応答する場合、HTTP的にはステータスコード200（OK）が一般的です。
  • よって [ウ] は「200」です。
• 1. [エ]
  • 問題文は「LBは、HTTPレスポンスのエヘッダフィールドにセッションIDを追加する」と記載。
  • HTTPレスポンスでブラウザへCookieを渡す標準ヘッダは “Set-Cookie” です。
  • よって [エ] は「Set-Cookie」です。
• 1. [オ]
  • 「HTTPレスポンスを受け取った利用者のWebブラウザは、エヘッダフィールドにあるセッションIDを、次に送信するHTTPリクエストのオヘッダフィールドに追加する」との記述。
  • ブラウザはCookieを次回リクエストの “Cookie” ヘッダに入れて送出します。
  • よって [オ] は「Cookie」です。

誤りやすいポイント

• ラウンドロビン＝“負荷均等”と連想し「均等」などと書いてしまう誤答が多いです。ラウンドロビンのキーワードは“順番”。
• 死活監視のポート番号を443と勘違いするケース。問題文に「HTTPを用い」とあり、TLSアクセラレーションでHTTPSは終端されている点を見落とさないこと。
• ステータスコードを302や304とする誤り。成功（OK）は200が基本。
• Cookieヘッダの方向性を混同し、Set-CookieとCookieを入れ替えるミスに注意。

FAQ

解答の論理構成

1. 【問題文】には、セッション維持機能の候補として
   ― “HTTPリクエストの送信元IPアドレスに基づいて行う方法”
   ― “LBによって生成されるセッションIDに基づいて行う方法”
   が示されています。
2. しかしWAF導入後は、
   “WAFサービスは、HTTPリクエストの送信元IPアドレスを…IP-w2に変更する。”
   とあるため、LBに到着するすべての通信の送信元IPは IP-w2で共通になります。
3. 送信元IPベースでセッション維持を行うと、LBは “同じ送信元IPの要求は同じWebサーバへ” と判断します。よって IP-w2に見える全ユーザのトラフィックが1台に集中してしまいます。
4. その結果、特定サーバにのみ処理が偏り、他サーバとの間でロードバランスが取れません。
5. したがって、送信元IP方式を採った場合に懸念される問題は「負荷が偏る」となります。

誤りやすいポイント

• “ラウンドロビンを使うから大丈夫” と考え、セッション維持設定の影響を見落とす。
• “IP-w2は複数あるのでは” と勘違いし、同一IPで固定される点を読み飛ばす。
• “X-Forwarded-Forに本来のIPが入るから問題ない” と早合点し、LBが参照するIPは変わらない事実を取り違える。

FAQ

解答の論理構成

• 【問題文】には、LBの機能として
  「HTTPヘッダの編集（追加、変更、削除）機能をもっている」
  と明記されています。
• さらにTLSアクセラレーション利用理由の一つとして
  「③LBが行うある処理のために、TLSアクセラレーション機能を利用することにした」
  と述べられています。
• 暗号化されたHTTPS通信では、ヘッダを編集するにはいったん復号が必要です。TLSアクセラレーションは復号／再暗号化を高速化する機能なので、対応する “ある処理” は「HTTPヘッダ編集」と判断できます。
• 以上より、③に入る内容は
  「HTTPヘッダを編集する処理」
  となります。

誤りやすいポイント

• TLSアクセラレーション＝暗号化処理高速化とだけ考え、ヘッダ編集との関係を見落とす。
• 死活監視やセッション維持の処理と誤って結び付けてしまう。
• 「HTTPヘッダ追加」や「HTTPヘッダ変更」のように限定的に書き、設問の「ある処理」の範囲を外してしまう。

FAQ

解答の論理構成

1. まず本文には、WAF経由運用時に行ったFWの設定変更として
   「FWに設定しているWebシステムへのHTTPS通信に関するアクセス制御について、IP-w2を送信元とする通信だけを許可するように、設定を変更することにした。」
   とあります。ここでFWがHTTPSの許可／遮断を制御していることが明示されています。
2. 次にWAFを長期間利用できなくなった場合の対策として
   「WAFサービスを経由せずに…直接通信させるために、WAFサービス導入時に設定変更を予定しているカの④設定を変更する」
   と記載されています。
   直接通信させるには、送信元がWAF（IP-w2）ではなく利用者各自のIPになるため、FWの「送信元IP制限」を元に戻す必要があります。
3. したがって カ に入る機器は、HTTPS通信をフィルタリングしている「FW」です。
4. 下線④で求められる具体的な変更内容は、先の制限を解除し
   「任意のIPアドレスからWebシステムへのHTTPS通信を許可する」
   ことになります。これでWAFを介さない通常のHTTPSアクセスが成立します。

誤りやすいポイント

• 「LBにもアクセス制御機能があるのでは」と考えて カ をLBとしてしまう。本文でアクセス制御を担当しているのはFWである点を見落としやすいです。
• ④の設定変更を「IP-w1を許可」などDNS側の操作と勘違いするケース。実際にはFWルールの送信元条件を“Any”に戻す作業です。
• 「HTTPS以外も許可する」と解釈してしまう。問題文は「WebシステムへのHTTPS通信に関するアクセス制御」と限定しているため、対象プロトコルは変わりません。

FAQ

解答の論理構成

1. 初期状態の資源レコード
   図2には【問題文】「shop IN CNAME waf-asha.tsha.net.」とあります。これは通常時、shop.asha.comへの問い合わせをT社のWAFへ転送するための設定です。
2. WAFが1日以上停止した場合の方針
   【問題文】「WAFサービス停止期間中も、オンラインショップでの商品販売を継続させたい。」
   → WAFを経由せず、直接Webシステム（LB）へ到達させる必要があります。
3. DNSで切替える対象
   【問題文】「⑤資源レコードの1行を書き換えることで対応できる」とあるため、shop.asha.comに関する行のみを書き換えます。
4. 直接接続時に示すべき宛先
   構成変更後の図3より、利用者が直接アクセスするLBのグローバルIPは【問題文】「199.α.β.2」です。
5. 必要なレコード種別
   ・CNAMEは “別の名前” を指し示すレコードであり、今回はFQDNではなくIPアドレスを返す必要があります。
   ・IPアドレスを返すレコード種別はAレコードです。
6. したがって書換え後の資源レコードは
   shop IN A 199.α.β.2
   となります。

誤りやすいポイント

• CNAMEのままIPアドレスを設定してしまう
  CNAMEは必ずFQDNを指定します。IPアドレスを記述すると仕様違反です。
• 末尾のドットを忘れる／付ける場所を誤る
  FQDNを書く場合は末尾のドットが要りますが、今回はAレコードなので不要です。
• TTLや $ORIGINを一緒に書き換えてしまう
  指定は「⑤資源レコードの1行」だけです。他の行を変更すると不具合の原因になります。
• AAAAレコードを追加してしまう
  既存システムがIPv4で運用されているため、IPv6用のAAAAを追加すると接続できない利用者が出る恐れがあります。

FAQ

解答の論理構成

1. 送信元IPをログに残す要件
   • 問題文より引用
     「現行のWebAPでは、Webシステムへのアクセス時の送信元IPアドレスをアクセスログに記録している。」
     「Uさんは、送信元IPアドレスの代りにXFFヘッダの情報を記録するように、WebAPの設定を変更することにした。」
     ⇒ 今後はWebAPがXFFヘッダ を参照してログを取る。
2. WAFが存在する場合
   • WAFの動作
     「WAFサービスは、アクセスを許可したHTTPリクエストの送信元IPアドレスを、HTTPヘッダのX-Forwarded-Forヘッダフィールド（以下、XFFヘッダという）に追加する…」
     ⇒ WAF経由時は自動的にXFFヘッダ が付与されるのでWebAPは問題なく記録できる。
3. WAFをバイパスする場合
   • 対応方針
     「Uさんは、WebAPのアクセスログについて、WAFサービスの有無にかかわらず、XFFヘッダの情報からWebシステムへのアクセス時の送信元IPアドレスを記録することとし、⑥LBに設定を追加した。」
     ⇒ WAFがない経路では誰もXFFヘッダ を付けないため、LBが代わりに付与する必要がある。
4. LBの機能確認
   • 「LBは… HTTPヘッダの編集（追加、変更、削除）機能をもっている。」
     ⇒ LBはヘッダ追加が可能。WAFバイパス時でも要件を満たせる。
5. 結論
   • したがって ⑥ の設定は
     「XFFヘッダに送信元IPアドレスを追加する設定」
     となる。

誤りやすいポイント

• 「WAFが無い＝XFFヘッダ不要」と勘違いし、LBの設定を忘れる。WebAPはXFFしか見ないのでログが空になる。
• XFFヘッダの“追記”と“置換”を混同し、既にWAFが付けた情報を上書きしてしまうケース。
• 送信元IPを別ヘッダ（例: Via）に入れると誤解しやすいが、問題文は明確に「XFFヘッダ」と指定している。

FAQ