ネットワークスペシャリスト 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