この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第17回です。
第2章では、要件定義で整理した条件をもとに、 IPアドレス、VLAN、ルーティング、冗長化、WAN、VPNなどの 基本設計へ落とし込む方法を学びます。
VPN設計とは？
拠点間・リモートアクセスVPNを安全に設計する考え方
VPNは、設定画面で暗号化方式を選択してトンネルを張れば終わりではありません。 誰と誰を接続するのか、どの通信を許可するのか、 どの経路を通すのか、障害時にどう切り替えるのか まで決めて初めて「VPN設計」になります。 この記事では、要件からVPN基本設計へ落とし込む流れを解説します。
中級編では、 VPNの基本と IPsec VPNの基本動作 を学びました。
上級編では、その知識を 「実際の案件でどのようなVPNを採用するか決める力」 へ変えていきます。
大切なのは設定コマンドを覚えることではありません。 要件、セキュリティ、可用性、性能、運用を比較し、 なぜそのVPN構成を採用したのか説明できることです。
この記事を読み終えるとできること
- VPN設計で決める項目を整理できる
- 拠点間VPNとリモートアクセスVPNを使い分けられる
- Route-basedとPolicy-basedの違いを説明できる
- 認証・暗号化・鍵管理の設計観点を整理できる
- VPNとルーティング・NATの関係を設計できる
- 冗長化・監視・障害試験まで考えられる
- VPN設計書に残す項目を整理できる
- VPN構成の選定理由を顧客へ説明できる
VPN設計とは何か
VPN設計とは、離れたネットワークや利用者を安全に接続するために、 接続方式・トポロジー・認証・暗号化・ルーティング・冗長化・性能・運用方法を 要件に基づいて決定する工程です。
VPNは「Virtual Private Network」の略です。 インターネットなどのネットワーク上に、 組織の通信に使用する論理的な接続を構成します。
しかし、実務で重要なのは 「VPNとは何か」を説明できることだけではありません。
たとえば、本社と大阪支店をVPNで接続する場合でも、 次のような項目を決める必要があります。
- どの拠点とどの拠点を接続するか
- インターネットVPNを利用するか
- どの機器をVPN終端装置にするか
- どのネットワーク間の通信をVPNへ通すか
- 拠点間でどのルートを交換するか
- 認証を事前共有鍵にするか証明書にするか
- どの暗号化ポリシーを使用するか
- 回線・装置・トンネルを冗長化するか
- 障害をどのように検知するか
- VPNの状態を誰がどのように監視するか
「IPsecを使う」と決めただけではVPN設計は完成していません。
IPsecはVPNを実現するための技術の一部です。 実際の基本設計では、その周辺にある 回線、アドレス、ルーティング、FW、NAT、監視、冗長化まで考える必要があります。
VPN設計の全体像
VPNは、次の順番で考えると整理しやすくなります。
VPN REQUIREMENTS TO DESIGN｜要件からVPN基本設計へ
VPN装置から設計を始めないことが重要です。
最初に「どの通信を、誰から守りながら、どの程度の可用性・性能で届ける必要があるか」 を整理し、その条件を満たすVPN構成を選びます。
最初に整理するVPN要件
VPN設計を始める前に、 少なくとも次の6つの観点を整理します。
接続対象
- 本社・支店
- データセンター
- クラウド
- 在宅利用者
- 協力会社
通信要件
- 送信元ネットワーク
- 宛先ネットワーク
- 利用アプリケーション
- 必要ポート
- 通信方向
セキュリティ
- 認証方法
- 暗号化ポリシー
- アクセス制御
- 鍵管理
- 監査ログ
可用性
- 許容停止時間
- 回線冗長化
- VPN装置冗長化
- 自動切り替え
- 切り替え時間
性能
- ピーク通信量
- VPNスループット
- 同時接続数
- 遅延
- パケットサイズ
運用
- 監視担当
- 障害通知
- 設定変更
- 証明書更新
- ログ保存
「安全につなぎたい」を具体化する
顧客から、 「本社と支店をVPNで安全につないでください」 と依頼されたとします。
この状態では、まだ設計できません。
| 曖昧な要望 | 確認すべき内容 |
|---|---|
| 安全につなぎたい | どの通信を保護するか、認証方法、暗号化方針、 通信許可範囲、ログ要件を確認する |
| 止まらないようにしたい | 回線・VPN装置・トンネルのどこまで冗長化し、 何秒・何分以内の切り替えが必要か確認する |
| 十分な速度がほしい | 平均・ピーク通信量、暗号化時の処理性能、 アプリケーションの遅延要件を確認する |
| 簡単に運用したい | 拠点追加頻度、設定変更担当者、監視方法、 鍵・証明書更新方法を確認する |
VPN方式を選ぶ
VPNでは最初に、 誰をどこへ接続するVPNなのか を整理します。
拠点間VPN
本社、支店、データセンターなど、 ネットワーク同士を接続します。
- 拠点側VPN装置で終端する
- 利用者がVPN接続操作を行う必要がない
- 複数ネットワーク間を継続的に接続できる
- ルーティング設計が重要になる
リモートアクセスVPN
在宅勤務者や出張者など、 利用者・端末から社内へ接続します。
- ユーザー認証が重要
- MFAなどの認証強化を検討する
- 端末へ付与するIPアドレスを設計する
- 社内へのアクセス範囲を制御する
リモートアクセスVPNについては、 上級編第46回 「リモートアクセスVPN設計」 で、認証、端末制御、MFA、アクセス範囲などをさらに詳しく扱います。
拠点間VPNの基本イメージ
本社と支店をインターネットVPNで接続
VPNトンネルの下では、インターネット回線とIP通信が動作しています。
VPNと回線は別物として考えます。
VPNトンネルが正常でも、その下のインターネット回線が停止すれば通信できません。 VPN設計では「トンネル」だけでなく、 その下にある回線・ルーティング・名前解決・到達性も確認します。
VPNトポロジーを設計する
複数拠点をVPNで接続する場合は、 拠点同士をどの形で接続するかを決めます。
Hub & Spoke
本社やデータセンターをHubとし、 各支店をSpokeとして接続します。
構成を集約しやすい一方、 拠点間通信がHubを経由する場合は、 Hub側の性能や障害影響を考慮します。
Full Mesh
各拠点同士を直接接続します。
拠点間を直接通信させやすい一方、 拠点数が増えるほどトンネル数・設定・監視対象が増えます。
Partial Mesh
重要な拠点だけ直接接続し、 その他はHub経由とします。
通信要件と運用負荷のバランスを取りながら、 必要な場所だけ直接経路を設けます。
| 方式 | メリット | 注意点 | 向いている考え方 |
|---|---|---|---|
| Hub & Spoke | 設定・セキュリティを集約しやすい | Hubへの負荷・障害集中 | 本社・DC中心の通信が多い |
| Full Mesh | 拠点間を直接通信できる | トンネル数と運用負荷が増える | 拠点間通信が重要 |
| Partial Mesh | 重要経路だけ直接化できる | 構成が複雑になりやすい | 通信要件に差がある |
Route-basedとPolicy-basedを理解する
IPsec VPNでは、製品や構成によって Route-based VPNと Policy-based VPN という考え方があります。
Route-based VPN
VPNトンネルを論理インターフェースとして扱い、 ルーティングによってVPNへ通信を送る方式です。
- 経路設計とVPN設計を分けて考えやすい
- 複数ネットワークを扱いやすい
- 動的ルーティングと組み合わせやすい
- 冗長化や拠点追加へ対応しやすい
Policy-based VPN
送信元・宛先などの条件によって、 VPNへ暗号化する通信を指定する方式です。
- 小規模な固定通信では分かりやすい場合がある
- 通信対象が増えるとポリシー管理が増える
- 経路制御との関係を整理する必要がある
- 製品間接続では仕様差を確認する
「どちらが常に優れているか」ではなく、設計要件で選びます。
将来の拠点追加、経路冗長化、動的ルーティングなどを想定する場合は、 VPN方式とルーティング方式を同時に検討することが重要です。
IPアドレス・NAT・ルーティング設計
VPNトンネルが確立していても、 IPアドレスや経路が正しくなければ通信できません。
実務では、 「VPNはUPなのに通信できない」 という状況が起こります。
確認する主な項目
Local Network
自拠点からVPNへ送るネットワークを決めます。
Remote Network
VPN先に存在するネットワークを決めます。
Routing
対象通信がVPNトンネルへ向かう経路を設計します。
NAT
VPN通信をNATするか、NAT対象外とするか整理します。
IPアドレス重複に注意する
VPN接続する2つの組織や拠点で、 同じIPアドレス帯を使用している場合があります。
IPアドレス重複の例
この場合、 単純にルートを追加しても 「192.168.1.0/24」がローカルなのかVPN先なのか区別できません。
アドレス変更が可能か、 NATなどによる変換が必要か、 接続対象を限定できるかを設計段階で検討します。
VPN構築開始後にアドレス重複が判明すると影響が大きくなります。
VPN設計前に、双方のIPアドレス一覧と将来利用予定のネットワークまで確認します。
スタティックルートと動的ルーティング
| 項目 | スタティック | 動的ルーティング |
|---|---|---|
| 構成 | 比較的単純 | ルーティングプロトコルが必要 |
| 拠点追加 | 手動変更が増える | 経路交換を自動化しやすい |
| 冗長化 | 経路優先度などを設計 | 経路制御と連携しやすい |
| 運用 | 小規模では把握しやすい | 規模が大きい場合に管理しやすい |
認証・暗号化・鍵管理を設計する
VPNは、通信を保護するための仕組みです。 そのため、 トンネルが張れることより、適切な相手と安全に通信できること が重要です。
設計する主な項目
認証
- 事前共有鍵
- 証明書
- ユーザー認証
- MFA
暗号化
- 暗号化方式
- 完全性保護
- 鍵交換方式
- セキュリティポリシー
鍵管理
- 発行方法
- 保管方法
- 更新周期
- 失効・変更手順
PSKと証明書
| 項目 | 事前共有鍵（PSK） | 証明書 |
|---|---|---|
| 導入 | 比較的簡単 | PKI・証明書管理が必要 |
| 拠点増加 | 鍵管理が煩雑になりやすい | 大規模管理へ向いている場合がある |
| 更新 | 双方の変更調整が必要 | 有効期限と更新運用が必要 |
| 設計ポイント | 鍵の強度・保管・変更手順 | 発行・失効・期限監視 |
暗号化方式だけでVPNの安全性は決まりません。
認証情報の管理、VPN装置自体の管理アクセス、 通信許可ポリシー、ログ、証明書更新、 OS・ファームウェア管理まで含めてセキュリティを設計します。
セキュリティパラメータは組織標準に合わせる
IKEやIPsecでは複数の暗号・認証・鍵交換方式を選択できます。
新規設計では、 組織のセキュリティ基準、接続先の対応状況、 製品の推奨設定を確認し、 古い方式との互換性だけを理由に安全性を下げない ことが重要です。
基本設計書では、単にパラメータ名を書くのではなく、 「社内セキュリティ標準に準拠」 「接続先との相互接続要件により選定」 など、選定理由も残します。
VPNの冗長化設計
VPNを冗長化するときは、 何の障害に耐えたいのか を先に整理します。
回線障害
ISPやアクセス回線の障害を想定します。
VPN装置障害
ルーター・FWなどの故障を想定します。
トンネル障害
VPNセッションだけが異常になるケースを考えます。
経路障害
トンネルはUPだが宛先まで届かない状態も考えます。
VPN冗長化の考え方
「2本ある」だけでは冗長化にならない
たとえばVPNトンネルを2本構成していても、 2本とも同じインターネット回線を利用していれば、 回線障害では同時に停止する可能性があります。
同様に、回線を2本用意しても、 1台のVPN装置で両方を終端していれば、 VPN装置故障が単一障害点になります。
冗長化設計では、「トンネル数」ではなく「障害点」を確認します。
障害検知方法も設計する
VPNには、 「装置は稼働している」「VPNセッションも存在する」 ものの、実際の業務通信だけが失敗している状態もあります。
そのため、次の複数レイヤーで監視することが重要です。
- 回線状態 物理リンクやインターネット到達性を確認する。
- VPNセッション IKE/IPsecなどのセッション状態を確認する。
- ルーティング VPN先ネットワークへの経路が存在するか確認する。
- End-to-End通信 実際の対向ネットワークまで疎通できるか確認する。
性能・MTU・帯域を設計する
「1Gbps回線を契約しているからVPNも1Gbps通信できる」 とは限りません。
VPN装置では暗号化・復号処理が必要になるため、 装置のVPN処理性能も確認します。
確認する性能項目
VPNスループット
暗号化を有効にした状態で、 必要な通信量を処理できるか確認します。
同時トンネル数
現在だけでなく、 将来の拠点・クラウド追加も考慮します。
CPU・セッション
VPN処理とFW、NAT、IPSなどを 同一装置で処理する場合の負荷も確認します。
遅延・パケットロス
VPNの下にあるインターネット回線品質も アプリケーションへ影響します。
MTUとフラグメント
VPNでは元のIPパケットへ IPsecなどの追加情報が付加されるため、 VPNを使用しない通信よりパケットサイズが大きくなります。
VPNによるカプセル化のイメージ
MTUが適切でないと、 小さいpingは通るのに、 大きなデータ転送や特定のアプリケーションだけ失敗することがあります。
必要に応じてMTUやTCP MSSを調整し、 実際のアプリケーション通信でも確認します。
VPNの監視・運用設計
VPNは構築した後も継続的な運用が必要です。
特に忘れやすいのが、 「トンネルがDOWNしたときに誰が気付くのか」 という設計です。
監視したい主な項目
状態監視
- トンネル状態
- IKE/IPsec SA
- 対向到達性
- ルーティング状態
性能監視
- 送受信量
- パケットロス
- 遅延
- 装置CPU・メモリ
セキュリティ監視
- 認証失敗
- 設定変更
- 証明書期限
- 異常な接続試行
運用手順も設計書へ残す
- VPN障害時の一次確認方法
- 対向組織への連絡方法
- PSK変更手順
- 証明書更新手順
- VPN装置交換時の手順
- 設定バックアップ方法
- ログ確認方法
- 障害切り戻し方法
VPNは自社だけで完結しない場合があります。
他社、クラウド事業者、回線事業者などとの接続では、 責任分界点と障害時の連絡経路 も設計の一部です。
VPN試験で確認すること
VPN試験では、 「トンネルがUPになった」だけで合格にしてはいけません。
| 試験分類 | 確認例 |
|---|---|
| VPN確立 | 想定した対向装置とのVPNセッションが確立する |
| 正常通信 | 許可したネットワーク・アプリケーションが通信できる |
| 禁止通信 | 設計上許可していない通信が遮断される |
| 経路 | 対象通信が想定したVPNトンネルを通る |
| NAT | VPN通信に必要なNAT・NAT除外が正しく動作する |
| 冗長切り替え | 主回線・主トンネル障害時にバックアップへ切り替わる |
| 復旧 | 障害復旧後の経路・トンネル状態が設計どおりになる |
| 性能 | 想定通信量で必要な性能を満たす |
| MTU | 大きなパケットや実アプリケーションで問題がない |
| 監視 | VPN停止時に監視システムから通知される |
要件定義で「回線障害時も業務を継続する」と決めた場合は、 VPN基本設計だけでなく、 障害を実際に発生させる試験項目 までつなげます。
VPN設計書に残す内容
VPN基本設計では、 詳細な装置コマンドよりも、 方式・設計方針・接続関係・選定理由 を明確にします。
VPN基本設計項目の例
本社・支店間の業務通信を安全に接続する。
インターネット経由の拠点間IPsec VPNを使用する。
本社・支店の境界ファイアウォールでVPNを終端する。
本社業務LANと支店業務LAN間を対象とする。
組織のセキュリティ標準および対向装置の対応方式に準拠する。
VPNトンネルを経由する対象経路と優先順位を定義する。
主回線障害時はバックアップVPNトンネルへ切り替える。
VPN状態、対向疎通、通信量、装置状態を監視する。
VPN確立・切断・認証失敗・設定変更を記録する。
正常通信、禁止通信、冗長切り替え、性能、監視通知を確認する。
パラメータ一覧も作成する
| 項目 | 本社 | 支店 |
|---|---|---|
| VPN終端装置 | 本社FW | 支店FW |
| WANアドレス | 設計値を記載 | 設計値を記載 |
| Local Network | 10.10.0.0/16 | 10.20.0.0/16 |
| Remote Network | 10.20.0.0/16 | 10.10.0.0/16 |
| 認証方式 | 案件のセキュリティ方針に従って定義 | |
| 暗号化ポリシー | 組織標準・相互接続要件に従って定義 | |
VPN設計でよくある失敗
VPNがUPでも、ルーティング・FW・NATに問題があれば 業務通信はできません。
他社やクラウドとのVPN接続では、 接続後に重複が判明すると大きな設計変更が必要になる場合があります。
VPN装置の暗号化処理能力や、 FW・IPSなど同時利用する機能の負荷も確認します。
2本のVPNが同じ回線・同じ装置を利用していれば、 共通障害点が残っています。
認証、アクセス制御、鍵管理、装置管理、 ログ、更新運用まで含めて設計します。
VPNカプセル化によるサイズ増加により、 一部通信だけ不安定になることがあります。
導入時だけでなく、 有効期限や担当者変更を含めたライフサイクルを設計します。
WAN、FW、NAT、ルーティング、冗長化、監視、試験まで 一連の通信経路として設計します。
顧客・上司へVPN設計をどう説明するか
技術に詳しくない相手へ、 IKE、SA、ESPなどの用語から説明する必要はありません。
まず、 何を守るためのVPNなのか を説明します。
説明例：
「本社と支店はインターネットを利用して接続しますが、 業務データをそのまま送るのではなく、 VPNによって通信を保護します。 また、主回線に障害が発生した場合でも業務を継続できるよう、 バックアップ回線側にもVPN経路を用意します。 VPNの状態だけでなく、実際に本社と支店間で通信できているかも監視します。」
設計理由を業務影響へ変換する
| 技術的な説明 | 顧客への説明 |
|---|---|
| VPNを冗長化する | 回線障害時も支店から業務システムを利用できるようにする |
| アクセス制御を行う | VPN接続した相手から必要なシステムだけ利用できるようにする |
| 証明書期限を監視する | 期限切れによる突然のVPN停止を防ぐ |
| VPN性能を確認する | 暗号化後も業務に必要な通信速度を確保する |
| End-to-End監視を行う | VPN表示が正常でも実通信が停止している状態を検知する |
上流工程では、 「VPNを使います」ではなく 「この業務要件を満たすため、このVPN構成にします」 と説明できることが重要です。
VPN設計で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Site-to-Site VPN | 拠点間VPN |
| Remote Access VPN | リモートアクセスVPN |
| VPN Gateway | VPN終端装置 |
| Tunnel | トンネル |
| Pre-Shared Key | 事前共有鍵 |
| Certificate | 証明書 |
| Encryption | 暗号化 |
| Authentication | 認証 |
| Key Exchange | 鍵交換 |
| Failover | 障害時切り替え |
| Redundancy | 冗長性 |
| Overlapping Subnet | 重複するサブネット |
設計・ベンダー確認で使える表現
Which networks should be reachable through the VPN tunnel?
VPNトンネル経由で到達可能にするネットワークはどれですか？
What authentication method will be used for the VPN?
VPNではどの認証方式を使用しますか？
Are there any overlapping IP address ranges?
重複しているIPアドレス範囲はありますか？
How will VPN failover be detected?
VPN障害時の切り替えをどのように検知しますか？
What is the expected encrypted traffic throughput?
暗号化通信ではどの程度のスループットを想定していますか？
理解度チェック
VPN用語の暗記ではなく、 設計判断ができるか を確認しましょう。
問題1．VPN基本設計で最初に行うこととして最も適切なのはどれですか。
- VPN装置のメーカーを決める
- 暗号化アルゴリズムだけを決める
- 誰と誰のどの通信を接続する必要があるか整理する
- 設定コマンドを作成する
解答を見る
まず接続目的・対象通信・セキュリティ・可用性などの要件を整理し、 その後でVPN方式や装置を決めます。
問題2．VPNトンネルがUPしているのに業務通信できません。 確認すべきものとして不適切なものはどれですか。
- ルーティング
- ファイアウォールポリシー
- NAT設定
- VPN状態がUPなので追加確認は不要
解答を見る
VPNセッションが確立していても、 経路、FW、NAT、対向ネットワークなどに問題があれば通信できません。
問題3．VPNトンネルを2本作成しました。 これだけで十分な冗長化と言えない理由を説明してください。
解答を見る
2本のVPNが同じ物理回線、同じISP、同じVPN装置などを共有している場合、 その共通部分の障害で両方とも停止する可能性があります。
冗長化ではトンネル数ではなく、 どの障害点を分離できているかを確認します。
問題4．VPN接続する2拠点で、 どちらも192.168.1.0/24を使用していました。 何が問題になるでしょうか。
解答を見る
ローカルネットワークとVPN先ネットワークが同じアドレスになるため、 通信先を経路だけで正しく区別できない問題が発生します。
アドレス変更、NAT、接続対象の見直しなどを検討します。
問題5．VPNの性能設計で回線帯域以外に確認すべきものを3つ挙げてください。
解答を見る
例：
- VPN装置の暗号化時スループット
- 同時VPNトンネル数
- CPU・メモリ負荷
- FW・IPSなど他機能を有効にした場合の性能
- MTU・TCP MSS
- 遅延・パケットロス
実践演習：本社と支店のVPN基本設計を作ろう
次の顧客要件から、 VPNの基本設計を考えてください。
演習用ネットワーク
顧客要件
- 東京本社と大阪支店を接続したい
- 業務システム通信を暗号化したい
- 支店から本社サーバーへアクセスする
- インターネット回線を利用したい
- 主回線障害時も業務を継続したい
- 今後さらに3拠点程度追加する可能性がある
- VPN停止時は運用担当者へ通知したい
課題1．VPN方式を決める
拠点間VPNとリモートアクセスVPNのどちらを選びますか。 理由も書いてください。
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
採用方式：拠点間VPN
東京本社LANと大阪支店LANという ネットワーク同士を継続的に接続するためです。
課題2．冗長化対象を整理する
主回線障害時も通信を継続するには、 どの部分を確認する必要がありますか。
・＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
・＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 予備インターネット回線
- 予備回線側のVPNトンネル
- 主VPNから予備VPNへの経路切り替え
- VPN装置自体の単一障害点
- 障害検知方法
- 復旧後の経路復帰方法
課題3．VPN監視項目を考える
VPN停止を確実に検知するため、 4つ以上の監視項目を挙げてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- インターネット回線状態
- VPNトンネル状態
- IKE/IPsecセッション状態
- 本社・支店間のEnd-to-End疎通
- VPN経由通信量
- VPN装置CPU・メモリ
- VPN関連ログ
課題4．基本設計方針を書く
顧客へ提示する想定で、 150〜250文字程度のVPN設計方針を書いてください。
回答例を見る
東京本社と大阪支店間は、インターネットを利用した拠点間VPNで接続し、 業務通信を保護します。 主回線障害時にも業務を継続できるよう予備回線側にもVPN経路を構成し、 障害検知後にバックアップ経路へ切り替えます。 VPN状態だけでなく、本社・支店間の実通信も監視し、 障害時は運用担当者へ通知します。
自分の言葉で説明する課題
上司から 「VPNは暗号化設定を決めれば設計完了ではないの？」 と聞かれました。 1分程度で説明してください。
説明例を見る
VPNでは暗号化方式だけでなく、 どの拠点や利用者を接続するか、 どの通信を許可するか、 どの経路をVPNへ送るか、 回線やVPN装置が故障したときにどう切り替えるかまで設計します。 また、性能、監視、鍵・証明書の更新、障害試験も必要です。 そのためVPNはネットワーク全体の一部として設計します。
まとめ
- VPN設計では、方式・接続対象・認証・暗号化だけでなく、 経路、NAT、冗長化、性能、監視まで決める
- ネットワーク同士を接続する場合は拠点間VPN、 利用者端末から接続する場合はリモートアクセスVPNを検討する
- VPNトンネルの下にはインターネット回線などのUnderlayが存在するため、 VPNと回線を分けて設計する
- VPNがUPでも、ルーティング・FW・NATに問題があれば業務通信できない
- IPアドレス重複はVPN設計の初期段階で確認する
- VPN冗長化では、トンネル数ではなく回線・装置・経路などの障害点を確認する
- 回線速度だけでなく、VPN装置の暗号化性能とMTUも確認する
- VPN状態だけでなく、対向ネットワークまでのEnd-to-End通信を監視する
- 基本設計では「何を設定するか」だけでなく 「なぜその方式を採用したのか」を残す
VPN設計で最も重要なのは、 「トンネルを作ること」ではなく、 必要な業務通信を安全かつ安定して届け続けることです。
第2章「基本設計」では、 要件から具体的なネットワーク構成へ落とし込む力を身につけます。
コメント