哲学者トニーくん

問題文

企業Aの拠点間接続におけるGRE over IPsecの導入

企業Aでは、本社と3つの支社間で安全かつ柔軟な通信を行うために「GRE over IPsec」を利用した拠点間VPNを導入することになった。

本社と各支社はインターネットを介して接続されており、既存の通信はIPsec VPNで暗号化されていた。しかし、支社ごとに複数のネットワークセグメントが存在し、OSPFによる動的ルーティングを利用したいという要望があった。そこで、IPsecの暗号化機能とGREのカプセル化機能を組み合わせることになった。

以下のネットワーク構成図を参照し、設問に答えよ。

[本社] ---[インターネット]---[支社1]
    |                               |
[192.168.1.0/24]            [192.168.2.0/24]

• 本社ルータ：WANインターフェース 203.0.113.1
• 支社1ルータ：WANインターフェース 198.51.100.1

GREトンネルの構成は以下の通り：

• トンネルインターフェースIP（本社）：10.0.0.1/30
• トンネルインターフェースIP（支社1）：10.0.0.2/30

IPsec設定は以下のポリシーに基づく：

• 暗号化アルゴリズム：AES-256
• 認証アルゴリズム：SHA-256
• IKEバージョン：IKEv2

設問

(1) GRE over IPsecを利用する理由として、以下の空欄[A]〜[C]に当てはまる語句を答えよ。

1. GREは、[A] プロトコルをカプセル化することで、異なるネットワーク間で非IPトラフィックやマルチキャスト通信を通過させることができる。
2. しかし、GRE自体には[B] 機能がないため、IPsecで通信内容を暗号化する必要がある。
3. GRE over IPsecの構成を用いることで、[C] などの動的ルーティングプロトコルを安全に利用できる。

(2) GREトンネルを構成した際の本社ルータ側の設定コマンド（Ciscoルータ）として適切なものを以下から選び、番号で答えよ。

interface Tunnel0  
  ip address 10.0.0.1 255.255.255.252  
  tunnel source 203.0.113.1  
  tunnel destination 198.51.100.1  
  tunnel mode ipsec ipv4  

interface Tunnel0  
  ip address 10.0.0.1 255.255.255.252  
  tunnel source 203.0.113.1  
  tunnel destination 198.51.100.1  

crypto map VPN-MAP 10 ipsec-isakmp  
  set peer 198.51.100.1  
  set transform-set ESP-AES-SHA  
  match address 100  

(3) トンネルインターフェースが正常に確立した場合、本社側ルータで以下のコマンドを実行した結果、支社側のトンネルIPが返ってこなかった。このとき、考えられる原因として最も適切なものを答えよ。

ping 10.0.0.2 source 10.0.0.1  

1. 支社側のトンネルインターフェースが無効になっている
2. IPsecのSA(Security Association)が確立されていない
3. 本社側でトンネルモードが正しく設定されていない
4. 支社側ルータのNAT設定が不正である

解答と解説

設問 (1)

1. GREは、[A] プロトコルをカプセル化することで、異なるネットワーク間で非IPトラフィックやマルチキャスト通信を通過させることができる。
2. しかし、GRE自体には[B] 機能がないため、IPsecで通信内容を暗号化する必要がある。
3. GRE over IPsecの構成を用いることで、[C] などの動的ルーティングプロトコルを安全に利用できる。

• [A] 任意のレイヤ3
• [B] 暗号化
• [C] OSPF

• GRE（Generic Routing Encapsulation）は、IPパケットだけでなく、IPv6、IPX、AppleTalk などのさまざまなレイヤ3プロトコルをカプセル化できます。これにより、異なるネットワーク間でマルチキャストやブロードキャストパケットを通過させることができます。
• ただし、GRE自体には暗号化機能がないため、データはそのまま平文で流れてしまいます。そこで、GREパケットごとIPsecで暗号化すると、安全性が確保できます。
• OSPFなどの動的ルーティングプロトコルはマルチキャストを使うので、IPsec単体では通りませんが、GREトンネル上なら正常に動作します。

哲学者トニーくん

IPsecはマルチキャストを扱えない。なので、OSPFのパケット（マルチキャスト）をユニキャストして扱えるようにする手段として、GREヘッダを挟むという訳です。

扱えない理由としては、IPsecで鍵交換する際にマルチキャストだと、相手が複数あり過ぎてどの相手とSAを確立すべきか分からなくなってしまうからです。また、マルチキャストに所属しているすべての相手と交換するという手段もありますが、それはもはやユニキャストになってしまい、マルチキャストのメリットが享受できません。

Nginx

| IPsecヘッダ | 外側IPヘッダ | GREヘッダ | 内側IPヘッダ | OSPFパケット |

設問 (2) の解答と解説

1.

interface Tunnel0  
  ip address 10.0.0.1 255.255.255.252  
  tunnel source 203.0.113.1  
  tunnel destination 198.51.100.1  
  tunnel mode ipsec ipv4  

この設定では、トンネルモードとして次の行があります：

tunnel mode ipsec ipv4

これは IPsecトンネルモード を直接トンネルインターフェースに適用しています。実はこの方法だと、GREトンネルが使えなくなるんです。つまり、「GRE over IPsec」ではなく、純粋なIPsecトンネルになります。

• GREのメリット（マルチキャスト対応、動的ルーティングプロトコルの利用）が失われる
• OSPFやEIGRPなどのマルチキャストを使うプロトコルが正常に動かない

要するに、「GREトンネルをIPsecで暗号化したい」のに、IPsecトンネルモードにしてしまうと、GRE自体が無効化されるわけです。

2.

interface Tunnel0  #仮想インターフェース "Tunnel0" を作成・設定します
  ip address 10.0.0.1 255.255.255.252  #仮想インターフェース（トンネル）のIPアドレスを設定
  tunnel source 203.0.113.1  #物理インタフェースのIPアドレスを設定
  tunnel destination 198.51.100.1  #相手の物理インタフェースアドレスを設定

この設定では、シンプルなGREトンネルを作成しています。

• トンネルインターフェースのIPアドレスを設定（仮想リンクのIP）
• トンネルの送信元・宛先IPを指定（物理インターフェースのパブリックIP）

この状態でトンネルができたら、IPsec設定は別途 “crypto map” で行うのが正しい構成です。つまり：

• GREでマルチキャストパケットをユニキャストパケットに包む
• IPsecでGREパケットごと暗号化

この順番を守ることで、動的ルーティングプロトコルが動作しつつ、安全な通信が確立します。

3.

crypto map VPN-MAP 10 ipsec-isakmp  
  set peer 198.51.100.1  
  set transform-set ESP-AES-SHA  
  match address 100  

これはIPsecのCrypto Mapの設定です。

• peer → トンネルの宛先IPアドレスを指定
• transform-set → 暗号アルゴリズム（AESとSHA）を指定
• match address → 暗号化対象トラフィックをアクセスリストで指定

この設定自体は必要ですが、インターフェース設定が抜けています。通常、これを使うなら：

interface Tunnel0
  tunnel source 203.0.113.1
  tunnel destination 198.51.100.1
  crypto map VPN-MAP

のように、トンネルインターフェースにCrypto Mapを紐付ける必要があります。単にCrypto Mapだけ定義しても、インターフェース側で使わないとIPsecが動きません。

設問 (3) の解答と解説

(3) トンネルインターフェースが正常に確立した場合、本社側ルータで以下のコマンドを実行した結果、支社側のトンネルIPが返ってこなかった。このとき、考えられる原因として最も適切なものを答えよ。

ping 10.0.0.2 source 10.0.0.1  

1. 支社側のトンネルインターフェースが無効になっている
2. IPsecのSA(Security Association)が確立されていない
3. 本社側でトンネルモードが正しく設定されていない
4. 支社側ルータのNAT設定が不正である

ping コマンドで支社のトンネルIPに通信できなかった理由として最も考えられるのは、IPsecのSAが確立していないことです。
SAが確立されていなければ、GREパケットが暗号化されずインターネット上で破棄される可能性があります。
この場合、以下のコマンドでSAの状態を確認できます。

show crypto ipsec sa 

もしSAが確立されていなければ、以下の点をチェックするとよいです：

• IKEフェーズ1・フェーズ2の設定（暗号化アルゴリズム、認証方式、プリシェアードキー）が一致しているか
• アクセスリストでGREトラフィック（プロトコル番号 47）が許可されているか
• 双方のルータのトンネルインターフェースのステータスが「up/up」になっているか

哲学者トニーくん

問題：IPsecを用いた拠点間接続の設計とトラブルシューティング

ある企業では、2つの拠点間を安全に接続するため、IPsec VPN を利用することになりました。以下のネットワーク構成図を参考に、設計方針やトラブル発生時の対応について考えてください。

ネットワーク構成図:

拠点A                         拠点B
+-------------+              +-------------+
| 192.168.1.0/24| ←IPsec→ | 192.168.2.0/24 |
|  ルータA      |              |  ルータB      |
|  (VPN GW)    |              |  (VPN GW)    |
+-------------+              +-------------+

IPsec設定情報:

• プロトコル: ESP (Encapsulating Security Payload)
• 暗号化アルゴリズム: AES-256
• 認証アルゴリズム: SHA-256
• モード: トンネルモード
• キー交換: IKEv2
• SAの有効期限: 3600秒

設問1: IPsecの基本動作

IPsecのトンネルモードにおいて、拠点Aから拠点Bへのパケット送信時に、次の処理が行われます。以下の問いに答えなさい。

(1) ESPを使用した場合、IPパケットにどのような変化が加えられるか、ヘッダ構成を説明しなさい。
(2) IKEv2を用いた鍵交換において、SA(Security Association)が確立されるまでの主要なフェーズを2つ挙げ、それぞれの役割を簡潔に説明しなさい。

設問2: トラブルシューティング

拠点Aのクライアントから拠点Bのサーバへの通信が確立しないという問い合わせがありました。調査の結果、ルータAのログに以下のメッセージが記録されていました。

IPsec: no proposal chosen

このメッセージの意味を説明し、問題を解決するための具体的な設定変更案を述べなさい。

設問3: セキュリティ強化

