- 概要
- Meraki MXのRouted Modeの特性
- Meraki MXと境界型のアクセス制御
- Meraki MXのRouting Protocol対応状況
- Meraki MXはLAN内のRouting Deviceとしての導入には不向き
- Meraki MX (Routed Mode)が適さない設計
- Meraki MXの制約を前提としたネットワーク設計
- 最後に
概要
Meraki MXには Routed Mode と Passthrough or VPN Concentrator がありますが、本記事では Routed Mode に焦点を当てて製品特性を整理します。
Meraki MXのRouted Modeの特性
Meraki MXのRouted Modeは、Internet Firewallに分類される製品特性を備えています。 基本的にRouted Modeの場合はInternetに面しての設置が想定されており、拠点へのInternet接続用のGatewayとしての導入が適しています。
セキュリティの側面ではInternet接続用のGatewayとしての役割が大きいのが理由で、
WAN←→LAN (North-South)の通信のアクセス制御に特化しております。
表現を変えると、境界型 (Zone-based)のFirewallではないため、
システム間のようなLAN←→LAN (East-West)の通信のアクセス制御には不向きとなります。
Meraki MXと境界型のアクセス制御
Meraki MXには境界型 (Zone-based)のアクセス制御の概念がないため、Firewall Policyの制御は運用性が高くありません。
Merakiはクラウド管理型の特性でInternetへの接続を前提としておりますが、その中でもMeraki MXはInternet接続用のGatewayの側面が強いため、
どうしてもLAN←→LAN (East-West)の通信の制御には不向きになっています。
Meraki MXのLayer 3 Firewall RulesにはZoneの概念はないため、送信元アドレスや宛先アドレスをベースとしたアクセス制御になります。
Meraki MXのRouting Protocol対応状況
Meraki MXはModeと設定によってRouting Protocolの対応状況が異なります。
Merakiはクラウド管理型のため、アーキテクチャ的にInternet側に流れる管理系の通信が異常な流量にならないような設計になっております。
その中でもMeraki MXは動的ルーティングでルートのフラップが発生しにくくなるように、状態変化が少なくなるアーキテクチャになっています。
そのため、OSPFはルートの広報は出来ますが、OSPF Neighborからのルートの動的な学習ができない仕様になっていると推察されます。
Routing Protocol対応状況の中でも特に注意が必要なのが、
Routed ModeはLAN settingの設定により、OSPF (広報のみ・学習なし)の対応可否が異なる点です。
拠点によってLAN側の収容設計を変える場合は、本仕様の影響を受ける可能性があるため留意してください。
一般的なRouting & Switchの知識があるベテランほど、状態変化が少なくなるアーキテクチャにハマりやすい点があるため、下記の記事も適宜参照してください。
Meraki MXはLAN内のRouting Deviceとしての導入には不向き
Meraki MXのRouted ModeはInternet接続用のGatewayとしての機能に特化しているため、 LAN内でのRouting Deviceとしての導入には不向きとなります。
UplinkはInternetへの接続を前提としているアーキテクチャとなっているため、Uplink側でOSPFとStatic Routeは設定できません。
Static RouteはLAN側に対して設定できますが、Uplinkに対する個別のStatic Routeは設定できないので勘違いしないように注意してください。
OSPFはAuto VPN Peerからのルートを広報をしますが、OSPFによる学習は行いません。 OSPFをルートの交換ではなく、経路を一方的に広報するのに使用するイメージとなります。
Meraki MXはUplinkでSource NATを行うため、LAN内のアドレスは隠蔽されます。
BETA機能 (2022年03月頃)のNAT Exceptions / No NATでSource NATの無効化は行えますが、
Internet接続用のGatewayは送信元NATがあってこそ成り立つため、Meraki MXの製品特性が瓦解しかねません。
その一例として、UplinkのWAN1とWAN2を用いたWAN負荷分散の機能は、
送信元NATを行って同じ出力Interface (WAN1,WAN2)に確実に通信が戻ってくるようにして成り立っています。
Meraki MX (Routed Mode)が適さない設計
Meraki MXで LAN setting を VLANs にして、多数のVLAN且つ1 Hop越えのセグメントを収容するのは不向きになります。
何故なら動的ルーティングの制御が弱いため、Meraki MX配下のL3 Deviceに対して多数のStatic Routeを設定する必要があるためです。
そして、Meraki MXのVLANs設定ではOSPF (広報のみ・学習なし)を設定できませんし。Meraki MXの配下のOSPF Router同士は、Meraki MXが介在してのOSPFでの経路交換も行えません。
Meraki MXの制約を前提としたネットワーク設計
Meraki MXで多数のVLANやセグメントを収容するは難しいため、 1 Hop越えのセグメントを収容する場合は、通信を通過 (Transit)させるためのTransit VLANを1つ作成して、配下のMS (L3SW)にGatewayを一任するのが現実的です。
明確な設計意図があるなら、Transit VLANをサービス系と管理系で2つで分けるなども良いかとは思います。
ただし、Tagged VLANを使用するために、LAN setting を VLANs にするとOSPF (広報のみ・学習なし)は使用できない点に留意してください。
MerakiのMXとMS (L3SW)のLayer 3 Topologyの情報に関しては、下記のドキュメントに記載があります。
MS (L3SW)がEndpointのGatewayとなると、Meraki MXのFirewall Policyによるアクセス制御は行えないのが欠点になりますが、 そもそもMeraki MXはLAN←→LAN (East-West)のアクセス制御が不向きである点を思い出してください。
上述の内容は、あくまでも「1 Hop越えのセグメントを収容する場合」であるため、 MS (L2SW)のLayer 2 TopologyにてMeraki MXで多数のVLANやセグメントを収容するのは、管理性や運用性に問題が出なければそれも1つの設計方法だとは思います。
最後に
Merakiは機能が限定されていてシンプルが故に、設計箇所が限定されるため素早く大量展開を行いやすいのが利点です。
逆にシンプルさ故に多機能さによる設計のリカバリはできないため、Merakiの不向きな環境に無理やりに複雑な設計で導入するのは製品特性に大きく反してしまいます。
そのため、製品が不得意とする側面を理解した上で、製品特性の長所を活かす形での導入をオススメします。
