- 設問1
- (3)b:本社のL3SW c:静的経路制御 d:静的経路制御
- (5)ISPが割り当てる営業所のIPsecルータのIPアドレスが動的だから
- p.8 セキュアウェブゲートウェイサービス(SWG)って何?
- Q.CASB(Cloud Access Security Broker)って何?
- Q.ZTNA(Zero Trust Network Access)って何?
- p.10 Q.どうやってデフォルトルートを使い分けているの?
- Q.VRF65000:1とVRF65000:2はどう連携しているの?
- Q.本社IPsecルータに届いた後のフローはどうなっている?
- Q.なんでIPsecはトンネルを使うの?
- Q.トンネルインタフェースのIPサブネットをそろえる理由は?
- p.10 Q.OSPFでデフォルトルートを配布するってどうやってやるの?
- Q.そもそも相手のIPアドレスわからないのにIPsec確立できるの?
- Q.IKEv1 メインモード(フェーズ1)の6つのメッセージとは?
- Q.IKEv1 アグレッシブモード(フェーズ1)の3つのメッセージとは?
- Q.IKEv1 クイックモード(フェーズ2)の3つのメッセージとは?
- Q.IKEv2とは?
設問1
(3)b:本社のL3SW c:静的経路制御 d:静的経路制御

| 項番 | 拠点 | 機器名 | VRF識別子 | 宛先ネットワーク | ネクストホップとなる装置又はインタフェース | 経路制御方式 |
|---|---|---|---|---|---|---|
| 1 | 本社 | FW | - | 0.0.0.0/0 | ISP のルータ | 静的経路制御 |
| 2 | 172.17.1.0/24(営業所の LAN) | 本社の L3SW | 動的経路制御 | |||
| 3 | IPsecルータ | 65000:1 | 0.0.0.0/0 | ISP のルータ | 静的経路制御 | |
| 4 | 65000:2 | 0.0.0.0/0 | 本社の L3SW(b) | 動的経路制御 | ||
| 5 | 172.17.1.0/24(営業所の LAN) | トンネル IF | 静的経路制御(c) | |||
| 6 | 営業所 | IPsecルータ | 65000:1 | 0.0.0.0/0 | ISP のルータ | 静的経路制御 |
| 7 | 65000:2 | 0.0.0.0/0 | トンネル IF | 静的経路制御(d) |
b:本社のL3SW
1.デフォルトルート(0.0.0.0/0)とは宛先が分からないときに流す経路である。
2.図1の構成図を見ると、インターネットに出るにFWを経由する必要がある。
3.FWに行くには本社L3SWがネクストホップの機器となる
c:静的経路制御(項番5)
「営業のLANへ行くにはトンネルIFへ」という経路は通常のルーティングとは異なるため、管理者が手動で設定してあげる必要がある。ip route vrf 65000:2 172.17.1.0 255.255.255.0 Tunnel0
d:静的経路制御(項番7)
デフォルトルートを指定するときは管理者が手動で設定してあげる必要がある。ip route vrf 65000:2 0.0.0.0 0.0.0.0 Tunnel0
では、おまけとして他の項番についても見ていこう!
項番2
項番5で静的経路制御したルートが、OSPFによって再配布されているので項番2では動的経路制御になっている。
項番3
IPsecルータがインターネットとつながっているインタフェースなので、静的にデフォルトルートを設定する必要がある。
項番4
FWが静的に登録したデフォルトルートがL3SWに届き、その経路がIPsecルータに届いているので動的経路制御となる。
(5)ISPが割り当てる営業所のIPsecルータのIPアドレスが動的だから