セキュリティをさらに強化するために、現在のIPsec設定に「Perfect Forward Secrecy (PFS)」を追加することが検討されています。

(1) PFSとは何かを説明しなさい。
(2) PFSを有効にすることで得られる利点と、考慮すべきパフォーマンスへの影響について述べなさい。

問題は以上です！

解答と解説

【FAQ】IPsecのあるある疑問をパパっと解消

そもそもIPsecって何？ IPsecとは？ VPNとは？ IPsecとVPNの関係 具体的なイメージ まとめ IPsecとESPの関係は？また、IPsecとIKEの関係は？ IPsecとESPの関係 IKEv2とは？ IPsecとIKEv2の関係はこう考える！ 鍵交換のフェーズで中間者攻撃される危険性もあるよね？ IKEv2 鍵交換の前のやり取りは本当に危険？ IKEv2 が中間者攻撃を防ぐ仕組み ① Diffie-Hellman (DH) 鍵交換 ② Nonce (ノンス) とハッシュの検証 ③ デジタル署名 & 証明書 (ID 認証) ④ 暗号アルゴリズムのネゴシエーションの保護 まとめ：IKEv2 が中間者攻撃に強い理由 フェーズ1 (IKE-SA) で Diffie-Hellman で鍵を共有できるなら、それだけで直接 IPsec のパラメータ交換して、そのまま通信開始すればよくない？ まず前提整理：フェーズ1 とフェーズ2 の役割 なぜ IKE-SA だけじゃダメなのか？ 1. IKE-SA の鍵は IKE 用、データ通信には向かない 2. 複数の Child-SA を作れる柔軟性 3. 鍵の再生成・ローテーションがスムーズ 4. フェーズ1 だけだと IPsec の細かい制御が難しい まとめ：フェーズを分ける意味 もしフェーズ1だけで済ませると？ 結論：フェーズを分けることでセキュリティと運用性を両立 フェーズ１の鍵が漏洩したら、元も子もないんじゃない？ 前提確認：フェーズ1とフェーズ2の関係 鍵漏えい時のリスクと設計思想 1. Diffie-Hellman の鍵交換自体は超強力 2. Perfect Forward Secrecy (PFS) の意味 3. フェーズ1鍵の漏えいは超クリティカルだけど短命 4. 鍵漏えいの現実的な経路 フェーズ1鍵漏えい時の対策 結論：フェーズ1の鍵漏えいは致命的、でも設計上の防御策は万全 フェーズ1 (IKE-SA) が短期間で終わるなら、フェーズ2 (Child-SA) の鍵ローテーションって意味あるの？ フェーズ1とフェーズ2の役割をもう一度整理 なぜフェーズ1が短期間でもフェーズ2の鍵ローテーションが必要なのか？ 1. IKE-SA は「メタ通信路」、Child-SA は「実データ通信」 2. フェーズ1の再ネゴシエーションは重い 3. セッション継続性の確保 4. 攻撃者のコストを爆増させる まとめ：フェーズ1短期終了と鍵ローテーションのバランス

ascend-beyond.com

2025.03.09

設問1(1) ESPを使用した場合のパケット変化

解答:
ESP (Encapsulating Security Payload) を使うと、IPパケットは暗号化・認証されます。トンネルモードでは、以下のようにヘッダ構成が変化します。

[新IPヘッダ] + [ESPヘッダ] + [元IPパケット (暗号化)] + [ESPトレーラ] + [ESP認証データ]

• 新IPヘッダ: VPNゲートウェイ同士のIPアドレスを送信元・宛先とするヘッダ。
• ESPヘッダ: セキュリティパラメータインデックス (SPI) やシーケンス番号を含む。
• 元IPパケット: 元の送信者と受信者のIPヘッダとデータ部全体が暗号化される。
• ESPトレーラ: パケットの長さ調整やプロトコル識別用データ。
• ESP認証データ: パケットの改ざん検知用のハッシュ値 (SHA-256 など)。

解説:
ESPは、通信データの 暗号化 と 完全性保護 を提供します。トンネルモードでは、元IPパケット全体を暗号化し、新しいIPヘッダを付加します。これにより、送信元や宛先のIPアドレス自体も隠され、セキュリティが強化されます。

設問1(2) IKEv2のフェーズ

解答:
IKEv2 には、次の2つの主要なフェーズがあります。

1. IKE SA (Security Association) の確立:
   • 双方のデバイスが暗号アルゴリズムや認証方式を交渉し、鍵交換を行う。
   • Diffie-Hellman (DH) 鍵交換で共有鍵を生成し、安全な通信チャネルを作成。
2. Child SA の確立:
   • 実際のデータ通信のためのIPsec SAを作成。
   • ここでESPや暗号化アルゴリズムのパラメータが決定され、通信準備完了。

解説:
IKEv2では、最初に安全な制御チャネルを作り、その後データ用のセキュリティ設定を確立します。これにより、安全に暗号鍵を交換しつつ、柔軟にセッション管理ができます。

哲学者トニーくん

２つのフェーズに分ける利点は…..堅牢な基盤 (IKE SA) + 軽くて回転の速い鍵 (Child SA) を組み合わせることで、安全性と効率のバランスを取っているんです！

フェーズ1 (IKE SA)

• 強固で安全な基盤を作るフェーズ。
• Diffie-Hellman でトンネル用の共通鍵を生成。
• ただし計算コストが高いため、頻繁には再生成しない。

フェーズ2 (Child SA)

• 実際のデータを暗号化するフェーズ。
• 軽くて素早く作成できるセッション鍵を使う。
• 定期的に鍵を自動更新し、漏洩しても影響を最小限に抑える。

2つに分けるメリット

• IKE SA で一度強固な安全トンネルを作れば、Child SA で効率的に暗号化通信を回せる。
• Child SA は頻繁に更新できるので、万が一鍵が漏洩しても、すぐ新しい鍵に切り替わる。

設問2: トラブルシューティング

IPsec: no proposal chosen

解答:
ログメッセージ “IPsec: no proposal chosen” は、両拠点のVPNゲートウェイ間で暗号化アルゴリズムや認証方式の設定が一致しない場合に発生します。

解決策:
ルータAとルータBのIPsec設定を見直し、暗号化・認証アルゴリズムが一致していることを確認します。例えば、以下の項目をチェックします：

• 暗号アルゴリズム: 両方とも AES-256 になっているか？
• 認証アルゴリズム: 両方とも SHA-256 になっているか？
• DHグループ: 両端が同じグループ番号を使っているか？ (例: group 14)
• ライフタイム: SAの有効期限が同じか？ (例: 3600秒)

解説:
IPsecは両拠点の設定が完全に一致していないと接続できません。設定ミスがあると交渉失敗し、IPsecトンネルが張れなくなります。ログメッセージは問題箇所のヒントになるので、しっかり読み取ることが大切です！

哲学者トニーくん

DHグループとは..DHグループは、Diffie-Hellman（ディフィー・ヘルマン）鍵交換アルゴリズムで使われる「鍵の強度」を決めるパラメータセットのことです！ざっくり言うと、「どれだけ複雑で安全な数学的計算を使うか」を決めるものです。グループ番号が大きくなるほど、計算量が増えてセキュリティは強くなりますが、その分処理速度は遅くなります。

代表的なグループ

• 速度重視：Group 19 (楕円曲線 256bit) → 軽くて強度も十分
• バランス型：Group 14 (2048bit) → 現代の標準。十分強く、速度も悪くない
• 最高強度：Group 20 (楕円曲線 384bit) or Group 24 (2048bit 以上) → 国家レベルの機密情報など超重要な通信向け

設問３(1) PFSとは？

解答:
Perfect Forward Secrecy (完全前方秘匿性) とは、セッションごとに異なる一時的な鍵を使うことで、過去のセッション鍵が盗まれても、他のセッションの通信内容は解読されない仕組みです。

解説:
通常の鍵交換だと、もし長期鍵が盗まれると、過去の通信内容も解読されるリスクがあります。しかし、PFSではセッションごとに新しい鍵を生成するため、過去や未来の通信への影響を防げます。

設問３(2) PFSの利点とパフォーマンス影響

解答:

• 利点:
  • セッションごとに新しい鍵を生成 → 鍵漏洩リスク低減。
  • 過去の暗号化データを盗聴されても解読困難。
• パフォーマンスへの影響:
  • 鍵交換のたびに新しいDH計算が必要 → CPU負荷増加。
  • 高トラフィック環境では、VPNゲートウェイの処理遅延発生の可能性。

解説:
PFSはセキュリティを強化する代わりに、処理コストが上がります。ただし、最近のルータやファイアウォールはハードウェアアクセラレーション機能があるため、適切な機器を選べばパフォーマンス問題は最小限に抑えられます。

哲学者トニーくん

問題文

ある企業 A 社は、国内の複数拠点を接続するために、通信事業者が提供する IP-VPN サービスを利用している。この IP-VPN サービスは、MPLS (Multiprotocol Label Switching) を用いた閉域ネットワークで構成されている。これにより、インターネットを経由せずに安全かつ効率的な拠点間通信が可能となっている。

A 社は次のような要件を満たすネットワークを構築したいと考えている：

• 拠点ごとに異なる IP セグメントを使用する。
• 優先度の高い通信（例えば、ビデオ会議）は低遅延で安定した通信経路を確保する。
• 新しい拠点が追加されても、既存の拠点の設定変更を最小限に抑えたい。

IP-VPN サービスは、MPLS による L3VPN (Layer 3 VPN) を用いて提供されており、各拠点には CE (Customer Edge) ルータが設置されている。通信事業者側のネットワークには PE (Provider Edge) ルータが存在し、MPLS ラベルを用いてパケット転送を行っている。

以下の図は、A 社の拠点間接続の概要を示している。

CE1 ---- PE1 ---- P ---- PE2 ---- CE2  

ここで、

• CE1, CE2：A 社の拠点ルータ
• PE1, PE2：通信事業者のエッジルータ
• P：通信事業者内部のコアルータ

