令和6年（2024年）ネスペ午後Ⅰ　問Ⅲ　解答解説

設問１

（１）ア：ハブアンドスポーク

これは知識問題なので覚えておこう！

（５）インタフェースにIPアドレス割り当てを行わない設定

IP Unnumberedは、文字通り「番号（IPアドレス）を割り当てない（Unnumbered）」技術のこと。通常、ルーターのポートや仮想インターフェース（Tunnel0 など）には、個別にIPアドレスを設定して通信を行う。しかし、1対1で直結されているトンネル接続などの場合、「わざわざトンネル専用のIPアドレスを消費するのはもったいない」という問題が生じる。そこで、既存のインターフェース（LAN側やWAN側など）のIPアドレスを流用することで、トンネルインターフェース自体には個別のIPアドレスを割り当てずに通信を可能にする設定が IP Unnumbered です。

Q.ルーティング設定はどうなるの？

A.インタフェースを指定する。トンネルを通るルーティングをトンネルIPアドレスを指定するのではなく、トンネルインタフェースを指定する。そうすることによって、IPに依存したルーティングから脱却できる。

ShellScript
#旧来（トンネルIPアドレスで指定）
ip route 相手WAN側IP 255.255.255.0 トンネルIP

#現在(トンネルインタフェースで指定）
ip route 相手WAN側IP 255.255.255.0 Tunnel 0
ShellScript
interface Tunnel0
 ip unnumbered GigabitEthernet0/0  ! LAN側などのIPを流用し、Tunnel自体にはIPを割り当てない
 tunnel source GigabitEthernet0/0
 tunnel destination 200.2.2.2
 tunnel mode ipip

Q.IP UnnumberedとNumberedの違いは？

方式メリットデメリット（なぜ全員が使わないか）
Numbered
（IPアドレスを割り当てる）		・Pingによる障害切り分けが超簡単
・動的ルーティング（OSPF等）が素直に動く		・トンネル用のIPアドレス空間（/30など）を消費する
IP Unnumbered
（IPアドレスを割り当てない）		・IPアドレスの無駄遣いをゼロにできる
・IP設計の手間が省ける		・Ping等での対向トンネル自体の監視・切り分けがしづらい
・1対1の接続でしか使えない

Q.Unnumberedだと障害切り分けが難しくなるというけどなぜ？

A.pingに応答する機器に制限があると絞り込みができないから。
正直、内部LANに配置されているPCやサーバすべてが常にpingを返す設定であれば、トンネルにIPを割り当てなくても、「拠点A内部LAN機器→拠点B内部LAN機器」の区間をpingすればトンネル障害であるか否かは判断できる。
しかし、pingを返す機器がサーバ１台だけの場合、もし「拠点A内部LAN機器→拠点B内部LANサーバ」をやって、通信失敗が起きてもそれがサーバ側の問題なのか、トンネルの問題なのか、拠点B内部LANルーティングの問題なのか切り分けられなくなる。
しかし、Numbered設定でトンネルIPも設定していれば「拠点AルータトンネルIP→拠点BルータトンネルIP」とピンポンとでトンネルを指定して、疎通を確認することができる。これによって、トンネル障害が否かを一発で判断できるようになる。
▼具体的な切り分け手順

ステップ実行するテスト（Ping等の対象）成功（クリア）時に確定すること失敗（NG）時の原因と次のアクション
Step 1WAN側IP ➔ 対向WAN側IPインターネット回線（物理層〜L3）は正常・物理回線障害、プロバイダ障害
・WAN側のルーティングミス
➔ VPN以前の通信経路（WAN側）を復旧する
Step 2トンネルIP ➔ 対向トンネルIP
(※Numbered構成のみ可能)		VPNトンネル（IPsec / カプセル化）は正常・IPsecの鍵不一致、SAセッション切れ
・トンネル設定ミス
➔ ルーターのVPN設定・ログを確認する
Step 3LAN側IP ➔ 対向LAN側IP
(Webサーバー宛て)		ネットワーク全般（L1〜L3）は100%正常・Webサーバー自体のダウン
・WebサーバーのFWによる拒否
・拠点B内部のルーティング/L2障害
➔ サーバー本体・アプリケーション層を調査する