もし、営業所IPsecルータが固定IPであれば、ip route 営業所固定IP 255.255.255.0 ISPのIPと静的に指定できる。しかし、問題文中にもある通り営業所IPsecルータは動的IPであるためデフォルトルートとして設定しておく必要がある。
p.8 セキュアウェブゲートウェイサービス(SWG)って何?
SWG(Secure Web Gateway)は、クライアント(社内PCやリモート端末)からインターネット(Web)へ向かう通信を中継・保護するクラウド型(またはオンプレミス型)のセキュリティサービス
| 機能 | 内容 |
|---|---|
| URLフィルタリング | カテゴリ(ギャンブル、アダルトなど)や、危険なサイトへのアクセスをブロック |
| マルウェア対策 | ダウンロードされるファイルをスキャンして、不正なものを遮断 |
| SSL/TLS復号(インスペクション) | HTTPS通信を復号して中身を検査する |
| アプリケーション制御 | SNSやクラウドストレージなどの利用可否、アップロード制限など |
| 情報漏えい対策(DLP) | 機密情報が外部へ送信されるのを検知・防止 |
| ログ取得 | 誰がどこにアクセスしたかの記録 |
▼従来のプロキシ・FWとの違い
- 従来のプロキシは、主にキャッシュや簡単なURL制限が目的
- SWGは、HTTPS復号、マルウェア検査、クラウドアプリ制御などを含む、Web通信に特化した総合的なセキュリティ機能
- 次世代ファイアウォールはWeb以外も含めた通信全体をL3〜L7で制御するが、SWGはWeb(HTTP/HTTPS)の検査に重点を置く
Q.CASB(Cloud Access Security Broker)って何?
CASB(Cloud Access Security Broker)は、社員が使うクラウドサービス(SaaS)の利用状況を可視化し、制御・保護するセキュリティの仕組み。
▼主な機能
| 機能 | 内容 |
|---|---|
| 可視化 | どのクラウドサービスを、誰が、どれくらい使っているかを把握(シャドーITの発見) |
| データ保護(DLP) | 機密情報のアップロード、共有、ダウンロードを検知・制限 |
| 脅威対策 | 不審なログイン、異常な操作、マルウェアを含むファイルを検知 |
| アクセス制御 | 端末の状態、場所、ユーザーに応じて、操作を許可・制限(例:私物PCからは閲覧のみ) |
| コンプライアンス | 利用状況のログ取得、規制への準拠確認 |
▼導入方式
| 方式 | 仕組み | 特徴 |
|---|---|---|
| プロキシ方式(インライン) | 通信をCASBに通して、リアルタイムに制御 | 即時ブロックできる。通信経路の変更が必要 |
| API方式 | CASBがSaaSのAPIと連携して、データや設定を検査 | 導入が容易。事後検知が中心(リアルタイム制御は限定的) |
| ログ分析方式 | FWやプロキシのログを解析して、利用状況を把握 | 可視化向け。制御はしない |
▼SWGとの違い
直前に説明したSWGと役割が近いため、混同しやすい。
| SWG | CASB | |
|---|---|---|
| 主な対象 | Web全般(HTTP/HTTPS) | 特定のクラウドサービス(SaaS) |
| 見る粒度 | URL、カテゴリ、ファイルのマルウェア | サービス内の操作(共有、アップロード、ユーザーごとの動き) |
| 例 | 危険なサイトへのアクセスをブロック | 会社のBoxから個人アカウントへのファイル共有を禁止 |
Q.FWaaS(Firewall as a Service)って何?
FWaaS(Firewall as a Service)は、ファイアウォール機能をクラウドサービスとして提供する仕組み
▼何をするか
通常のファイアウォールと同じ制御を、クラウド側で行う。
- IPアドレス、ポート、プロトコルによる通信の許可・拒否(L3/L4)
- アプリケーションの識別と制御(L7)
- IPS/IDS(侵入防止・検知)
- URLフィルタリング、マルウェア対策(次世代FWの機能)
- ログの取得・可視化
機能面では次世代ファイアウォール(NGFW)をクラウドで提供するものと考えて大きくは間違いない。
▼従来のFWとの違い
| 従来のFW(オンプレ) | FWaaS | |
|---|---|---|
| 設置場所 | 拠点やデータセンターに機器を置く | クラウド上(事業者が運用) |
| 機器の保守 | 自社でファームウェア更新、冗長化、故障対応 | 事業者が行う |
| 拡張 | 性能が足りなければ機器を買い替え | クラウドなので柔軟に拡張 |
| ポリシー管理 | 拠点ごと・機器ごとに設定しがち | 1つの管理画面で全拠点・全ユーザーに一元適用 |
| テレワーク端末 | VPNで社内FWを経由させる必要がある | 端末からクラウドFWへ直接向けられる |
▼なぜ使われるか
- 拠点が多い、テレワークが多い、クラウド利用が多い環境で、「全通信を本社のFWに集める」構成だと遅延や負荷が問題になる
- FWaaSなら、拠点や端末から、近いクラウド拠点(POP)でFWの検査を受けてそのままインターネットやクラウドへ出られる
- 機器の更新やパッチ当てを事業者に任せられる
Q.ZTNA(Zero Trust Network Access)って何?
ZTNA(Zero Trust Network Access)は、「社内ネットワークの中にいるから安全」とは考えず、アクセスのたびにユーザーと端末を検証して、必要なアプリにだけ接続を許可する仕組み
*SWG,CASB,FWaaSは内から外への通信が対象。しかしZTNAは内部のサーバへのリソースアクセスを制御するもの。外→内や内→内といった通信が対象となる。
- ネットワークの場所(社内か社外か)だけでは信頼しない
- 誰が、どの端末で、どんな状態でアクセスしているかを、毎回確認する
- 必要最小限のアクセスだけを許可する(最小権限)
▼何をするか
| 要素 | 内容 |
|---|---|
| ユーザー認証 | IDaaSやMFA(多要素認証)でユーザーを確認 |
| 端末の状態確認 | OSのパッチ、ウイルス対策、暗号化、会社管理端末かなどを確認 |
| アプリ単位の許可 | ネットワーク全体ではなく、許可されたアプリ・サーバだけに接続させる |
| 継続的な検証 | 接続中も状況の変化(端末の状態悪化など)を監視し、必要なら遮断 |
▼仕組み(典型的な構成)
ZTNAでは、ユーザーが社内アプリへ直接つながるのではなく、仲介役(ブローカー/ゲートウェイ)を経由する。
- ユーザーの端末が、ZTNAのクラウド(または専用ゲートウェイ)に接続を要求
- ユーザーと端末を検証し、ポリシーで許可されているか判定
- 許可されたアプリへだけ、仲介役が接続を中継
- アプリ側は、外からの接続を直接受けず、社内から仲介役へ外向きに接続する構成が多い(インターネットに公開しなくてよい)
p.10 Q.どうやってデフォルトルートを使い分けているの?
| 拠点 | ルータ | AS番号 | 宛先プレフィックス | ネクストホップ | 経路制御方式 |
| 営業所 | IPsecルータ | 65000:1 | 0.0.0.0/0 | ISP のルータ | 静的経路制御 |
| 営業所 | IPsecルータ | 65000:2 | 0.0.0.0/0 | トンネル IF | 静的経路制御 |
上の図はp.10の表2を抜粋したもの。これを見ると2つのデフォルトルートが登録されている。上段は一般的なインターネットアクセス用。下段はP社営業支援サービス用。どちらもデフォルトルートなのにどうやって使い分けているの?
A.結論から言うと、「パケットがルータに届いた時点(デフォルトルートを見る前)に、どのVRFに入れるかは完全に決まっている」というのが答え
▼2つのVRFの役割
65000:1(インターネット用VRF)- 営業所の「IPsecルータ自身」が、ISPと直接つながってIPsec VPNのトンネル(対向の本社ルータとの間)を確立・維持するための物理的なインターネット通信用。
65000:2(VPN用VRF)- 営業所の「PC(社内LAN)」からのすべての通信を収容する空間。
ここからわかる通り、営業所のアクセスはP社に限らず、営業所から出るインターネット向けの通信は「すべて(0.0.0.0/0)」問答無用で本社側へ経由(バックホール)する設計になっている。
Q.VRF65000:1とVRF65000:2はどう連携しているの?
物理的なインターネット接続用の0.0.0.0とすべてをトンネルIFに流すための0.0.0.0はどうやって連携しているの?65000:2で受け取ったパケットをインターネットに流すには65000:1のインターネット用のVRFを使わないとルーティングできないよね?そこらへんはどうなっているの?
A.65000:2 から入った通信が、最終的に物理的なインターネットへ出ていく段階で 65000:1 側の経路・仕組みとガッツリ結合(連携)している。そのフローを見ていこう!
ステップ1:65000:2(VPN用)でのキャッチとトンネル突入
- 営業所のPCから出たパケット(平文)がルータのLAN-IFに届く。
- 所属が
65000:2なので、VPN用VRFのルーティングテーブルを参照する。 0.0.0.0/0のネクストホップとして指定されている「トンネルIF」にパケットが押し込まれる。
ステップ2:トンネルIFでのカプセル化
- トンネルIFに入ったパケットは、IPsecによって暗号化・カプセル化される。
- 暗号化された中身を包み込むように、外側に「新しいIPヘッダ」が新しく付く。
*この瞬間にトンネル設定等で宛先VRFを指定して、65000:2から65000:1のVRFに移行される!!
ステップ3:65000:1(インターネット用)との連携による外部送出
- さあ、この「本社のグローバルIPが宛先になった新しいパケット」を、営業所の物理的な外(ISP)へ送り出さなければならない。
- しかし、
65000:2の世界には「トンネルの中(本社行き)」の経路しかない。本社のグローバルIPにどうやって到達すればいいのか(物理的なISPへの出口はどこか)は、65000:2は知らない。 - そこで、ルータの内部でこのパケットは、インターネット直結用の部屋である
65000:1(インターネット用VRF)のルーティングテーブル を参照し、そこにいる0.0.0.0/0 ➡ ISPのルータ(INT-IF)の経路を使って、物理的にISPへと飛び出していく。
#! --- 1. VRF(部屋)の定義 ---
ip vrf 65000:1
description === Internet / FVRF (外側) ===
ip vrf 65000:2
description === VPN & LAN / IVRF (内側) ===
#! --- 2. 物理インターフェースの割り当て ---
#! ① インターネット側(ISP直結)は「65000:1」に所属
interface GigabitEthernet0/0
description INT-IF (to ISP)
ip vrf forwarding 65000:1
ip address w.x.y.z 255.255.255.0
#! ② 社内LAN側(PC接続)は「65000:2」に所属
interface GigabitEthernet0/1
description LAN-IF (to L2SW)
ip vrf forwarding 65000:2
ip address 172.17.1.1 255.255.255.0
#! --- 3. VPNトンネルインターフェースの設定(ここが核心!) ---
interface Tunnel0
description IPsec VPN Tunnel to HQ
ip vrf forwarding 65000:2 ! トンネルの内側は「内側VRF(65000:2)」に所属
ip address unnumbered GigabitEthernet0/1
tunnel source GigabitEthernet0/0 ! 物理的な送信元は外側インタフェースを指定
tunnel vrf 65000:1 !【超重要】外側パケットは「外側VRF(65000:1)」を使って送り出せ!
tunnel destination <本社のグローバルIP>
#! --- 4. 各VRFごとのルーティング(表2の再現) ---
#! ① 外側VRF(65000:1)のデフォルトルート = ISPへ直行
ip route vrf 65000:1 0.0.0.0 0.0.0.0 <ISPのルータIP>
#! ② 内側VRF(65000:2)のデフォルトルート = すべてトンネルへ流す
ip route vrf 65000:2 0.0.0.0 0.0.0.0 Tunnel0Q.本社IPsecルータに届いた後のフローはどうなっている?
#! ==========================================
#! 1. VRF(ルーティングの部屋)の定義
#! ==========================================
ip vrf 65000:1
description === Internet / FVRF (外側・インターネット用) ===
ip vrf 65000:2
description === VPN & Internal / IVRF (内側・社内/VPN用) ===
#! ==========================================
#! 2. 物理インターフェースの設定
#! ==========================================
#! ① インターネット側(ISP直結)
interface GigabitEthernet0/0
description WAN-IF (to ISP Router)
ip vrf forwarding 65000:1
ip address s.t.u.v 255.255.255.0
no shutdown
#! ② 社内LAN側(本社のL3SW直結)
interface GigabitEthernet0/1
description LAN-IF (to Honsha L3SW)
ip vrf forwarding 65000:2
ip address 172.17.0.1 255.255.255.0
no shutdown
#! ==========================================
#! 3. IPsecトンネルインターフェースの設定
#! ==========================================
interface Tunnel0
description IPsec VPN Tunnel to Branch Office
ip vrf forwarding 65000:2 ! トンネルの内部(中身)は「内側VRF(65000:2)」に所属
ip address unnumbered GigabitEthernet0/1 ! IPアドレスを節約するためLAN側から借用
tunnel source GigabitEthernet0/0 ! 送信元となる物理IF(外側)を指定
tunnel vrf 65000:1 ! ★外側パケットは「外側VRF(65000:1)」を使って送り出せ!
tunnel destination <営業所のグローバルIP>
no shutdown
#! ==========================================
#! 4. ルーティングの設定(表2の完全対応)
#! ==========================================
#! ① 外側VRF(65000:1)のデフォルトルート = インターネット(ISP)へ直行
ip route vrf 65000:1 0.0.0.0 0.0.0.0 <ISPのルータIP>
#! ② 内側VRF(65000:2)の「営業所LAN宛て」 = トンネルIFへ流す(静的経路)
ip route vrf 65000:2 172.17.1.0 255.255.255.0 Tunnel0
#! ==========================================
#! 5. OSPF(動的経路制御)の設定
#! ==========================================
#! 本社側は内側VRF(65000:2)の中でOSPFを動かし、L3SWとデフォルトルート等をやり取りする
router ospf 1 vrf 65000:2
router-id 192.168.10.254
network 192.168.10.0 0.0.0.255 area 0
! 表2にある「本社のL3SWからOSPF経由で受け取る 0.0.0.0/0」をここで学習するStep 1:外側インターフェースでの受信(65000:1)
- 営業所から飛んできたIPsecパケットが、本社の外側物理インターフェース(
INT-IF/GigabitEthernet0/0)に到着する。 - このインターフェースは
65000:1(外側VRF) に所属しているため、パケットはまず外側の部屋に入る。
Step 2:IPsecエンジンによるセキュリティチェックと復号
- ルータのIPsecエンジンがパケットをキャッチする。
*IPヘッダの中のプロトコル番号がIPsec(ESP:プロトコル番号50、またはIKE:UDP 500/4500番)に該当したらIPsec処理へ投げる - SPIの読み取りとSADの参照:
パケットのESPヘッダに含まれる SPI を読み取り、SADから該当する鍵を取り出す。
*SPI(Security Parameters Index):受信したIPsecパケット(ESPヘッダ)に書かれている識別子。ルータはパケットのSPIを見ることで、「SADの中から、どの鍵や設定を取り出せばこのパケットを正しく復号できるか」を一意に特定できる。
*SAD (Security Association Database):実際に使っている暗号アルゴリズム、鍵、生存期間などの具体的なパラメータ(実態)を保持するデータベース。 - 復号の実行:
その鍵を使ってパケットの暗号化を解除し、外側のIPヘッダを剥ぎ取る。これで中の「平文のパケット」が姿を現す。 - SPDの確認:
「このパケットは本当にIPsecで保護された正当な通信か?」をポリシーデータベースで照合する。
*SPD(Security Policy Database):「この通信はIPsecで保護(または復号)すべきルールに合致しているか?」という方針(ポリシー)を管理するデータベース。
Step 3:内側VRFへのバトンタッチ(65000:2 とトンネルIF)
- 暗号を解かれて出てきた平文パケットは、ルータの内部処理において「
Tunnel0(トンネルインターフェース)から受信したデータ」として扱われる。 - この
Tunnel0は、コンフィグでip vrf forwarding 65000:2(内側VRF)に所属しているため、パケットは外側の部屋(65000:1)から、内側の部屋(65000:2)のルーティング空間へ一瞬でバトンタッチされる。
▼受信したパケットの外側ヘッダーが、これらの設定と一致したら、そのトンネルインターフェースで処理される
interface Tunnel0
ip address 10.255.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile MYPROFILEStep 4:内側VRFのルーティングとOSPFによる社内転送
- 内側の部屋(
65000:2)に入ったパケットは、そのルーティングテーブルを参照する。 - 表2にある通り、デフォルトルート(
0.0.0.0/0)のネクストホップは 本社のL3SW(空欄b) になっているため、パケットは本社のL3SWへ送り出される。 - 本社L3SWやFW、社内サーバーの間では OSPF(動的経路制御) が稼働しているため、ルーティングに従って目的地の社内サーバーやPCへと最終的に届けられる。
Q.なんでIPsecはトンネルを使うの?
IPsecを使う時はトンネルを使うことが多い。え?でもさ、外側IPヘッダのカプセル化だけでよくね?なんでわざわざトンネルを経由させる必要があるの?
A.実はIPsecを実現するには「トンネル」と「クリプトマップ」の2つの方式がある。
1. クリプトマップ方式(ポリシーベースVPN)
- 仕組み: パケットの「送信元・宛先(アクセスコントロールリスト / ACL)」を個別に指定して、「この組み合わせの通信だけを暗号化しなさい」と直接ルータに指示する方式。
- デメリット: 拠点間のネットワークが増えたり、新しいサブネット(部署やPC)が追加されるたびに、両方のルータでアクセスのルール(ACL)をいちいち書き換え・追加しなければならず、管理が地獄のように面倒になる。
2. トンネル方式(ルートベースVPN / VTIなど)
- 仕組み: 仮想的な「トンネルインターフェース」を作り、ルーティング(静的ルートやOSPFなど)を使って「営業所宛てのパケットはとりあえずこのトンネルに流す」と指定する方式。
- メリット: トンネルに流しさえすれば、中の宛先が何個増えようが「このトンネルを通る通信はすべてまるごと暗号化する」という一律のルールで一網打尽にできるため、管理が圧倒的に楽になる。さらにOSPFなどの動的ルーティングとも相性が抜群に良い。
以上より、別にトンネルインタフェースを利用しなくてもIPsecは利用できるということが分かる。しかし、運用・管理の面でトンネルインタフェースを使った方がメリットがあるためトンネルインタフェースが使われている。
Q.トンネルインタフェースのIPサブネットをそろえる理由は?
正直、IPサブネットを対向同士でそろえなくてもIPsecは確立する。しかしルーティングの観点からそろえたほうが良いことが多い。
パターン1:IPサブネットをそろえないと?
基本的にOSPFで隣接関係を確立するには、同一のサブネット内に属する必要がある。そのため、サブネットをそろえないと隣接関係を構築することができない可能性がある。
また、たとえ隣接関係を構築できてもルーティング設定が複雑になってしまう。
パターン2:IPサブネットをそろえると?
対向のトンネルインタフェースからのOSPFパケットを受け取ると、同一サブネットであるためスムーズに隣接関係を結べ、ルーティング設定もわかりやすくなる。
p.10 Q.OSPFでデフォルトルートを配布するってどうやってやるの?

