
Cisco 担当者コラム
Cisco・Meraki
Meraki 第145回「Meraki MXによるAuto VPN環境からSecure Connectへの移行」
こんにちはMeraki製品担当の林です。
今回はすでにMeraki MXによる拠点間VPNを導入済みの環境を、Secure Connectへ接続していく方法についてご紹介していきたいと思います。
まず前提として、Secure Connectは下記のようにクラウドを唯一のハブとしてすべてのユーザを接続するソリューションです。
<Cisco Secure Connectの利用イメージ>

この構成ではすべての通信をSecure Connectに集めることで、一元的なポリシー管理とトラフィックの可視化を実現することが可能になります。
この点は非常に分かりやすいメリットとなるのですが、すでにMeraki MXのAuto VPNでは大きな拠点やデータセンターをハブとして構築されているお客様の環境では、移行時に全体のトポロジ変更が発生します。
<Meraki MXのAuto VPNの利用イメージ>

トポロジ変更は、各拠点のMXがSecureConnect側からBGPでデフォルトルートを受け取る形で自動的に行われるため、例えば試しに拠点AをSecure Connectへ繋いでみたら元の拠点と通信できなくなってしまった、ということも考えられます。
<拠点AのみをSecure Connectへ接続した場合のイメージ>

もちろん全拠点を一斉にSecure Connectに繋ぎこむ、という選択肢もありますが、拠点数の多いユーザ様での作業を想定するとなかなかハードルが高いな、ということで今回は段階的な接続について試していきます。
まずは、既存のMeraki MXが紐づいたダッシュボードとSecure Connectを紐づけていきます。
この際の手順についてはこちらの記事でご紹介しておりますが、一旦Merakiダッシュボードに“セキュアコネクト”タブが追加されたところで手を止めます。※サイトの接続はまだ行いません!

ここでのポイントとしてMerakiダッシュボードをSecure Connectへの紐づけだけでは、トポロジの変更は起こりません。
続いて、Merakiサポートに対してケースオープンを行い下記の機能の有効化を依頼します。
※この機能は2024年5月現在パブリックプレビューとなるため有効化にはサポートへのリクエストが必要です。
<依頼内容のイメージ>

詳細はリンクのドキュメントをご一読いただければと思いますが、基本的にSecureConnect環境ではすべての拠点のMXをスポークとして構成する必要があります。
もしMXをハブとして構成してしまった場合、デフォルトではハブのMXからSecure Connectへのトラフィックが全てドロップされてしまい、インターネットへの接続ができなくなってしまいます。
<ハブ間通信はドロップされる>

今回の趣旨である段階的な移行を行うためには、ハブ拠点を維持したままSecureConnectへの繋ぎこみを行う必要がありますので、先ほどのサポートへの依頼でハブに対するこの仕様を変更してハブ間の通信を許可してもらう必要があります。
サポートから変更完了の連絡が来ましたら、まずはハブをSecure Connectに接続します。
<ステップ1>

こちらの設定が完了すると、MXのルーティングテーブルとしては次のようになります。
※スポーク側のMXではインターネット宛のトラフィックを直接インターネットへ向けている想定とします。
<表1>

この時点ではスポーク拠点からの通信には特に影響は出ておらず、本社からのインターネットアクセスがSecure Connect経由となっただけです。
次のステップとして、拠点を順番にSecure Connectへ接続していきます。
このステップではすべての拠点がSecure Connectへ接続されるまで、Secure Connectに接続するスポークと本社に接続するスポークとが混在する環境となります。
<ステップ2>

上の図のように拠点AをSecure Connectへ接続し、拠点BがSecure Connectへ未接続の場合ルーティングテーブルは次のようになります。
<表2>

赤文字で書きましたが、Secure Connectの仕様として、Secure Connectに接続されたスポークはSecure Connectに未接続のスポークに対しての接続ができなくなります。
※厳密にはルートがSecure Connectに向くのですが、そこでドロップされます。
これを防ぐために、他の拠点からアクセスが必要な拠点は前のステップ1でハブとしてSecure Connectへ接続しておくようにしてください。(複数のハブ拠点をSecure Connectへ接続する構成が可能です。)
全ての拠点がSecureConnectに接続完了すると次のようになります。
<ステップ3>

この形になりますとスポーク間でもSecure Connect経由で通信が可能になります。
<表3>

最後にハブ拠点をスポークに変更して接続しなおすことで、SecureConnectのみをハブとする構成へ変更いただくことが可能です。
<ステップ4>

ステップ3と4の違いとしては、スポーク拠点から本社に対しての通信がSecure Connectを経由するのかどうかという部分です。
<表4>

せっかくSASEのソリューションとしてSecure Connectを使って頂くのであれば、
ステップ4のすべての通信がSecure Connectを経由する形をおすすめしておりますが、オンプレミスのサーバに対して非常に大きなトラフィックが発生するような環境のユーザ様ですと、ステップ3の形のまま運用頂く、という選択肢も考えられるかと思います。
このあたりはお客様のご要件に応じて使い分けてみてください。
いかがだったでしょうか。
私自身の感想としてMerakiを使用することで設定自体はほぼ全自動で行われるため非常に簡単なのですが、プランニングにあたっては、裏でどんな動きをしているのかを把握することが重要だなと感じました。
このあたり、ご導入の際には、一度検証頂いた上で作業を行って頂くことをオススメします。
今回は以上です。最後までお読みいただきありがとうございました。
<<<Cisco Meraki エンジニア情報局 前回の記事>
<Cisco Meraki エンジニア情報局 次回の記事>>>
Ciscoの記事
- Security 第80回「Cisco Secure Endpoint 主要な脅威検知エンジンについて」
- Collaboration 第147回 「Webex Calling のご紹介 その1~ 概要紹介 ~」
- Meraki 第153回「Secure Connect Reserved IPオプションついて」
- Security 第79回「Cisco Secure Client Cloud Managementのご利用の流れ」
- Meraki 第152回「Meraki Subscriptionライセンスについて」
- Collaboration 第146回 「高品質な音声体験を実現するCisco Webex の生成AI技術 ~Webex AI Codec~」