（6）転送負荷の増大

UTMでIPフラグメント化を強いられるということは、「①パケットの分割②そのパケットに１つずつIPsec処理」といったように処理負荷が増大することが分かる。
もし、MSSクランピングなどを導入していたら「パケットにIPsec処理」のみで完結できるため処理負荷を抑えられる。

設問２

（５）　UTMプロキシサーバのFQDNがことなるから

図４のPACファイルを見ると、proxy.osaka.a-sha.jp:8080と大阪支社特有のFQDNが指定されていることが分かる。そのため、ほかの支社でも正常に動作させるにはこの部分を各支社のFQDNに直す必要がある。つまり、UTMプロキシサーバのFQDNが支社ごとに異なるためPACファイルも支社ごとに作る必要があるということ。

設問３

（１）　イ：DHCP　ウ：DNS　エ：HTTP　オ：URL

イ：DHCP　ウ：DNS
WPADにはDHCPとDNS方式がある。（詳しくはこちら）

エ：HTTP
　WPADではPACファイルの格納場所をDHCPやDNSを使って判明させる。そのサーバにはHTTPを使ってアクセスするのが基本なので、ここにはHTTPが入る。
また、HTTPサーバよりもWebサーバの方が聞き覚えがあるが、Webはプロトコルではないので空欄エにはHTTPが入る。

オ：URL

WPADを無効にした場合にはどのようにPACファイルを取得するかが問われている。まずは、WPADのデメリットを見ていこう！

Q.WPADのデメリットは？

A.WPADのメリットでもある動的な配布は一歩間違えるとデメリットにもなる。「動的」とういことは管理者が関与しない部分が生まれるということ。そのため、そこの隙をついた攻撃が生まれてしまう。
なので、今回の場合は、そのような隙を作るよりもあらかじめスタティックにURLを指定しておこうよねということである。

Q.URLではなくFQDNを指定するのはだめなの？

FQDNをスタティックに指定しても一見動作しそうだが、実際は動作しない。まず、WPADのDNS方式では、WPADのプログラムが「ドメインに.wpad.datをつけて名前解決」したり「URLを動的に生成してhttp://[取得したIP]/wpad.datにアクセス」したりとプログラムがURLを作ってくれた。
一方WPADを使わないとプログラムは動作しないので、FQDNだけ指定しても、名前解決もしなければ、そこからURLを作りだすということもできない。
なので、FQDNではなくURLを最初からハードコーディングしている。

（２）　不正なプロキシサーバに中継される

この問題は、悪意のあるDNSサーバやDHCPサーバがあるとどのような問題があるかを聞かれている。結論から言うと、偽のプロキシサーバに中継してしまい、内部情報の漏洩や通信障害を引き起こしてしまうことが発生する。では、以下で攻撃のフローを見ていこう！

▼攻撃フロー

  1. 攻撃の起点（偽DNS / 偽DHCP）
    • ネットワーク内に「悪意のあるDNSサーバー」や「悪意のあるDHCPサーバー」が存在すると、PCに対して偽のPACファイル置き場（URL）を掴ませることができる。
  2. 偽PACファイルの取得
    • PCは自動検出によって、攻撃者が用意した偽のPACファイルをダウンロードする。
  3. 攻撃者のプロキシへ誘導（Man-in-the-Middle / MITM攻撃）
    • 偽PACファイルには「すべての通信は proxy.attacker.example:8080（攻撃者のプロキシ）を通せ」と書かれている。
  4. 被害（情報漏えい・盗聴・通信遮断）
    • PCの通信がすべて「不正なプロキシサーバーに中継される」状態になり、通信内容の盗聴・改ざん（中間者攻撃：Man-in-the-Middle）や、重要情報の漏えい、あるいは通信妨害といった重大なセキュリティ被害が発生する。