A 社は、通信品質向上のため、トラフィックエンジニアリング (TE) を活用し、特定の拠点間通信を最適化したいと考えている。また、各拠点間の IP アドレス管理を簡素化するため、BGP (Border Gateway Protocol) を用いたルート制御を導入している。

設問 1

MPLS を使用した IP-VPN において、拠点間のデータ通信がどのように MPLS ラベルを用いて転送されるかを説明せよ。

設問 2

MPLS L3VPN における「VRF (Virtual Routing and Forwarding)」の役割を 具体的な例を挙げて説明せよ。

設問 3

通信事業者は、トラフィックエンジニアリング (TE) を実現するために、MPLS-TE を導入している。MPLS-TE の仕組みと、A 社がビデオ会議の遅延を抑えるために MPLS-TE を活用する方法について説明せよ。

設問 4

新しい拠点 CE3 を追加する場合、A 社の既存拠点の設定変更を最小限にするために、BGP のどの機能を活用すればよいか。また、その機能がどのように拠点追加時の運用負担を軽減するか説明せよ。

解答＆解説

設問 1：MPLS を使用した IP-VPN において、拠点間のデータ通信がどのように MPLS ラベルを用いて転送されるかを説明せよ。

解答:
MPLS を使用した IP-VPN では、通信事業者のネットワーク内でパケットに MPLS ラベルを付与して転送する。以下の流れで通信が行われる。

1．ラベルの付与 (Push)
CE1 から PE1 に送信された IP パケットは、PE1 で BGP ルーティング情報に基づき VRF を参照し、対応する MPLS ラベルを付与する。

哲学者トニーくん

VRF (Virtual Routing and Forwarding) とは、ルーター内に複数の独立したルーティングテーブルを作成する技術。

2．ラベルスイッチング
PE1 から P ルータへの転送時、MPLS ラベルに基づいてパケットを転送する。コアルータ (P ルータ) は IP アドレスではなくラベルを見て転送するため、高速な転送処理が可能。

3．ラベルの入れ替え (Swap)
中継する P ルータでは、受信したラベルを次のホップ用ラベルに置き換えて転送する。

4．ラベルの削除 (Pop)
最終的に PE2 に到達すると、PE2 はラベルを外し (ラベルポッピング)、元の IP パケットを CE2 に転送する。

この仕組みにより、拠点間の通信は事業者ネットワーク内でラベルにより効率的かつ閉域的に行われる。

哲学者トニーくん

MPLSとは、そもそも何かというと….MPLSとはIP アドレスではなくラベルを使ってパケットを転送する技術です。これにより、ルータは IP ルーティングテーブルを毎回検索する必要がなく、処理が高速化します。また、ラベルを工夫して使うことで、トラフィックの負荷分散や仮想ネットワークの分離など、柔軟なネットワーク設計ができるのも特徴です。

設問 2：MPLS L3VPN における「VRF (Virtual Routing and Forwarding)」の役割を 具体的な例を挙げて説明せよ。

解答:
VRF は、ルータ内に複数の独立したルーティングテーブルを作成し、異なる VPN を分離して管理する仕組み。例えば、A 社と B 社が同じ通信事業者の IP-VPN を利用していても、それぞれの拠点は VRF により論理的に分離される。

• 具体例:
  • A 社の拠点: 192.168.1.0/24
  • B 社の拠点: 192.168.1.0/24 (同じアドレス範囲でも VRF で独立)

PE ルータは VRF を参照して、宛先に対応する MPLS ラベルを付与し、各社のトラフィックが混在しないよう制御する。この仕組みで、プライベートアドレス空間を利用しつつ、安全な通信を実現できる。

哲学者トニーくん

MPLSは１台のルータ内に複数のルーティングテーブルを持つことができます。つまり、同じIPアドレスを使ってもルーティングテーブルが違うから、それらは別物として振る舞うことができるよねっていうことです。

設問 3：通信事業者は、トラフィックエンジニアリング (TE) を実現するために、MPLS-TE を導入している。MPLS-TE の仕組みと、A 社がビデオ会議の遅延を抑えるために MPLS-TE を活用する方法について説明せよ。

解答:
MPLS-TE は、特定の通信経路に帯域制御や優先制御を適用し、最適な経路選択を行う技術。拠点間のビデオ会議トラフィックを安定させるには、以下の手順を踏む。

1. 帯域予約
   特定の MPLS ラベルスイッチパス (LSP) に帯域を予約し、ビデオ会議など遅延に敏感なトラフィックを優先させる。
2. リンク状態の考慮
   RSVP-TE (Resource Reservation Protocol) を使用して、ネットワークのリンク状態や遅延を考慮した最適経路を構築する。
3. 柔軟な経路制御
   通常の IP ルーティングでは最短パスのみ選択されるが、MPLS-TE により回線負荷が低い経路を選択することで、混雑による遅延を回避できる。

このように、MPLS-TE を活用すれば、ビデオ会議などの重要なトラフィックの安定性と品質を確保できる。

哲学者トニーくん

トラフィックエンジニアリング (Traffic Engineering, TE) は、ネットワークのトラフィックを最適に制御・分散させて、効率的に通信できるようにする技術や手法 のことです。

通常のルーティングプロトコル (OSPF, BGP など) は、最短パス を選ぶことが多いです。ところが、ネットワークには帯域のムダ遣い、ボトルネック、障害発生時の冗長性不足などの問題があり、それらの問題に効率的に対処するルーティング方法がTEという訳です。

設問 4：新しい拠点 CE3 を追加する場合、A 社の既存拠点の設定変更を最小限にするために、BGP のどの機能を活用すればよいか。また、その機能がどのように拠点追加時の運用負担を軽減するか説明せよ。

解答:
拠点追加時の設定変更を最小限に抑えるには、BGP の Route Reflector (RR) や Route Target (RT) を活用する。

1．Route Reflector (RR)
PE ルータの一部を RR に指定し、各拠点 (CE ルータ) から受信した経路情報を他の拠点に自動的に広報する。これにより、新拠点 CE3 を追加しても、既存の CE1, CE2 へのルータ設定変更は不要になる。

哲学者トニーくん

RRはBGPにおける中央ハブ。通常、BGPはフルメッシュ接続なので、１第1台が直接リンクする必要がある。しかし、それだとスケールの障壁となる。そこで、中央的なRRを用いることで、他のルータはRRとBGP セッションを張るだけですべてのルータと接続できるようになる。

2．Route Target (RT)
RT を使って、特定の VPN に関するルーティング情報を識別し、各拠点が受信すべきルートを制御する。例えば、新拠点 CE3 に RT を設定するだけで、必要なルートが自動的に広告される。

哲学者トニーくん

RTとはどのVRFにルートを入れるかを決めるタグ。１つのルータには複数のVRFがある。なので、どのテーブルに記載するかを指定する必要がある。そのときに使うタグがRT。

このように、BGP の動的経路制御機能を使うことで、新拠点追加時の手作業を大幅に減らせる。

まとめ

MPLS を使った IP-VPN は、ラベルスイッチングにより高速かつ閉域的な通信を実現します。VRF によりネットワークを論理分離しつつ、MPLS-TE で重要なトラフィックの品質を最適化でき、BGP を使えば拠点追加時の運用負担も軽減できます。

ケルベロスについてのQ＆A

哲学者トニーくん

🔑 Kerberos とは？

Kerberos は、ネットワーク上で安全にユーザ認証を行うためのプロトコルです。特に、パスワードを盗まれずに安全にログインしたり、サービスにアクセスしたりするための仕組みとして使われます。

名前の由来は、ギリシャ神話の「ケルベロス（3つの頭を持つ冥界の番犬）」です。3つの頭は、次の3つの役割にたとえられます。

1. クライアント（利用者やPC）
2. 認証サーバ（AS: Authentication Server）
3. サービスサーバ（メールサーバやファイルサーバなど、利用したいサービス）

---

⚙️ 何がすごいの？

通常、ユーザがパスワードを使ってログインすると、ネットワーク上にパスワードが流れてしまいます。これだと、悪意ある第三者がパスワードを盗み見て不正アクセスする危険があります。

でも Kerberos は、次のような工夫で安全性を確保しています：

1. チケット（Ticket）を使う
   → パスワードそのものを送らず、「チケット」と呼ばれる一時的な証明書を発行します。このチケットを使ってアクセスします。
2. 暗号化
   → データは暗号化されてやり取りされるので、途中で盗み見られても内容は読めません。
3. タイムスタンプ
   → チケットにはタイムスタンプが含まれ、一定時間を過ぎると無効になります。これで「リプレイ攻撃」（過去の通信を再利用する攻撃）を防ぎます。

---

🚀 Kerberos の流れ（ざっくり版）

1. ログインリクエスト（クライアント→認証サーバ）
   → クライアントが認証サーバにログインを要求。
2. TGT（Ticket Granting Ticket）発行
   → 認証サーバは、パスワードから生成した鍵で暗号化された「TGT」をクライアントに渡します。これは「サービスチケット発行のための許可証」です。
3. サービスチケット取得
   → クライアントは、TGT を使って「TGS（チケット発行サーバ）」からサービス用のチケットを取得します。
4. サービスへのアクセス
   → クライアントはサービスサーバにチケットを提出し、正しければアクセスが許可されます。

これなら、ネットワーク上にパスワードが流れず、安全にサービスを利用できます！

---

🎯 一言で言うと？

Kerberos は「チケット制の認証システム」で、暗号化とタイムスタンプを活用して、ネットワーク上で安全にログインできる仕組みです！

たとえば、遊園地で「入場券（チケット）」をもらい、アトラクションごとにチケットを見せて乗る、みたいなイメージです！パスワード（現金）は直接出さず、チケットでやり取りするので安全、という感じです。

哲学者トニーくん

🏢 認証サーバ（AS）とチケット発行サーバ（TGS）はどういう関係性は？

実は、AS と TGS は物理的には同じサーバーに置かれることが多いんです！ただし、論理的には「役割」が分かれています。

• AS（Authentication Server）認証サーバ → パスワードを確認し、TGT を発行する
• TGS（Ticket Granting Server）チケット発行サーバ → TGT を確認して、サービスチケットを発行する

この2つは 同じ物理サーバー 上に動くことが多くて、まとめて KDC（Key Distribution Center: 鍵配布センター） と呼ばれます。

