設問１

（１）DNSラウンドロビン

１つのドメイン名に対して複数のIPアドレスを割り当てることをDNSラウンドロビンという。
▼具体的な挙動
例えば、同一ドメインに対して3つのAレコード（IPアドレス（IP-1, IP-2, IP-3））が登録されている場合、DNSサーバは以下のように応答する。

1回目の問い合わせ：[ IP-1, IP-2, IP-3 ] の順番で返す
2回目の問い合わせ：[ IP-2, IP-3, IP-1 ] の順番で返す
3回目の問い合わせ：[ IP-3, IP-1, IP-2 ] の順番で返す

1件だけ返してしまうと、そのサーバが死んでいた場合にPCは通信不能になる。複数件まとめて返しておけば、PCは「先頭のIP（例: IP-1）に接続を試みてタイムアウトしたら、2番目のIP（例: IP-2）へ自動的に再接続する」という動作ができるため、クライアント側での簡易的な障害回避が可能になる。

（３）192.168.2.145

切り替え後、つまり障害が発生した際にはどのプロキシサーバを使うかが聞かれている。
案１を見ると、通常時はB（192.168.1.145)が使われて、障害時はCに切り替えると書かれているのでCのIPアドレスである192.168.2.145を指定することが推測される。

＊注意！案２でもDNSのIPアドレス変更は必須

正直、案２の場合はDNSを書き換えなくても、クライアントには複数レコードが配られるので自動でフェイルオーバーできるから書き換える必要はないのでは？？という発想が生まれる。
しかし、クライアント側に自動フェイルオーバーがない場合はアクセスできなくなってしまう。また、もしもフェイルオーバー機能があったとしても、障害発生プロキシのIPが先頭の状態で届いたクライアントは確実に１回はアクセスできないサーバにアクセスしなければならず、それは非効率。
そのため、ワンちゃんフェイルオーバー機能で通信できるかもしれないけど、ユーザに迷惑をかける確率の方が高いので障害が起きたらしっかりとDNS設定を変更しようよね！ということ。

（５）方法：プロキシ自動設定機能を利用する　制限事項：対応するPCやサーバでしか利用できない

では、一つずつ分解しながら回答を導いていこう！

Q.DNSとは異なる方法とは？

「DNSとは異なる方法」とは、DNSゾーンファイルの書き換えを行わずに、端末自身に即座に正常なプロキシへ切り替えさせることを意味している。指している。

Q.プロキシサーバを利用する側の環境とは？

「プロキシサーバを利用する側の環境」とは、つまりプロキシサーバを使うユーザ/クライアント側の環境を意味する

Q.そもそもユーザはどうやってホスト名を知っているの？

「従業員が指定するホスト」と書かれているが、もしもこれがユーザの持つPACファイルに書かれた情報をもとにしているのであれば、WPADなんか使わずに、最初からこのPACファイルに負荷分散をするJavaScriptを書けばいいのでは？

#負荷分散ができるJavaScript
function FindProxyForURL(url, host) {
    // クライアントのランダム値で50%の確率で優先順位を反転
    if (Math.random() < 0.5) {
        return "PROXY ProxyB:8080; PROXY ProxyC:8080";
    } else {
        return "PROXY ProxyC:8080; PROXY ProxyB:8080";
    }
}

A.結論として、元々はPACファイルではなく、ブラウザにホスト名が直接設定されている状態である。PCのキッティング時やActive Directoryのグループポリシー（GPO）によって、ブラウザの「プロキシ設定」の項目に、手動設定の形で proxy.a-sha.co.jp:8080 と直書きされている。したがって、クライアントは通信のたびに proxy.a-sha.co.jp のIPアドレスをDNSに問い合わせをしている。

結論

以上の点から、PACファイルを動的に配ることができれば、ブラウザに直書きの情報ではなくPACによる制御に変えられる。PACには以下のようなプロキシを負荷分散できるJavaScriptを書くことができるので、PACファイルさえ配れれば案２を満たすことができる。
そして先ほどから挙がるプロキシを動的に配る方法こそがプロキシ自動設定機能（WPAD:WebProxyAuto-Discovery）である。これはプロキシをDNSやDHCPなどの機能を使って配布する方法である。しかし、そもそもの前提として、これをWPADを利用するには、プロキシを利用するクライアント端末（OS、ブラウザ、アプリ）側が、PACファイル（JavaScript）を実行・解釈する機能を持っている必要がある。つまりは対応するPCやサーバでしか利用できないということ。

#負荷分散ができるJavaScript
function FindProxyForURL(url, host) {
    // クライアントのランダム値で50%の確率で優先順位を反転
    if (Math.random() < 0.5) {
        return "PROXY ProxyB:8080; PROXY ProxyC:8080";
    } else {
        return "PROXY ProxyC:8080; PROXY ProxyB:8080";
    }
}

▼WPADの詳しいフローなどはこちら

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

設問１（１）ア：ハブアンドスポークこれは知識問題なので覚えておこう！（５）インタフェースにIPアドレス割り当てを行わない設定IP Unnumberedは、文字通り「番号（IPアドレス）を割り当てない...

ascend-beyond.com

2026.09.12

設問２

（１）a:　b:　c:　d:　e:ルーティングテーブル（RIB）　f:

e:ルーティングテーブル（RIB）

これを間違えてFIBと回答してしまう人が多々いる。なので、ここではRIB、FIB、ルーティングテーブルの違いをササっと見ていこう！
▼簡易的な流れ
１．ルーティングプロトコルが自身のアルゴリズムをベースに最適パスを見つける。その最適パスをRIBに提出する
２．RIBはAD値で比較してどのプロトコル（OSPF,BGP,EIGRPなど）を最適経路として扱うかを決める。これがいわゆるルーティングテーブルに登録するという段階
３．パケット転送には、ネクストホップのIPアドレスだけでなく、ネクストホップのMAC、そこに行くための送信ポートを検索する必要がある。それらを毎回やるのは非効率なので１つのテーブルとしてまとめておいてくれるのがFIB。

▼FIBとは？

たとえば、BGPで学習したRIBの情報は次のようになっている。

宛先: 10.0.0.0/8 ➔ ネクストホップ: 192.168.1.1

これを受け取ったルータは、パケットを目の前のLANケーブルに流すために、以下の3ステップの検索を毎回行わなければならない。

1. RIBを検索（1回目）：宛先 10.0.0.0/8 に行くには 192.168.1.1 に送ればいいな。
2. RIBを再検索（2回目）：で、192.168.1.1 に送るにはどの物理ポート（例: Ge0/0/1）から出せばいいんだ？（直結経路の確認）
3. ARPテーブルを検索（3回目）：192.168.1.1 のMACアドレスは何だ？

パケットが1個届くたびに、CPUがルーティングテーブルとARPテーブルを何回も往復して検索（再帰検索）していたら、毎秒数百万〜数億個届くパケットを捌ききれない。そこで、BGP更新や静的経路の変更があった時に、あらかじめCPUがこの3ステップを事前に計算して解決した「カンニングペーパー」を作成する。これがFIB。

（２）自身のIPアドレス

R13はR11からR12の情報をもらった場合、ネクストホップはR12となっている。なぜならiBGPではネクストホップを変えずに流すから。そのため、R13はR12と接続していないので、その経路は無効扱いになってしまう。R13はR11からR12の情報をもらった場合、ネクストホップはR12となっている。なぜならiBGPではネクストホップを変えずに流すから。そのため、R13はR12と接続していないので、その経路は無効扱いになってしまう。それを防ぐために、R11ではnext-hop-selfをつかう。next-hop-selfを使うことで、ネクストホップを自身のIPアドレスに上書きできる。これによりR13はR11からもらうR12からの経路も有効として判断できる。
これは、R13からR11に渡す場合も同様である。

（４）VRRPマスターになったR13が経路情報を保持していないと受信したパケットを転送できないから

Q.BGPを行った後にVRRPを導入する理由は？
A.もし、先にVRRPを稼働させた場合、誤ってR13がマスタになるとR13は経路情報をまだ学習できていないので、流れてきたパケットは破棄されてしまう。そのため、まずは、BGPで経路情報を取得して疎通できる状態にしてから、VRRPを動作させる。
そうすることで、VRRP設定時に意図せずR13がマスタに昇格しても疎通を続けられるというわけである。
＊VRRP設定作業では、障害が起きていなくてもR13が一瞬（または恒久的に）VRRPマスタになることがあるので、念には念をという観点でこの順番をとる。

（５）確認事項：パケットロスが発生しないこと① [送信元：R13 宛先：FW10] or [送信元：FW10 宛先：R13] or [送信元：R13 宛先：R11] or [送信元：R11 宛先：R13] ② [送信元：R14 宛先：R13] or [送信元：R13 宛先：R14]

確認事項：パケットロスが発生しないこと。
　確認事項としては、pingが一発届くだけでなく、しっかりと連続で届くことを確認する。そうすることでパケット落ちが発生してないかという回線・機器の品質を確かめられる

① [送信元：R13 宛先：FW10] or [送信元：FW10 宛先：R13] or [送信元：R13 宛先：R11] or [送信元：R11 宛先：R13]
　LAN側の確認をしている

② [送信元：R14 宛先：R13] or [送信元：R13 宛先：R14]
　WAN側の確認をしている

（７）① R11② R13③ R11 と R12 とを接続する回線④ R13 と R14 とを接続する回線⑤ R11 と L2SW10 とを接続する回線⑥ R13 と L2SW10 とを接続する回線

これは新規導入による疎通確認テストではない。あくまでも障害試験である。
障害試験とは稼働中のシステムに対して、あえて意図的に障害を起こし、裏のルートに切り替わるかを確認すること。
よって、今回の目的はマルチホーミングなので既存のR11などもわざと障害を起こしてR13経路に切り替わるかを確認する必要がある。

設問３

（１）ルーティングのループが発生する

では、１つ１つ現象を紐解いていこう！

Q.D社閉域NWの設定変更とは？

A.FW40にインターネット宛てのデフォルトルートを広告する設定である。これを設定することで、R12,R14へとインターネット宛ての経路が確立される

Q.FW10のデフォルトルートの設定変更を行うとは？また、どうなる？

A.FW10の変更とは、インターネット宛ての通信をR10からVRRPの仮想IP宛て（＝D社閉域網宛て）に変えることを意図している。

Q.なぜループになるの？

A.上述した内容を念頭に置きつつループが発生するフローを見ていこう
▼ループのフロー
１．F10のルーティングテーブルにインターネット宛てをD社閉域網宛てにする（VRRPの仮想IP）
２．FW10にインターネット宛てのパケットが届くとR11に転送する
３．R11のテーブルではインターネット宛てはFW10となっているのでFW10へ送信する
４．TTLが０になるまで１～３を繰り返す＝ループ
以上がループが起きる原因である。
では、次は逆にD社閉域網側のFW40にインターネット宛てのパケットを受け取る設定を入れた場合のフローを見ていこう！
▼正しい手順でインターネット宛てルートを設定した場合
１．FW40にインターネット宛てデフォルトルートを設定する
２．D社閉域網内のMP-BGPによりR12,R14にその経路が流れる
３．FW10側でもインターネット宛てはD社閉域網側に行くように設定する
４．実際のパケットがFW10に届くとR11に転送する
５．R11はR12からeBGPでインターネット宛ての経路を受け取っているのでR12に転送する
６．R12はFW40に転送する
７．FW40はインターネットへ流す

（３）送信元IPアドレスがプロキシサーバAで宛先IPアドレスがインターネットであった場合にネクストホップをR10とする設定

▼整理された全体フロー

• 特定部門（送信元IP制限のあるサービスを利用）
  1. 本文にもある通り特定部門にはプロキシAを案内し、ブラウザ等でプロキシAを設定してアクセス
  2. FW10がPBRによって「送信元＝プロキシA」を検知し、ネクストホップをR10（旧ルート）へ強制転送
  3. 旧グローバルIPのままインターネットへ出るため、外部サービスのフィルタリングを無事クリア
• 一般部門（通常通信）
  1. DNSの自動制御（案2）によりプロキシBまたはCを参照
  2. FW10は通常通りデフォルトルートに従い、D社閉域網（新ルート）へ転送
  3. D社閉域網を通ってFW40（新グローバルIP）でNAPT変換され、インターネットへ出る

▼PBRの例

access-list 1 permit プロキシAのIP サブネット

route-map ルートマップ名 permit シーケンス番号
 match ip address 1
 set ip next-hop R10のIP
 
interface プロキシとつながっているインタフェース名
 ip policy route-map ルートマップ名

p.2 Q.IaaS（Infrastracture as a Service）って何？

A.IaaSとは、インフラをクラウド上で利用できるサービスのこと。つまり、自社内に電源、サーバーラック、LANケーブル、ネットワーク環境などの手配をする必要がなくなるということ。しかし、その上で動作するOS、アプリ、FWルールなどはすべて自分でやる必要がある。

p.2 Q.閉域網ってなに？

A.閉域網とはインターネットとは隔絶された独自のネットワーク。主にMPLSサービスなどが代表例としてある。これを使うことによって、閉じた空間なのでプライベートIPアドレスを広告して、離れた拠点間とのプライベートIPアドレス同士の通信ができるようになったりする。

Q.閉域網とインターネットVPN（IPsecなど）の違いは？

正直、閉域網でできることってインターネットVPNでも実現できるよね？暗号化して、カプセル化をすれば離れた拠点でもプライベートIP同士の通信ができるよね。じゃあ、なんで今も閉域網サービスは存在しているの？

A.結論から言うと、現代において企業がインターネットVPNではなく閉域網を選ぶ最大の理由は「通信品質の保証（SLA）」と「回線の信頼性・安全性の確保」にある。現代のインフラ観点でのポイントを比較表でまとめよう。

Q.IaaSと閉域網の連携は誰が負担するの？

A社側がIaaS上で自分でD社と契約処理をしているのか、はたまた、B社がサービスとしてあらかじめD社の閉域網を利用できる形式を整えてくれているのか？だれが何をやっているのかを明確にしたい。

A.結論から言うと、費用や契約の最終的な負担者は「A社」だが、D社閉域網とB社IaaSの間の物理的・論理的な接続ライン（相互接続）自体は、B社とD社（事業者同士）があらかじめ準備して連携しているものになる。
▼各プレイヤーの役割と負担

• B社（IaaS）と D社（回線事業者）の関係
  • あらかじめB社のデータセンターとD社の閉域網（MPLS網）を大容量の回線で相互接続（ピアリング）しておく。
  • これにより「D社の閉域網を使っている顧客なら、インターネットを経由せずに直接B社IaaSにアクセスできる準備」が整っている。
• A社（利用企業）の契約と費用負担
  • 費用を支払うのはすべてA社。
  • A社は ①D社に対して「自社〜B社IaaS間の閉域網利用オプション料金」 を支払い、②B社に対して「閉域網接続用ポート（専用線ゲートウェイなど）の利用料」 を支払って設定を行う。

Q.もし、IaaSがサポートしていない閉域網を自社で使っていたら？

IaaSはサービスとして閉域網をあらかじめ接続準備してくれている。しかし、もし、自社で使っている閉域網がIaaSではサービス対象外であった場合、自分で接続処理などをしなくてはならないの？また、それはどうやってやるの？

A.「IaaS側で自社の閉域網が直接サポートされていない場合、中間事業者（マルチクラウド接続事業者）を挟んで繋ぐ」というのが、現代のエンタープライズネットワークにおける標準的な解決策。

Q.どうやって繋ぐのか？（解決策：中間事業者の利用）

そこで登場するのが、Equinix（エクイニクス）やMegaport（メガポート）といったデータセンター／マルチクラウド接続事業者（データエクスチェンジ事業者）。
▼接続のイメージ

• 自社〜中間事業者：既存の閉域網（D社）を中間事業者のデータセンターまで伸ばして接続する。
• 中間事業者〜IaaS：中間事業者はすでに主要なIaaS（AWS, Azure, GCP等）すべてと大容量の専用線で直結している。
• データ転送：中間事業者の拠点でパケットを折り返し、自社の閉域網からIaaSへ通信を流し込む。

Q.っつか、じゃあ中間事業者をメインの閉域網として使えばよくね？

A.完全にその通りで、実際に多くの企業がそのような構成（自社拠点〜中間事業者〜各クラウド）へ移行している。中間事業者の内部ネットワークも閉域網として運用されているので、乗り換えても閉域網として維持できるので問題ない。しかし、運用・契約上の都合などによって従来の閉域網を残す理由もある。
▼従来の閉域網（D社等）を残す主な理由

• ラストワンマイル（物理回線）の調達能力
  中間事業者（Equinix等）は「都市部のデータセンター内」に拠点を持っている。全国にある自社オフィスや工場からそのデータセンターまで物理的な回線を引いて連れてくる役割（アクセス回線）として、キャリア（D社等）の網が必要になる。
• 長年の契約とコスト・移行リスク
  すでにD社と長期契約（数年単位の割引等）を結んでいたり、全国数十拠点の設定変更・乗り換え工事に膨大なコストとリスクがかかるため、既存網を活かしたままクラウド接続部分だけを追加・拡張するケースが多く存在する。

p.3 A社の静的経路制御とは？

スタティック設定にしていると記されているが、具体的にどの機器でどんなスタティック設定をしているのか？現在の構成（図1）を見ると、通信の行き先は主に3パターンしかないので、それらを見ていこう！

1. 本社PCから営業所やIaaSへ行く通信
   • L3SW10：物理的にFW10にしかつながっていないので、ネクストホップはすべてFW10になる
   • FW10：FW10は「192.168.1.0/24（B社IaaS）や営業所宛てのパケットが来たら、ネクストホップ（次の送り先）を R11 に向ける」というスタティック経路を手動で書き込んでいる。
2. 本社からインターネットへ行く通信
   • L3SW10：物理的にFW10にしかつながっていないので、ネクストホップはすべてFW10になる
   • FW10の設定：「デフォルトルート（0.0.0.0/0：どこにも該当しない外向けの通信）は R10 に向ける」というスタティック経路を設定している。
3. 営業所から本社やIaaSへ行く通信
   • R20（営業所ルータ）の設定：「本社やIaaS宛て、あるいはインターネット宛ての通信はすべて D社閉域網（R21） に向ける」というスタティック経路を設定してる。

p.3 “開発サーバをシステム部が構築”って具体的に何をやっているの？

A.開発担当者には、あたかも「物理サーバがすぐそこにある」という状態で渡したい。そのために以下の設定が必要になる。
＊ちなみに、「開発サーバ」とはシステムを開発するためのサーバ。このサーバ上で多くのトライ＆エラーやりながら開発を進めていく。「テストサーバ」は開発サーバである程度形になったものの挙動をテストするためのサーバ。このテストサーバ上で、コードの修正などは基本的に実施しない。
▼構築

• インフラリソースの手配：B社IaaS上で仮想マシン（VM）を作成（CPU・メモリ・ディスク容量の割り当て）
• ネットワーク・IP設定：社内からアクセスできるようにプライベートIPアドレス（192.168.1.x）を付与し、ルーティングやFW/セキュリティグループを設定
  ＊開発担当者に直接仮想サーバを作らせると、内部でIPアドレスの重複が起きたり、セキュリティ設定が甘くなったりして、踏み台にされてしまうリスクがある。そのため、システム部門で一元管理している。
• OSのインストール・初期設定：LinuxやWindows ServerなどのOSを導入し、セキュリティパッチの適用や最低限のアカウントを作成

▼引き渡し

• アクセス用情報の提供：「IPアドレス（またはホスト名）」「管理用アカウント（管理者IDと初期パスワード、またはSSH秘密鍵）」を担当部門に通知する。
• 利用環境の案内：「社内PCからSSHやリモートデスクトップ（RDP）でアクセスして開発に使ってください」と伝達する。

▼引き渡し後
引き渡された後、開発サーバBの中で何をするかは担当部門（現場のエンジニア）の責任になります。

• ミドルウェア・開発環境の導入：Webサーバ（Apache/Nginx）、データベース（MySQL等）、PythonやJavaなどのプログラミング言語環境のインストール
• ソースコード・アプリの配置：開発するシステムのプログラムを入れて動かす
• 日々の運用管理：アプリのログ管理、開発メンバー用のアカウント追加・削除、不要になった際のシャットダウンや再起動

p.3 サーバがプロキシを使うとは？

プロキシを使う対象として、ブラウザとサーバが挙げられている。ブラウザはわかるけど、サーバにプロキシを指定って。。。どのサーバのこと？

A.開発サーバにはどのプロキシを使うかの設定が必要。APIやライブラリなどと連携するときにインターネットからそれらの情報を取得したりする必要があるので開発サーバにもプロキシ設定は必要。

Q.NAPTとは？

NAPT（IPマスカレード）とは送信元IPアドレスに加え「送信元ポート番号」も一緒に変換することで、1つのグローバルIPを複数の内部機器で同時に共有できるようにするアドレス変換技術。

▼NAPT雑学

ポートは2¹⁶、つまり総数は65,536個。その中の0~1023はウェルノウンポートとして予約されている。つまり、1つのアドレスで表現できる総数は、65536-1024=64,512個となる。

▼NAPT実装コマンド

①インターフェースの内外(inside/outside)を指定
②内部から外部への変換対象を定義(アクセスリスト)
③NAT/PATを有効化するコマンドを設定
④確認・検証

#１．インターフェースの内外(inside/outside)を指定
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip address 192.168.1.1 255.255.255.0
Router(config-if)# ip nat inside
Router(config-if)# exit

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip address 203.0.113.1 255.255.255.0
Router(config-if)# ip nat outside
Router(config-if)# exit

#２．変換したい内部ネットワーク(送信元アドレス範囲)を指定
Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

#３．パターン１（プールを使わない場合）
Router(config)# ip nat inside source list 1 interface GigabitEthernet0/1 overload