さらに深いVersion………………………………

p.16 UTMってなに？ｰｰｰｰｰｰｰｰｰｰｰｰｰｰ

UTMはUnified Threat Management（統合脅威管理）の略。イメージとしては「セキュリティ機能満載の多機能オールインワンルーター（または多機能ファイアウォール）という感じ。昔は別々の専用機器（FW装置、IPS装置、VPNルーター、Webプロキシなど）で構築されていた機能を１台にまとめたものがUTM。

▼UTMの機能
・ファイアウォール（アクセス制限）
・NAT / NAPT（IPアドレス・ポート変換機能。ルーターとしての役割）
・IPS/IDS（不正侵入検知・防御）
・アンチウイルス / アンチスパム（通信内のウイルスチェック）
・Webフィルタリング（危険なサイトや業務無関係なサイトへのアクセスブロック）
・VPNゲートウェイ（拠点間を暗号化してつなぐ機能。今回の問題でも使われる）
・Webプロキシ（プロキシサーバとして動作可能）

p.17 プロキシサーバのログ取得———-

▼プロキシサーバが記録する情報

  • アクセス日時（時刻）
  • 送信元IPアドレス（アクセスしてきたPCのIP）
  • 宛先情報（アクセス先のURLやFQDN、ポート番号など）

これだけで、よさそうだがプロキシサーバのログだけでは不十分なのでDHCPのログも取得しておく必要がある。なぜなら、IPアドレスは変動するものなので、その時間に誰がそのIPアドレスを使っていたかを特定する必要がある。

▼DHCPサーバが記録する情報

  • DHCPサーバ側で「どのMACアドレス（端末）に、いつからいつまで、どのIPアドレスを割り当てたか」のログを保持。
  • プロキシログの「日時＋IPアドレス」と照合することで、後から「どの端末（誰）がアクセスしたか」を正確に特定する。

p.17 IP in IPってなに？

IP in IPとは、通常のIPパケットに、新たなIPヘッダでカプセル化することにより、元のIPパケットをペイロードとして扱える技術。

Q.何がメリット？

A.内部情報を変更せずに相手の内部LAN内の機器にアクセスできるようになる。

Q.IP in IPではなく、NAT/NAPTを使ったら？

A.送信側がNAT/NAPTを使うと、送信元IPアドレスが外部IPに変わってしまう。NATすると、送信元IPがすべて「ルーターのIP」に上書きされる。受信側のサーバーは「社内のどの端末（誰）がアクセスしてきたのか」をログやアクセス制御（「営業部だけ許可」など）で判別・制御できなくなる。逆に、受信側がNAT/NAPTをすると、内部LAN内のサーバに対応した外部IPを公開することになるので、外部から簡単にアクセスできるようになってしまう。

Q.IP in IPとGREの違いは？

比較項目IP-in-IP（IPIP）GRE（Generic Routing Encapsulation）
標準規格 (RFC)RFC 2003RFC 2784 / RFC 2890
プロトコル番号4 (IPv4-in-IPv4)47
運べるパケット（中身）IPv4 のみIPv6、マルチキャスト、Ethernet（L2）等
ヘッダーサイズ外側IP（20B）のみで軽量外側IP（20B）＋ GREヘッダー（4〜16B）
データ整合性チェックなし（上層プロトコルに依存）あり（オプションのチェックサム機能）
パケット順序制御なしあり（オプションのシーケンス番号）
主な用途・メリットIPv4通信のオーバーヘッド最小化、IPsecとの組み合わせ動的ルーティング（OSPF等）の通過、マルチプロトコルカプセル化

IP-IP over IPsecとは？

IP-IP over IPsecとは、IP-in-IPでパケットをカプセル化（トンネル化）し、それをIPsecで暗号化して安全に通信する拠点間VPN技術のこと。