つまり、AS と TGS は「別の役割だけど、同じ場所にいることが多い」と考えてOKです！

---

🛜 ネットワーク構成のイメージ

例えば、会社のネットワークではこんな感じです！

HTTP

[クライアントPC]  
      ↓  
[認証サーバ (AS) + チケット発行サーバ (TGS)]  ← (ここが KDC)  
      ↓  
[ファイルサーバ、メールサーバなどのサービスサーバ]

• 最初のログイン → 認証サーバ（AS）が確認して、TGT を発行
• サービスアクセス時 → クライアントが TGT を持って TGS にリクエストして、サービスチケット発行

AS と TGS は同じ場所にあって、ポート 88 番 で Kerberos プロトコルの通信を待ち受けています。

---

⚙️ なんで役割が分かれてるの？

役割が分かれているのは、セキュリティを強化するためです。

• AS はパスワードの確認だけを行い、直接サービスチケットを発行しない
• TGS は TGT を受け取ってサービスチケットを発行するが、パスワードは扱わない

こうすると、パスワードが盗まれるリスクを減らしつつ、TGT をうまく使ってシングルサインオンを実現できます！

---

🎯 結論：AS と TGS は…

• 論理的には別物だけど、物理的には同じサーバーに置かれることが多い
• 両方合わせて KDC（Key Distribution Center: 鍵配布センター） と呼ぶ
• サービス提供側のネットワーク内（例えば Active Directory のドメインコントローラー）に設置される

哲学者トニーくん

クライアントはどうやってケルベロスを使うかどうかを判断するの？

クライアントは、「普段の通信」からいきなり「Kerberos を使う通信」に切り替えたりするわけではありません。実は、クライアントは事前に 設定ファイルや環境情報 をもとに、どのサービスが Kerberos を使うかを知ります。

具体的には次のような方法があります！

---

🏢 1. DNS（ドメインネームシステム）を使う

Kerberos は通常、DNS を使って KDC（認証サーバ） の場所を特定します。クライアントがサービスにアクセスするとき、まず DNS でサービス名を解決し、同時に Kerberos 関連のレコードを見に行きます。

🔧 SRV レコードの例

HTTP

_kerberos._tcp.example.com  IN SRV  0  100  88  kdc.example.com

これを見ると：

• example.com ドメインは Kerberos を使ってる！
• 認証サーバ（KDC）は kdc.example.com で、ポート 88 で待ち受けている

この情報があれば、クライアントは「じゃあ Kerberos 認証が必要だ！」と判断します。

---

🗃 2. サービス自体が「401 Unauthorized」で返してくる

たとえば Web サービスの場合、最初のリクエストで普通にアクセスしたときに、サーバーが HTTP 401 Unauthorized を返して、「Negotiate」ヘッダで Kerberos を要求することがあります。

🔧 レスポンス例

HTTP

HTTP/1.1 401 Unauthorized  
WWW-Authenticate: Negotiate

これを受け取ったクライアントは、「あ、このサービスは Kerberos 使ってるんだな」と気づいて、Kerberos チケットを取得し、再度リクエストを送ります。

---

⚙️ 3. OS の設定やクライアントの設定ファイル

クライアントマシン自体に Kerberos の設定ファイル（例：Linux の /etc/krb5.conf）があって、ここで「どのドメインが Kerberos を使うか」をあらかじめ決めておくこともできます。

🔧 krb5.conf の例

HTTP

[libdefaults]  
    default_realm = EXAMPLE.COM  

[realms]  
    EXAMPLE.COM = {  
        kdc = kdc.example.com  
        admin_server = kdc.example.com  
    }

この設定があると、クライアントは example.com のサービスにアクセスするとき、自動的に Kerberos 認証を試みます。

---

🧠 じゃあ Kerberos を使っていない場合は？

もしサービス側が Kerberos に対応していない場合は：

• DNS に Kerberos 関連のレコードがない
• サービスから 401 Unauthorized とか Kerberos を要求するレスポンスが返ってこない

この場合、クライアントは普通の通信（例：ユーザー名・パスワードでのログイン）にフォールバックします。つまり、「Kerberos ある？ → いないなら普通のやり方でアクセス」という流れです。

---

🎯 まとめると？

1. クライアントは自動で Kerberos を検出する
   • DNS SRV レコード
   • サービスの HTTP 応答ヘッダ（WWW-Authenticate: Negotiate）
   • OS やクライアントの設定ファイル
2. 使わないときは普通の通信に戻る
   • Kerberos のサーバーが見つからなかったり、サービスが Kerberos を要求しなければ、普通のパスワード認証などに切り替わる

---

例えば、Windows ドメイン環境では、クライアント PC はドメイン参加時に自動的に KDC の場所を DNS で探します。ユーザーは何もしなくても、必要なときだけ Kerberos 認証に切り替わるんです！

哲学者トニーくん

パスワードがネットワーク上を流れないってどういう仕組みで認証しているの？

ケルベロス認証は「パスワードを直接流さないから安全」って言っておきながら、最初にパスワードでログインするなら結局流れてるじゃん？って思いますよね。

でも実は、パスワードそのものはネットワーク上に直接流れていません！ここが Kerberos のすごいポイントなんです。順番に説明しますね！

---

🧠 最初の認証時のパスワード処理

クライアントがログインするとき、実際に KDC に送るのは パスワードのハッシュ値 を使った暗号化データです。これによって、パスワードの生データがネットワーク上を流れることはありません！
（パスワードのハッシュ値：パスワードをハッシュ関数に入れて算出された値のこと）

具体的にはこうなります：

1. クライアントがユーザーのパスワードから共通鍵を生成
   • パスワード自体ではなく、パスワードから ハッシュ関数 を使って鍵を作成
2. KDC からのチャレンジメッセージを暗号化
   • KDC は「ランダムなデータ」（ノンス）をクライアントに送信
   • クライアントはこのノンスを、パスワードハッシュで暗号化して返す
3. KDC 側で検証
   • KDC はユーザーごとにパスワードハッシュを持っている
   • 送られてきた暗号化データを復号し、ノンスが一致すれば認証成功！

---

🔑 なぜ安全なのか？

• パスワード自体は一切ネットワーク上に流れない
  • 流れるのは暗号化済みのデータだけ
  • 盗聴されてもパスワードの逆算は難しい（辞書攻撃や総当たり攻撃が必要）
• ノンスでリプレイ攻撃を防止
  • 毎回ランダムなデータ（ノンス）を使うので、過去のやりとりを盗んでも使えない
• チケットはクライアントとサーバー間でのみ利用可能
  • TGT やサービスチケットは、それぞれ固有の鍵で暗号化されていて、盗まれてもすぐ使えない

---

⚠️ でも完全無敵ではない！

たとえば、クライアントマシンが既にマルウェアに感染している場合は、キー生成の前段階でパスワードを盗まれる可能性はあります。でもこれは Kerberos に限らず、あらゆるシステムの共通課題ですね。

このため、Kerberos を運用するときは：

• クライアントとサーバーの時刻同期（タイムスタンプチェック）
• 安全なクライアント環境の維持（ウイルス対策・OS の更新）
• ネットワーク暗号化（例えば TLS で通信を二重に保護）

こうした総合的な対策が重要です！

---

🎯 まとめ

• Kerberos は最初のログイン時にもパスワードの生データは流さない
• パスワードハッシュ と ノンス を使ったチャレンジレスポンス方式で認証
• チケットとセッションキー を使い、ログイン後の通信はより安全

だから、「最初の認証でも安全」と言えるんです！

哲学者トニーくん

認証サーバからTGTを取得するまでの流れは？

Kerberos におけるログインから認証成功までの流れを、ノンス や 暗号化・復号化 のタイミングまで詳しく解説します！

以下の流れで、クライアントが認証され、TGT (Ticket Granting Ticket) を取得するまでのやりとりを追っていきましょう！

---

🏗️ 前提：事前に知っているもの

• ユーザー名 と パスワード（クライアントが入力）
• KDC（AS と TGS のセット） は、ユーザーのパスワードハッシュを保持

ここでは、共通鍵暗号 を使うので、パスワードから作ったハッシュ値（暗号鍵）が重要です！

---

📩 STEP 1: AS 要求（ログイン要求）

1. クライアントが AS（認証サーバ）に「ログインしたい」とリクエストします。
   • 送るデータ：
     • ユーザーID
     • タイムスタンプ

🔒 この時点ではまだ暗号化されていないですが、パスワード自体は送りません！

---

🔑 STEP 2: AS 応答（ノンスと TGT 発行）

2. AS はクライアントからのリクエストを受け取ると、次の処理を行います。
   • ノンス（ランダムな一時データ） を生成
   • TGT (Ticket Granting Ticket) を作成
   • セッションキー を生成
3. その後、以下のデータをクライアントに送信します。
   • TGT（TGS に渡す用のチケット）
   • セッションキー（共通鍵）
   • ノンス

🔒 ここが重要！ このデータは、KDC 側で保存してある「ユーザーのパスワードから作った暗号鍵」で暗号化します。

---

🔓 STEP 3: クライアント側で復号化

4. クライアントは、パスワードをローカルでハッシュ化して、暗号鍵を作ります。
5. サーバーからの応答データを、その暗号鍵で復号します。

この復号に成功すると：

• セッションキー を取得
• TGT を取得
• ノンス を確認

もし復号できなければ、パスワードが間違っていることがわかります。

---

✅ STEP 4: 認証成功

6. クライアントは、復号したノンスを使って 認証応答 を返します。
   • ノンス + 1 をセッションキーで暗号化して AS に送信
7. AS は、受け取ったデータをセッションキーで復号し、ノンスが正しいか確認します。
   • ノンス + 1 が正しければ認証成功！

これでクライアントは正式に認証され、TGT を使って TGS にサービスチケットをもらいにいけるようになります！

---

🔥 なぜ安全なのか？

• パスワード自体は一度もネットワークを流れない
• 共通鍵暗号 なので通信の盗聴だけでは復号できない
• ノンス により、リプレイ攻撃（過去の通信を再送信する攻撃）も防止