#３．パターン２（プールを使う場合＝グローバルIPが複数ある場合）
Router(config)# ip nat pool MYPOOL 203.0.113.10 203.0.113.20 netmask 255.255.255.0
Router(config)# ip nat inside source list 1 pool MYPOOL overload

#４．確認
#現在の変換テーブルの確認
Router# show ip nat translations
#NATの統計情報(ヒット数、インターフェース設定など)を確認
Router# show ip nat statistics

Q.キャッシュDNSサーバのフローはどうなってる？

1. PC ➔ キャッシュDNSサーバ

• PCはDHCP等で知らされた「キャッシュDNSサーバのIP」宛てに名前解決要求（53番ポート宛て）を送信する。

2. キャッシュDNS ➔ ルートDNSサーバ（1段階目）

• キャッシュDNSはあらかじめ保持している「ルートヒント」からルートDNSのIPを選ぶ。
• パケット：送信元＝[キャッシュDNSのIP : ランダムなポートA] ➔ 宛先＝[ルートDNSのIP : 53]
• FW10のNAPT：送信元を「FW10のグローバルIP : ランダムなポートB」に動的NAPT変換して外へ送出。
• 応答：ルートDNSから「.jp を管理するTLDサーバのIPアドレス」が返ってくる。

3. キャッシュDNS ➔ TLD（.jp）DNSサーバ（2段階目）

• 同様に、ランダムな送信元ポートを使ってTLDサーバへ問い合わせる。
• 応答：TLDサーバから「co.jp を管理するDNSサーバのIPアドレス」が返ってくる。

4. キャッシュDNS ➔ 権威DNSサーバ（3段階目）

• 最終的に example.co.jp を管理する権威DNSサーバへ問い合わせる。
• 応答：権威DNSから www.example.co.jp の最終的なIPアドレス（例: 192.0.2.1）を取得する。

5. キャッシュDNS ➔ PC

• 取得したIPアドレスをPCに回答し、同時にその結果を一定時間（TTL）自身の中にキャッシュ（保存）。

Q.DNSSECとは？

DNSSECとはキャッシュポイズニングを防止する技術の一つ。では、フローを見ながら理解していこう！

ステップ1：レコード自体の検証（ZSKを使用）

• 対象：Aレコードなど
• 検証：権威DNSから取得したDNSKEYレコード内の ZSK(ZoneSigningKey)公開鍵 を使い、Aレコードに付いている RRSIG(Resource Record Signature) を検証する。
  ＊RRSIG（A)は権威DNSがAレコードから生成したハッシュ値をZSK秘密鍵で暗号化したもの。
  ＊検証するときは検証側がZSK公開鍵で署名を復号し、出てきたハッシュ値と検証側でも生成したハッシュ値が一致することを確認する。
• 結果：Aレコードが改ざんされていないことが判明。

ステップ2：ZSK公開鍵の検証（KSKを使用）

• 対象：ZSK公開鍵が含まれる「DNSKEYレコード」
• 検証：権威DNSから取得した KSK(KeySigningKey)の公開鍵 を使い、DNSKEYレコードに付いている RRSIG(DNSKEY) を検証する。
• 結果：ZSK公開鍵が本物であることが判明。

ステップ3：KSK公開鍵の検証（親ゾーンと連携）

• 対象：KSK公開鍵
• 検証：
  1. 親ゾーン（例：.jp）へ問い合わせて DSレコード(Delegation Signer)（＝子ゾーンのKSK公開鍵のハッシュ値）を取得する。
  2. 手元にあるKSK公開鍵を自分でハッシュ化し、親からもらったDSレコードと一致するか比較する。
• 結果：KSK公開鍵が親ゾーンによって保証された本物であることが判明。

p.5 プロキシサーバを動的に切り替える方法は？

案１を見ると、障害が起きるとプロキシCを使いたい旨の記載がある。では、具体的にどうやっているのか？

１．DNSを変更している
　DNSでFQDNに対するIPアドレスをBからCのアドレスに変更すれば、必然的にCのプロキシが使われることになる。
２．PACファイル
　PACファイルだと動的にクライアント側が宛先を変更できるため、以下のような設定をすればプロキシCが使われる。

#通常時はproxybで名前解決されるが障害が起きると、２つ目のproxycが利用される。
return "PROXY proxyb.a-sha.co.jp:8080; PROXY proxyc.a-sha.co.jp:8080";

p.7 Q.マルチホーム環境でも静的経路で対応できるのでは？

結論から言うと、「FW10でIP SLA＋スタティック制御を行う」というアイデアは、A社から出ていく通信（往路）だけを見れば動くように思えるが、実際のネットワーク構築（特に復路通信、プロバイダ連携、運用性）においては致命的な欠陥が4あり、採用できない。