ShellScript
#! 1. Phase 1 設定 (ISAKMP / IKEv1 ポリシー & 事前共有鍵)
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
exit

#対向ルーターのWAN IPと事前共有鍵（パスワード）を設定
crypto isakmp key secret123 address 200.2.2.2


#! 2. Phase 2 設定 (Transform Set & モード指定)
crypto ipsec transform-set MY_TS esp-aes 256 esp-sha256-hmac
 mode transport
exit


#! 3. IPsec プロファイルの作成 (ここが疑問だった箇所です)
crypto ipsec profile MY_PROFILE
 set transform-set MY_TS
exit


#! 4. トンネルインターフェース作成 & IPsec適用
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 200.2.2.2
 tunnel mode ipip   ! ※GREの場合は「tunnel mode gre ip」（デフォルト）
 
 #! 作成した IPsec プロファイルをトンネルに適用
 tunnel protection ipsec profile MY_PROFILE
exit

Q. IPフラグメントって何？——-

IPフラグメントとは、パケットのサイズ（IPヘッダーを含む全体の長さ）が、通過する経路の物理ポートの限界値（MTU：Maximum Transmission Unit）を超えたときに、途中のルーターがパケットを小さく分割して送出する処理のこと。

Q.IPフラグメントのデメリットは？

A.大きく以下👇の３つがある。
デメリット①：途中のルータに負荷がかかる。
　経路途中のルータでフラグメント処理を強いられると、負荷がかかる。
デメリット②：1個でも破棄されると「全体が再送」になる（非効率）
　IPフラグメントで分割されたパケットは、受信側の端末（PCやサーバ）に届くまで元に戻せない。 もし分割された3つのうち1つでも途中でドロップ（パケットロスト）すると、受信端末は再構築できず、元の大きなパケット全体を最初から再送（TCP再送）させることになる。
デメリット③：パケットの到着順序が入れ替わるとドロップしやすい
　分割されたパケットが別々のルートを通って到着順序がバラバラになると、受信側での復元処理（リアセンブル）が失敗しやすくなる。

Q.IPフラグメントを防ぐ方法は？

A.MSSクランピングとPMTUDが代表的な解決方法。
・MSSクランピング：
　TCP通信の開始時（3ウェイ・ハンドシェイク時）に、端末同士が「一度に送信できる最大データサイズ（MSS）」を宣言し合う。ルーターがその宣言をのぞき見して書き換える。「SYNパケット」を通過する際にMSSの値を勝手に小さく書き換える（クランプする）ことで、送信元PCに最初から小さいパケットを作らせる。
・Path MTU Discovery：
　端末自身が、宛先までの経路上で「最小のMTU」を自動で調べる仕組み。

Q.WPADとは？—–

WPADとはWebProxyAuto-Discovery Protocolの略。一言で言うと、「PC（ブラウザ）にPACファイルの置き場所を自動で見つけさせる仕組み」。

Q.WPADのDNS方式とは？

A.WPADには主に２つの代表的な手法がある。DNS方式とDHCP方式。では、こここではDNS方式を見ていこう！

WindowsなどのOSやブラウザ（EdgeやChromeなど）には「WPADによるプロキシ自動検出ルール」が最初から仕様として組み込まれている。

  1. PCがLANに接続すると、自分の所属するドメイン名（例: branch.example.co.jp）を確認
  2. OS/ブラウザが自動的に wpad というホスト名を先頭に付け足し、以下の順番でDNSサーバーへ問い合わせ（名前解決）を行う。
    • wpad.branch.example.co.jp
    • wpad.example.co.jp
  3. 見つかったIPアドレス（Webサーバー）のルート直下にある /wpad.dat（PACファイルの中身と同じ）を自動取得しに行く。

つまり、ユーザーが何も設定しなくても、OSやブラウザが「プロキシを探すときはとりあえず wpad.ドメイン名/wpad.dat を見に行こう」とあらかじめプログラムされている、ということ。

設問３（１）に戻る