---

🏁 まとめ

Kerberos のログインフェーズは、次の手順で進みます！

1. クライアント → AS: ログインリクエスト（ユーザーID + タイムスタンプ）
2. AS → クライアント: ノンス・TGT・セッションキーをパスワードハッシュで暗号化して送信
3. クライアント: パスワードをハッシュ化 → サーバーメッセージを復号
4. クライアント → AS: ノンス + 1 をセッションキーで暗号化して返答
5. AS: ノンス + 1 をチェック → 認証成功！

この仕組みにより、パスワード漏洩のリスクを抑えつつ、安全なログイン処理 を実現しているんです！

哲学者トニーくん

TGTを取得してからサービスを利用するまでの流れは？

認証サーバー（AS）で認証が成功して、TGT（チケット発行チケット）をゲットした後、実際にサービスを使うまでの流れを一緒に見ていきましょう！

ここからは TGS（チケット発行サーバー） の出番です！

① クライアント → TGS にサービスリクエスト

クライアントは、「このサービスを使いたい！」と TGS にリクエストを送ります。

送るデータ：

• TGT（認証サーバーからもらったチケット）
• サービスID（どのサービスを使いたいか）
• タイムスタンプ
• 認証データ（セッションキーで暗号化したクライアントID＋タイムスタンプ）

➡️ TGT は暗号化されていて、TGS 以外は中身を見れません。だから盗まれてもすぐには悪用されません！

---

② TGS がリクエストをチェック

TGS は以下を確認します：

• TGT を復号（AS が発行したので、TGS なら復号できる）
• TGT の有効期限 をチェック
• 認証データをセッションキーで復号
• クライアントID や タイムスタンプ が一致するか確認

もし問題なければ、TGS はサービスチケットを発行します！

---

③ TGS → クライアントにサービスチケット発行

TGS は サービスチケット を作成して、クライアントに返します！

返すデータ：

• サービスチケット（対象サービス用のセッションキー入り、サービスサーバー用に暗号化）
• クライアントとサービスの共通セッションキー（クライアント用に暗号化）

---

④ クライアント → サービスサーバーに接続リクエスト

クライアントは、もらった サービスチケット を使って、サービスサーバーに接続リクエストを送ります。

送るデータ：

• サービスチケット（TGS からもらったもの）
• 認証データ（共通セッションキーで暗号化したクライアントID＋タイムスタンプ）

---

⑤ サービスサーバーが認証チェック

サービスサーバーは以下を確認します：

• サービスチケットを復号（TGS が発行したものなので、サービスサーバーは復号可能）
• セッションキーを取得
• 認証データを復号し、クライアントIDやタイムスタンプを確認

問題なければ、最終確認のため ノンス + 1 のようなレスポンスを返します。

---

⑥ クライアント → サービス利用開始！

クライアントはレスポンスを確認し、正常ならそのままサービス利用開始！
その後の通信は、サービスチケット内の セッションキー を使って安全にやりとりします。

---

✅ ポイントまとめ

• TGT は TGS だけが復号できる（他人が盗んでも無意味）
• サービスチケットはサービスサーバーだけが復号できる
• 共通セッションキー を使うことで、以降の通信は暗号化される
• タイムスタンプやノンス でリプレイ攻撃対策もバッチリ

つまり、クライアントはパスワードを1回入力するだけで、複数のサービスをシームレスに使える ！これが Kerberos の強みですね！

哲学者トニーくん

問題

企業A社では、社内システムのセキュリティ強化のため、ユーザ認証にKerberosを導入することにした。Kerberosはチケットベースの認証プロトコルであり、クライアントとサーバ間の通信を安全に行うことができる。以下の図は、A社のネットワーク構成の概要である。

[クライアントPC] — [認証サーバ (KDC)] — [アプリケーションサーバ]

A社のネットワークでは、クライアントPCがアプリケーションサーバにアクセスする際、Kerberos認証によってセッション鍵を共有する仕組みを採用している。以下の説明を読み、設問に答えなさい。

認証フロー

1. クライアントPCは、KDC の AS (Authentication Server) にユーザIDを送信し、チケット発行を要求する。
2. KDC の AS はクライアントのパスワードから生成された鍵を使い、セッション鍵と TGT (Ticket Granting Ticket) を暗号化してクライアントに返す。
3. クライアントは、AS から受け取った TGT を使い、TGS (Ticket Granting Service) にアクセスチケットを要求する。
4. TGS は、クライアントの TGT を検証し、アクセスしたいサーバ用のサービスチケットを発行する。
5. クライアントは、発行されたサービスチケットをアプリケーションサーバに送信し、認証を完了させる。

設問 1

次の文中の (a) ～ (c) に入る最も適切な語句を、解答群から選びなさい。

(1) クライアントPCは最初に、AS に対してユーザ名を送信し、(a) の発行を依頼する。
(2) AS は、ユーザのパスワードから生成された (b) を使って、セッション鍵と TGT を暗号化する。
(3) アプリケーションサーバは、受け取った (c) を検証し、クライアントとのセッションを確立する。

解答群

1. サービスチケット
2. チャレンジレスポンス
3. TGT
4. パスワードハッシュ
5. クライアントID

設問 2

以下の選択肢の中から、Kerberosの設計上の特徴として 適切なもの を2つ選びなさい。

• ア) パスワードはネットワーク上を平文で流れる。
• イ) サーバごとに秘密鍵が必要である。
• ウ) TGT の有効期限が切れると再認証が必要である。
• エ) クライアントは最初に直接サービスサーバと鍵交換を行う。
• オ) サービスチケットは KDC からアプリケーションサーバに直接送信される。

設問 3

Kerberosでは「リプレイ攻撃」を防ぐ仕組みが備わっている。どのような仕組みでリプレイ攻撃を防いでいるか、100文字以内で説明しなさい。

解答

設問 1 ：次の文中の (a) ～ (c) に入る最も適切な語句を、解答群から選びなさい。

(1) クライアントPCは最初に、AS（認証サーバ） に対してユーザ名を送信し、(a) の発行を依頼する。
(2) AS は、ユーザのパスワードから生成された (b) を使って、セッション鍵と TGT を暗号化する。
(3) アプリケーションサーバは、受け取った (c) を検証し、クライアントとのセッションを確立する。

解答:
(a) 3. TGT
(b) 4. パスワードハッシュ
(c) 1. サービスチケット

解説:

1.　(a) TGT (Ticket Granting Ticket)
クライアントPCは最初に、AS (Authentication Server：認証サーバ) に対してユーザ名を送り、TGT の発行を依頼します。TGTはクライアントが後続の認証で繰り返し使う一種のパスで、これがあると何度もパスワードを入力する必要がなくなります。

哲学者トニーくん

認証サーバはサービスを提供する側のネットワークに配置されています。

【FAQ】ケルベロス認証のあるある疑問をパパっと解消

🔑 Kerberos とは？ 🏢 認証サーバ（AS）とチケット発行サーバ（TGS）はどういう関係性は？ クライアントはどうやってケルベロスを使うかどうかを判断するの？ パスワードがネットワーク上を流れないってどういう仕組みで認証しているの？ 認証サーバからTGTを取得するまでの流れは？ TGTを取得してからサービスを利用するまでの流れは？

ascend-beyond.com

2025.03.03

2.　(b) パスワードハッシュ
ASは、ユーザのパスワードからハッシュ化した秘密鍵を作り、その鍵でセッション鍵と TGT を暗号化してクライアントに渡します。これにより、パスワード自体をネットワーク上に送らずに安全に鍵交換が行えます。

哲学者トニーくん

ハッシュ化とはある値を関数に入れることによって、別の新たな値を生成することです。

3.　(c) サービスチケット
クライアントがTGS (Ticket Granting Service) から取得したサービスチケットをアプリケーションサーバに提示すると、サーバはそのチケットを検証して、セッションを確立します。サービスチケットには、利用するサービス用のセッション鍵などが含まれています。

哲学者トニーくん

TGSは認証ステップを通過できたデバイスに対して、サービスの許可証を渡す役割です。配置場所はASと同じ物理サーバ内（KDC）に配置されることが多いです。

設問 2 ：以下の選択肢の中から、Kerberosの設計上の特徴として 適切なもの を2つ選びなさい。

• ア) パスワードはネットワーク上を平文で流れる。
• イ) サーバごとに秘密鍵が必要である。
• ウ) TGT の有効期限が切れると再認証が必要である。
• エ) クライアントは最初に直接サービスサーバと鍵交換を行う。
• オ) サービスチケットは KDC からアプリケーションサーバに直接送信される。

解答:
イ, ウ

解説:

• イ) サーバごとに秘密鍵が必要である → 正しい
  Kerberosでは、各サーバには固有の秘密鍵があります。これにより、KDCが発行するチケットを復号してセッション鍵を取得できます。秘密鍵がなければチケットの中身を読み解くことができません。
• ウ) TGT の有効期限が切れると再認証が必要である → 正しい
  TGTには有効期限があります。有効期限が切れた後は再認証が必要になるので、古いチケットを使った攻撃を防げます。
• ア) パスワードはネットワーク上を平文で流れる → 誤り
  Kerberosでは、パスワードそのものはネットワーク上に流れません。パスワードから生成された鍵でデータを暗号化してやりとりします。

哲学者トニーくん

パスワードをハッシュ化した値が流れるだけなので、生のパスワードデータはネットワーク上には流れません。

• エ) クライアントは最初に直接サービスサーバと鍵交換を行う → 誤り
  最初の鍵交換は KDC を介して行われます。クライアントは KDC (AS → TGS) を経由して、サービスサーバに接続するためのチケットを取得します。
• オ) サービスチケットは KDC からアプリケーションサーバに直接送信される → 誤り
  サービスチケットは、KDC からクライアントに渡されます。そして、クライアントがそのチケットをサービスサーバに提示します。

設問 3 ：Kerberosでは「リプレイ攻撃」を防ぐ仕組みが備わっている。どのような仕組みでリプレイ攻撃を防いでいるか、100文字以内で説明しなさい。

解答:
タイムスタンプを含めた認証データを暗号化し、一定時間内のリプレイを検出して無効化する。