・復路を制御できない
例えば、R11とR12間をFW10がIP slaで監視したとする。そして、経路に障害が起きたらサブルートであるR13とR14の経路を優先させる静的ルートを設定しておく。これだと、A社側からの通信はR13経由にできる。しかし、外部からはR11とR12間で障害が起きていることを知らないので、R12宛ての経路が届いてしまう。。
では、仮にR12でip slaを稼働させR11とR12を観察し、その結果をMP-BGPでD社閉域網に流すという方法であれば実現できなくもない。(トラッキングで当該ルートを削除。→RIBから情報が消える→BGPの参照先であるRIB当該経路が消えたことを検知→BGPでwithdrawを流す）

しかし、それは現実的じゃない。というか、そもそも、そのような動的に経路を変更したりできるものが動的なルーティングプロトコルである。なので、経路が複数ある場合は基本的に静的ではなく動的なルーティングプロトコルの制御を使うのがベターとなる。

Q.VRRPとは？

VRRP（VirtualRouterRedundancyProtocol）とはデフォルトルートを冗長化するためのプロトコル。複数のルータを１つのルータのように振舞わせることで、１台が故障してもほかのルータで通信を継続させることができる。

▼障害検知方法

マスターが１秒ごとにマルチキャスト224.0.0.18宛てにAdvertisementを送る。これがタイムアウト時間届かないと、バックアップは障害と検知して仮想IP/仮想MACを引き継ぎGARPを送信する。

▼FHRP（First Hop Redundancy Protocol）とOSPF

p.8 Q.専用線で接続するとは物理的にどうやっているの？

A社からD社まで直通の超長いケーブルを1本物理的に引っ張るわけではない。通信事業者（NTT等）がすでに地下や電柱に張り巡らせている既存の光ファイバー網（インフラ）を活用し、両端の拠点へケーブルを引き込んで接続している。

Q.物理的にどう繋がっているのか？

A社本社のR13からD社網のR14までは、以下の3つの区間で物理的につながっている

• １．A社側の引き込み（ラストワンマイル）
  ①電柱やビル地下のクロージャから通信事業者の光ファイバーの先端とA社側ケーブルの先端をつなぐ。
  ②A社側のもう一方の先端は端子盤につなぐ
  ③端子盤とONU（光回線終端装置）をつなぐ
  ④ONUが光信号を電気信号に変えてR13につなぐ
• ２．通信事業者のビル間ネットワーク（中継網）
  ①A社から引き込んだ光信号は、最寄りのNTT等の基地局（収容局）へ入る。
  ②ここから先は、地下に埋まっている既存の巨大な光ファイバー網を通じて、D社最寄りの基地局まで運ばれる
• ３．D社側の引き込み
  A社側と同様に、D社拠点（R14側）のビルにも光ファイバーが引き込まれ、D社側のONUに繋がる

p.8 Q.なぜBGPをすぐに確立しないの？また、それは技術的に可能なの？

A.「BGP設定を入れてもセッションを確立させない」ことは技術的に可能。また、一括して確立させない理由は設定途中の「中途半端な状態」での経路流入事故を防ぐため。
要は、手動で１行ずつ設定していくと、行と行の間で数秒間経過してしまい、その間にフィルタリングをする前に情報が流入・流出してしまうのでそれを防ごうねということ。

確立させない方法

BGPの設定コマンドの中に neighbor <IPアドレス> shutdown という命令を書いておく。 これを書いておくと、設定自体はルータに保存されるが、相手（ピア）へBGPの接続要求（OPENメッセージ）を送らなくなる。

#無効化させるとき
neighbor <IPアドレス> shutdown

#有効化させるとき
no neighbor <IPアドレス> shutdown

Q.即座にBGP起動するとどういう不具合があるの？

1. フィルタ未設定による「ルートリーク（経路の誤流出）」
BGPの設定手順は、コマンドの構造上「相手と繋ぐ設定（neighbor）」を投入した後に、「外に流す経路を絞り込む設定（prefix-listやroute-map）」を書き込む流れになる。
即時接続させてしまうと、絞り込み設定を打ち込むまでのわずか数十秒の間に、社内ネットワークの不要な経路が外部（D社網）へ一気に漏洩（リーク）する。流出した経路の量によっては、D社側のルータの防御機能（Prefix Limit）が作動し、回線を自動遮断される恐れがある

2. 接続の不整合による「ブラックホール（パケット吸い込み・破棄）」
たとえば、先に「R13 ⇔ R14（WAN側）」のBGPだけが繋がり、「R13 ⇔ R11（社内iBGP）」の設定がまだ完了していない時間が発生したとする。

• 行き：D社側（R14）は「R13経由でA社に行ける」と認識し、データ（パケット）をどんどん送り込んできます。
• 戻り：しかしR13側は、社内のR11との連携（iBGP）がまだできていないため、届いたパケットを社内へ流せず、そのまま捨ててしまう（通信断）。

3. 経路のバタつき（フラッピング）による既存通信の瞬断
4台のルータがバラバラのタイミングでBGPを繋ぎ始めると、各ルータは不完全な情報をもとに「どのルートが最適か」を何度も再計算する。その結果、現在正常に動いている「R11 ⇔ R12」の既存ルートまで経路が頻繁に切り替わり（フラッピング）、現在稼働中の業務通信に遅延やパケットロスなどの悪影響を与えてしまう。

概要

事件の背景（何が起きたのか？）

1. YouTubeのブロック試み：パキスタン政府の命令で、国内プロバイダ（パキスタン・テレコム）が自国内でYouTubeを見られないよう、YouTubeのIPアドレス帯（/24）に対する「偽の経路（ブラックホール経路）」を内部で作った。
2. 誤広告（BGPハイジャック）：その偽の経路情報を、誤って上位プロバイダ（PCCW）へBGPで広告してしまった。
3. 世界中へ拡散：BGPは「より細かいPrefix（/24）の経路を優先する」というルールがあるため、世界中のインターネットトラフィックがYouTubeの本物サーバーではなくパキスタンへ集中し、YouTubeが世界中でダウンした。

登場する重要単語・技術

この「誤ったBGP広告を信用して広めてしまった」対策として登場するキーワードが以下の３つ。

• IRR（Internet Routing Registry）
  • 各AS（プロバイダ等）が「自分がどのIPアドレス帯を広報する権利を持っているか」を登録しておくデータベース。
  • 限界：誰でも登録できるなど認証が甘く、偽装を完全には防げなかった。
• RPKI（Resource Public Key Infrastructure）
  • IRRの弱点を補うために作られた「暗号技術（電子署名）を使ったBGP経路の認証基盤」。
  • APNICやJPNICなどの地域インターネットレジストリ（RIR）が発行する証明書を使って、IPアドレスの所有権を証明します。
• ROA（Route Origin Authorization）
  • RPKIの仕組みの中で作成される「経路証明書」データのこと。
  • 「このIPアドレス帯（例：208.65.152.0/22）を広告して良いのは、ASXXXX（YouTube）だけである」という正しいペアを電子署名付きで定義します。

なぜRPKI/ROAがあれば防げたのか？

上位プロバイダ（PCCW等）が RPKI Validation（ROV: Route Origin Validation） を導入していれば：

1. パキスタンから「YouTubeのIPアドレス」のBGP広告が届く。
2. RPKIデータベースと照合し、「このIPを広告して良いのはYouTubeのASだけで、パキスタンのASは許可されていない（Invalid）」と即座に判別できる。
3. 誤ったBGP広告をその場で破棄（Drop）できたため、世界中へ被害が広がるのを防げた。

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

Q.そもそも、どうやって偽の経路を作るの？

A.「通常のスタティックルートとBGPの再配送（アナウンス）」の設定によって偽の経路を作っていた。

▼パキスタンが実際に行った「偽の経路」の作り方
パキスタン・テレコムは、RTBHやFlowspecなどのセキュリティ技術を使ったわけではなく、ルーターの「通常のスタティックルートとBGPの再配送（アナウンス）」の設定ミスをやらかした。

１．国内向けの破棄設定（Null 0行き）をルーターに入れる
・パキスタン政府から「YouTubeをブロックしろ」と言われたエンジニアは、国内のユーザーがYouTubeに行けないようにするため、パキスタン・テレコムの国境ルーターに次のような設定を入れた。
・「208.65.152.0/24（YouTubeのIP）宛てのパケットが来たら、すべて Null 0（ゴミ箱・破棄）に送れ
・（※これにより、パキスタン国内のルーターにとっては、YouTube宛ての通信は自社内で消滅する「ブラックホール」になった）

👆これはIGP（OSPFやIS-ISなど）によって、Null経路が配られていた。末端のルータがYoutube宛てを受信すると、Null経路を持っている当該ルータへ運んでいた。すべてのルータにYoutube宛ては自身のルータ内でNullで破棄して！というわけではない。

２．その「破棄用の経路」を、あろうことか外（BGP）に広告してしまった
・本来、この Null 0 行きのルートはルーターの内部だけで使うもの（外部に教えてはいけないもの）。
・しかし、設定ミスかテストの意図で、パキスタン・テレコムはこの「YouTubeの経路はうち（AS17557）にあるよ！」という情報を、通常のBGPの経路情報（NLRI）としてそのまま上位プロバイダ（PCCW）に流して（アナウンスして）しまった。

👆再配布のミス！IGPで広告していたNull経路をAS外にもフィルタリングを怠ったせいで広告してしまった。それによって、インターネットに広がってしまった。

３．世界中がそれを「本物の道」と勘違いした
・上位プロバイダから見れば、送られてきたBGP情報は「普通のYouTubeへの経路」に見える。
・そのため、「YouTubeの細かいプレフィックス（/24）の道がパキスタンから来たちょっと近道だ！」と世界中のルーターが勘違いし、世界中のYouTube宛て通信がパキスタンテレコムへ向かって吸い寄せられてしまった。

👆当時、Youtubeは/22で運用されていた。これは正規のプロバイダから取得した正規のアドレス範囲。一方、パキスタンテレコムの/24はNull用のダミーの広告だが、当時は広告の正当性を確認するプロセスがおざなりであったため、論ゲストマッチの原則に基づき、より長いプレフィックスをもつパキスタンのダミー経路が優先されてしまった。

Q.どうやって復旧させたの？

A.この2008年の事件の最もドラマチックなところは、「パニックになったパキスタン側がすぐにミスに気づいて自主的に直してくれなかった」という点にある。そのため、被害が拡大する中でYouTube自身が驚きの「カウンター攻撃」に出て事態を収束させた。

▼実際の復旧・解決までのプロセス
パキスタン・テレコム側はパニックや連絡の不備もあり、すぐに誤った広告を引っ込められなかった。そこで、被害を直接受けていたYouTube（Google）側が次のようなウルトラCの対抗措置を取った。

１．YouTube側が「さらに細かいプレフィックス（/25）」で対抗広告を出した
・パキスタンが流していたのは /24 。
・これに対抗するため、YouTubeはさらに細かく分割した /25（/24 の半分のサイズ） の正当な経路情報を世界に向けて急遽広告した。

２．ロンゲストマッチによる奪還
・BGPの「より長いプレフィックスを優先する」という鉄則を利用し、パキスタンの /24 よりもさらに細かい YouTube自身の /25 の方を世界中のルーターに最優先させた。
・これにより、世界中のトラフィックが強烈に本物のYouTubeへと引き戻された。

３．上位ISPによる強制遮断
・その後、香港の上位プロバイダ（PCCW）が事態を重く見て、パキスタン・テレコムからの不正な広告を強制的に削除（Withdraw）したことで、約2時間越しに完全に幕を閉じた。

Q.プレフィックスを大きくするとどうなるの？

プレフィックスを大きくするとどうなるのか。。。大きくして対応できるなら、なぜ最初から/25で広告しなかったのか？
A.プレフィックスを大きくすると、広告するエントリー数が増大する。そのため可能な限りプレフィックスは小さめにして広告したいが、そうするとパキスタン側に負けてしまうので、ウルトラCとしてプレフィックスを大きくした

▼具体例

例えば、10.0.0.0/8という１つの広告を10.0.0.0/9にする場合は何個のプレフィックスになるのか？

10.0.0.0/8 →①10.0.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111


10.0.0.0/9 →①10.0.0.0 ~ 10.127.255.255 / ②10.128.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.01111111.11111111.11111111
00001010.10000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111


10.0.0.0/10 →①10.0.0.0 ~ 10.63.255.255 / ②10.64.0.0 ~ 10.127.255.255 / ③10.128.0.0 ~ 10.191.255.255 / ④10.192.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.00111111.11111111.11111111
00001010.00000000.00000000.00000000 ~ 00001010.01111111.11111111.11111111
00001010.10000000.00000000.00000000 ~ 00001010.10111111.11111111.11111111
00001010.11000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111

以上のように、プレフィックスが小さくなるほど、集約できるアドレス数も減ってしまう。その結果より多くのエントリーを登録することになる。

▼プレフィックスが増大した時のエントリ数が何個になるかの計算方法

増えた分のエントリ数＝２^{（変更後のプレフィックス長-変更前のプレフックス長）}

例１：/8 から /10 にした場合
2^(10-8)=4

例２：22/ から /25 にした場合
2(25-22)=8

Q.RPKI（ResourcePublicKeyInfrastracture）とは？

RPKIを一言で言うと「このIPアドレスは、本当にこのプロバイダ（AS）が名乗っていいものか？」を暗号学的なデジタル証明書で証明・検証する仕組み。従来のBGPには「身分証の確認プロセス」がなかったため、誰でも「うちはYouTubeの経路を持っているぞ！」と嘘（あるいは間違い）を言えてしまう。そこに「身分証（証明書）」を導入するのがRPKI。

▼RPKIの全体フロー（証明書はどうなっていて、動検証するのか？）

1. 事前準備：ROA（証明書）の登録と保管
・誰が作るの？：IPアドレスの正当な持ち主（例：YouTube）が、地域インターネットレジストリ（APNICなど）を通じて「我が社はこのAS番号でこのプレフィックスを広告してよい」という証明書（ROA：RouteOriginAuthorization）を発行してもらう。
・どこに保管されるの？：このROA（証明書データ）は、インターネット上にある「RPKIリポジトリ（公開サーバー）」という専用のデータベースに、常に誰でもダウンロードできる状態で保管されます。

2. ルーター側の準備：キャッシュサーバーとの連携（ここがポイント！）
・個々のルーターが直接インターネット上のリポジトリから1つずつ証明書を都度ダウンロード・検証しているわけではない！
・キャッシュサーバー（RPKI Validatorなど）と呼ばれる専用のサーバーが、インターネット上のRPKIリポジトリからすべての正当なROA（証明書の一覧）をあらかじめ一括でダウンロードし、手元にキャッシュ（保存）しておく。
・ルーターは、そのキャッシュサーバーから定期的に「正当な証明書のリスト」を受け取って手元に持っておく

#キャッシュサーバとの接続設定社内に置いたキャッシュサーバー（例: 10.0.0.50）とポート323（または3323など）で接続する
router bgp 65001
  bgp rpki server tcp 10.0.0.50 port 3323 refresh 300
  
#ルーターがちゃんとキャッシュサーバーから証明書を受け取れているか確認
Router# show ip bgp rpki servers

＊キャッシュサーバは基本的に社内に配置する。で、ルータはそのキャッシュからROIを検索する
＊キャッシュサーバーが世界中から複雑な証明書（ROA）を集めて複雑な暗号検証をすべて肩代わりし、「このIPとこのASの組み合わせは Valid（有効）」というシンプルな判定用リスト（軽量化されたデータ）だけを、定期的にルーターに配給（同期）している

3. 実際のBGP受信と検証のフロー
ここで、隣のルーター（ネイバー）からBGPの経路情報が流れてくる。
①BGP経路の受信
　・ネイバーから「このIPアドレス（/24など）を、このAS番号が持っているよ」という通常のBGP経路情報が届く。（※ここには証明書はくっついていない！ただの経路の文字情報）
②手元のリスト（キャッシュ）と突合する
　・ルーターは、受け取った経路情報の 「IPプレフィックス」 と 「広告してきたAS番号」 を取り出す。
　・そして、あらかじめ手元に持っているROA（証明書のリスト）と照らし合わせる。
③暗号学的な検証（バリデーション）
　・「手元の証明書リストの中に、このAS番号がこのIPを広告してよいというデータ（電子署名付き）は存在するか？」をチェックする。
　・署名の正当性（改ざんされていないかなど）は、証明書を発行した上位機関の公開鍵を使って数学的に検証される。
　＊なお、署名の正当性は事前にキャッシュサーバが肩代わりしてくれているので、ルータはリストへの有無を見ればいいだけ。
④判定（Valid / NotFound / Invalid）
　・一致する正当な証明書があれば Valid（有効）。
　・リストになければ NotFound。
　・範囲やAS番号に矛盾があれば Invalid（無効：偽物・ミス） として、自動的にその場で破棄する。

Q.ROA(RouteOriginAuthorization)の取得～検証のフローは？

ROAの取得では、WebのSSL/TLS証明書（Let’s Encryptなど）でよくある「その場しのぎのファイルを置く」のではなく、「インターネットの公的な階層構造（レジストリ）そのものを使って正当性を証明する」という仕組みになっている。
▼取得～検証フロー
1. ROA（証明書）の取得・発行フロー
Webの証明書発行（CSRを生成して…という手順）とは異なり、ROAは「IPアドレスの割り当てを受けている公的な組織のポータルサイト」で直接作成・発行する。

1. IPアドレスの正規の割り当てを受けていることの証明
   • 大前提として、そのIPアドレスブロックは、APNIC（アジア太平洋地域）やJPNICなどの上位レジストリから、正規にお金を払って割り当てを受けている自社のリソースである必要がある。
2. 証明書発行機関（LIR / NIR）のポータルへログイン
   • 自社が管理するIPアドレスを管理しているレジストリ（日本であればJPNIC経由、または上位のLIR/ISP）の専用管理ポータルにログインする。
     ＊管理ポータルにログインしたユーザとIPアドレスはバックエンドで対応づけられているので、このポータル内で偽のIPのROAを要求することはできない。
3. ROAの発行申請（パラメータの入力）
   • ポータル画面で、以下の情報を指定して「この内容で証明書を作ってくれ」と申請。
     • 対象のIPプレフィックス（例: 208.65.152.0/22）
     • 許可する最大プレフィックス長（例: /24 までなら分割して広告してもいいよ、という上限）
     • 広告を許可するAS番号（例: AS15169）
4. RPKIリポジトリへの自動登録
   • 申請ボタンを押すと、レジストリ側のシステムが電子署名（デジタル証明書＝ROA）を自動生成し、インターネット上に公開されている公式の RPKIリポジトリ（公開サーバー群） に自動で登録されます。
   • （※ここで「私たちがこのIPをこのASに広告させていいという証明書」が世の中に誕生する）

2. ルーター（キャッシュサーバー）側での検証フロー
世の中に公開されたROA（証明書）を、キャッシュサーバーがどうやって拾って検証するのか、おさらいも含めて全体の流れ。

1. キャッシュサーバーが証明書を回収
   • 社内のキャッシュサーバー（Validator）が、インターネット上の公的RPKIリポジトリから、世界中の正当なROAファイルを定期的に一括ダウンロード。
2. 暗号学的な検証（ここで公開鍵が使われる）
   • 「公開鍵による検証」はまさにここで行われる。
   • キャッシュサーバーは、ダウンロードしたROAに付いている「電子署名」を、上位のレジストリが持つ「公開鍵」を使って数学的に検証する。「途中で改ざんされていないか」「有効期限内か」「本当に正当な機関が発行した証明書か」をここで厳しくチェックする。
3. 安全なリスト（VRP）の作成
   • 検証に合格した「安全な証明書データ」だけを綺麗に整理し、合格リスト（VRP：Valid ROA Payload）としてキャッシュサーバー内に保持する。
4. ルーターでの突合判定
   • ルーターはキャッシュサーバーからその合格リストを受け取っておき、ネイバーから新しいBGP経路（IPとAS番号）が届くたびにリストと突合し、「Valid（合格）」か「Invalid（不合格・偽物）」かを一瞬で判断する。

設問１

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

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

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

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

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

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

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

#現在(トンネルインタフェースで指定）
ip route 相手WAN側IP 255.255.255.0 Tunnel 0

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の違いは？

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」とピンポンとでトンネルを指定して、疎通を確認することができる。これによって、トンネル障害が否かを一発で判断できるようになる。
▼具体的な切り分け手順

（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-IP over IPsecとは？

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

#! 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）
   • DHCPサーバーは、PCに割り当てるIPアドレスやサブネットマスクと一緒に、「オプション252（Option 252）」 という項目の中にPACファイルのURLを書き込んで返す。
   • 送信されるデータの例：(http://192.168.1.100/proxy.pac) や (http://wpad.example.co.jp/wpad.dat)
3. PCがURLを読み取る
   • PCは受け取ったDHCP応答の中からオプション252の文字列を取り出し、「あ、プロキシ設定ファイルは http://192.168.1.100/proxy.pac にあるんだな」と理解する。
4. HTTPでPACファイルをダウンロード
   • PCは教えてもらったURLに対してHTTPリクエスト（GET /proxy.pac）を送り、PACファイルをダウンロードしてブラウザに設定を適用する。

設問３（１）に戻る

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 というグループの一員だ」と認識する。

設問１

（１）ア：カスタマー　イ：再配布　ウ：DMZ　エ：eBGP　オ：プライベート　カ：ポリシーベース

ア：カスタマー/イ：再配布/エ：eBGP/オ：プライベート
　この空欄に関しては知識問題であるため説明は割愛

ウ：DMZ　

問題の雰囲気的に「インターネット・OSPF・配布」という単語から、つい「デフォルトルート」と回答してしまうかもしれない。しかし、その単語をいれると「デフォルトルートのサブネットを～」と書いてあり、文章として成立しなくなってしまう。デフォルトルートは特定のサブネットではないから！
文脈として可能性が最も高いのは「インターネットアクセス、特定のサブネット、HTTP/HTTPS」という単語からプロキシサーバが配置されているDMZという回答になる。

Q.DMZではなく、プロキシサーバ単体で広告すれば？
DMZのプレフィックスよりもプロキシサーバ単体でよくね？
A.大抵の場合、DMZには複数の機器が収容されている。そのため、それらを一つずつ広告するとエントリー消費が無駄になる。なので、DMZのプレフィックスでまとめて広告している。

Q.プロキシサーバまで行くのはPACファイルで登録すればいいのでは？
PACファイルなどでPC内にデフォルトルートでプロキシサーバの場所を埋め込んじゃえば、プロキシサーバに関する広告は不要では？
A.PACファイルはプロキシのIPはわかるが、経路まではわからない。広告をすることで経路が明確になる。以下、フローで確認しよう。
▼PCからプロキシまでのフロー
① PCがPACファイル参照（宛先: プロキシIP）
② 最寄りのL3SWへ送信
③ L3SWはOSPFで学んだ「DMZサブネット宛て」の経路に従いルータへ
④ ルータからMPLS VPN（BGP）を渡ってデータセンターのPE1/ルータ1へ
⑤ 本社のL3SW1 ➔ FW ➔ DMZ内のプロキシサーバーに到着！
このように、宛先に届かすには経路広告の情報が必要となる。

カ：ポリシーベースルーティング
　ポリシーベースルーティングとはルーティングプロトコルによって導きだされたSPFではなく、定義したポリシー（条件）ごとにルーティング経路や優先度を変更させること。逆を言えば、最適経路以外でも、余裕で使われるということ。

設問２

（１）a: 10.3.0.0/16　b:64500 64500

a:10.3.0.0/16
これに関しては、支店Vの経路情報が届いているので、表２より支店Vのプレフィックスである10.3.0.0/16を書けばよい。

b:64500 64500
　as-overrideを使うと、AS-PATHが上書きされる。G社のASは65500だとわかるので、64500がL社のAS番号であるとわかる。つまり、65500を64500で上書きするだけなので、64500 64500となる。
＊ちなみにAS-PATHは右側が発信源で、左にどんどん追加していく。なので、「50000 60000 70000」というようなAS-PAHTがあったら、70000が最も遠く50000が最も自分の近くにあるASであると判断できる。

設問３

（２）タイプ：Type５　機器：ルータ３

まずは背景を整理しよう。
　背景：
　　・データセンターからのDMZに関する広告がBGPを経由して流れてくる
　　・で、その広告がOSPFに入るときにどのタイプになるか
　　・また、そのOSPF広告を流したのはだれか？
ということから答えを導いていこう。

まず、BGPからOSPFに経路が入るということは外部経路なのでType５であることが分かる。で、かつ、外部経路をOSPFに変換する機器はどこか？と考えると、BGPとOSPFの両方のプロトコルが稼働しているのはルータであることが分かる。で、問題では支店V社にフォーカスしているので、支店V社におけるルータはルータ３なので答えはルータ３となる。

設問４

（１）IPsecトンネル確立のためのIPアドレス、IPsecトンネル確立のための鍵情報

では、まずはSD-WANとかは置いといてIPsecに必要な情報を整理していこう！
▼IPsecに必要な情報
・相手のIPアドレス
・認証用の鍵情報
・暗号化方法
・認証方法
・ハッシュ方法
・Diffie-Hellmanのグループ番号
・ライフタイム

crypto isakmp key パスワード address 相手のIPアドレス #相手のIPアドレス＆認証用の鍵情報
crypto isakmp policy ポリシー番号
 encryption aes #暗号化方法
 authentication pre-share #認証方法
 hash sha256 #ハッシュ方法
 group 14 #Diffie-Hellmanのグループ番号
 lifetime 3600 #ライフタイム

以上の情報の中で、相手が変わっても変化がない情報は「暗号化方法・認証方法・ハッシュ方法・Diffie-Hellmanのグループ番号・ライフタイム」である。逆に相手に応じてかける必要がある情報は「相手のIPアドレス・認証用の鍵情報」である。
言い換えると、前者の相手が変わっても変化がない情報はSD-WANコントローラーがポリシーとして一括配布できる情報である。一方、後者はSD-WANルータ毎に配らなければならない情報である。

上記の前提を念頭に置いたうえで、問題文を確認すると「SD-WAN装置ごとの～と、IPsecトンネルを構築するための情報」と書かれているので、SD-WAN装置毎に送らなければならない情報は相手のIPアドレス・認証用の鍵情報である。

（２）IPsecトンネルに障害があった場合の検出を高速にする

BFDとはBidirectional Forwarding Detection（双方向転送検出）の略。通信経路（トンネルや物理リンク）の障害をミリ秒単位で超高速に検知する軽量プロトコル。
そのため、BFDを使うことで、IPsecトンネルに障害があった場合の検出を高速にすることができる。

また、障害検知だけでなく、以下のように👇より細かな情報も取得できる。
レイテンシー（遅延）： パケットの往復にかかる時間
パケットロス（欠損率）： 通信がどれくらい途切れているか
ジッター（パケブレ）： 遅延の揺らぎ・ばらつき

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

p.9 支店が追加されたら、どのような変更があるの？ｰｰｰｰｰｰｰｰｰｰｰｰｰｰ

Q.視点を追加すると変更作業が起きると書かれている。が、実際にはどのような変更作業があるのか？

A.結論から言うと、現行構成（MPLS VPN＋BGP/OSPF）のまま支店を増やす場合、「新規支店以外の既存拠点（データセンターや本社など）」でのルータ設定変更作業はほぼ発生しない。
新規拠点側ではルータのコンソールに接続し、IPアドレス、eBGP設定、OSPF再配布、ルートフィルタなどを1台ずつ手動でコマンド設定（CLI）する必要がある。しかし、新拠点のサブネット情報は、BGPとOSPFの再配布によって自動的にデータセンターや本社、他支店へ伝播する。そのため、既存ルータの設定をわざわざいじる必要はない。

p.9 現行構成における課題と、SD-WAN導入による改善点

Q.どうやってSD-WANはゼロタッチプロビジョニングを実現しているの？

A.コントローラからポリシーを配布してもらっている。では、フローを見ながらSD-WANにおけるゼロタッチプロビジョニングを確認していこう！

▼SD-WAN 起動〜設定完了までの詳細フロー
1：出荷および事前準備（ベンダーX社・クライアントA社）

• 機器の出荷と登録（X社）： X社はSD-WANルータを工場から発送する際、そのルータの個体識別情報（シリアル番号やMACアドレス等）と「A社」の顧客情報を紐づけて、自社の「中央集権型ZTPリダイレクトサーバー」のデータベースに登録する。
• 初期ハードコーディング（X社）： ルータのファームウェアには、無条件で「X社の中央集権型ZTPリダイレクトサーバー（例: ztp.vendor-x.com）」へアクセスする宛先情報が最初から組み込まれている。
• 事前にコントローラーでのポリシー定義（A社）： A社のネットワーク管理者は、クラウド上の「A社専用SD-WANコントローラー」の管理画面にて、新規追加するルータのシリアル番号を指定し、適用させたいネットワーク設定（IPアドレス、BGP/OSPF、IPsecトンネル、VPNポリシーなど）を作成しておく。

2：現地設置および自動リダイレクト（現地・ZTPサーバー）

• 現地設置と電源投入（現地）： 現地作業員（専門知識不要）がルータを箱から取り出し、LAN/WANケーブルを挿して電源を入れる。
• 中央サーバーへのアクセス（ルータ ➔ X社ZTP）： ルータは起動後、ハードコードされた宛先（ztp.vendor-x.com）へ自動で通信を行い、「私のシリアル番号は SN12345 です。私の接続先コントローラーを教えてください」とリクエストを送信する。
• 契約情報の照合と案内（X社ZTP ➔ ルータ）： X社ZTPサーバーは、受信したシリアル番号 SN12345 をデータベースと照合し、「この機器はA社所有」であることを特定する。特定後、ルータに対して「A社専用コントローラーのFQDN/IPアドレス（例: controller.a-company.com）」を応答（リダイレクト案内）する。

3：認証および設定ファイルの適用（ルータ ➔ A社コントローラー）

• 専用コントローラーへの接続（ルータ ➔ A社コントローラー）： ルータは案内された「A社専用コントローラー」へアクセスし、証明書等を用いて安全な暗号化通信（TLSトンネル）を確立する。
• 設定データ（構成定義）の配布（A社コントローラー ➔ ルータ）： A社コントローラーは、接続してきたルータのシリアル番号を認証し、あらかじめ準備しておいた設定データ（JSON、XML、YANGモデル形式など）をTLSトンネル経由で流し込む。
• 設定の自動反映（ルータ内部）： ルータ内のOS（エージェント）が受け取った設定データを解析し、ルーティングテーブルの構築、IPsecトンネルの確立、OSPF/BGPプロセスの起動などを自動で実行・適用する。

4：開通・運用開始

• オーバーレイ網の確立と開通： 設定完了後、他の拠点のSD-WANルータとの間で自動的にIPsecトンネルが立ち上がり、オーバーレイネットワークの通信がスタートする。

Q.従来のZTPとSD-WANのZTPの違いは？

正直、従来環境でもZTPはできていた。従来の普通のルータ（制御と転送が一体化している機器）でも、DHCP Option 66/67やTFTP/FTPサーバーを使って「電源を入れたら自動で設定ファイルをダウンロードして適用する」というZTP（自動構築）の仕組みは存在していた。しかし、それはあくまでも静的なコマンド投入である。
一方、SD-WANはコマンドではなく、ポリシーをZTPで配布している。そして、そのポリシーを解釈して実際に動作に落とし込むのはSD-WANルータ自体の仕事。つまり、動的な設定を投入することができるようになったということが従来とSD-WANでは違う。

Q.ってか、、そもそもWANって何？

A.「自社の敷地や所有設備を出た外側の領域全体」をWAN（Wide Area Network）という。

Q.SD-WANのインターネット通信に対するアプローチはどういう感じ？

SD-WANルータは基本的にSD-WANコントローラの制御に従う。これは当たり前だが、SD-WANコントローラ配下の拠点間だから成立する。しかし、インターネット接続（Google、Yahhoo、一般Webサーバ）の場合は、それらのサーバはSD-WANコントローラ配下にはない。なので、通常の拠点間通信とは異なるアプローチによって経路が選択される。

▼拠点間通信とインターネット通信の違い

SD-WANコントローラー配下の拠点間通信（自社拠点 ⇔ 自社拠点）

• アプローチ: 「双方向の協調制御」
• 送信側と受信側の両方にSD-WANルータ（CE機器）が存在。
• お互いに制御パケット（BFDなど）を送り合うことで、遅延・パケットロス・ジッターを双方向でリアルタイム測定し、コントローラーが定めたポリシーに従って最適なトンネル（IPsec）へパケットを動的に流す。

インターネット通信（自社拠点 ➔ 一般Webサーバ / SaaSなど）

• アプローチ: 「片側（送信側ルータのみ）での単独制御」
• 相手（Google、Yahoo!、Microsoft 365など）は自社のSD-WANコントローラーの制御配下にはない。
• そのため、送信側のSD-WANルータが単独でアプリケーションを識別（DPI）したり、片道のレスポンス速度を測定したりして、「自社の出口回線（MPLS経由か、一般インターネット回線へのローカルブレイクアウトか）」をポリシーに基づいて判断・選択する。

▼取得できる情報の違い

Q.もし回線が1つしかなかったらSD-WANを導入する意味なくね？

Q1.そもそもSD-WANの目的はポリシーによって動的な経路制御をすることである。しかし、そもそもの回線が１つしかなかったら、動的に経路制御しようと思っても結局１つしか道がないんだからポリシーによる動的制御しても意味なくね？
Q2.また、ZTPに至っても、自社で初期の設定コマンドなどのコンフィグを自社サーバなどに配置して、起動時にそれを取得するようにハードコーディングしておけば、それによって一元的なポリシー割り当ても可能になるのでは？
ということから、回線が１つであればSD-WANを導入する意味ってなくね？

A.では、疑問を一つずつ答えていこう！
A1.「回線が1本なら動的ルーティング（経路切替）の意味がない」 ⇒ 【100% 正解】 逃げ道の回線がない以上、どれだけリアルタイムに遅延やパケットロスを検知しても、その回線を通すしかない。

A2.「ZTP（ゼロタッチ）や一括設定投入だけなら、SD-WANじゃなくてもできる」 ⇒ 【100% 正解】 従来のルータでもDHCP/TFTPやAnsible等の構成管理ツール、独自ZTPサーバーを使えば初期設定の一括配布は可能。

Q.では、回線1本でもSD-WANを入れるメリットとは何か？

「回線が1本」という条件であっても、SD-WAN（クラウドコントローラーによる一元管理）を導入するメリットは主に3つある。

① 「ZTPそのもの」ではなく「開通後の継続的な集中管理（Day 2 Operation）」
　従来のZTP（TFTP等）は「最初の設定を入れる時（Day 1）」だけの仕組み。 開通後に「セキュリティポリシーを変更したい」「新しい通信を許可したい」となった場合、従来方式では全拠点のルータに個別ログイン（CLI）して設定変更を打ち込む必要がある。 SD-WANであれば、コントローラーのUI上でポリシーを1回変更するだけで、全国100拠点のルータへ一瞬で変更が波及・同期される。

② 「アプリの可視化」と「優先度制御（QoS）」
　回線が1本しかないからこそ、帯域の奪い合いが発生する。

• 状況： 1本しかない回線で、誰かが巨大なファイルをダウンロードして帯域を圧迫した。
• SD-WANの動作： アプリケーション識別（DPI）機能により、「Web会議（Teams等）」のパケットを最優先し、「ファイルダウンロードや動画視聴」の帯域を動的に制限（QoS）する。 経路変更はできなくても、「1本の回線の中でどのアプリを優先して通すか」という帯域制御（シェーピング）が強力に働く。

③ セキュリティ連携（SASE / SSE への発展性）
　現在、1回線（インターネットVPN）の拠点でSD-WANを入れる最大の理由はクラウドプロキシ（ZscalerやPalo Alto Prisma Access等）との自動連携。

• ローカルブレイクアウトの簡略化： クラウド型セキュリティ（SASE）へ通信を飛ばすための暗号化トンネルの設定や、IPアドレス変更への自動追従をコントローラーがすべて自動で行ってくれる。

p.9 MPLSとは?———————

MPLS（Multi-Protocol Label Switching）とはIPヘッダの宛先IPアドレスを見る代わりに、パケットに付与した短い『ラベル』を見て超高速に転送（スイッチング）する技術。
しかし、現在のルータではMPLSと同等レベルの転送処理が可能になってきているので、高速転送というメリットは薄くなってきている。

p.9 MPLSとMPLS VPNの違いは？

Q.MPLS VPNのフローは？———————–

G社の本社CEから支店CEへ「10.1.0.0/24（本社）」の経路を教える流れを見ていこう！

[本社CE] ➔(eBGP/OSPF)➔ [PE-1] ➔=== (MP-BGP) ===➔ [PE-2] ➔(eBGP/OSPF)➔ [支店CE]

1. コントロールプレーン（経路広告のフロー）
①アンダーレイ構築：
　PE-1、P（中継）、PE-2 間でOSPF/IS-ISとLDPを動かし、事業者網内の全ルータが「PE-1やPE-2のループバックIP」へ届く状態（トランスポートラベル）を作る。
②CE ➔ PE-1（経路の受領）：
　本社CEがPE-1の「G社用VRF」へ 10.1.0.0/24 を広告。
③PE-1 での加工（VPNv4化）：
　PE-1は受け取った 10.1.0.0/24 に以下を付与する。
　　・RDをくっつけて「一意なVPNv4アドレス（例: 65000:1:10.1.0.0/24）」に変換。
　　・RT（エクスポートタグ）を付与。
　　・G社用VRF宛てであることを示す「VPNラベル（内側ラベル）」を自動採番。

④PE-1 ➔ PE-2（MP-BGPで広告）： PE-1は対向のPE-2へ、MP-BGPを使って上記の情報を一括送信。

⑤PE-2 での取り込み： PE-2は届いたRTタグを見て「G社用VRF」に合致することを確認。RDを外して元の 10.1.0.0/24 に戻し、G社用VRFのルーティングテーブルへ登録。

⑥PE-2 ➔ 支店CE： 支店CEへ 10.1.0.0/24 を広告。

2. データプレーン（実際の通信フロー）

支店CEから本社（10.1.0.0/24）へパケットを送る際の流れです。

1. 支店CE ➔ PE-2： 普通のIPパケット（宛先: 10.1.0.1）をPE-2のG社用VRF宛てに送信。
2. PE-2 での2重ラベル付与：
   • 内側（VPNラベル）： MP-BGPでPE-1から教えてもらった「G社VRF識別用ラベル」を貼る。
   • 外側（トランスポートラベル）： LDPで知った「PE-1（目的地）まで運ぶためのラベル」を貼る。
3. Pルータ（中継）： 外側ラベルだけを見て、ラベルを付け替えながらPE-1へ超高速転送（内側ラベルやIPヘッダは見ない）。
4. PE-1 到着：
   • 外側ラベルが剥がれ（※直前のPルータで剥がれるPHP機能が一般的）、PE-1には「内側ラベル＋IPパケット」が届く。
   • PE-1は内側ラベルを見て「これはG社VRF行きだ」と判断し、ラベルを剥がしてG社VRFのルーティングテーブルを参照。
5. PE-1 ➔ 本社CE： 生のIPパケットとして本社CEへ渡す。

LDPのメカニズム＆フロー

OSPFで経路ができた後、LDP（Label Distribution Protocol）がどうやってラベルのバケツリレー表を作り上げるのか、そのメカニズムをステップ順に解説します。

▼前提コンポーネント
　CE1（本社） / CE2（支店）： 顧客（G社）のルータ
　PE1 / PE2： 事業者（L社）のエッジルータ（VRFを設定）
　P： 事業者（L社）のコア中継ルータ（VRFは存在しない）

ステップ1：アンダーレイIGP（OSPF/IS-IS）の確立

　・事業者内のルータ（PE1, P, PE2）間でOSPFまたはIS-ISを起動。
　・これにより、事業者網内の全ルータが「互いのIPアドレス（Loopback等）」に届く状態を作る。

ステップ2：LDPによるトランスポートラベル（外側）の配布

　・LDP（Label Distribution Protocol）が起動し、IGPで学習した宛先（特にPEのLoopback IP）に対してラベルを割り当てる。
　・動作： 下流（PE2）から上流（PE1）に向かって、「PE2宛てのパケットはラベルXで送ってくれ」とバケツリレー式にラベル情報（外側ラベル）を伝播し、全ルータにLFIB（ラベル転送表）を構築する。（このプロセスのわかりやすい具体例はこちら）

ステップ3：PEルータでのVRF・RD・RTの設定

　・PE1およびPE2に顧客（G社）用の仮想ルータ（VRF）を作成する。
　・RD（Route Distinguisher）： 他社とIPが重複しても一意に識別できるよう、IPプレフレフィックスの先頭に付与する（例：65000:1 + 10.1.0.0/24 ➔ 65000:1:10.1.0.0/24 というVPNv4アドレスを生成）。
　・RT（Route Target）： どのVRFに経路を取り込むかを制御するタグ（Export/Importルール）を設定する。

ステップ4：CE ➔ PE 間の経路学習

　・CE1（顧客G社本社）が自身の持つ経路（10.1.0.0/24）をPE1へ広告する（eBGPやOSPF等を使用）。
　・PE1は届いた経路を「G社用VRF」のルーティングテーブルに登録する。

ステップ5：PE1でのVPNラベル（内側）自動採番とMP-BGP広告

　・PE1は、顧客G社VRF宛てを引き込むためのVPNラベル（内側ラベル、例: 1001）を内部で自動生成する。
　・PE1はPE2に対して、MP-BGP（iBGP）を使って以下の情報をセットで広告します。
　　・VPNv4アドレス： 65000:1:10.1.0.0/24
　　・ネクストホップ： PE1のIPアドレス
　　・内側ラベル： 1001
　　・RTタグ： Export RT（例: 65000:100）
　　・内側ラベルのわかりやすいプロセスはこちら

ステップ6：PE2でのRT照合とVRFへの取り込み

• PE2はMP-BGPで受信した経路のRTタグ（65000:100）を確認します。
• 自身のVRFに設定されたImport RTと一致したため、RDを取り除いて普通のIPv4（10.1.0.0/24）に戻し、G社用VRFテーブルへ登録します。
• PE2はG社VRFからCE2（支店）へこの経路を広告します。

▼外側ラベルの配布メカニズム＆フロー

直感的に理解できるように、ルータを1列に並べた超シンプルな具体例で解説していこう！
＊ルータが4台一直線に並んでいる場合

目的は、PE1からゴールである「PE2（IP: 2.2.2.2）」へパケットを届けること。
[PE1] ─── [P1] ─── [P2] ─── [PE2]

▼LDPのバケツリレー（ラベルの通知フロー）
LDPはゴールのPE2から始まって、下流から上流へ向かってメッセージを送っていく。

① PE2 ➔ P2 への通知
　・PE2の主張： 「P2さん、僕（2.2.2.2）宛ての荷物を持ってくるときは、ラベル10を貼って渡してね！」
　・P2の処理： P2はメモする。
　　[メモ：PE2（2.2.2.2）に行くなら ➔ ラベル10を貼ってPE2へ投げる]

② P2 ➔ P1 への通知
　ここが疑問のコア！P2は「ラベル10」をそのままP1に教えるのではなく、P2自身が新しい番号（ラベル20）を勝手に決めてP1に伝える。
　・P2の主張： 「P1さん、PE2（2.2.2.2）宛ての荷物があるなら、僕にはラベル20を貼って渡してね！」
　・P1の処理： P1はメモする。
　　[メモ：入力ラベル20が来たら ➔ ラベル10に付け替えてP2へ投げる]

[PE1] ーーーーーーーーーーー [P1] ーーーーーーーーーーー [P2] ーーーーーーーーーーー [PE2]
      ←2.2.2.2はラベル30　　　　　←2.2.2.2はラベル20　　　　←2.2.2.2はラベル10
                      

③ P1 ➔ PE1 への通知
　P1も同じように、自分専用の新しい番号（ラベル30）を決めてPE1に伝える。
　・P1の主張： 「PE1さん、PE2（2.2.2.2）宛ての荷物は、僕にはラベル30を貼って渡してね！」　
　・PE1の処理： PE1はメモする。
　　[メモ：PE2（2.2.2.2）行きパケット ➔ ラベル30を貼ってP1へ投げる]

▼実際のデータ（パケット）が流れる
全ルータが「隣のルータから指定されたラベル」に貼り替えながら投げるので、パケットは無事に届きくようになる。

1. PE1： PE2行きのパケットに、P1から頼まれた「ラベル30」を貼ってP1に投げる。
   ＊入り口部分のPEルータでは、IPアドレスも確認する。そして、「あ、このIPアドレス宛はこのラベルだなと」判断してラベルを付与。以降のPルータはラベルのみで転送する。
2. P1： 「30」が届いたので、P2から頼まれた「ラベル20」に貼り替えてP2に投げる。
3. P2： 「20」が届いたので、PE2から頼まれた「ラベル10」に貼り替えてPE2に投げる。
4. PE2： 「10」が届いたので、自分宛てだと分かって受領する。

👆ステップ２の解説に戻る

▼内側ラベルの配布メカニズム＆フロー

出口側であるPE1（本社側）が顧客網（CE1）から経路を学習し、入口側であるPE2（支店側）へ内側ラベルを配るまでの流れを見ていこう。

[CE1] ーーーーーー [PE1] ーーーーーー [P1] ーーーーーー [P2] ーーーーーー [PE2]
              

1.PE1：CE1からIPv4経路を学習:
　VRF内での処理。
　・PE1は、接続されているCE1（顧客本社）から普通のIPv4経路（例: 10.1.0.0/24）を学習し、顧客A用のVRF-Aに登録する。
　・検証: PE1の show ip route vrf VRF-A で 10.1.0.0/24 が見えれば成功。

2.PE1：VPNv4アドレスへの変換と内側ラベルの採番:
　・MP-BGPでの処理。
　・PE1は、この経路を対向のPE2へ通知するために次のように加工。

1. RDの付与: IPv4経路の頭にRDを結合し、VPNv4アドレスに変換する（65001:100 : 10.1.0.0/24）。
2. 内側ラベルの採番: このVRF-A宛て専用の内側ラベル（例: 1001）を自前で1つ割り当てる。
3. RT（Export RT）の付与: 判定用のRTタグ（例: 65001:10）を付与する。

　・検証: PE1のBGPテーブル（show bgp vpnv4 unicast all）で、VPNv4経路にラベル 1001 が紐付いていれば成功。

3.PE1 ➔ PE2：MP-BGP UPDATEメッセージの送信:
　・PE間（iBGP）通信。
　・PE1は、MP-BGP（iBGP）を使ってPE2へアップデートメッセージを直接送信する。
　・途中のPルータはこの通信を単なるIPパケット（あるいはBGPパケット）として透過するだけで、中身は見ない。

• 送信される内容:
  • Destination (NLRI): 65001:100 : 10.1.0.0/24（VPNv4アドレス）
  • VPN Label: 1001（内側ラベル）
  • Route Target: 65001:10（Export RT）
  • BGP Next-Hop: 192.168.1.1（PE1のLoopback IPアドレス）

4.PE2：RT判定とVRFへの取り込み:
　Import処理。
　・メッセージを受け取ったPE2は、付与されているRT（65001:10）を確認する。
　・PE2の「VRF-A」に設定された Import RT と一致するか判定。
　・一致した場合、RDを取り除いて元のIPv4経路（10.1.0.0/24）に戻し、PE2の「VRF-A」のルーティングテーブルに登録します。
　・このとき、ネクストホップ 192.168.1.1（PE1）へ向かうための内側ラベルとして 1001 を内部テーブル（LFIB）に記憶します。
　・検証: PE2の show ip route vrf VRF-A に 10.1.0.0/24 が登録され、ネクストホップがPE1のIPになっていれば完了。

▼実際のパケットが転送される
＊支店（CE2）から本社（CE1: 10.1.0.1）宛てにパケットが送信されたときのラベル挙動。

[CE2] ──(生のIP)──> [PE2 (入口)] ──(2重ラベル)──> [Pルータ網] ──(内側のみ)──> [PE1 (出口)] ──(生のIP)──> [CE1]

1. PE2（入口ルータ）でのルックアップ:
   CE2から送られてきた生のIPパケット（宛先: 10.1.0.1）を「VRF-A」で検索。
2. 2重ラベルの着せ替え（Push）:
   • 内側ラベル (1001): MP-BGPでPE1から教わった「VRF-A識別用ラベル 1001」を貼る。
   • 外側ラベル (30): LDPで隣のPルータから教わった「PE1（192.168.1.1）へ運ぶ用のトランスポートラベル 30」を上から重ねて貼る。
3. 網内（Pルータ）の転送:
   Pルータ群は外側ラベル（30）だけを見てバケツリレー（Swap）を行います。内側ラベル 1001 は隠されたままで無視される。
4. PE1（出口ルータ）でのカプセル解除（Pop）:
   • 外側ラベルが剥がされた状態でPE1に届く（※PHP機能により直前のPルータで外側が剥がされている場合もある）。
   • PE1は残った内側ラベル 1001 だけを見て、「あ！これはVRF-A向けの荷物だ！」と一瞬で判断する。
   • 内側ラベル 1001 を剥がし、生のIPパケットに戻してCE1（本社）へ送信する。

step5に戻る👆

Q.なんでRDタグが必要なの？

Q.RTタグがあるなら、RDっていらなくね？だって、複数の会社で同一のプレフィックスを使っていても、RTで分ければ、問題なくね？
A.RDが必要になる理由はPEルータ内のBGPプロセス内で経路を識別するため。参考書に乗っているRDの説明を聞くと「コアネットワーク内で経路を一意に識別するため」と書かれてミスリーディングをされることがある。そもそも、RDの内容をコアルータは見ないので、これは完全なミスリーディングとなる。
実際は、PEルータ内のBGPプロセスにおいて、同じプレフィックスがあると属性などから最適な経路のみが登録されることになって、それ以外が破棄されてしまうから。

Q.もしRDがないと？

・パターン１：
　PEルータが複数の会社から同一プレフィックスを広告するときに、BGPプロセス内で「あ、これ同一プレフィックスだから１番いい経路だけ広告して他は破棄しよ」となってしまい、広告されなくなる。

・パターン２：
　PEルータが複数の同一プレフィックスから経路を受信しても、その中から最も良い経路のみがテーブルに登録される。たとえ、RTで別々のVRFに登録してね！と明示してあったとしても、それを確認する前にBGPプロセスで最良経路が選択されて、最良経路のみのVRFに登録される。ほかのVRFには登録されなくなる。

Q.CEルータとPEルータはどうやってつながっているの？

CEルータとPEルータはどのようにつながっているのか？専用線のようなものを施設しているのか。それとも、なにか別の接続方法でつながっているのか。それを紐解いていこう！
A.「顧客ビルから通信事業者の設備（PEルータ）まで物理的なアクセス回線（光ファイバーなど）を直接引き込んで接続する」のが一般的。
インターネット経由で自宅のルータからVPNを張る（IPsec VPN等）のとは異なり、MPLS VPNは「暗号化を使わない代わりに、物理・論理的にインターネットから完全に孤立させた閉域網を使う。拠点（CE）からPEルータまでの間に「何が存在し、どう繋がっているのか」を以下で詳細を記す。

▼MPLS VPNにおけるCEとPEのフロー

[顧客ビル]                                 [通信事業者（L社）の拠点]
┌───────┐      ┌────────┐                  ┌────────┐      ┌────────┐
│  CE   │ ───> │ ONU /  │ ═══════════════> │ L2/L3  │ ───> │   PE   │
│ルータ │ (LAN)│ ONU(ONU)│   アクセス回線   │ 網装置 │ (LAN)│ルータ  │
└───────┘      └────────┘  (光ファイバー)   └────────┘      └────────┘
                           └───────────────┘
                              ↑ 中間にNTTなどの
                                ダークファイバや
                                網内スイッチが存在

物理的なアクセス回線（光ファイバーやONU）の仕組み自体は、個人宅の光回線（フレッツ光など）と全く同じ。
特別な「MPLS専用の魔法の光ファイバー」が地中に埋まっているわけではない。違いは物理回線ではなく、「集約局（基地局/収容局）でどの網へ振り分けるか（スイッチング）」という論理的な出口（VLANやポート）の話。

Q.再配布のループ防止方法は？——————

本文中では「ループ防止のため経路フィルターを設定」としか書かれていないため具体的なイメージがわかない。なので、ここでは再配布時に発生するループを防ぐ方法を具体的に見ていこう！

手法1：ルートタグ（Route Tag）を使う方法【推奨・最もスマート】

再配布するときに経路へ「目印（数字のタグ）」を貼り付け、そのタグが付いた経路が入ってきたら再配布を拒否する手法。
仕組み：
　・OSPFからBGPへ渡すとき：「タグ 100」 を貼って再配布する
　・BGPからOSPFへ渡すとき：「タグ 100」が付いている経路は再配布をブロックする。
Cisco IOSでの設定コマンド例👇

#① タグを定義するルール（Route-map）を作成
route-map OSPF-TO-BGP permit 10
 set tag 100      #再配布する経路に「100」のタグを貼り付ける

route-map BGP-TO-OSPF deny 10
 match tag 100    #「100」のタグが付いた経路は拒否（再配布しない）
route-map BGP-TO-OSPF permit 20
                  #その他の経路は許可

#② BGPプロセス側で再配布を設定
router bgp 65001
 redistribute ospf 1 route-map OSPF-TO-BGP  #タグ100を貼ってBGPへ入れる

#③ OSPFプロセス側で再配布を設定
router ospf 1
 redistribute bgp 64512 subnets route-map BGP-TO-OSPF  #タグ100付きを拒否してOSPFへ入れる

手法2：ディストリビューションリスト（Prefix-list）を使う方法

自拠点のIPプレフィックスを明示的に指定してフィルタリングする手法。
　仕組み：
　　「自社のIPアドレス範囲（例: 10.0.0.0/8）はBGPからOSPFへ絶対に再配布しない」というフィルターを直書きする。
　デメリット：
　　拠点やネットワークが増えるたびにルータのリストを手動で更新する必要がある（タグ方式の方が自動化できるため実務では好まれる）。

#プレフィックスリストの場合
ip prefix-list prefix_リスト seq 10 deny 10.0.0.0/16
ip prefix-list prefix_リスト seq 20 permit 0.0.0.0/0 le 32

#ACLの場合
access-list ACL名 deny 10.0.0.0 0.0.255.255
access-list ACL名 permit any

router ospf プロセス番号
 distribute-list prefix prefix_リスト名 in #プレフィックスリストの場合
 distribute-list ACL名 in #ACLの場合
 area 1 filter-list prefix prefix_リスト in #エリア1に入ってくるSAを制限
 
*filter-listはprefix-listしか対応していない。
また、BGPのfilter-listはas-pathリストにしか対応していない。

p.12 SD-WANコントローラとエッジルータのmTLS通信とは?——————

mTLS通信とは、Mutual TLS（相互TLS認証）の略でクライアントとサーバーの「双方が」お互いにデジタル証明書を提示し合い、「お前は誰だ？」「お前こそ誰だ？」と互いの身元を確認する通信方式のこと。一般的なWebアクセスではクライアント側が証明書を提供しない、いわば片方向のTLSであることが多い。しかし、クライアント側も証明しなければならないときは、双方向のTLS、つまりmTLSが必要となる。

Q.証明書はだれが？いつ？発行してくれるの？
誰が発行したかをわかっていないと、事前にどのルートCAの証明書をインストールしておくかわからない
A.SD-WAN機器の製造ベンダー（Cisco等）が運営する認証局（ベンダー独自CA）が、工場出荷時（製造工程）に機器固有のクライアント証明書を発行する。 機器側には、このクライアント証明書および秘密鍵、そして検証用のベンダーのルートCA証明書が、TPM等の耐タンパー性を持つ暗号チップ内（ハードウェア領域）にあらかじめプリインストール（組み込み）される。

Q.OMPってなに?————————

Q.SD-WANを勉強していると必ずと言っていいほど、OMPが出てくる。何かの情報を運ぶんだろうなぁという解釈はあるが、いまいちわかっていない。。。なので、ここですっきりしていこう！

A.OMPとはOverlay Management Protocolの略でCisco SD-WAN（旧Viptela）独自で動作するコントロールプレーン用プロトコル。コントローラーとSD-WANルーター間で、オーバーレイ網の構築に必要な各種情報を一括してやり取りする「司令塔通信の言葉」。
一言で言うと、OMPは「拠点同士が直接IPsecトンネルを張るための仲介役（ルーティング＆鍵情報・IP情報の動的交換プロトコル）」。

mTLSでコントロールプレーンが確立された後、コントローラーとルータの間でこの「OMP」という独自ルーティングプロトコルが動き出す。具体的には、以下の3つの情報をOMPでやり取りしている。

１. 相手のIPアドレスや暗号鍵の交換（TLOC情報）
　・ルータAは「自分の今のWAN側IP」や「IPsec用公開鍵」を、OMPに乗せてコントローラーへ送る（収集）。
　・コントローラーは、「対向ルータBのWAN側IP」や「対向ルータBの公開鍵」をOMPに乗せてルータAに配る（配布）。
　・これによって、ルータAとルータBが手動設定なしで直接IPsecトンネルを全自動で張れるようになる。

2. 各拠点配下のLANのルーティング情報（OMP Routes）
　・「拠点Aの配下には 192.168.10.0/24 があるよ」「拠点Bの配下には 192.168.20.0/24 があるよ」というLAN側のルート情報をOMPでコントローラーへ送る。
　・コントローラーがこれを全拠点のルータへ配ることで、各拠点ルータのルーティングテーブルに自動的に相手拠点のルートが追加される。

3. サービスやセキュリティポリシー情報（Service Routes / Policies）
　・「ファイアウォールはデータセンターを通せ」「Teams通信は各拠点から直出し（ブレイクアウト）しろ」といった動的な経路変更指示をOMPで配る。

Q.なんでわざわざOMPを使うの？

OMPを使わずにHTTPやmGRE/NHRPなどの既存の技術を使っても実現できそうなのに、なんでわざわざ、面倒くさそうなOMPを導入しているの？決められたフォーマットを使えばまとめて情報を送れるから？でもそれも、JSONとか使えばHTTPでもフォーマット作ってまとめて送れるよね？あと、HTTPはステートレスっていうけど、セッションの保持時間を長くすればたとえNAT環境とかでもコントローラからの通信を受け取れるよね？

A.既存技術（HTTPやmGRE/NHRP）では、数千台規模の大規模企業網の制御、多重回線の集約、複雑なポリシー制御に耐えられないから。

▼OMPとHTTPの違い
OMPはルーティングプロトコルそのもの。つまり受け取ったポリシーからスムーズにルーティングに落とし込むことができる。一方HTTPはただデータを運ぶだけなので、受け取った後に再度、プログラムを稼働させてからでなければルーティングに落とし込むことができない。いわば無駄なオーバーヘッドが生まれてしまうということ。なので、OMPを使うべき。

Ｑ．OMPで配布する情報とそれ以外で配布する情報の違いは？

要は、拠点に依存しない設定であればZTP直後に配布する。逆に拠点依存の設定はOMPで動的に配布するという棲み分けがある。

Q.SD-WANにおけるIPsec構築フロー

1. 初期生成（ローカル）：各エッジルーターは起動時、内部でDH鍵ペア（秘密鍵 a, 公開鍵 A）を生成する。
   • 公開鍵 A の計算式: A＝ g^a mod p (g と p は共通ポリシーで固定指定された値）
2. OMPによる集約と配布（制御プレーン）：ルーターは自身の「WAN側IP」「UDPポート」「公開鍵 A」などをセット（TLOC Route）にして、OMPでコントローラーへ送信。コントローラーはこれを全拠点へ一括配布する。
3. 共通鍵の自動導出（ローカル）：拠点1は、OMPで届いた「拠点2の公開鍵 B」と「自分の秘密鍵 a」を掛け合わせ、共通鍵 K を計算する。
   • 拠点1の計算: B^a mod p = (g^b)^a mod p = g^ab mod p
   • 拠点2の計算: A^b mod p = (g^a)^b mod p = g^ab mod p
     双方の手元で交渉なしに全く同じ共通鍵 K が完成する。
4. 事前確立とデータ通信（データプレーン）：通信が発生する前にバックグラウンドでIPsecトンネルを開通。実際のデータ通信時には、導き出した共通鍵 K（AES）で高速に暗号化・復号を行う。

以上のようなフローになる。また、上記より、SD-WANではIKEが不要であることが分かる。

Q.なぜ DMVPN では IKE をやめられなかったのか？

1. 理論的には可能だった
   NHRP を拡張して「IPアドレス」と一緒に「各拠点ルータの公開鍵」もハブから配れば、理論上は IKE を排除できる。
2. ハードウェアと役割の限界（現実の壁）
   当時のハブは単なる 1 台の物理ルーターであり、パケット転送処理でスペックがカツカツ。全拠点の鍵の最新状態や Re-key（更新）までハブで一元管理すると莫大なメモリ領域、CPUが必要で処理が破綻するため、「鍵交渉や認証（IKE）は拠点同士で直接やってくれ」 という設計（割り切り）にせざるを得ない。

Q.なぜ SD-WAN では IKE を捨てられたのか？

1. 制御（Control）と転送（Data）の分離
   パケット転送を行わない「制御専用」のコントローラー（vSmart等）を分離独立させた。
2. クラウド・サーバのハイスペック化
   クラウド上の強力な CPU/メモリ を背景に、中央コントローラーが「全拠点の認証」「暗号ルールの統一」「安全なパイプ（mTLS/OMP）での鍵配布」をすべて一括処理できるようになった。
3. 結果
   IKE がやってくれていた泥臭い事前交渉をすべてコントローラーが完了させておいてくれるため、エッジルーター同士は IKE 交渉をスキップしていきなり IPsec トンネルを開通できるようになった。

p.12 なぜSD-WANはVRFが必要なの？

Q.「MPLS-VPNのPEルータみたいに複数の企業と接続するためにVRFでルーティングを分ける」という理由ならVRFの必要性にうなずける。しかし、SD-WANの場合は１つの会社の拠点間で運用されているので、ルーティングが混ざっても問題ないのではないか？それなのになぜVRFを使うの？

A.SD-WANにおけるVRFは「ルーター内部で『アンダーレイ（制御用通信）』と『オーバーレイ（社内データ通信）』を分けるためのセキュリティ壁として利用されている。

ループの構成を簡単にすると👇
①わからない宛先があった、0.0.0.0は本社IPsecだな！よし、IPsecに入れよう！
②よし、カプセル化できたからインターネット経由で流そう！インターネットのルーティングはわからないから0.0.0.0のデフォルトルートで流そう！
③ん？デフォルトルートはIPsecに入れるの？
というように、ループが発生する。
なので、そもそも、１つのデフォルトルートを参照し続けるのではなく、ルーティングテーブルを２つ持って、それぞれのデフォルトルートを持てば解決するよねっていう単純な話だったのである。

Q.もし、VRFを使わないと何が起きるの？

SD-WANでVRFが使われるのは制御プレーンとデータプレーンを分けるためという理解はできたが、もし、分けなかったら具体的に何が起きるのかがいまいちイメージできない。なので、それをはっきりさせていこう！

制御プレーンとデータプレーンのループ（矛盾）が生まれる

ルーティングテーブルが1つ（単一のVRF）しかない場合、「トンネルを作るための外側のパケット」と「トンネルを通すための内側のパケット」の宛先判断が混ざり、ルーティングの無限ループ（再帰的ルーティングループ）が発生する。具体的には、センタートラフィック集約で、わからないルートはすべて本社のIPsecに流すとい設定をした場合に発生する。ローカルブレイクアウトではこれは起きない。
▼具体的な発生メカニズムとフロー
前提：
　拠点Aの物理WAN IP： 203.0.113.1（アンダーレイ）
　拠点Bの物理WAN IP： 198.51.100.2（アンダーレイ）
　IPsecトンネル（データプレーン）： 拠点Aと拠点Bの間に張り、デフォルトルート（0.0.0.0/0）または他拠点宛の経路をトンネル向けに向ける。

①.拠点AのPCから通信が発生:
　拠点Aの社内PCが、拠点B宛にデータ（例: 10.2.0.5）を送信
②.IPsecトンネルへルーティング:
　拠点Aのエッジルーターはルーティングテーブルを参照
　「10.2.0.0/24 宛は IPsecトンネル（ipsec0） に送る」というルールに従い、パケットをトンネルに送る
③.暗号化と外側ヘッダー（ESP）の付与:
　ルーターは元のパケットを暗号化し、対向の物理WAN IP（拠点B: 198.51.100.2）へ届けるため、新しいIPヘッダー（送信元: 203.0.113.1 / 宛先: 198.51.100.2）を包み込むように付与（カプセル化）する。
④.【障害発生】外側パケットの再ルーティング:
　カプセル化した「新しいパケット（宛先: 198.51.100.2）」を実際にWANポートから物理送信するため、ルーターはもう一度同じルーティングテーブルを参照する。
　ここで、OMPや動的ルーティングにより「0.0.0.0/0（全通信）は IPsecトンネル（ipsec0） に送る」という集約ルートや過剰な経路が入っていると、ルーターはこう判断する。
「198.51.100.2 宛のパケットも、IPsecトンネル（ipsec0）の中に送らなきゃ！」
⑤.無限ループ（カプセル化の再帰）:
　「暗号化パケット」をさらにIPsecトンネルに送り込むため、ルーターはもう一度暗号化し、さらに外側に新しいIPヘッダーを付与。
以上👆より、要は、
①わからない宛先があった、0.0.0.0は本社IPsecだな！よし、IPsecに入れよう！
②よし、カプセル化できたからインターネット経由で流そう！インターネットのルーティングはわからないから0.0.0.0のデフォルトルートで流そう！
③ん？デフォルトルートはIPsecに入れるの？
というように、ループが発生する。

結果として「カプセル化されたパケットを、さらにカプセル化してトンネルに投げる」という処理がメモリやCPUの限界まで無限に繰り返され（またはTTL切れで廃棄され）、通信が完全に破綻する。
しかし、これはあくまでもデフォルトルート（0.0.0.0/0）をIPsecにすべて流すようなセンタートラフィック集約を意図した場合である。ローカルブレイクアウトであれば、パケットがカプセル化（IPsec化）されないため、「暗号化された外側パケットがもう一度トンネルに吸い込まれる」という現象自体が起こり得ない。

Q.なぜ普通のルーター（従来のIPsec）はVRFを使わずにループしないのか？

ループのメカニズムを確認すると、SD-WANに限った話ではないように感じる。しかし、旧来のIPsecルータはVRFをデフォルトで必要としない。でもループは起きない。ではなぜか？？

A.普通のルーター（CiscoのIOSなど）で「全通信（0.0.0.0/0）をIPsecトンネルに投げる」設定をした場合、ルーター内部では特殊な処理（ローカル配送の例外処理）が働いている。

【従来のルーター内部の例外処理】
1. PCから通信が来る ➔ ルーティングテーブルを見て「0.0.0.0/0 宛てだから Tunnel0（IPsec）へ投げる」
2. ルーターが暗号化して「対向物理IP（200.200.200.200）」を外側に貼り付ける。
3. ★ここがポイント！★
   従来のIPsec（GRE/VTIなど）機能は、「自分自身が生成した暗号化後の物理パケット（宛先: 200.200.200.200）」を、もう一度ルーティングテーブルに通すのではなく、物理WANポート（Ge0/0）へ直接吐き出す特殊なマーク（ソケットバインド）を内部で自動的に行う。

従来のルーターは「暗号化したパケットは例外的にループ判定から外して物理WANに出す」というOS内部の泥臭いハードコード（内部実装）によって、単一VRFでもギリギリでループを防いでいた。

Q.SD-WANにおけるBFDとは？——-

Q.どの区間でBFDが実施されるの？
A.BFDが実施されるのは拠点間。コントローラとの通信はOMPのKeepAliveを使う。

Q.なんで拠点間はBFDを使うの？
A.コントローラとの通信はリアルタイム性がそれほど求められないため、OMPのKeepAliveで十分。一方、拠点間の通信は実際のデータパケットが流れるため、より障害に敏感にならなければならないから。なので、ミリ秒単位で障害を検知できるBFDを使う

Q.IPsecのKeepAlive機能じゃダメなの？
A.IPsecにも障害を検知するための機能がある。それがDPD（DeadPeerDetection）である。しかし、それはBFDに比べ、検知が遅く品質も判断できないという粗い精度なので、より高性能なBFDを使っている。

設問２

（１）ウ： 大きい　エ： 小さい

これは知識問題。LOCAL＿PREFは大きな値が優先され、MEDは小さな値が優先される。

▼設定方法

#Local-Preference
route-map ルートマップ名 permit シーケンス番号
 set local-preference 値　#デフォルト値は100

router bgp AS番号
 neighbor ネイバーIP route-map ルートマップ名　in
 
 
 
#MED
route-map ルートマップ名 permit シーケンス番号
 set metric 値　#デフォルト値は0
 
router bgp AS番号
 neighbor ネイバーIP route-map ルートマップ名　out

（３）不正なBGP接続

隣接ASのBGPルータとMD５認証のための共通のパスワードを設定することで、「不正なBGP接続」を防ぐことができる。

Q.なんで不正なBGP接続を防ぎたいの？
A.「不正な経路の混入（Route Hijacking）」や「誤った経路の流出・漏洩（Route Leak）」を防ぐため。

▼設定方法
*OSPFやEIGRPの認証方法が気になる場合はこちら

#認証設定方法（シンプルバージョン）-------------------------------
router bgp AS番号
neighbor 192.0.2.2 password MySecretPassword123

#認証設定方法（キーチェーンを使うバージョン）-----------------------
key chain キーチェイン名
 key キー番号
  key-string パスワード
  send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026

 key キー番号
  key-string パスワード
  send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  
router bgp 65001
 neighbor 192.0.2.2 password encrypted-key-chain キーチェイン名
  
#send-lif：このカギを送信時に使う期間
#accept-lifetime:このカギを受信時に使う期間

（４）不正な経路に含まれるアドレスブロックへのコンテンツ配信ができなくなる。

Q.不正な経路が混入するとネットワークではどのようなことが起きてしまうのか？
A.以下のメカニズムを見ていこう！
１．不正な経路の受取：
　悪意あるAS（あるいは設定ミスのAS）から、「このIPアドレスブロック（例：203.0.113.0/24）宛ての通信は俺のところ（不正なAS）に送れ！」というBGP UPDATEメッセージが届きます。
２．ルーティングテーブルの汚染：
　E社のBGPルーターがフィルタリングせずにそれを受け取ってしまうと、正しい行き先ではなく、不正なAS宛ての経路を「正解」として登録してしまいます。
３．トラフィックの迷子（ブラックホール化 / 盗聴）：
　 E社（PoP）からゲーム端末（ユーザー）へコンテンツデータ（ゲーム配信等）を送ろうとした際、不正な経路に従って送信されるため、データは本物のユーザーへ届かず、途中で破棄（Null）されるか、攻撃者のルーターへ吸い込まれて到達不可になります。

設問３

（１）攻撃パケットを攻撃もとに近いところで遮断できる。

RTBHを使うとBGPルータ（エッジルータ）でパケットをドロップさせることができる。以下のような特徴があるので、見てみよう。

• 「ファイアウォール（FW1）に届く前」 ➔ FW1でフィルタリング（ACL等）をする場合、攻撃パケットは「BGPルータ1 ➔ 中間ルータ ➔ FW1」まで届いてしまう。RTBHを使えば、FW1どころか中間ルータや内部回線を圧迫する前に破棄できる。
• 「エッジルーター（BGPルータ1）で破棄できる」 ➔ POPの最前線（インターネットとの境界）にある BGPルータ1 の段階で Null0（ペイツー/廃棄）に送るため、内部ネットワークへ侵入することを防止できる。
• 「攻撃元に近いところで遮断できる」の意味： FW1という「システムの奥側（内部）」と比較した時に、インターネットとの境界線である「入口（BGPルータ1）」というより攻撃元（インターネット側）に近い最前線で遮断できるという意味。

要は「FW1まで届かせることなく、入口であるBGPルータ1（エッジ）で即座に破棄できるため、FW1や内部帯域への負荷を防げる」という理解でOK！

（２）より細かい条件で選別して破棄することができる

BGP FlowspecはRTBHよりも細かなフィルタリングが可能。以下、RTBHの限界とFlowspecの進化を見ていこう！
▼RTBH（Remotely Triggered Black Hole）の限界
従来のBGP（NLRI）は「IPプレフィックス（宛先IP）」しか広報できなかった。そのため、特定の宛先IP宛ての通信を丸ごと Null0 へ引き込んで破棄するしかなく、正常なユーザーの通信まで巻き添えで遮断（共倒れ）してしまうという弱点があった。

▼BGP Flowspec（Flow Specification）の進化
・MP-BGP（拡張NLRI）の利用: 宛先IPだけでなく、「送信元IP」「プロトコル（TCP/UDP等）」「送信元/宛先ポート番号」「ICMPタイプ」といったL3/L4の複数条件（フロー情報）をNLRIに乗せて送信可能になった。
・BGP拡張コミュニティ属性（Extended Community）の利用: そのフローに対してどのような処理を行うかという「アクション（Discard/破棄、Rate-limit/帯域制限など）」を一緒に伝達できる。
・動的ACLの生成: ルータ（BGPルータ）はこれを受け取ると、内部で動的にACL（アクセスリスト）をインストールし、ピンポイントなトラフィックだけをフィルタリングする。

さらに深いVersion….

p.3 なぜ端末内のデータを暗号化するの？ｰｰｰ

Q.正直、端末内にあるデータを暗号化する必要性が分からない。。
別にプライバシー情報が入力されていたりするわけじゃないのに。。。
A.データの改ざんを防ぐため。平文で保存するとユーザがテキストエディタや専用ツールでセーブファイルを開き、「所持金：999999」「スコア：999999」のように簡単に書き換えられてしまいます。暗号化しておくことで、ファイルの直接編集を困難にする。

p.3 ロードバランサーの処理フロー（DNSや振り分けなど..）

１．クライアントは203.x.11.21へアクセスする
２．LBはURLをもとに適切な内部サーバへ割り振る
１つのIPアドレスで３つのサービスを運用する場合は、Hostヘッダフィールドを確認することで適切な宛先をLBが判断できるようになる。
３．内部サーバが処理

このような流れでLBはサービス提供の通信を支えている。

p.4 CDNを採用する理由は？—

Q.グローバル化と大容量化するとCDNを導入した方がいいの？なんで？
A.👇
グローバル化への効果： 世界各地の最寄りPOPから配信し、「物理的な距離による遅延（レイテンシー）」を減らす。
大容量化への効果： キャッシュサーバーが配信を肩代わりし、自社インフラの「回線帯域とサーバー負荷のパンク」を防ぐ。

CDNのフロー

１．企業AとCDN事業者Bが契約する
２．企業A側がDNS設定で、当該サービスのIPアドレスをCDN事業者宛てのIPに変える
３．最初の1人目が東京のPOPにアクセスする。
４．東京POPは「あれ？このファイル（ゲームα）持ってないな」となり、D社のデータセンター（オリジン）へ1回だけ取りに行く（ここで1回だけD社〜POP間で大容量通信が発生）。
５．東京POPは受け取ったデータをキャッシュ（保存）しつつ、1人目のユーザーに渡す。
６．2人目〜10万人目のユーザーが東京POPにアクセスする。
７．東京POPは自分の手元にあるキャッシュを渡すだけ。D社のデータセンターへは1回もアクセスがいかない。
８．もしシンガポールからの要求があった場合はシンガポールPOPが対応する。シンガポールPOPに情報がない場合は、オリジンへの大容量通信が１度だけ発生する。

p.4 POPって何？—

Q.POPってなに？CDNを勉強すると、必ずと言っていいほど頻出するこの単語。なんとなくは理解しているつもりだけど、詳細はいまいちわかっていない。。。
A.POP（Point Of Presence）の略。PoPは単一の物理サーバーではなく、「CDN事業者が各地のデータセンター内に置いている設備一式（物理的な拠点・ラック群）」のこと。
PoPの中身は、大きく分けて2つの役割の機器で構成されている。
　・ロードバランサー（LB）： 拠点（PoP）の入り口に立つ交通整理役
　・多数のキャッシュサーバー： 実際にWebページやゲームファイルを保存して配信するサーバー群（数十〜数百台）

どうやってPOP内部の多数のキャッシュサーバに割り振るの？–

Q.POP内部には多数のキャッシュサーバが配置されている。多数のキャッシュサーバーがある中で、どうやって目的のサーバーまで辿り着き、複数の会社（マルチテナント）のデータを区別しているの？
A.結論から言うと、「特定の会社専用のキャッシュサーバーがあるわけではなく、どのキャッシュサーバーも全会社のデータを扱える」のがカラクリ。

[ ユーザーのリクエスト ]
  │  HTTP Header ──>  Host: alpha.example.net (D社のゲーム)
  ▼
【 1. LB (ロードバランサー) の処理 】
  │  ・Hostヘッダーを見る必要は必ずしもない（単に「暇なサーバー」を選ぶだけ）
  │  ・IPレベル/TCPレベルで、一番負荷が低い「キャッシュサーバー3」へ丸投げ
  ▼
【 2. キャッシュサーバー3 の処理 】
  │  ・届いたHTTPリクエストの「Host: alpha.example.net」をチェック
  │  ・自機のディスク/メモリ内を検索：「D社のデータはあるか？」
  │
  ├─ [ パターンA：キャッシュ有り (Hit) ]
  │      保存してあるデータをそのままユーザーへ返却して終了！
  │
  └─ [ パターンB：キャッシュ無し (Miss) ]
         D社のオリジンサーバーへデータを取りに行き(同期)、
         自分のストレージに保存してからユーザーへ返却！

ポイント：会社の特定は「キャッシュサーバー」がやるということ
。。。ん？どうやって？
A.URL（ホスト名＋パス）をラベルにした巨大なメモ書き（データベース）をサーバ内に持っておく。初学者が持つイメージは「①あ、このURLってことは、②この会社で、この会社ってことはサーバ内の③この領域で、で、その領域の④ここにデータが配置されている！」みたいなステップをイメージする。しかし、実際は「あ、このURLね。データベースで検索して、あ、このデータね！」という極めて単純なステップで解決する。

Q.どうやって最寄りのPOPに引き込むの？DNS設定とかで工夫するの？

A.POPを経由させるにはBGP Anycast方式がある。

BGP Anycast方式

　仕組み：世界中にあるすべてのPoP（東京、シンガポールなど）が、全く同じIPアドレスをインターネット上にBGPで経路広告する。
　ルーティング：ユーザーがそのIPアドレスにアクセスすると、インターネット上のルーターがBGPの仕組み（経路長など）に基づき、自動的に物理的・ネットワーク的に最も近いPoPへパケットを誘導する。
　特徴：DNSでアクセス先を切り替える必要すらなく、IPアドレスレベルで自動的に最寄りのPoPに届く。

BGP Anycastフロー

１．企業A社とCDN事業社Bが契約する
２．BがAにアドレスブロックを割り当てる
３．AがDNS設定で、オリジンサーバ宛てのIPをB社から割り当てられたIPに変更する
４．B社の複数POPがBGPで当該IPを広告する
５．BGPの経路選択によって最寄りもPOPが使われるようになる。

Q.BGP Anycastは複数のPOPが同一のIPアドレスを広告している。それが許可されるなら、誰でも偽ったIPを広告できちゃうんじゃないの？（BGPハイジャック）

確かに、複数の拠点で同一のIPアドレスを広告できてしまうなら誰でも、例えばGoogleのIPを広告できたりとかしちゃえるのでは？と疑問が出る。そういった不正を防ぐ工夫がBGPには用意されている。では、見ていこう！

① RPKI（Resource Public Key Infrastructure）による暗号署名

IPアドレスの所有者（例: E社）は、レジストリ（APNICやJPNICなど）に「このIPアドレスブロックは、AS-Eだけが広告できる」というデジタル証明書（ROA）を登録します。他のASが勝手に広告しても、暗号的に署名が一致しないため無効（Invalid）として世界中で破棄されます。

＊レジストリ：世界中のIPアドレス、AS番号を割り振っている元締めのこと。「このIPアドレス範囲はこの組織に貸し出したものだ！」とかを一元管理している。

② IRR（Internet Routing Registry）での事前登録

プロバイダ同士がBGPで接続する際、「どのIPアドレスを広告する予定か」をデータベース（IRR）に事前登録します。登録にないIPを勝手に広告しても、接続先のプロバイダでブロックされます。

③ 隣接ASでの経路フィルタリング

BGPルーターは、受け取った経路情報が「事前契約された正規のIPアドレスとAS番号の組み合わせ」と一致するかを常にチェックし、一致しない不正な経路はフィルタリング（遮断）します。

CDNはどうやって大容量通信をさばいているの？—

Q.CDNは企業側サーバに負担がかかるのを減らすために利用される。要は、企業側の負担がすべてCDNに降りかかることになる。そのような大容量をCDNではどうやってさばいているの？もし、それができるなら、企業側もその技術使っちゃえばいいじゃん？
A.超大規模なインフラと帯域のバルク買い（スケールメリット）
CDN事業者（CloudflareやAkamaiなど）は、世界中の主要なIX（インターネットエクスチェンジ：プロバイダ同士の交差点）や大手ISP（NTT、KDDI等）のデータセンター内部に直接自社のサーバー（PoP）を設置している。テラビット級（Tbps）の超絶に太い回線と何千台ものサーバーを抱えており、個人企業とは桁違いのインフラ規模を持っている。

Q.「データセンター内部に直接自社のサーバー（PoP）を設置している」とは？
A.CDN事業者が、ISPやデータセンター事業者の「コロケーションサービス（場所や電源を借りる仕組み）」を利用して、相手の建物内に自社のPoP（サーバー群）を設置しているということ。
特に大手ISPに対しては、お互いに通信コストを削減できるメリットがあるため、ISP側から「お願いだからうちの設備内にPoPを置いてください！」と連携を打診されるケースもある。

p.5 IXとは？—

各プロバイダ（A社、B社、C社…）やコンテンツ事業者（Google、Amazon、Cloudflare等）が、それぞれ1本ずつIXの設備（巨大なL2スイッチ）に回線を差し込む場所。これによって、高額な上位回線（トランジット）を経由しなくてもIXに参加している事業者同士で直接BGPの経路情報（「このIP宛てはうちへ送って！」）を交換できるようになった。

いろいろな認証コマンド

p.5でBGPに関する認証が出てきた。なので、ついでにOSPFやEIGRPの認証方法も学んでおこう！

▼OSPF設定方法

#インタフェース単位のMD5認証
int g0/0
ip ospf authentication message-digest #MD5認証の有効化
ip ospf message-digest-key キーID md5 パスワード #キーIDとパスワードの設定

#インタフェース単位の平文認証
int g0/0
ip ospf authentication
ip ospf authentication-key パスワード

#エリア単位の認証
router ospf 1
 area 0 authentication message-digest #エリアでMD5認証を有効化する

int g0/0
 ip ospf message-digest-key キーID md5 パスワード
 
#キーチェインを使う場合
key chain キーチェイン名
 key キー番号
  key-string パスワード
  cryptographic-algorithm hmac-sha-256
  send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026

int g0/0
 ip ospf authentication key-chain キーチェイン名

▼BGP設定方法

#認証設定方法（シンプルバージョン）-------------------------------
router bgp AS番号
neighbor 192.0.2.2 password MySecretPassword123

#認証設定方法（キーチェーンを使うバージョン）-----------------------
key chain キーチェイン名
 key キー番号
  key-string パスワード
  send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026

 key キー番号
  key-string パスワード
  send-life 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  accept-lifetime 00:00:00 Jan 1 2026 23:59:59 Dec 31 2026
  
router bgp 65001
 neighbor 192.0.2.2 password encrypted-key-chain キーチェイン名
  
#send-lif：このカギを送信時に使う期間
#accept-lifetime:このカギを受信時に使う期間

▼EIGRP設定方法
＊EIGRPはキーチェインの設定が必須

#HMAC-SHA-256バージョン
key chain キーチェイン名
 key 1
  key-string MyEigrpPassword123
  cryptographic-algorithm hmac-sha-256

int g0/0
 ip authentication mode eigrp 100 hmac-sha-256 キーチェイン名
 
#MD5バージョン
key chain キーチェイン名
 key 1
  key-string MyEigrpPassword123
  cryptographic-algorithm hmac-sha-256
  
int g0/0
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 キーチェイン名

p.5 BGPで経路フィルタリングをするには？

本文中に、不正経路の混入を防ぐためにフィルタリング設定を行っている旨の記述がある。これを実際にどうやっているのかを見ていこう！

１．アドレスブロックの偽装を防ぐ手法

ip prefix-list プレフィックス名 seq シーケンス番号 permit IPアドレス/数字

router bgp AS番号
 neighbor ピアIP prefix-list プレフィックス名 in

上記のコマンドを実施することによって、接続先ASが持つプレフィックスのみを取得できる。これによって、対向ルータから8.8.8.8などの経路が送られてきてもdropできる。

２．AS番号の偽装を防ぐ手法

ip as-path access-list ACL名 permit 正規表現

router bgp AS番号
 neighbor ピアIP filter-list ACL名 in

3. より高度な現代のフィルタリング（RPKI・ROA）

手動のリスト（Prefix-list）更新だと追いつかない大規模なインターネット（IX等）では、RPKI（Resource Public Key Infrastructure）という暗号署名データベースを使った自動フィルタリングも広く使われる。
仕組み： 「このIPアドレスブロックは本当にこのAS番号の所有者か？」をIRR（Internet Routing Registry）やRPKIで自動照合し、偽装された不一致経路（Invalid）をルータが自動でドロップする。

p.6 DDoS攻撃とは？—

Q.キャッシュサーバーなどを勉強していると必ずと言っていいほど、DoS、DDoS攻撃を耳にする。なんとなく、サービスを妨害する攻撃なのかなぁというニュアンスはわかっても、いまいちピンとこない。。いったい何なの？
A.サービスの提供を妨害・停止させる攻撃全般をDoS、DDoS攻撃という。中にはアプリケーション層の攻撃のみをDoSとしてとらえてしまう人もいるが、レイヤー（層）に関係なく、サービスの提供を妨害・停止させる攻撃全般をDoS/DDoS攻撃という。アプリケーション層（L7）だけでなく、トランスポート層（L4）の SYN フラッディングや、ネットワーク層（L3）の ICMP フラッディングもすべて立派な DoS / DDoS 攻撃になる。
▼DoSとDDoSの違い
DoS（Denial of Service）： 1台の端末から攻撃を仕掛け、サービスを不能（拒否状態）にする。DDoS（Distributed Denial of Service）： 攻撃者がマルウェアなどで乗っ取った複数台（ボットネット）から一斉に攻撃を仕掛ける。

p.6 Destination Address RTBH Filteringとは？—

Q.Destination Address RTBH Filteringってなに？
A.Destination Address RTBH Filteringは通常、RTBHやブラックホールルーティング、D-RTBHと呼ばれたりする。ちなみにRTBHはRemote Triggered Black Holeの略。
目的：
　DDoS攻撃の対象となっている「攻撃を受けているサーバー（被害者）」宛ての通信を、ネットワークの入り口（エッジルーター）で強制的に破棄（Null0へ転送）し、ISP全体の回線や内部ルーターがダウンする連鎖障害を防ぐことです。
＊自社でBGP運用している場合は、自社の最前線ルータでRTBHを動作させる。一方、ISPのアクセス回線を使っている場合は、ISP側が破棄してくれる。

▼RTBHのフロー

０．事前準備（DoS/DDoS発生前）
　ネットワーク内の全ルータでダミーIP（例：192.0.2.1）を同一にして、かつそのネクストホップをNullに設定したスタティックルートを作成する

ip route 192.0.2.1 255.255.255.0 Null

１．DoS/DDoSの発生と検知
　攻撃者が大量のボットを使って、自社の特定サーバー（例: 10.1.1.50/32）へ一斉攻撃を仕掛けてくる。
　運用者（または自動検知システム）が「10.1.1.50 が攻撃を受けている！」と特定する
２．トリガールータからのBGP広告
　運用者が管理用（トリガー）ルーター1台から、ピアに向けてBGPで更新情報を飛ばす。
　広報するメッセージ：
　　・宛先（Prefix）：10.1.1.50/32
　　・ネクストホップ（NEXT_HOP）：192.0.2.1（共通のダミーIP）

#攻撃対象（203.0.113.50）宛てのネクストホップをダミーIP（192.0.2.1）にするスタティックルートを設定
ip route 203.0.113.50 255.255.255.255 192.0.2.1

#1. 該当のスタティックルートを引っかけるACLを作成
access-list 10 permit 203.0.113.50

#2. Route-map を定義し、NEXT_HOP 属性をダミーIPに書き換える
route-map RTBH-MAP permit 10
 match ip address 10
 set ip next-hop 192.0.2.1
 set community no-export        ! （任意）外部ASへ勝手に漏れないよう制限
 
#router bgp 65000
 bgp router-id 1.1.1.1
 neighbor 10.0.0.2 remote-as 65000
 #スタティックルートを Route-map を適用しながら BGP へ取り込む（再配送）
 redistribute static route-map RTBH-MAP
 
 #攻撃が収まったらルートを削除。これにより自動でwithdrawnが流れる
 no ip route 203.0.113.50 255.255.255.255 192.0.2.1

３．エッジルーターのテーブル更新
　BGPメッセージを受け取った各エッジルーターは、自身のBGPテーブル・ルーティングテーブルを自動更新する。
　書き換わったルール： 「10.1.1.50 宛てのパケットは、ネクストホップ 192.0.2.1 へ転送せよ」
４．入り口での即時ブロック（再帰検索）
　外部（インターネット）から 10.1.1.50 宛ての攻撃パケットがエッジルーターに届く。
　エッジルーターの内部処理：
　　パケットをその場で破棄（Drop）。
　　「宛先は 10.1.1.50 か。ネクストホップは 192.0.2.1（ダミーIP）だな」
　　「192.0.2.1 の行き先は……（事前設定を参照）……あ、Null0（ゴミ箱）だ！」

Q.NetFlowはCisco独自？

Q.あれ？NetFlowってCisco独自のプロトコルじゃないの？
A.もともとはCisco独自だったが、RFC3954として公開・標準化され、さらにそれをベースにして完全な国際標準（IPFIX）へと発展したという経緯がある。

configure terminal

! 1. Exporter（データの送信先・送信元を指定）
flow exporter EXPORTER-1
 destination 192.168.1.100            ! コレクター（分析サーバー）のIP
 source GigabitEthernet0/0            ! ルーター自身の送信元インターフェース
 transport udp 2055                   ! （任意）UDPポート番号指定（デフォルト2055）

! 2. Record（どんな情報を収集・集計するかを定義）
flow record RECORD-1
 match ipv4 source-address            ! 検索キー：送信元IP
 match ipv4 destination-address       ! 検索キー：宛先IP
 match ipv4 protocol                  ! 検索キー：プロトコル（TCP/UDP等）
 match transport source-port          ! 検索キー：送信元ポート
 match transport destination-port     ! 検索キー：宛先ポート
 collect counter packets              ! 付加情報：パケット数
 collect counter bytes                ! 付加情報：バイト数

! 3. Monitor（Record と Exporter を紐付け）
flow monitor MONITOR-1
 record RECORD-1
 exporter EXPORTER-1

! 4. インターフェースへの適用
interface GigabitEthernet0/0
 ip flow monitor MONITOR-1 input      ! イングレス（流入）トラフィックの監視
 ip flow monitor MONITOR-1 output     ! エグレス（流出）トラフィックの監視
 
#旧バージョン
ip flow ingress（旧：ip route-cache flow と同じ意味。入ってくる通信を計測）
ip flow egress

#確認コマンド
!ルーターが現在リアルタイムで収集・集計しているフロー情報（キャッシュ）を表示します。
show flow monitor <モニター名> cache

!ルーターが現在リアルタイムで収集・集計しているフロー情報（キャッシュ）を見やすく表示します。
show flow monitor <モニター名> cache format table

!どのインターフェースにどの Monitor が適用されているかの確認。
show flow interface [インターフェース名]

Q.サーバってBGPを動作できるの？

Q.検知サーバがBGPを～と書いてあって、「あれ？サーバがBGPを使う？どゆこと？」と感じる。。。どういうことなのか。見ていこう！
A.BGPは特殊なハードウェアを必要とするプロトコルではない。「TCP（ポート179）の上で制御用メッセージをやり取りする単なるソフトウェア（プログラム）」。Linuxなどの一般的なOSの上に、BGPを制御するオープンソースソフトウェア（例: FRRouting、GoBGP、BIRDなど）をインストールして起動するだけで、サーバーは立派な「BGPスピーカー（BGPを喋る機器）」に変身できる。つまり、Ciscoルーター専用のOSで行っているBGP処理と同じ処理を、通常のLinuxサーバー上のアプリとして実行しているだけ。

Q.NetFlowコマンドにすると？—

コマンドで表現すると、以下のようになる。

flow recorder レコーダ名
 match ipv4 source-address
 match ipv4 destination-address
 match transport source-port
 match transport destination-port

p.7 BGPコミュニティ属性ってなに？—

「BGPコミュニティ属性」を一言で表すと、BGPの経路情報にくっつける「自由なグループ分け用の付箋（メモ書き）」。ルーティングテーブルの「宛先IP」や「ネクストホップ」といった通信に必要な基本情報とは別に、運用者が自由に意味を決めてペタペタ貼れるタグのようなもの。

▼RTBHフロー

もともとRTBH用のタグが固定で存在している」わけではなく、管理者が自分で番号を決めて（定義して）、その番号に対する処理ルール（Route-map）を事前にルーターへ設定・配布しておく

１．【受信側】タグ（例：65000:666）の定義と一致条件の作成

ip bgp-cummunity-list standard コミュニティ名 permit 65000:666

2. 【受信側】タグが来たときの動作（Route-map）の定義

route-map MAP-RTBH-IN permit 10
 match community コミュニティ名             ! 「65000:666」が付いていたら…
 set ip next-hop 192.0.2.1                ! ネクストホップをダミーIP（Null0行き）に変更

3. 【受信側】BGPプロセスへの適用（iBGPピアからの受信用）

router bgp 65000
 neighbor 10.1.1.100 remote-as 65000     ! 検知サーバー（トリガールーター）のIP
 neighbor 10.1.1.100 route-map MAP-RTBH-IN in

４．【送信側】DDoS検知サーバー（トリガールーター）側の発動コマンド

! 1. 攻撃対象IP（ホスト経路 /32）を定義
ip prefix-list PL-ATTACK-TARGET permit 203.0.113.50/32

! 2. タグと「外部広報禁止（no-export）」をセットで付与
route-map MAP-RTBH-OUT permit 10
 match ip address prefix-list PL-ATTACK-TARGET
 set community 65000:666 no-export        ! 自作タグとRFC標準の広報禁止タグをダブル付与！

! 3. BGPでネットワークを広告
router bgp 65000
 network 203.0.113.50 mask 255.255.255.255 route-map MAP-RTBH-OUT

Q.NLRI（Network Layer Reachability Information）とは？

Q.BGPを勉強していると必ずと言っていいほど、NLRIが出てくる。そのたびになんとなくわかった気で入るけど、再度出会うと、やっぱりよくわかっていないという感じになる。それをここで解消していこう！
A.NLRI（NetworkLayerReachabilityInformation）とはBGP Updateを構成する主要な要素である。BGP Updateは以下の２つで構成されている。

1. NLRI（宛先のアドレス情報）
　役割： 「どのネットワーク（IPアドレス/サブネットマスク）へ通信を届けたいか」という対象の宛先そのものです。
　例： 203.0.113.0/24 や 192.0.2.50/32
2. パス属性（Path Attributes：通信条件やタグ）
　役割： NLRIで示した宛先に対して、「どういう条件でパケットを運ぶか」「どう処理すべきか」という付加情報です。
　含まれる主な属性：
　NEXT_HOP： 次にどのルーターへ渡すか
　AS_PATH： どのAS（組織）を通ってきたか
　LOCAL_PREF： 社内（iBGP）での優先度はいくつか
　COMMUNITY（BGPコミュニティ）： コミュニティ属性もまさにここ（パス属性）に含まれる

p.7 BGP Flowspecとは？—

これまでのRTBH（Remotely Triggered Black Hole）にあった致命的な弱点を克服するために生まれた、より高度なDDoS対策技術。

Q.なぜ BGP Flowspec が必要なのか？（RTBHの限界）
RTBHには、運用上の大きな弱点がある。
　RTBHの弱点（大ざっぱすぎる）： RTBHは「宛先IP（/32）」単位でしか通信をドロップできません。つまり、攻撃パケットだけでなく、サービスを利用したい一般ユーザーの正常な通信（Webアクセス等）まで一緒に遮断されてしまう（巻き添えを食らう）という問題がある。
　BGP Flowspecの解決策（ピンポイント遮断）： 「宛先IP」だけでなく、送信元IP、プロトコル（TCP/UDP）、ポート番号（80, 443など）、パケット長など細かな条件（L3/L4情報）を指定して、攻撃パケットだけをピンポイントでドロップできるようにしたのが Flowspec です。

Q.どうやって、宛先IP以外の情報をNLRIに乗せるの？
A.NLRI（宛先情報）を拡張する。本来のNLRIには「IPアドレス」しか入らない。しかし、Flowspec（RFC 8955）ではNLRIの枠組みを拡張し、送信元IP、TCP/UDPポート番号、ICMPタイプなどに加え、Discardなどの動作指示といった「フィルター条件（フロー定義）」をまるごと詰め込んで送れるようになった。なお受け取ったルータはルーティングテーブルではなく「アクセスリスト（ACL）」を内部で自動生成する。ルーターがACLでパケットを直接ドロップするため、ダミーIPもNull0へのルーティング設定も一切不要。

▼BGP Flowspecのフロー

「Webサーバー（203.0.113.50）の80番ポート宛てに、特定送信元からUDP 53の攻撃パケットが大量に届いている」ケースを例に理解していこう！

① 【検知】DDoS検知サーバーが攻撃パターンを特定
　NetFlowなどのログから、攻撃のシグネチャ（宛先IP: 203.0.113.50 / プロトコル: UDP / 送信元Port: 53）を判定。
② 【広報】検知サーバーが BGP Flowspec（拡張NLRI）を発行
　※このメッセージ自体に「どう捨てるか」が入っているため、事前設定されたダミーIPなどは準備不要。
　以下のデータを入れたBGP UPDATEメッセージを生成してエッジルーターへ送る。
　　拡張NLRI（マッチ条件）： 宛先 203.0.113.50/32 ＋ UDP ＋ 送信元Port 53
　　拡張コミュニティ（動作指示）： Action: Discard（破棄）
③ 【変換】エッジルーターがBGPメッセージを「ACL」に自動変換
　(内部イメージ: deny udp any eq 53 host 203.0.113.50 をインターフェースのIN方向に自動適用)
　エッジルーター（address-family ipv4 flowspec が有効なルーター）がメッセージを受信。
　ルーターはBGPの指示を読み取り、内部のハードウェア（TCAM）上に動的なACL（フィルタールール）を自動で即座に作成・適用。
④ 【遮断】攻撃パケットのみをピンポイントでドロップ
　正常なパケット（TCP 80）： ACLの条件に合致しないためスルーされ、Webサーバーへ無事に届く（サービスが継続できる）。
　攻撃パケット（UDP 53）： 入口のエッジルーターで自動生成されたACLにヒットし、その場で即座にドロップされる。

▼RTBHとBGP Flowspecの違い

p.6 図３の構成について疑問をいろいろ解消したい…

Q.どうやって適切なLBまで運ぶの？FWとかルータが記憶しておかなきゃダメなの？

まず、LBの前には、FWとルータがある。で、あるデータを一度キャッシュサーバに覚えさせたら、以降の通信は同一のキャッシュサーバ、ないしはLBに振り分けたい。そうしないと非効率だから。ではどうやってそんなことをしているの？
A.答えはシンプル。そもそものパケットの宛先がLBのIP宛てに設定されている。そのため、中間のFWやルータはただ中継するだけでよい。一度、通ったパケットだからと言って、同じLBに割り振ろう！覚えておかなきゃ！と気合を入れる必要はない。なぜなら、そもそもLB宛だから。

Q.なんでLBが複数あるの？

LBが何台もあったら複雑になってややこしくなるじゃん！
A.負荷分散のため。１台のLBで稼働させると単一障害点となってしまうので冗長化構成をとる必要がある。

Q.インターネット→ルータ→FW→LB→キャッシュサーバのパケットフロー

【① クライアント ➔ ルーター ➔ FW ➔ LB1】
・送信元IP: 1.1.1.1（クライアント）
・宛先IP : 10.0.0.1（LB1のVIP1）

【② LB1 ➔ キャッシュサーバー】
LB1は「送信元」と「宛先」の両方を書き換える（SNAT + DNAT）。
・送信元IP: 10.0.0.100（LB1の物理IP）※LB1へ戻すため
・宛先IP : 192.168.1.10（キャッシュサーバーの物理IP）

【③ キャッシュサーバー ➔ LB1】
・送信元IP: 192.168.1.10（キャッシュサーバーの物理IP）
・宛先IP : 10.0.0.100（LB1の物理IP）

【④ LB1 ➔ FW ➔ ルーター ➔ クライアント】
LB1が内部のセッションテーブルを参照し、クライアント向けに復元します。
・送信元IP: 10.0.0.1（VIP1）※クライアントが見ている宛先に戻す
・宛先IP : 1.1.1.1（クライアント）

Q.ルータ、FW、LBを冗長化しても必ず同じキャッシュサーバに到達するのはなぜ？

Q.👆このような構成の場合、同じデータに対して同一のキャッシュサーバを使い続けることが可能なのかな？（同じキャッシュを使わないとキャッシュミスして毎回オリジンにアクセスしなくなるので）
だって、送信元が違ったらルータのアルゴリズムで振り分け先FWが変更したりするじゃん？で、FWも同じで、振り分け先LBが変わっちゃうのでは？そうなると、異なるキャッシュサーバにアクセスせざるを得ないのでは？

A.すべてのLBはすべてのキャッシュサーバと疎通できる構成になっているのでOK！！
LBに到達するまでは、IPやポートによって振り分けアルゴリズムが動く。そのため、送信元が違えば、たとえ同じデータを要求していても、異なるFW、LBが選択される。しかし、それは全く問題ない。なぜなら、すべてのLBはすべてのキャッシュサーバと疎通ができるから。たとえ、LB１へ振り分けられようとLB2,LB5など様々なLBに振り分けられても、取得するデータが同じなら必ず同一のキャッシュサーバが宛先として選出されるのでまったくもって問題はない。

設問１

（１）mail.y-sha.lan

この問題は社内メールサーバYがどこに転送するかを聞いている。社内メールサーバが外部へ送る際のスマートホストとして、DMZの中継サーバを使用する。
なお、以上の画像の下線②から転送先は１つの固定ではなくラウンドロビンが使われることが分かる。それをベース考えると、図３で同一のFQDNが２つ存在するレコードがある。それがmail.y-sha.lanなので、答えもmail.y-sha.lanになる。

（２）TTLを60秒という短い値に設定している

TTLを短くすることで、使用中のレコードがローテーションしやすくなる。そのため60秒おきに別の中継サーバを使えるようになる可能性が上がる。また、今回の構成で、mail.y-sha.lanの名前解決をするのはほぼ、社内メールサーバしか存在しない。つまり、１つのクライアントしかいないということ。
ということは、結局60秒間はずっと同じ中継メールサーバが使われるということである。
逆を言えば、もし、複数のクライアントがいたら、そもそものDNSラウンドロビンによって分散されるのでTTLをそこまで短くする必要はないし、リアルタイムで並列処理が行われる。

Q.リアルタイム並列処理をするには？
ラウンドロビンを使っても結局、クライアントは社内メールサーバYのみなので、60秒間はずっと同じ中継メールサーバが使われ続けてしまう。なので、一方が遊休に近い状態になってしまう。クライアントが少数でも、この問題を解消しする方法はあるのか。。
A.ロードバランサー（LB）を導入することによって、クライアントが少なくてもリアルタイムで分散処理が可能になる。
手順１：DNSにmail.y-sha.lanのIPアドレスをLBのIPアドレスとしたAレコードを設定する
手順２：内部メールサーバYが名前解決により、LBに転送する
手順３：LBが配下の中継メールサーバのリアルタイム情報から、適切な方へ転送する

（３）a: Preference　b: y-mail2　c: 逆引き

a:Preference
　優先度やPriorityと書かれることもたまにあるが、正式にはPreferenceが正しい。

b: y-mail2
　MXレコードはPreferenceが小さい方が優先度が高くなる。このことより、Preferenceが1であるy-mail2が正解である。

c: 逆引き
　逆引き（ReverseLookUP）とはIPアドレスからホスト名を導くことである。これを使うと送信元認証に使えるが、弱点もある。では、逆引きのフローを見ていこう！

▼グローバルIP 200.100.50.1を逆引きする場合
１．逆引きアドレスを作成しDNSに問い合わせる
　オクテット単位で分割し、順番を逆にした値（200.100.50.1→1.50.100.200）の後ろに、in-addr.arpa.をつける。＝（1.50.100.200.in-addr.arpa.)
２．DNSがその名前を辿る
　DNSサーバはin-addr.arpa.の世界から順に、その名前が登録されているPTRレコードを探す。
３．ホスト名が返ってくる
　DNSから「そのIPのホスト名はmail.example.comだよ」と返ってくる

#PTRレコード
1.50.100.200.in-addr.arpa.   IN   PTR   mail.y-sha.com.

４．一致チェック
　メールの差出人アドレスのドメインとDNSから教えてもらったホスト名のドメインが一致するかを確かめる。

（５）メールサーバのFQDNに詐称したメールアドレスのドメイン名を登録する

この問題では、逆引きにフォーカスが当てられているが、正引きでも同じ現象は起こる。管理者であればDNSレコードは偽れるという弱点で見ると正引きも逆引きも同じ弱点を抱えている。では、逆引きがどのように詐称するのかを見ていこう！

▼逆引きの詐称方法と効果
１．200.100.50.1に対するPTRレコードを準備する
　＊グローバルIP200.100.50.1を保持する管理者が、自身が管理するDNSサーバ（atteker.evil.com.)にホスト名を詐称したレコードを追加する

#PTRレコード
1.50.100.200.in-addr.arpa.   IN   PTR   mail.gmail.com.

２．攻撃者は偽のメールを送信する
　偽のメールは、送信元を1で偽造したホスト名のドメインと同一のドメインにして送信する。（xxxxx@gmail.com)
３．受信者は逆引きで正当性を確かめる
　送信元のIPアドレスを逆引きしていくと、攻撃者のDNSまでたどり着き、そこからPTRレコードを取得する。すると、ホスト名がmail.gmail.com.であることが分かる。そのドメインとメール送信元のドメインxxxxx@gmail.comが同じなので整合性があると誤った判断をしてしまう。