Q.WPADのDHCP方式とは？

DHCP方式は 「DHCPサーバーがIPアドレスを配るタイミングで、PACファイルの置き場（URL）を親切にPCに教えてあげる」 という仕組み。
（DHCPはDiscover→Offer→Request→ACKのフローである）

  1. PCがIPアドレスを要求（DHCP Discover / Request）
    • PCがネットワークに接続した際、DHCPサーバーに対して「IPアドレスをください！」とリクエストを送る。
    • このとき、PCは「オプション252のデータ（WPADのURL）も欲しいです」というフラグを含めて送る。
  2. DHCPサーバーがIPアドレスとURLを返答（DHCP Offer / Ack）
  3. PCがURLを読み取る
    • PCは受け取ったDHCP応答の中からオプション252の文字列を取り出し、「あ、プロキシ設定ファイルは
      http://192.168.1.100/proxy.pac
      192.168.1.100
      (http://192.168.1.100/proxy.pac)       にあるんだな」と理解する。
  4. HTTPでPACファイルをダウンロード
    • PCは教えてもらったURLに対してHTTPリクエスト（GET /proxy.pac）を送り、PACファイルをダウンロードしてブラウザに設定を適用する。
項目DHCP方式（オプション252）DNS方式（wpad.ドメイン名）
最大のメリット拠点ごとに違うPACファイルを簡単に配り分けられる
（URL・ポート・ファイル名を自由に指定できる）		DHCPサーバーがない環境や静的IPのPCでも動作する
（DNSさえいれば動く）
デメリット・一部の端末やブラウザ（古いAndroidや特定ブラウザ等）でサポート外の場合がある
・DHCPサーバー側の設定変更が必要		・ファイル名が wpad.dat / ポート80（HTTP）に固定される
・全拠点に同じ設定が配られやすい
得意なケース拠点ごとにプロキシ（UTMプロキシなど）を使い分けたい場合
（今回の問題のようなローカルブレイクアウト構成）		全社で1つのプロキシ（本社プロキシ）しか使っていないシンプルな環境

設問３（１）に戻る

Q.ドメインとは？

先ほどのWPADのDNS方式では、「自分が所属しているドメインの配下にwpadをつけて名前解決を～」とあった。ここで出てきたドメイン。。。なんか、わかってそうだけど実は全然わかってないかも⁉では、見ていこう！

A.ドメインは、「同じルール（ポリシー）で管理される1つの大きな部屋（組織）」のイメージ。
DNSのドメインと同じ考え方をするとしっくりくる。ユーザの所属ドメインさえわかれば、そのドメインを管理しているサーバに認証可否を依頼すれば、それで認証プロセスを進ませることができる。
これはDNSも一緒。そのドメインを管理しているサーバに情報を聞きに行けばそれに付随した情報が手に入る。ドメインと仕組みがあるからこそ、その情報の管理者を明確にでき一元的な管理・プロセスを可能にすることができる。

Q.なんでADでもDNSと同じドメイン名（example.co.jp など）を使うの？ADのドメインとDNSのドメインってなに？

A.実は、AD（管理の仕組み）は、土台としてDNS（名前解決の仕組み）を全面採用して作られている。その結果、ネットワーク上の他の機器を探すとき（例：WPADを探すとき）に、自動的に自分のADドメイン名を後ろにくっつけて wpad.example.co.jp というDNS名を作り出し、DNSサーバーに名前解決を聞きにいけるようになる。

ADが動くにはDNSが必須：
　・AD管理下のPCが「ログイン認証をしてくれるADサーバー（ドメインコントローラー）」を探すとき、裏側でDNSを使って検索する。
　・そのため、ADのグループ名をつくるときに、そのままDNSのドメイン名（example.co.jp）をADのグループ名として兼用する設計になっている。

共通の「苗字」として機能する：
　・PCが example.co.jp というADドメインに参加すると、PC自身も「自分は example.co.jp というグループの一員だ」と認識する。

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