router ospf 1
default-information originateこれだけで、その機器がすでに持っているデフォルトルート(スタティックなどで設定された 0.0.0.0/0 の経路)を、OSPFの仲間たちに向けて「インターネットへ行くときは俺に持ってきてくれ!」と自動で配る(アドバタイズする)ことができるようになる。
Q.そもそも相手のIPアドレスわからないのにIPsec確立できるの?


本問題では、営業所IPsecルータが動的IPであるため、本社側IPsecルータは静的なデフォルトルートを準備する必要がある。もし、固定であれば、ip route 営業所固定IP 255.255.255.0 ISPのIPのように指定できいるのに。。でも、これは逆を言えば、相手のIPアドレスが分からなくてもIPsecが確立できるということである。ん?そんなことできるの?
A.「相手のIPが動的で分からないなら、本社からどうやってVPNを張るんだよ?」という疑問、まさにその通りで、もし本社側から「本社 ➔ 営業所」へと一方的に話しかけよう(接続を始めよう)としても、相手のIPが分からないので絶対に不可能!!。
結論から言うと、この仕組みのカラクリは 「必ず営業所側から本社へ『おーい!』と話しかけている(発信している)」 という点にある。
では、フローを見ながら理解していこう!
▼片方が動的IPの時のIPsec確立フロー
フェーズ1:IKE-SA(ISAKMP-SA)の確立
目的:お互いの身元を確認し(認証)、この後の通信を安全に行うための「暗号化された制御用の安全な部屋(IKE-SA)」を作る。
- 第1パケット送信(営業所 ➔ 本社)
- 営業所のルータが、本社の固定IP宛てにUDP 500番ポートで「IKEの提案(俺はこういう暗号方式が使えるけどどう?)」を送る。
- この瞬間、本社側はパケットの「送信元IPアドレス」を読み取り、営業所の「今のグローバルIP」を初めて把握する。
- パラメータの合意とDH鍵交換(Main Mode または Aggressive Mode)
- お互いに暗号アルゴリズム(AESなど)やハッシュ関数、事前共有キー(PSK)などの認証方式が一致しているかを確認する。
- Diffie-Hellman(DH)アルゴリズムを使って、通信を盗聴されても絶対に解読されない共通の暗号鍵の素材を安全に交換する。
- 相互認証の完了 ➔ IKE-SA確立
- お互いが「本物だ」と確認できたら、IKE-SA(ISAKMP-SA)というセキュリティ管理用のトンネルが完成する。以降、設定のやり取りはこの安全な制御チャネル上で行われる。
*事前共有鍵が一致していたら認証が成功したことになる
- お互いが「本物だ」と確認できたら、IKE-SA(ISAKMP-SA)というセキュリティ管理用のトンネルが完成する。以降、設定のやり取りはこの安全な制御チャネル上で行われる。
フェーズ2:Child SA(IPsec SA)の確立
目的:実際のユーザーデータ(社内LANのパケット)を流すための「データ用の暗号トンネル(IPsec SA)」を作る。フェーズ1で作った安全なIKE-SAの中を通って交渉する。
- クイックモードの開始(営業所 ➔ 本社)
- 「実際にデータを暗号化して送るためのルールを決めようぜ」と、営業所から本社へクイックモードの要求を送る。
- トラフィックセレクターと暗号方式の合意
- 「どの通信を暗号化の対象にするか(例:営業所LAN
172.17.1.0/24⇔ 本社LAN172.16.0.0/24)」という保護範囲(トラフィックセレクター)や、実際のデータ暗号化に使うプロトコル(ESPなど)を合意する。
- 「どの通信を暗号化の対象にするか(例:営業所LAN
- Child SA(IPsec SA)の確立
- 交渉が成功すると、送信用と受信用でペアとなったIPsec SA(別名:Child SA)がバシッと生成される。これで、データ用のトンネルが完全に開通する。
実際のデータ通信のフロー(トンネル稼働後)
- パケットの投入
- 営業所のPCが本社へデータを送ろうとすると、営業所ルータは静的ルートに従ってそのパケットを「トンネルインターフェース」に流し込む。
- ESPカプセル化と暗号化
- ルータは、そのパケット全体をIPsec(ESP:プロトコル50)で丸ごと暗号化し、外側に「本社と営業所のグローバルIP」のヘッダーを付けてインターネットへ送り出す。
- 復号と転送
- 本社のルータがそれを受け取り、IPsec SAの鍵を使って復号し、中身を取り出して本社側(内側VRFやL3SW)へ送り届ける。
Q.IKEv1 メインモード(フェーズ1)の6つのメッセージとは?
では、まずは全体像を見ていこう!
| 往復 | メッセージ | 主な目的 |
|---|---|---|
| 1往復目 | ① Initiator → Responder | IKE SAの暗号化・認証方式などを提案 |
| ② Responder → Initiator | 提案を選択して応答 | |
| 2往復目 | ③ Initiator → Responder | Diffie-Hellman(DH)の公開値とNonceを送信 |
| ④ Responder → Initiator | DHの公開値とNonceを送信 | |
| 3往復目 | ⑤ Initiator → Responder | 暗号化されたIDと認証情報を送信 |
| ⑥ Responder → Initiator | 暗号化されたIDと認証情報を送信 |
*捕捉
・⑤⑥暗号化されたIDと認証情報を送信
DH公開値、Cookie、SA提案、IDなど、認証に必要な項目を決められた順序で連結して計算する
Q.IKEv1 アグレッシブモード(フェーズ1)の3つのメッセージとは?
| メッセージ | 主な目的 | |
|---|---|---|
| 1 | ① Initiator → Responder | 暗号化方式などの提案、DH公開値、Nonce、自分のIDをまとめて送信する。 |
| 2 | ② Responder → Initiator | 提案する条件の選択、Responder側のDH公開値・Nonce・IDを送り、自身の認証を行う。 |
| 3 | ③ Initiator → Responder | Initiator側の認証情報を送り、Responderが検証する。正常に完了するとIKE SAが確立する。 |
*補足
・アグレッシブモードはIDを平文で送る代わりに、わずか3メッセージでIKE SAを確立できるようになる。
Q.IKEv1 クイックモード(フェーズ2)の3つのメッセージとは?
| メッセージ | 主な目的 | |
|---|---|---|
| 1 | ① Initiator → Responder | IPsec SAの条件を提案する。 ESPの暗号化・認証方式、Nonce、保護対象の通信などを送る。PFSを使う場合は追加のDH公開値も送る。 |
| 2 | ② Responder → Initiator | IPsec SAの条件を選択して返答する。 合意する方式やResponder側のNonceなどを返す。PFSを使う場合はResponder側もDH公開値を送る。 |
| 3 | ③ Initiator → Responder | 最終確認を行う。 認証用ハッシュを送信し、Quick Modeの交換内容を確認する。正常に完了するとIPsec SAが確立する。 |
Q.IKEv2とは?
IKEv2はIKEv1で実施していたフェーズ1とフェーズ2をわずか4メッセージで完結させたもの。
| メッセージ | 主な目的 | |
|---|---|---|
| 1 | ① Initiator → Responder SAi1, KEi, Ni | 使用可能な暗号方式などを提案し、DH公開値とNonceを送る。 |
| 2 | ② Responder → Initiator SAr1, KEr, Nr | 選択した暗号方式、Responder側のDH公開値とNonceを返す。 |
| 3 | ③ Initiator → ResponderSK { IDi, AUTH, SAi2, TSi, TSr, ... } | 暗号化・完全性保護されたメッセージで、自分のIDと認証情報を送り、Child SAの条件も提案する。 |
④ Initiator → ResponderSK { IDr, AUTH, SAr2, TSi, TSr, ... } | Responder自身のIDと認証情報を送り、Child SAの条件を返答する。 |