解説:
リプレイ攻撃とは、攻撃者が過去の通信データを盗み取り、それを再送信して不正アクセスを試みる攻撃です。Kerberosでは、暗号化したタイムスタンプを認証データに含め、サーバはそのタイムスタンプが現在時刻と大きくずれている場合にリクエストを拒否します。これにより、過去のデータを再送信しても認証に失敗します。

まとめ

ケルベロス認証は「チケット制の認証システム」で、暗号化とタイムスタンプを活用して、ネットワーク上で安全にログインできる仕組みです！

🚀 Kerberos の流れ（ざっくり）

1. ログインリクエスト
   → クライアントがKDC（認証サーバ）にログインを要求。
2. TGT（Ticket Granting Ticket）発行
   → 認証サーバは、パスワードから生成した鍵で暗号化された「TGT」をクライアントに渡します。これは「サービスチケット発行のための許可証」です。
3. サービスチケット取得
   → クライアントは、TGT を使って「KDC（TGS：チケット発行サーバ）」からサービス用のチケットを取得します。
4. サービスへのアクセス
   → クライアントはサービスサーバにチケットを提出し、正しければアクセスが許可されます。

これなら、ネットワーク上にパスワードが流れず、安全にサービスを利用できます！

哲学者トニーくん

そもそもSet-Cookieとは

Set-Cookie は、Webサーバーがクライアント（ブラウザ）に対してCookieを保存するよう指示するHTTPヘッダ です。

簡単な流れ

1. サーバー → クライアント（ブラウザ）
   • サーバーが Set-Cookie ヘッダを使ってCookieを発行し、ブラウザに保存させる。
2. クライアント → サーバー
   • 次回以降、ブラウザは保存したCookieを Cookie ヘッダに含めてサーバーに送信する。

なぜCookieが必要なの？

HTTPはステートレス（状態を保持しない） なプロトコルなので、サーバーはクライアントの状態を覚えていない。
そこで、Cookieを使って「このユーザーはログインしている」「カートに商品が入っている」などの情報を管理する。

具体例（ログイン時のセッション管理）

1. 初回リクエスト（ログイン）

クライアントがサーバーにログインリクエストを送る

POST /login HTTP/1.1
Host: example.com

サーバーがセッションIDを発行して、Set-Cookieを送る

HTTP/1.1 200 OK
Set-Cookie: session_id=abcdef123456; Path=/; HttpOnly; Secure

➡️ ブラウザは session_id=abcdef123456 を保存する。

2. 次回以降のリクエスト

保存されたCookieが、サーバーへのリクエスト時に自動的に送られる。

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abcdef123456

➡️ サーバーはこの session_id を確認し、ログイン済みのユーザーであることを判別する。

設問

あなたは、A社のWebシステムのセキュリティ改善を担当するネットワークエンジニアである。現在、A社では、ユーザ認証後にセッション管理のために Set-Cookie ヘッダを用いてセッションIDを発行し、ブラウザに保存させている。

しかし、最近になって、以下のようなセキュリティ上の問題が指摘された。

• (1) クロスサイトスクリプティング（XSS）によるセッションIDの漏洩の可能性
• (2) HTTPSを使用しない場合のセッションIDの漏洩の可能性
• (3) サブドメイン間での不要なCookieの共有

これらの問題を防ぐために、適切な Set-Cookie の属性設定を行うことになった。

設問 1

(1) の問題（XSSによるセッションIDの漏洩）を防ぐために、 Set-Cookie のどの属性を設定すべきか。また、その属性の具体的な動作を説明せよ。

設問 2

(2) の問題（HTTPSを使用しない場合のセッションIDの漏洩）を防ぐために、 Set-Cookie のどの属性を設定すべきか。また、その属性の具体的な動作を説明せよ。

設問 3

(3) の問題（サブドメイン間での不要なCookieの共有）を防ぐために、 Set-Cookie のどの属性を設定すべきか。また、その属性の具体的な動作を説明せよ。

設問 4

A社の開発チームが Set-Cookie の設定を以下のように変更した。

Set-Cookie: session_id=abcdef123456; Path=/; HttpOnly; Secure; SameSite=Strict

この設定により、上記の (1) ～ (3) の問題に対してどのような効果が得られるか。それぞれについて説明せよ。

解説

設問 1：XSSによるセッションIDの漏洩を防ぐには？

解答:

HttpOnly 属性を設定する。

解説:

• HttpOnly を設定すると、JavaScript から Cookie を取得できなくなる。
• これにより、攻撃者が XSS（クロスサイトスクリプティング）を利用して JavaScript を実行し、 document.cookie でセッションIDを盗むことを防げる。

具体例:

Set-Cookie: session_id=abcdef123456; HttpOnly

この設定により、JavaScript (document.cookie) から session_id が取得できなくなる。

設問 2：（HTTPSを使用しない場合のセッションIDの漏洩）を防ぐには？

解答:

Secure 属性を設定する。

解説:

• Secure を設定すると、HTTPS（暗号化通信）を使用している場合のみ Cookie が送信される。
• これにより、HTTP（平文通信）経由でセッションIDが盗聴されることを防げる。

具体例:

Set-Cookie: session_id=abcdef123456; Secure

この設定により、HTTPS接続時のみ Cookie が送られ、HTTP通信では送信されなくなる。

設問 3：サブドメイン間での不要なCookieの共有を防ぐには？

解答:

Domain 属性を適切に設定しない、または SameSite 属性を設定する。

解説:

• Domain 属性を指定しなければ、Cookie は発行したドメイン（example.com など）でのみ有効になる。
• もし Domain=example.com を設定すると、sub.example.com などのサブドメインにも Cookie が送信されてしまう。
• SameSite 属性を Strict や Lax にすることで、異なるサイト（またはサブドメインを含む）からの不要なリクエストで Cookie を送信しないよう制御できる。

具体例:

Set-Cookie: session_id=abcdef123456; SameSite=Strict

この設定により、異なるサイト（サブドメインを含む）からのリクエスト時に Cookie が送信されなくなる。

設問 4：以下の Set-Cookie 設定での効果

Set-Cookie: session_id=abcdef123456; Path=/; HttpOnly; Secure; SameSite=Strict

この設定による効果を説明する。

解答と解説:

1. HttpOnly の効果（XSS対策）
   • JavaScript (document.cookie) から Cookie を読み取れないため、XSS攻撃によるセッションIDの漏洩を防ぐ。
2. Secure の効果（HTTPS強制）
   • HTTPS通信でのみ Cookie が送信されるため、HTTP経由の盗聴を防ぐ。
3. SameSite=Strict の効果（クロスサイトリクエスト対策）
   • 他のサイトからのリクエストでは Cookie を送らなくなるため、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぎやすくなる。
   • ただし、他のサイトからのリンクをクリックした際にセッションが適用されない可能性がある（厳格すぎる場合がある）。

まとめ：この設定の効果

✅ XSSによるセッションID漏洩を防ぐ（HttpOnly）
✅ HTTPS以外でのセッションID漏洩を防ぐ（Secure）
✅ CSRFや不要なサブドメイン間Cookieの共有を防ぐ（SameSite=Strict）

補足（より実践的な設定）

場合によっては SameSite=Lax のほうが利便性が高いこともある。

• SameSite=Strict は、他のサイトからのリンクをクリックした場合でも Cookie を送信しないため、ログインが必要なサイトでは使いづらい。
• SameSite=Lax ならば、同じブラウザタブ内での遷移は許容されるため、利便性を維持できる。

Set-Cookie: session_id=abcdef123456; Path=/; HttpOnly; Secure; SameSite=Lax

この設定なら、
✅ XSS・盗聴を防ぎながら、最低限のクロスサイト対策を確保できる。

総括

Set-Cookie の適切な設定は、セキュリティを向上させるだけでなく、利便性とのバランスを取ることが重要！試験対策としては、以下の3つを押さえておけば安心：

• HttpOnly → XSS対策
• Secure → HTTPS強制
• SameSite → CSRF・不要なCookie共有対策（LaxかStrictを選択）

実際のシステムでは、要件に応じて SameSite の設定を慎重に選ぼう！

はじめに

哲学者トニーくん

【９秒チャレンジ】
SPFは、送信に使われたメールサーバーの正当性を確かめる仕組み。よく誤解されるが、「送信者本人の正当性」ではなく、あくまでも「送信メールサーバーの正当性」を検証するもの。

仕組みは以下の通り：

1. 受信サーバーは、SMTPの MAIL FROM（エンベロープFrom）フィールドのドメイン を確認する。
2. そのドメインの DNSサーバー に問い合わせ、SPFレコード（TXTレコード）を取得する。
3. SPFレコードには、そのドメインが許可する 送信元メールサーバーのIPアドレス が記載されている。
4. 受信サーバーは、実際に送られてきたメールの 送信元IPアドレス が、そのリスト内にあるかをチェック。
5. 一致していれば「正当なメールサーバーからの送信」と判定し、不一致なら「なりすましの可能性あり」と判断する。

👉 SPF = 送信メールサーバーの正当性をDNSで確認する仕組み！

更に詳しく知りたい場合↓

では、練習問題を通して実感していきましょう！

問題

設問1

SPF（Sender Policy Framework）は電子メールの送信ドメイン認証技術の一つであり、不正なメール送信を防ぐために使用される。SPFの基本的な仕組みについて、以下の問いに答えよ。

1. SPFの認証プロセスにおいて、DNSに登録されるレコードの種類を答えよ。
2. SPFレコードに指定される「include」の役割を説明せよ。
3. SPFレコードの評価結果（Pass, Fail, SoftFail, Neutral など）の違いを説明せよ。

設問2（SPFレコードの解析）

ある企業のメールサーバーの管理者が、以下のSPFレコードを設定した。

v=spf1 ip4:203.0.113.10 include:spf.example.net -all

このSPFレコードについて、以下の問いに答えよ。

1. このSPFレコードが意味する内容を日本語で説明せよ。
2. -all の意味を説明し、~all や ?all との違いを述べよ。
3. 送信元IPアドレスが 203.0.113.20 であるメールが送信された場合、このSPFレコードに基づく認証結果はどうなるか。理由も含めて説明せよ。