設問2

（2）d: SMTP　e: MAIL FROM　f: y-sha.com

この問題はSMTPの基本的なフローの理解ができているかを問われている。なので、SMTPフローを見ていこう！

▼SMTPフロー
１．送信前の準備（DNSの引き方）
　メールを送り出す前に、送信側サーバーは「どこにコネクトすればいいか」を調べるためにDNSを引く。（＝MXレコードとA/AAAAレコードの取得）
２．TCP接続とSMTPセッションの開始
　特定したIPアドレスの ポート25番 に向かってTCPのコネクションを張り、ここからSMTPの会話（セッション）を始める
　①送信側が接続すると、受信側サーバーがまずウェルカムメッセージ（220応答）を返す
　②その後、送信側が挨拶のコマンド（EHLO/HELO）を送る
　　HELO：ただ挨拶するだけ
　　EHLO：認証、拡張機能などの交渉・確認の役割も持つ
３．エンベロープ（封筒）のやり取り
　ここから「誰から誰に送るのか」という宛先・差出人の情報を伝える（※ここで前述したSPFのチェックが裏で行われる）。
　①MAIL FROM
　　「このメールの差出人は（エンベロープFROM）はこのアドレスですよ」と伝える。
　　例：MAIL FROM:<tarouyamada@example.com>
　②RCPT TO
　　「このメールの宛先（エンベロープTo）はこの人です」と伝える。（複数の宛先がある場合はこのコマンドを繰り返す）。
　　例：RCPT TO:<tarouyamada@example.com>
４．本文データの送信
　封筒の宛先が決まったら、いよいよ中身（便箋）を送り始める。
　①DATA
　　「これより後ろはすべてメールのデータ（ヘッダーと本文）だよ」と受信側に伝える。受信側がOK（354応答）を返すと、データ送信モードに入る。
　②ヘッダーと本文の送信
　　From: 太郎 <tarouyamada@example.com>
　　To: 花子 <recipient@example.com>
　　Subject: 会議の件
　　（空行）
　　本文のテキスト
５．切断
　　QUIT
　　「もう用事は済んだので切断します」と伝え、お互いにコネクションを閉じます。