設問3（SPFと他のメールセキュリティ技術との関係）
SPFは送信ドメインのなりすましを防ぐ技術の一つであるが、単独では完全なセキュリティ対策とはならない。そのため、DKIM（DomainKeys Identified Mail）やDMARC（Domain-based Message Authentication, Reporting, and Conformance）と組み合わせて運用されることが多い。

1. SPFとDKIMの違いを説明せよ。
2. DMARCがSPFやDKIMとどのように連携して動作するかを説明せよ。
3. SPFの仕組みにおける「フォワードメール」の課題を説明し、それを解決するための方法を1つ挙げよ。

このような問題がネットワークスペシャリスト試験の午後問題として出題される可能性があります。さらに詳しく解説が必要な部分があれば教えてください。

解説

設問1

1. SPFの認証プロセスにおいて、DNSに登録されるレコードの種類を答えよ。

解答：
SPFレコードは TXTレコード としてDNSに登録される。

解説：
かつてSPF専用の SPF レコードが提案されたが、現在は TXT レコードを使用するのが一般的である。DNSに TXT レコードとしてSPFポリシーを記述し、受信メールサーバーが送信元のIPアドレスと照合して認証を行う。

哲学者トニーくん

前提として、SPFレコードはそのメールドメインを管理する送信側のDNSサーバに登録する。これを念頭に置いて、軽くSPFの流れを頭に入れましょう。

1. 送信元IP（203.0.113.20）がSPFレコードに含まれていなければ、SPF認証 Fail（失敗） となる。
2. user@example.com からメールを送信。
3. 受信サーバーが送信元IPアドレスを取得（例：203.0.113.20）。
4. 受信サーバーは 「example.com のDNSサーバー」 に問い合わせ、SPFレコードを取得。
5. 取得したSPFレコードと、実際の送信元IPアドレスを照合。

2. SPFレコードに指定される「include」の役割を説明せよ。

解答：
include は、別のドメインのSPFレコードを参照し、そのドメインで許可された送信元IPアドレスも有効とみなすために使用される。

解説：
例えば、example.com では、以下の2つのサーバーを使ってメールを送信しているとします。

1. 自社サーバー（IPアドレス：203.0.113.10）
2. Google Workspace（Gmail の送信サーバーを利用）

この場合、SPFレコードは以下のようになります。

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

この設定の意味

1. 自社のサーバー（203.0.113.10） からの送信を許可
2. Google の SPF レコード（_spf.google.com）に記載されたサーバーも許可
   • _spf.google.com の中には、Gmailの正規の送信サーバーのIPアドレスが含まれている
   • これを 「そのまま」 参照できるので、管理が楽になる

哲学者トニーくん

つまり、「このメールは、Gmailの送信サーバーを使って送ることもあるから、Gmailの正規サーバーもSPFで許可してね！」 という意味で include:_spf.google.com を使う、ということです！
こうすることで複数のメールサーバーを使うときも、それぞれのSPF設定を手動で書く代わりに 他のドメインのSPFレコードを簡単に参照できるというわけです。

3. SPFレコードの評価結果（Pass, Fail, SoftFail, Neutral など）の違いを説明せよ。

解答：

• Pass（合格）: 送信元IPアドレスがSPFレコード内で明示的に許可されている。
• Fail（失敗）: 送信元IPアドレスがSPFレコードで許可されていない（-all の指定時）。
• SoftFail（弱い失敗）: 送信元IPアドレスが許可されていないが、厳格な拒否は行わない（~all の指定時）。
• Neutral（中立）: SPFポリシーに適合するかどうかを示さない（?all の指定時）。

解説：
-all を使うと、SPF認証に失敗したメールがブロックされる可能性があるため、最初は ~all を使用し、運用を確認してから -all に変更するのが一般的である。

設問2（SPFレコードの解析）

1. このSPFレコードが意味する内容を日本語で説明せよ。

v=spf1 ip4:203.0.113.10 include:spf.example.net -all

解答：
このSPFレコードは、次のルールを指定している。

• ip4:203.0.113.10 → 送信元IPアドレスが 203.0.113.10 の場合、メール送信を許可
• include:spf.example.net → spf.example.net のSPFポリシーを適用
• -all → 許可されていない送信元IPアドレスからのメールは拒否

2. -all の意味を説明し、~all や ?all との違いを述べよ。

解答：

• -all（Fail） → SPF認証に失敗した場合、メールを拒否または破棄する。
• ~all（SoftFail） → SPF認証に失敗した場合、メールは受け取るが、スパムとして扱われる可能性がある。
• ?all（Neutral） → SPFポリシーを適用しない（どの送信元でも許可・拒否の判定を行わない）。

解説：
厳格なポリシーを採用する場合 -all を使用するが、導入直後は ~all にして影響を観察することが推奨される。

3. 送信元IPアドレスが 203.0.113.20 であるメールが送信された場合、このSPFレコードに基づく認証結果はどうなるか。理由も含めて説明せよ。

解答：
SPF認証は Fail（失敗） となる。

理由：

• ip4:203.0.113.10 にはマッチしない。
• spf.example.net のSPFポリシーを参照するが、203.0.113.20 が含まれていなければ適合しない。
• -all により、許可されていない送信元は拒否される。

解説：
この設定では、明示的に許可されたIPアドレス以外からのメール送信は許可されないため、メールがブロックされる可能性が高い。

設問3（SPFと他のメールセキュリティ技術との関係）

1. SPFとDKIMの違いを説明せよ。

解答：

• SPF → 送信元IPアドレスの正当性を検証する。
• DKIM → 電子署名を用いてメールの改ざんを防ぐ。

解説：
SPFはIPアドレスベースで認証を行うため、メール転送時に破綻する可能性がある。一方、DKIMはメールのヘッダーや本文に署名を付けることで、改ざんを防止できる。

哲学者トニーくん

SPFは 「送信者のメールアドレスが本物かどうか」 を直接チェックするのではなく、あくまでも送信メールサーバの正当性を確認する仕組みです。

例えば、攻撃者が user@example.com を詐称してメールを送ったとしても、正規の example.com のメールサーバーを経由すれば、SPF認証は PASS（成功） してしまいます。

つまり、SPFはメールサーバーの正当性は保証できるが、送信者本人が本当に正しいかどうかまでは保証できない ということです。

2. DMARCがSPFやDKIMとどのように連携して動作するかを説明せよ。

解答：
DMARCは、SPFおよびDKIMの認証結果を基に、受信メールの処理ポリシー（許可・隔離・拒否）を決定する。

解説：
DMARCポリシーは p=none（監視のみ）、p=quarantine（隔離）、p=reject（拒否）などを指定できる。さらに、認証失敗時のレポートを受け取ることが可能である。

哲学者トニーくん

先ほども述べたように、SPFだけでは脆弱です。そこで、DKIM（電子署名）やDMARC（総合ポリシー）を組み合わせて使うことで、送信者のなりすましをより強力に防ぐことができます。

• SPF → メールを送った サーバー の正当性をチェック
• DKIM → メールに付与された 電子署名 をチェック（改ざん防止）
• DMARC → SPFとDKIMを組み合わせて、なりすまし対策のポリシーを設定

3. SPFの仕組みにおける「フォワードメール」の課題を説明し、それを解決するための方法を1つ挙げよ。

解答：
課題：
フォワードメールでは、元の送信者のIPアドレスが維持されないため、転送先の受信サーバーがSPF認証を失敗と判定する可能性がある。

解決策：
SPFの代替策として、DKIM を利用することで、電子署名によりメールの正当性を保証する。

解説：
SPFは転送メールと相性が悪いため、DMARCとDKIMを併用することで認証成功率を高めることができる。

まとめ

SPFはIPアドレスを基にした送信者認証を行うが、単独ではフォワードメールの問題などがあるため、DKIMやDMARCと組み合わせることが重要である。

はじめに

哲学者トニーくん

【９秒チャレンジ】
ECNは、輻輳を明示的に伝える仕組みです。というのも、TCPでは、輻輳時にルータがパケットを破棄し、送信元がタイムアウトやACK未達を通じて輻輳を間接的に検知します。そのため再送が必要になり、効率が低下します。一方、ECNでは、ルータがCEフラグを付けて宛先に届け、宛先がECEビットで送信元に通知します。これにより、パケットを破棄せずに輻輳を検知し、輻輳ウィンドウを縮小することで効率的な通信を実現します。

では、練習問題を通して実感していきましょう！

問題

次の状況において、ECN（Explicit Congestion Notification）を使用した輻輳制御の動作について説明しなさい。

状況
あるネットワークにおいて、トラフィックが増加し、ルータが輻輳を検出しました。ECNをサポートするルータがネットワーク内に配置されており、ECNが有効になっています。ネットワークを通じてデータが送信され、送信元と宛先の両方がECN対応のTCP/IPノードであると仮定します。

このシナリオにおいて、次の質問に答えてください。

1. ECNがどのように輻輳を検出し、通知するのかを説明しなさい。
2. ECN通知を受けた送信元と宛先は、どのように通信を調整するのかを説明しなさい。
3. ECNが輻輳制御においてTCPの通常の輻輳制御とどのように異なる点があるかを説明しなさい。

回答

1. ECNがどのように輻輳を検出し、通知するのかを説明しなさい。

回答:
ECN（Explicit Congestion Notification）は、ネットワーク内の輻輳を検出し、パケットのヘッダーを利用して送信元と宛先に輻輳の発生を通知する仕組みです。具体的には、以下の流れで輻輳を検出し、通知します。

• 輻輳検出:
  ルータが輻輳を検出する方法として、通常の輻輳制御（例：バッファが満杯になった場合）に加え、ECNをサポートしているルータは、パケットのヘッダーにある「ECNフィールド」を利用します。ネットワークが輻輳状態になると、ルータはパケットを破棄せず、ECNビット（2ビット）を設定します。このビットが設定されたパケットは、送信元に対して輻輳が発生していることを示す通知となります。