以上の流れより、MAIL FROMコマンドで得られるドメインはメール送信元のメールアドレス。つまり、この場合だと、y-sha.comになる。

設問３

（３）受信したメールが正規のメールサーバから送信されたものかどうかが分かるから

DKIMでは受信者が送信者の公開鍵を使って署名を検証する。その検証が成功するということは、送信者が正しい秘密鍵を保持していることを意味する。つまり、送信者の正当性が保証できるということ。

設問4

（1）DNSサーバ名：外部DNSサーバY　登録する情報：メール中継サーバZのIPアドレス

SPFの検証方法が頭に入っていれば、この問題は解けるようになっている(SPFについてはこちら）。
Z社はY社ドメインを使っているので、受信者はY社のDNSにSPFを要求する。しかし、実際の送信元はZ社の中継メールサーバである。そこで、不整合が起きてしまわないように、Y社側のSPFレコードにZ社の中継メールサーバのIPアドレスを登録しておけば整合性が取れる。

Q.include使った方が効率よくね？
A.Yes！！includeを使わないと、Z社の中継メールサーバのIPアドレスが変わるたびにY社のSPFレコードの更新をしなくてはならなくなる。それよりも、Z社側でドメインを管理した方が、Z社中継メールサーバのIPが変わったとしても、Y社には影響を与えずに運用を続けることができる。

（２）j: y-sha.com

Q. d=をz社のドメインにした方が効率がいいのでは？
だって、実際に署名しているのはZ社サーバなんだから、なぜそこでわざわざd=をy-sha.comにするのかがよくわからない。。
A.本文をよく見ると、「外部DNSサーバYを使用してDKIMの検査を行うことができるように~」と記されている。つまり、Y社のDNSサーバを使わせたいので、必然的にY社ドメインを指定することになる。

また、現在のセキュリティにおいては、FromドメインとDKIMドメインが一致していないと正当なメールとして認められないこともある。そのため、Y社のDNSを使わせている。

（３）メール中継サーバZから鍵が漏洩しても、Y社で実施中のDKIMの処理は影響を受けない。

Z社の秘密鍵（セレクター：sel.zsha）が漏洩した場合、攻撃者はZ社が担当するサポートメールなどを偽装できるリスクが生る。だけど、Y社自身が元々使っている本体のメールシステムは別の秘密鍵を使用しているため、その安全性は一切脅かされない。

（４）なりすましメールもメール中継サーバZから社外に転送されるから

これは何を意味しているかというと、Z社のメール中継サーバを使えるなら誰でもy-sha.comを送信元にできて、認証も通ってしまうということを意味する。そのため、Z社内からスパムメールを大量に送ったりなりすましをしたりできてしまうということ。
で、設問では、それがなぜか？と聞かれている。
A.メールが中継サーバを通りさえすれば、誰が書いたメールであってもサーバが勝手に認証を通れるように作動してしまう。つまり、DKIMはあくまでもサーバ単位の正当性を認証するものであるため、そのサーバを使えさえすれば誰でも認証を通過できてしまう。なので、ユーザ単位の認証が必要になる。

Q.じゃあ、どうすればいいの？
A.S/MIMEを使う。DKIMはサーバ単位の署名。S/MIMEは個人単位の署名なので不正なユーザであれば認証を通らせなくできる。

設問５

（１）　送信者の秘密鍵でハッシュ値を暗号化する

電子署名データの作成は、ハッシュ値を秘密鍵で暗号化することで作成できる。これはS/MIMEに限った話ではなく、署名を作るときの流れは大抵この方式で作られる。

（２）　送信者の公開鍵で署名を復号する

署名は送信者の秘密鍵で暗号化されているので、それを復号すればハッシュ値を取り出すことができる。そして、秘密鍵で暗号化されたものを復号できる鍵は、そのペアの公開鍵なので、回答も送信者の公開鍵となる。

（３）　取り出したハッシュ値と生成した値が一致する

送信側と受信側で生成したハッシュ値が一致することは、改ざんがされていないことの証明になる。　

p.3 図３ 社内DNSサーバYが管理するゾーン情報の見方ｰｰｰｰｰｰｰｰｰ

Q.急にドメイン「.lan」とかが出てきたり、同じIPアドレス（192.168.0.1,192.168.0.2）を持つレコードが出てきたりと、意味不明。。。。なので、１行ずつ冷静に見ていこう！
A.以下を見ていこう！
①y-mail3.y-sha.lan. IN A 192.168.1.1
図１サーバセグメント内の社内メールサーバYのホスト名とIPアドレスをあらわしている。
②③mail.y-sha.lan. 60 IN A 192.168.0.1 （と .2）
図１中のDMZにあるメール中継サーバY1とY2の代表エイリアス
２行あることでラウンドロビンが可能になる。
④⑤ y-mail1.y-sha.lan. / y-mail2.y-sha.lan. IN A 192.168.0.1 （と .2）
管理目的で明示的に社内からDMZの中継サーバにアクセスしたいときに使う。②③だとラウンドロビンされてしまうので、意図した方のサーバにアクセスできないから。

Q.どうゆう流れでDNSレコードが参照されているのかよくわからない。。。
A.では、フロー（社内PC→外部ホスト）を参照しながら疑問を解消していこう！
１．社内PCがメールを作成
２．PC内のメールソフトクライアントが社内メールサーバYへ送信
＊運用ルールで、本文中に社内メールサーバYを経由すると記されているので、Yを経由させる

＊メールサーバYを経由させるには、メールソフトクライアントにメールサーバYのFQDN（y-mail3.y-sha.lan. ）やIPアドレスをリレーサバ（スマートホスト）として設定しておく
→この時に使われるレコードが①。これによってメールサーバYへ到達できる
３．社内メールサーバYから中継メールサーバへ
社内メールサーバYにもスマートホスト（リレーサーバ）として中継メールサーバのFQDN（mail.y-sha.lan.）を設定しておくことで転送処理がスムーズにできる。
４．中継メールサーバから外部ホストへ
中継メールサーバはアプリケーション層内の宛先ドメインを確認し、名前解決によってMXレコード、Aレコードを取得し当該メールサーバへ転送する。

SPF(Sender Policy Framework)とは？——

SPFは送信元のドメインの正当性を確認する仕組みのひとつ。では、そのフローを見ながら理解していこう！

▼SPFフロー
１．接続とMAIL FROMの通知（送信側→受信側）
　送信側サーバーが受信側に接続し、MAIL FROM: <xxx@example.com>（エンベロープFrom）を送信する。
２．IPとドメインの取得（受信側）
　受信側は、いま接続してきている送信元のIPアドレスと、MAIL FROM で指定されたドメイン名を保持する。
３．SPFレコードの問い合わせ（受信側 ➔ DNS）
　受信側は、取得したドメインのDNSサーバーに対して、SPFレコード（TXTレコード）を自分から問い合わせに行く。
４．照合と判定（受信側）
　DNSから返ってきたSPFレコードの中に、「いま接続してきている送信元IPアドレス」が許可されたものとして書かれているかを確認する。

v=spf1 ip4:192.0.2.1 ip4:192.0.2.0/24 include:_spf.google.com ~all

#解説
v=
　SPFのバージョン
　
include:ドメイン名
　メール配信をクラウドサービスなどに委託している場合に、当該サービスのSPFを参照してもらうための仕組み。また、クラウドのIPは動的にころころ変わる。その度にSPFを修正するのは面倒くさいのでincludeにする。

▼許可リストにない時のルール
~all
 ソフトフェイル（怪しいけどブロックはせず迷惑フォルダやフラグを付ける）
-all
 ハードフェイル（受信拒否）
?all
 ニュートラル（何も判断しない、承認成功も失敗もしない。ただの保留＝事実上の無効化）
+all
 パス（誰であろうと全部認証成功！正しいユーザと承認する）
 

５．結果に応じた処理
　含まれていた場合（合格）: そのまま通信を続け、後続の本文（DATAコマンド）を受け入れる。
　含まれていなかった場合（不合格）: 本文データを受け取る前に、その場でメールの受信を拒否する。

以上！（設問４(1)に戻る）

DKIM(DomainKeys Identified Mail)とは？—–

DKIMも送信元ドメイン認証の方法の一つ。では、フローを見ながら理解しよう！

▼DKIMのフロー
＊前提：DKIMに使う鍵は第三者認証ではなく各サイトの管理者が生成する
１．DKIM署名ヘッダーの読み取り
　受信したメールのヘッダーから DKIM-Signature: を見つけ出し、そこに書かれている以下の情報を抽出する。
d= （ドメイン名）：例 example.com
s= （セレクター名）：例 selector1
a= （アルゴリズム名）：例 rsa-sha256　暗号化にはRSAを、ハッシュにはsha256を利用している意
b= （署名データ）：送信側が付けた電子署名そのもの
２．公開鍵の取得（DNS問い合わせ）
　抽出したドメインとセレクターを組み合わせて、DNSに公開鍵を要求する。
　問い合わせ先の形式: selector1._domainkey.example.com のTXTレコード

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0v... (長い公開鍵文字列) ..."


#詳細解説
selector1._domainkey.example.com.
　セレクタ：ただTXTレコードを取得するだけだとたくさんあって、どのTXTか判断できない。そこでセレクタという識別子を使うことで数あるTXTレコードから適切なレコードを取得できる
　
v=
 バージョン
 
k=
 暗号アルゴリズム
 
p=
　公開鍵の実データ

３．署名の検証（復号とハッシュ比較）
取得した公開鍵を使って、メールに添付されていた電子署名（b=）を復号し、送信側が作った「元のハッシュ値」を取り出す。
同時に、受信側自身でも手元に届いたメールの本文等を同じアルゴリズムでハッシュ化し、「受信側で計算したハッシュ値」を作る。
４．署名の検証（復号とハッシュ比較）
　取得した公開鍵を使って、メールに添付されていた電子署名（b=）を復号し、送信側が作った「元のハッシュ値」を取り出す。
　同時に、受信側自身でも手元に届いたメールの本文等を同じアルゴリズムでハッシュ化し、「受信側で計算したハッシュ値」を作る。
５．照合と判定
　「公開鍵で復号したハッシュ値」と「受信側で計算したハッシュ値」を比較する。
　一致した場合: 途中で改ざんされておらず、かつ、そのドメインの秘密鍵を持っている正当な送信者から送られたものであると証明されるため 【合格（Pass）】 となる。
　一致しなかった場合: 途中でデータが書き換えられている（改ざん）、あるいは偽の署名であるため 【不合格（Fail）】 となる。

以上がフロー。ただしこのフローからもわかる通り、Header Fromの確認はしないので、そこの偽造を検知するにはまた別の機能が必要となる。。。

p.19 Y社の運用ポリシーについて

Y社ではメールを運用においてポリシーを制定している。この一つずつの意図を理解していこう！

(あ)　社内メールサーバYには、Y社に勤務する従業員以外のメールボックスは設定しないこと

Q.なんでY社以外のメールボックスは設置しないの？意図は？
A.無関係のアカウントが存在していると、そのアカウントを皮切りに社内への不正アクセスなどにつながってしまうから。社内ドメインのアカウントが不正に利用されると、同じドメインであるためチェックが緩くなったりして、通常の外部アカウントよりも不正にできることが増えてしまう。

(い)　社内PCによるメール送受信は、社内メールサーバYを介して行うこと

Q.なんで社内メールサーバYを介すの？直接、中継メールサーバに送っちゃダメなの？
A.社内からでるすべてのメールを一元管理・統制するため。これをすることによって、社内メールサーバYへのセキュリティ対策が社内メール全体に波及させることができるから。もし、一元化しないと、各PCが勝手に外部と直接メールをやり取りすると、会社側がウイルスチェックやログの監査、誤送信防止などのセキュリティ対策を一切コントロール（一元管理）できなくなる。

(う)　メール中継サーバY1及びY2にはメールボックスは設定せず、社内メールサーバYから社外宛て、及び社外から社内メールサーバY宛ての、メールだけを中継すること

Q.なんで中継メールサーバにメールボックスを置かないの？
A.中継メールサーバはDMZ、つまり外部からアクセス可能な領域に配置されている。この場所でメールボックスを置くと、外部からメールボックスの中身を覗かれてしまい情報漏洩などにつながってしまうから。そうならないように、DMZにはメールボックスは配置しない。

Q.送信元と宛先を限定するのはなぜ？
A.踏み台サーバとして利用されることを防ぐため。中継サーバーが誰でもかれでも自由にメールを中継できる状態（オープンリレー）になっていると、世界中のスパム業者に悪用（踏み台に）されてしまう。これをしてしまうと、メールプロバイダのブラックリストに登録されてしまいY社自身のメール送受信が停止されてしまう。

(え)　Y社のドメインを利用するメールには、なりすまし防止などの情報セキュリティ対策を講じること

A.これは疑問の入り込む余地すらないことだが、SPFやDKIMなどのセキュリティ対策をすることによって、正規の送信元であるお墨付きを作る。

p.20 Z社に委託するメールによるサポート方法

Q.これはどういうこと？

A.これは、Z社のサポートチームYにY社のsupport@y-sha.comを使用させるということ。送信元をsupport@y-sha.comとしてメールを送れるようにしている。

Q1.抽出して転送ってどうやって？

A1.Y社のメールサーバにフィルター付きのソフトを稼働させることで、Z社に依頼している製品にヒットしたメールを転送するという仕組みを構築する。

Q2.転送時の送信元/宛先はどうなる？

A2.送信元はY社のメール中継サーバになり、宛先はZ社のグループアドレスになる。

#Z社に届くメール
--------------------------------------------------
【転送メールのヘッダー情報】
From: Y社メールサーバー <mailer@y-sha.com>  ← ここは転送元（Y社）になる
To: Z社グループアドレス <support-team-y@z-sha.co.jp>
Subject: 【転送】製品についての問い合わせ

【転送メールの本文（ここがポイント）】
---------- Forwarded message ----------
From: 困っている顧客 <customer@example.com>  ← ★ここに元々の顧客のアドレスが残っている
To: support@y-sha.com
Subject: 製品が動きません

はじめまして、〇〇の製品について質問なのですが...（顧客の問い合わせ内容）
--------------------------------------------------

で、Z社からクライアントに返信する時の送信元にはy-shaドメインを使う。

Q3.Z社からの返信はどうなるの？なんか、送信元をy社ドメインにするときと、z社ドメインにするときの切り替えはどうやってるの？面倒くさくない？

A3.通常のOutlookなどのメールクライアントは使わずにServiceNowのようなITサービスマネジメントプラットフォームを導入することが多い。宛先ごとにメール送信元を手動で変更したりするのはとても手間がかかるので、メールクライアントで制御するよりも専用のシステムを利用する。

p.21 S/MIMEとは？——

DKIMはサーバ単位の認証。一方、S/MIME（Secure/Multipurpose Internet Mail Extensions）はユーザ単位の認証をサポートする。では、どのように実施するのか？フローとともに見ていこう！

▼S/MIMEのフロー
１．証明書の発行
サポート担当者（例：佐藤さん）は、信頼できる認証局（CA）から「佐藤さん本人＝ support@y-sha.com の持ち主」であることを証明する電子証明書と秘密鍵を発行してもらう。（秘密鍵・公開鍵
Q.どこのCAから発行するの？
A.証明書でやりたいことは、「Y社の一員ですよ！」とやりたい。なので、発行する主体のCAはY社のCAである。
２．メール作成・送信
佐藤さんがパソコンのメールソフトでメールを書き、送信ボタンを押す。
この時、メールソフトが佐藤さんの「秘密鍵」を使って、メール本文にデジタル署名（電子的なハンコ）をペタッと貼り付ける。
３．受信側で検証
顧客のメールソフトがメールを受信する。
受信側のソフトは、メールについている署名を見て、「これ本当に佐藤さん（support@y-sha.com）が書いたものか？」を、認証局の公開鍵を使ってチェックする。

MUA,MAT,MDAとは？—-

メールのフローを勉強していると必ずと言っていいほど出てくる用語がある。それを見ていこう！

不備により設問５は成立しないとは？—

Q.問題文を読んだいる限り目立った矛盾点はなさそう。。。。ではどこが不備なのか？
A.本文中に「秘密鍵を共有する」旨の記述がある。

本来、秘密鍵とは共有するものではない。また、S/MIMEは個人の証明をするものなのに、その情報を共有するとなるとS/MIMEの根幹部分に矛盾を生じさせるようなものである。
。。といった理由で不備とされている可能性があるかもしれない。。

設問１

（３）同じレイヤー２のネットワークを持つすべてのリモートVTEPに転送するため

これは、要は、L2におけるフラッディングをL3上で再現するための仕組みである。なお、ここではEVPNを使っていないので、このような面倒くさいタスクが必要になる。

▼EVPNを使わないときのアドレス解決

１．VTEP-A配下のVM１がIPアドレス10.0.0.100のMACアドレスを知りたいと思いARP要求
２．仮想L2スイッチはARPテーブルを持っていないので、適切なVLNAタグが付与してVTEP-Aに届ける
３．VTEP-AはVLANからVNIを割り出す。そしてVNIに対応するマルチキャストアドレスをセットしてL3ネットワークに送信する
＊EVPNがないと、以前にVM100と通信指定も保持できる情報は、「外側のリモートVTEPのIPアドレスとVMのMACアドレスのみ」であるため、過去にVTEP-AがVM100と通信していてもVTEP-Aが直接ARP応答を返すことはできない。
＊VNIとVLAN IDのマッピングはEVPNがないと、管理者が手動で設定しなければならない。
４．マルチキャストが当該グループに属するすべてのVTEPに届き、当該VNIに対応するVLAN IDに属するポートへ流す
５．物理サーバNICから仮想L2スイッチまで届き、当該VLANに属するVMに転送する
６．VMに届き、自分のIPであればARP応答を返し、自分のIPでなければ破棄をする
＊この流れからわかる通り、EVPNがない場合は関係のないパケットが下流のVMまで届いてしまうので無駄が多い。例えば、VM自体のCPU,仮想L2スイッチのCPU、物理サーバまでの帯域など、消費する必要のないものを消費してしまっているので非効率と言わざるを得ない。

設問２

（1）d:LSDB　e:最短経路

d:LSDB
　同一エリア内で同一リンク情報を同期させたデータベース
e:最短経路
　最短経路ツリーの別解としてはSPF（ShortestPathFirst）ツリーも有効。

令和7年（2025年）ネスペ午後Ⅰ　問１　解答解説

設問１（２）不正なOSPFルータと隣接関係になり経路交換してしまう問題不正なOSPFルータと経路交換をすると自分の内部アドレスの情報が漏れたり、逆に悪意のあるルートを注入されたりしてしまい正常な通信の妨害となる。なお、余談だがOS...

ascend-beyond.com

2026.08.08

（３）複数ある経路のそれぞれの経路について、コストの合計値を同じ値にする

ECMP（Equal-Cost-Multi-Path）とは「宛先までの合計コストが同一＆かつ複数のネクストホップがある」という２つの条件をみたした経路では、ルーティングテーブルに登録され、負荷分散が可能になる。
＊通常のルーティングテーブルには宛先に対して１つのネクストホップしか登録されないのが常。しかし、ECMPでは１つの宛先に複数のネクストホップが登録されるようになる。

設問４

（３）利点：iBGPピアの数を減らすことができる　IDの名称：クラスターID

iBGPには「iBGPから受け取った経路をほかのiBGPには流さない」というルールがある。つまり、フルメッシュ構成を強いられるのである。しかし、それではピアが増えれば増えるほど、CPU負荷、ネットワーク帯域負荷が発生してしまう。そこで出てきたのがルートリフレクターである。ルートリフレクターとは、iBGPの経路をほかのiBGPへ流すことが許可されているルータである。つまり、これにピアを張りさえすれば、ピア関係にないiBGPの経路も受け取れるようになるのでフルメッシュ構成から解放される。

クラスターIDとは…
　ルートリフレクター（RR）を冗長化した時にRR同士で経路情報がループするのを防ぐための識別番号。RRの導入はそもそも「iBGPから受け取った経路をほかのiBGPには流さない」というルールの抜け穴を作るためである。しかし、それが災いしてRR間でループを引き起こしてしまう。それを防ぐために、クラスターIDを使うことでRR間でループを検知できるようになる。

#クラスターIDの設定
router bgp AS番号
　bgp cluster-id 1.1.1.1
　
#RRの設定
 neighbor 配下IP route-reflector-client

p.3 データセンターを所有する大手EC事業者とは？ｰｰｰｰｰｰｰｰｰ

Q.EC事業者がデータセンターを所有？どうゆうこと？ECはECだけやればいいじゃん？
A.大量の物理サーバやネットワーク機器を設置するための施設がデータセンター。小規模であれば、自社内に配置できる。しかし、大規模・大量の場合は、強固な建屋、安定した電源、空調、高いセキュリティといった観点からデータセンターを自社で建てて/借りて、自社専用のデータセンターを丸ごと運用するというパターンがよくある。

Q.そもそもECサイトとは？？
A.ECはElectronicCommerce（電子商取引）の略。つまり、ウェブサイトやアプリなどのネットを介して取引を行うビジネスのこと。

p.3 VXLANとは？——-

Q.なんでVXLANが必要なの？ややこしくて複雑な仕組みだけど、メリットあるの？
A.従来のVLANでは実現できないことがVXLANでは実現可能なので、VXLANが使われている。

メリット１：仮想ネットワークの拡大
　VLANはVLAN IDが12ビットで構成されているため、4094(2¹²-2）個しか利用できない。一方、VXLANはVNIが24ビット、つまり約1677万（2²⁴-1）個も利用できる。これによって大規模データセンター内で利用できるようになった。
＊VLANの場合は規格で0と4095が予約されているためマイナス２となる。一方、VXLANの場合は0のみの予約なのでマイナス１となる。

メリット２：L3を跨いだL2延伸ができる
　VXLANはイーサネットパケットをカプセル化することで、L3を跨いでも同一のL2として扱うことができる。一方VLANは同一VLAN内でL3を跨いだ通信はできない。
Q.L2を延伸できたら何がいいの？？
A.離れていても同一プレフィックスで構成できるため、ライブマイグレーションなどでIPアドレスを変更しなくてもよくなりサービス継続がスムーズになる。L2延伸ができない、＝プレフィックスが変わるとIPアドレスを変えざるをえないのでDNS設定などの各種設定変更が必要になる。
Q.なんでVLANではL3跨げないの？
A.ルータはL2を破壊して、つまりガン無視してL3による転送処理をする。また、ルータはブロードキャストを転送しない。ルータは同一プレフィックスを複数のポートに割り当てられない。
これらの特徴より、VLANのみではL3を跨げない。
Q.ルータ・オン・ア・スティックではVLAN間通信できるじゃん⁉それと同じ感じでL3跨げばいいじゃん？
A.ルータオンアスティックはあくまでも異なるVLAN間の通信を処理しているだけ。いわば、L2部分はガン無視してL3の宛先IPアドレスから出力ポートを決定し、そのポートに割り当てられたVLANを再度付与して転送しているだけ。一方、同一VLANでルータを越えようとしても、ルータには同一プレフィックスのポートは持てないので、IPによる転送をしてもそのプレフィックスは他のポートには割り当てられないので結局L3を跨げない。

p.3 EVPNとは？————

EVPNはEthernetVPNの略で、MP-BGPの一種。本来BGPはIPv4にしか対応していないが、IPv6やVPNの情報も運びたいというニーズに答えた、様々な種類を運べるようにしたものがMP-BGP。そのMP-BGPの中でL2の情報も運べるものがEVPN。

EVPNはBGPアップデートの中にNLRIというデータ枠を設けて、その中にVTEP情報やVM情報などを入れる。これによって、VTEP間で配下のVM情報を認識できるようになる。

NLRI（NetworkLayerReachabilityInformation）：BGPアップデート内のデータ枠。この中にType２，３，５などを格納する。また、NLRIはEVPNに限った用語ではなく、BGPでも普通に使われている。
Type2（MAC/IP広報）:配下のVM MAC＋配下のVM IP+VNI＋VTEP自身のIP
Type3（VTEPのIPアドレス）：BUMトラフィックを配信するためのVTEP一覧
Type5（IPプレフィックス）:デフォルトルートやサブネット単位のIP経路、経路集約など

AFI/SAFIとは？————–

Q.EVPNを勉強していると、AFIやSAFIという単語を耳にする。それらはいったい何なのだろうか。
A.AFIとSAFIを一言で言うとMP-BGPで使われるタグ。MP-BGPではIPv4,IPv6,VPNなど様々アドレスファミリが利用されるため、内部で「これはこのアドレスファミリの広告ですよ！」と伝える必要がある。そのタグが、AFIとSAFIである。

Q.AFIとSAFIを具体的に….？
A.AFIはAddressFamilyIdentifier（アドレスファミリ識別子）である。SAFIはSubsequentAddressFamilyIdentifierの略。MP-BGPで広告種類を表すタグとして、AFIとSAFIがある。AFIはその中でも大まかな種類を表したもの。SAFIはより具体的な種類を表したタグになる。具体的にはこんな感じ👇

p.3 VTEPとは？———-

VTEP(VXLAN Tunnel End Point)は普通のルータやスイッチにVXLANカプセル化・解除を行う機能を追加した機器（またはソフトウェア）のこと。で、あとはシンプルにBGPを流すの同様の流れで、相手とネイバー関係を築いて、EVPNのやり取りをする。

VXLANのパケット構成———–

┌─────────────────────────────────────────────────────────────┐
│ 外側L2ヘッダー   : 物理スイッチ宛てのMACアドレス               │
├─────────────────────────────────────────────────────────────┤
│ 外側L3ヘッダー   : 宛先VTEPのIPアドレス (IP)                  │
├─────────────────────────────────────────────────────────────┤
│ 外側L4ヘッダー   : 宛先ポート 4789 (UDP)                     │
├─────────────────────────────────────────────────────────────┤
│ VXLANヘッダー   : VNI (24bitのネットワーク識別子)             │
├─────────────────────────────────────────────────────────────┤
│ 元のL2フレーム   : サーバーが出した「元のMAC + IP + データ」   │
│ (ペイロード)                                                │
└─────────────────────────────────────────────────────────────┘

Q.VXLANのパケット構成では、UDP4789やVXLANヘッダーなどのいろいろなヘッダーを追加していく。では、それらがなぜ必要なのかを見ていこう！
A.VXLANヘッダーはVNIを格納し、どのVNI、つまりVLANと対応ずいているのかを示すのに使われる。UDP4789はVTEPが受け取った時に、「あ、これはVXLANの処理をすればいいんだな」と理解できるようにするためのヘッダー。
では、フローを見ていこう！

▼VXLANパケットのフロー

VTEP-Aの配下にある物理サーバ内のVM10からVTEP-Ｂの配下にある物理サーバ内のVM100への通信を例に見ていこう！

１．VMがパケットを生成して送信
　＊この時点では通常のイーサネットパケット
２．物理サーバ内の仮想スイッチに届くL2スイッチに届きフラッディングをする
　＊VLANタグの付与：仮想スイッチは受信ポートから「あ、このポートはVLAN○番だな！」と判断し、VLANタグをつける
　＊フラッディング：仮想スイッチが宛先を知らない場合、フラッディングをして、物理NICと他のVMにも転送する
３．VTEPに届きL3ネットワークへ
　＊フラッディングにより物理NICを経由してVTEPに届く
▼VTEPの処理フロー
①VNIの付与：パケットのVLANタグをみて「あ、VLAN○番はVNI△番に対応しているからVNIは△番を設定しよう」と判断し、VLANタグを剥がしVXLANヘッダーを付与する
②UDP4789の付与：受信側が個のパケットはVXLANのパケットだと識別できるようにUDP4789番を付与する
③外側IPヘッダーの付与：EVPNで学習したテーブルを参照し、「あ、この宛先MACアドレスはこのVTEP配下にあるVMだな。では、宛先IPを当該VTEPに設定しよう」となる。
４．L3ネットワーク
　＊OSPFやIS-ISなどのIGPでL3ネットワークのアンダーレイを構築しておき、VTEP間の疎通を可能にさせる
５．宛先VTEPに届く
▼VTEPの処理フロー
①L3処理：宛先IPが自分宛なのでL3を解体してL4の中身を確認する
②L4処理：L4はUDP4789が設定されているので、「あ、これはVXLANだ！」と判断しVXLANプロセスを待機させる
③VXLANヘッダー処理：VXLANヘッダー内のVNIを確認し、そのVNIにマッピングされているVLANを見つける。
④生パケットの送信：①～③のカプセル化を解除すると生のイーサネットパケットが出てくる。その生パケットに③で判明したVLAN情報タグをセットする。その後、生パケットの宛先IPから適切な出力ポートを判断し、出力する
６．物理サーバに届く
　＊物理サーバに届くと内部の仮想L2スイッチに転送される
通常の物理サーバは宛先MACが自分以外であると、処理せず破棄される。なので、ここではひと工夫必要となる。
工夫１：プロミスキャスモードに設定
　プロミスキャスモードに設定することで、自分以外の宛先MACアドレスでも処理対象にすることができる。
＊ただし、まったく関係のないパケットも節操なく処理してしまうのでCPU負荷が高まってしまうというデメリットがある
工夫２：MACテーブルのオフロード
　ハイパバイザが配下にあるVMのMACアドレス情報をサーバのMACアドレステーブルに反映させる方法。これにより、VM宛てのパケットでも物理サーバは「あ、自分の配下にあるMACだな」と判断して処理フローに進めるようになる。
＊ただし、サーバー用NICがSmartNICやSR-IOV対応NICである必要がある。
７．仮想L2スイッチに届く
　仮想L2スイッチに届くとVLANタグと宛先MACアドレスを確認して、適切な出力ポートから出力する。
８．VMに届き、一件落着！！

p.5 タグVLANとは？—–

VLANには主に２つの種類がある。ポートベースVLANとタグVLANである。
ポートベースVLAN：
　ポートに直接VLANを割り当てる方式。いわば、そのポートからは１つのVLANしか扱えないということ。
タグVLAN：
　パケットの中（送信元MACとタイプの間）にVLANタグを挟むことでポートに依存しないVLANを構成することができる。つまり、１つのポートで複数のVLANを扱えるということ（＝トランクリンク）。

p.5 PIM-SMとは？———

PIM-SMやPIM-DMとはマルチキャスト通信を目的地まで届けるためのルーティングプロトコル。
PIM-SM：
　配信ツリーの作り方：受信側から「ちょうだい（Join）」と言われてから、必要な場所にだけ伸ばしていく。
　作るツリー：最初は 共有ツリー（RPT） を作り、途中から 最短経路ツリー（SPT） に切り替える。
＊共有ツリーとはマルチキャストで使われるルーティングテーブルのこと。
PIM-DM:
　配信ツリーの作り方：最初にとりあえず全網へドカンと流し、不要な場所から「いらない（Prune）」と言われて削っていく。
　作るツリー：最初からいきなり 最短経路ツリー（SPT） を作る（※DMには「共有ツリー」や「ランデブーポイント」は存在しません）。

そもそもマルチキャストとは？——

マルチキャストとは、複数の宛先にまとめて送れるアドレスのこと。複数ユーザーに１回１回ユニキャストすると、送信元のCPU負荷や経路途中の帯域などを非効率に使ってしまう。しかし、マルチキャストであれば、１つの送信で複数の宛先に届くため、より効率的になる。

▼マルチキャストの種類

▼マルチキャストのコマンド

#マルチキャストルーティングテーブルの表示
show ip mroute

#ランデブーポイントの情報を表示
show ip pim rp mapping

#ランデブーポイントの設定
ip multicast-routing　#マルチキャストの有効化
ip pim rp-address RPのアドレス

#PIM-SMの有効化
interface g0/0
ip pim sparse-mode

なぜ現行ネットワークではLAGができないのか？——-

現状の構成と新規の構成を比較して、色々な疑問が出てくる。なぜそもそもこのような構成なのか？なぜ現行ではLAGできないのか。。などなど。それらの疑問を一つずつ紐解いていこう！

Q.なんで、L3SW11とL3SW12に分けてるの？
リンクアグリゲーションをしたいなら最初からL3SW11に２本のリンクつなげればよくね？
A.L3SW11が故障した場合、物理サーバ内のすべてのVMが利用不可能になってしまうため、冗長性として、L3SW12を準備している。

Q.現行構成ではどうやって経路切り替えしているの？
L3SW11とL3SW12によって冗長化構成になっていることは理解できた。しかし、もしL3SW11に障害が発生した場合は、どのように検知してどのように経路がL3SW12へと切り替わるのかのイメージがつかめない。。。
A.現行構成ではNICチーミングが使われている。では、フローを見ながら理解していこう！
①物理障害の検知
　L3SW11が落ちるとサーバの左側NICのリンクがダウンする
②サーバ内の切り替え
　サーバの仮想スイッチが「あ、メインの線死んだ。。」と判断して右側のNICをアクティブにする
③GARPの送信
　サーバは切り替えた瞬間に「私（VM）は切り替えました」というGARP（GratuitousARP）をL3SW12に向けて投げる
④L3SW12からリモートVTEPに伝播
　L3SW12に届いたGARPはVXLANヘッダにカプセル化され、マルチキャストグループ宛てに送信される。そして、リモートVTEPまで渡り学習される。
　リモートVTEPは、外側の送信元（L3SW12）のIPアドレスと、内側のGARP情報（リモートVMのIP、MAC）を学習する。また、内側の情報は、適切なVLAN内へブロードキャストして伝える

Q.現行だとなぜLAGできないの？
A.LAG（リンクアグリゲーション）をするにはいくつかの条件を満たす必要がある。しかし、現行では、L3SW間でスタック接続や同期設定を採用しているわけではないのでLAGはできない。
１．System ID
　SystemIDは「ブリッジ優先度＋スイッチMACアドレス」で構成されている。これがLAG対象の対向リンクですべて一致している必要がある。
２．ポート設定
　速度、モード（Full Duplex）、VLAN設定（Trunk/AccessやVLAN ID）が双方で一致していること
３．LACPキー
　双方で同じポートグループとして設定されていること

#Etherchannelの作成
interface range G0/0-1
channel-group 1 mode active
exit

#Etherchannelの詳細設定
interface Port-channel 1
switchport mode trunk
switchport trunk allowed vlan 100,200

#Etherchannelの状態確認
show etherchannel summary

なぜ新構成ネットワークだとLAGできるのか？—-

現行の構成では、さまざまな制約によりLAGができなかった。しかし、新構成にするとなぜかLAGができる。どうやらEVPNやESIと呼ばれる機能がそれらを支えているらしい。。。しかし詳しいことはわからない。なので、それを紐解いていこう！

Q.ESIとは？
A.ESI（EthernetSegmentIdentifier）とは名前の通りセグメントの識別子である。つまり、同一の物理サーバにつながっているL3SWリンクのESIは同一のESIとして設定する。
なお、ESIを設定する目的はVTEP同士で、自分と同一のESIであればVTEP間でテーブル情報を同期したり、配下のサーバーとのLAGのための仮想MAC同期などを実施できるようになる。
また、周囲のVTEPに対しても同一のESIを持つものだと認識させL3ネットワーク上の負荷分散などにも寄与させることができる。

Q.ESIとEVPNの関係は？
A.ESIはEVPNのType４に載せて広告する。

Q.EVPN-MHとは？
EVPNとESIをつかって～というと、マルチホーミングが～でといった返しをされることがある。いったいなんなのか？
A.EVPN-MH（EVPN-MultiHoming)とはEVPNとESIを組み合わせて配下にある機器にとっての出口を複数にする技術である。マルチホーミングとは、１つの端末が複数のスイッチやルーターに対して足を延ばして冗長接続している状態のことである。

Q.なぜ新構成ではLAGが組めるのか？
A.ESIによって、VTEP間で同一セグメント内であることを認識できるようになったためLAGが組めるようになった。具体的には、同一セグメントであると判断すると、そこから動的に仮想MACアドレスを生成・同期できる。LAGの条件である同一のシステムID（ブリッジ優先度＋スイッチMAC）を利用することができるようになるので、LAGが組めるようになる。

Q.なんでスタック接続しないの？
スタック接続をすれば、わざわざL3で同期したりする必要もなくなる。なのに、L3での同期にこだわっている。それはなぜ？
A.一見よさそうに見えるスタックだが、デメリットも存在する。
・脳みそが共通化されてしまう：
　脳みそが共通化されると、片方のスイッチでOSバグやバッファあふれが起きると、もう片方も巻き添えを食らうことになってしまう。つまり、冗長化のための機能を果たせなくなってしまう。
・物理的な制約：
　スタックは物理的な接続が必要なので、少し離れてしまうとケーブルが届かなくなってしまう。

Q.VSSとStackWiseの違いは？
CiscoのCCNPなどでよく出てくるこれら二つの用語は非常に紛らわしい。ということで、先ほどまでで関連用語が出てきたので、この先にまとめておこう！

設問１

（１）複数機器のログを時系列で確認するため

NTP×ログ解析ときたら→「複数機器＆時系列」という組み合わせが王道。複数機器同士で異なる時間軸を使ってしまうと、ログを時系列で確認できなくなってしまう。そのため、同一の時間軸を使うことでしっかりとログの前後関係が明確になり、事象を追いやすくなる。

（２）登録したFQDNやIPアドレス宛ての通信をブロックするため / 利用者認証を行うため / Webサイトへのアクセス履歴の確認のため

▼p.16

そもそも、プロキシの目的は、アウトバンド（内→外）の通信に対して「誰が、どこに、何を」といった情報を検査することである。
「誰が」を担当するのが認証、「どこに」はURLフィルタリング、レピュテーションが担当し、「何を」はSSLインスペクション、DLPなどが担当する。
要は、認証、フィルタリング、ログ収集という３つの主要な役割がある。それを本文中から見つけてあげればよい。

（３）L3SWのDHCPリースログ

FWの通信ログにもIPアドレスは記載されている。しかし、社内IPアドレスは概して動的に一時的付与であることが多い。そのため、不正通信が発覚した時刻に使われていたIPアドレスの利用者と現在の当該IPアドレス利用者ではリース時間の関係で異なる可能性がある。そのため、DHCP機能を有したL3SWのDHCPリースログを確認する必要がある。

▼PC（MACアドレス）を特定するコマンド

#DHCPバインディングテーブルの表示
show ip dhcp binding

#DHCPバインディングテーブルで192.168.1.50を含む行のみ表示
show ip dhcp binding | include 192.168.1.50

#Syslogの中でDHCPが含まれている＆192.168.1.50が含まれているログを出力する
show logging | include DHCPD.*192.168.1.50