• 通知:
  ECNをサポートしている場合、ルータは「ECNフィールド」の「Congestion Experienced (CE)」ビットをセットすることで、パケットが輻輳していることを通知します。このビットは、パケットが宛先に届いた際に送信元に通知されるため、送信元はこれを受け取って輻輳が発生したことを認識します。

2. ECN通知を受けた送信元と宛先は、どのように通信を調整するのかを説明しなさい。

回答:
ECN通知を受け取った送信元と宛先の通信は、以下のように調整されます。

• 宛先（受信側）:
  宛先ノードは、受信したパケットのECNフィールドを確認します。もしECNの「CE（Congestion Experienced）」ビットが設定されていれば、受信側はそのパケットが輻輳状態であることを認識します。しかし、ECN通知は主に送信側に伝達されるため、宛先ノードは通常、これを特に処理することはなく、通常通りパケットを受け取ります。
• 送信元（送信側）:
  送信側は、宛先から返送されるACKパケットを通じて、ECNフィールドに設定されたCEビットを確認します。このCEビットを受け取ることで、送信元はネットワーク内で輻輳が発生していることを認識します。そのため、送信元は輻輳回避のために通信を調整します。具体的には、送信元は送信ウィンドウサイズを縮小し、送信レートを減少させることで、輻輳を軽減しようとします。送信元は、ECN通知を受け取った場合、通常のTCP輻輳制御（例えば、輻輳ウィンドウの減少）と同様に、レート制御を行いますが、パケット破棄が発生しない分、再送の必要が減り、より効率的な輻輳制御が可能となります。

哲学者トニーくん

TCPでは輻輳が発生するとパケットを破棄します（破棄したことは送信元に通知しない）。これによってトラフィックの平準化を図ります。しかし、これだと、再送が必要になります。
逆に、ECNでは輻輳が発生しても、一応、時間がかかりながらも最後まで届けます。そして、宛先側が輻輳の発生を明示的に送信元に伝えます。これにより、送信元は輻輳の発生を知り、送信データ量を抑えます。この方法では、最後まで一応データが渡っているので、再送が不要になります。

3. ECNが輻輳制御においてTCPの通常の輻輳制御とどのように異なる点があるかを説明しなさい。

回答:
ECNとTCPの通常の輻輳制御には以下のような違いがあります。

• 通常の輻輳制御（パケット破棄を利用した方法）:
  通常のTCP輻輳制御では、ネットワーク内で輻輳が発生すると、ルータはパケットを破棄します。このパケット破棄が、送信元に対して輻輳が発生していることを通知する方法となります。送信元は、受信側からのACKが遅れることや、パケット再送が発生することで輻輳を認識します。通常、輻輳が発生した場合、送信元は輻輳ウィンドウを減少させ、再送が行われます。再送はネットワークの負担を増加させ、効率が悪くなる可能性があります。
• ECNを使用した輻輳制御:
  ECNでは、パケット破棄を避け、ルータが輻輳を検出した際に、パケットヘッダーのECNビットをセットして輻輳を通知します。この方法では、パケットの再送が発生しないため、ネットワーク全体の効率が向上します。送信元はECN通知を受け取ることで、輻輳を早期に認識し、再送を行うことなく送信レートを調整できます。これにより、通常の輻輳制御と比較して、再送の負担が減り、よりスムーズに輻輳を回避できるという利点があります。

解説

ECNは、ネットワークにおける輻輳をより効率的に制御するための仕組みです。通常、輻輳制御の方法としては、パケットの破棄を基にした手法が一般的ですが、ECNを使用することで、パケットを破棄せずに輻輳を通知することができ、再送による無駄なトラフィックを減らすことができます。この仕組みは、ネットワークの帯域を効率的に使いたい場合や、再送を減らしてパフォーマンスを向上させたい場合に非常に有効です。

ECNはTCP/IPの輻輳制御を補完する役割を果たし、特に混雑が頻繁に発生する大規模なネットワークでその効果を発揮します。ECNに対応するルータやノードが増えれば、ネットワーク全体のパフォーマンス向上が期待できます。

哲学者トニーくん

【１分チャレンジ】
ECNというのは輻輳を明示的に伝えてくれるものです。これはなんで明示的を強調しているかというと TCPでは輻輳を明示的に伝えてくれないからです。TCPの方法としては輻輳が発生するとルーターがパケットを破棄します。このパケットを破棄したことは明示的には伝えられません。送信元はタイムアウトの発生とかACKが返ってこないとか、そういう状況を自分で判断することによって輻輳が発生しているんだなというのを理解します。
しかし、これだとパケットを破棄しているので再送の必要があります。それに比べてECNだと輻輳が発生しても 一応最後まで届くことには届きます。それで宛先が輻輳が発生しているよというのを通知します。通知することによって輻輳が発生しているんだということで 輻輳ウィンドウを縮小して少しずつ送るようになります。これはパケットが破棄されていないので再送は発生しません。なのでより効率的な通信ができるよねというのをECNでは実現しています。

哲学者トニーくん

問題文

ある企業では、拠点間の通信を最適化するために、QoS（Quality of Service）の導入を検討している。この企業は以下のような要件を抱えている。

1. 拠点間での音声通話（VoIP）は、リアルタイム性が重視され、遅延（Latency）を50ms以内に抑えたい。
2. 動画会議のデータは、安定した帯域幅を確保する必要があり、パケット損失率（Packet Loss）が1%以内であることを要求されている。
3. 社内ファイル転送は大量のデータを伴うが、遅延が発生しても問題ない。

ネットワーク管理者は、これらの要件を満たすために以下の設計案を立てた。
また、各通信には異なる優先順位を設定し、DiffServ（Differentiated Services）を利用して、トラフィックを分類・制御することを考えている。

【設計案】

1. 音声通話（VoIP）: Expedited Forwarding（EF）クラスを使用し、優先的に処理する。
2. 動画会議: Assured Forwarding（AF）クラスを利用し、帯域幅を確保しつつ、他の通信と共存させる。
3. ファイル転送: Best Effort（BE）クラスを利用し、空いている帯域を活用する。

この設計案に基づき、QoSを実装するためのポリシー設定を検討したところ、次の課題が発生した。

【課題】

1. 帯域幅が限られている場合、VoIPと動画会議の通信が競合する可能性がある。
2. ファイル転送が増加した場合、全体の遅延が増大し、リアルタイム性を必要とする通信に影響が出る可能性がある。

これらの課題を踏まえ、以下の設問に答えよ。

設問

設問1

QoSにおけるDiffServの仕組みについて、以下の用語を使って50字以内で説明せよ。
「トラフィッククラス」「優先度」

設問2

上記の設計案に基づき、VoIPと動画会議の競合を避けるための具体的な対策を50字以内で説明せよ。

設問3

ファイル転送のトラフィックが急増した場合に備え、全体のQoSを維持するために設定すべき具体的な制御方法を2つ挙げ、それぞれ50字以内で説明せよ。

解答

設問1

QoSにおけるDiffServの仕組みについて、以下の用語を使って50字以内で説明せよ。
「トラフィッククラス」「優先度」

解答:

DiffServはパケットに優先度を示すパケットマークを付け、トラフィッククラスごとに異なる優先度で処理する仕組み。

解説:

DiffServ（Differentiated Services）は、IPパケットのヘッダに「DSCP（Differentiated Services Code Point）」というフィールドを使用して、トラフィックを分類します。これにより、ネットワークデバイスはパケットマークを基にトラフィッククラスを判別し、優先度に応じて帯域幅や遅延を制御します。この仕組みはシンプルでスケーラブルなQoSの手法として広く使われています。

哲学者トニーくん

DSCPフィールドとはIPヘッダの「Type of Service (ToS)」フィールド内に存在し、6ビットで表現されます。これにより、最大64種類（2^6 = 64）のクラスを指定できます。その中のEFクラスは46、BF（best effort)は0、という特定の値を持ちますが、AFクラスは更に細分化されA1～A４（10~38)のクラスに分かれています。

設問2

設計案に基づき、VoIPと動画会議の競合を避けるための具体的な対策を50字以内で説明せよ。

解答:

EFクラスの帯域幅を固定で確保し、AFクラスの帯域幅を動的に調整する。

解説:

VoIPは遅延に非常に敏感なため、EF（Expedited Forwarding）クラスで一定の帯域を保証する必要があります。一方、動画会議は比較的柔軟に帯域を調整できるため、AF（Assured Forwarding）クラスで動的制御を行うことで競合を回避します。たとえば、EFに50ms以内の処理を優先させ、AFに空き帯域を割り当てることで実現可能です。

哲学者トニーくん

EFクラスやAFクラスは、IPパケットのDSCPヘッダ内に格納する値として定義されます。
EFクラスは、リアルタイム性が要求される通信を最優先で処理するために設けられたトラフィッククラスです。
AFクラスはAFクラスは、重要度はあるがEFほど厳密なリアルタイム性を必要としない通信を制御するためのトラフィッククラスです。

設問3

ファイル転送のトラフィックが急増した場合に備え、全体のQoSを維持するために設定すべき具体的な制御方法を2つ挙げ、それぞれ50字以内で説明せよ。

解答1:

BEクラスにポリシングを設定し、帯域使用量を制限する。

解説:

ポリシングは特定のトラフィックが設定した帯域を超えた場合に、パケットを破棄または遅延させる方法です。これにより、Best Effort（BE）トラフィックがQoS全体に影響を与えないよう制御できます。

哲学者トニーくん

BE(Best Effort)とはQoS制御を行っていない通信のことです。つまり、トラフィックが空いているいるときは問題ないけど、混んできたらもろに影響を被るという通信形態です。

解答2:

優先度の低いトラフィックにシェーピングを適用し、送信速度を調整する。

解説:

シェーピングは、トラフィックの送信速度を調整し、急激な帯域占有を緩和する方法です。BEトラフィックに適用することで、EFやAFクラスの通信が影響を受けにくくなります。

哲学者トニーくん

シェーピングの他にはポリシングというものもあります。
シェーピングはトラフィックを一旦バッファに蓄えて、そこから再度送信することで、送信レートを一定に保つ方法です。
ポリシングは設定されたトラフィック量を超えたものを破棄することによってトラフィックを制御する方法です。