単刀直入に言うと、Meraki を導入したいと考えているのであれば、Meraki の機器がダッシュボードとやりとりする通信 (管理トラフィック) はプロキシサーバを通らなくてもインターネットへアクセスできるよう、ファイアーウォール (FW) の設定を変更することを推奨します。もちろんプロキシを通して使用することもできますが、プロキシを使用した時の制限事項により Meraki の良さが半減してしまいます。 プロキシ環境 Explicit プロキシを導入している多くの企業では、プロキシサーバの送信元 IP アドレスのみインターネットへのアクセスを許可する制限が FW に設定されているはずです。このような設定をすれば、直接インターネットにアクセスしようとするクライアントは自分自身の IP アドレスでインターネットにアクセスしようとするので、FW が通信を遮断します。Yahoo! JAPAN にアクセスしたいクライアントを例にこの動作を考えてみましょう。 クライアントの IP アドレスを 192.168.0.1、プロキシサーバを 10.0.0.100、Yahoo! Japan を 182.22.59.229 とします。なお、FW ではプロキシサーバの IP である 10.0.0.100 のみ許可し、それ以外は拒否しています。図の上の矢印のように、クライアントが Yahoo! JAPAN へ直接アクセスを試みると、FW に到達するパケットの送信元 IP は 192.168.0.1 になるので、FW で設定されたルールに基づいてパケットを落とします。逆に図の下の矢印のようにプロキシを経由すれば、クライアントが送信したパケットの送信元 IP はプロキシサーバの IP に書き換えられるので、FW のルール番号 1 に基づき許可され、クライアントは Yahoo! JAPAN にアクセスすることができます。 推奨設定 さて、このような環境で … Continue reading プロキシ環境下で Meraki を導入することはおすすめできない →

Meraki MR では media access control (MAC) アドレス認証「もどき」を実現することができます。Cisco の Wireless LAN Controller (WLC) では MAC アドレスをデータベースに登録し、service set ID (SSID) の画面で mac filtering を設定しますが、Meraki ではスプラッシュページとグループポリシーという仕組みを利用します。 セキュアではない ただし、実現できるからといって推奨するわけではありません。MAC アドレス認証はセキュアではないので、使用するべきではありません。使用する場合は access control list (ACL) でインターネット接続を防ぎ、レイヤ 2 よりも上のレイヤのプロトコルで通信を暗号化するべきです。詳しくはこの記事を確認してください。 また、Meraki の公式ドキュメントではホワイトリストでの手順を紹介していますが、ホワイトリストに追加するとその端末は外部も内部もアクセスできてしまいます。ホワイトリストを使用せずに、グループポリシーで許可する通信先のみを定義し、セグメンテーションをしっかりと実施してください。 設定手順 今回はグループポリシー内の Layer 3 ファイアーウォールにてセグメンテーションを実施し、同ポリシー内でスプラッシュページをバイパスする設定で MAC アドレス認証を実現させます。設定手順は下記の通りです。 1. SSID を作成 ワイヤレス > SSID にて、SSID を新規に作成します。今回は se-japan-mac という名前にしました。 次に「設定の変更」から SSID … Continue reading Meraki MR + グループポリシーで実現する MAC アドレス認証 →

O365 等のクラウドサービスが増え、拠点側の全トラフィックがデータセンタ (DC) を通過するネットワークアーキテクチャが破たんしつつあります。DC からインターネットへ抜けるための FW もしくは回線がボトルネックとなり、ユーザから O365 が「遅い」「接続が切れる」と言った苦情が相次いでいます。これを解決するために、各ベンダはクラウド通信を拠点側から「抜く」機能をルータもしくはファイアウォールに実装しました。この機能の呼び方は様々ですが、ローカルブレイクアウトやダイレクトインターネットアクセスと呼ばれています。ほとんどのベンダーがこの機能を実装していますが、Meraki MX 以外の製品は言葉通りトラフィックをただ単に「抜く」だけで、拠点側のセキュリティを担保していません。拠点側のブラックボックス化を防ぎ、ローカルブレイクアウト機能、ファイアーウォール機能、VPN 機能をワンボックスで提供しているのは MX のみです。 既存ネットワークアーキテクチャの問題 MX を既存ネットワークに導入すれば問題は発生しないのですが、O365 をそのまま導入するとどのような問題が発生するか説明します。既存ネットワークにそのまま導入すると、下の画像の通り O365 へのアクセスは本社もしくは DC を経由することになります。 拠点側の端末が O365 へアクセスしたい場合、パケットは拠点と DC を繋ぐ回線を通過し、DC に設置されている各種セキュリティ製品でポリシーに準拠しているか確認され、インターネットへ抜けます。今日では拠点側のセキュリティを DC 側で担保している場合がほとんどなので、全てのトラフィックは DC を通過しなくてはいけません。なので、拠点側のデバイスが直接インターネットへと抜ける事はタブー中のタブーなのです。ですが、DC を中心としたアーキテクチャではインターネットの依存度が高いネットワークの要件を満たすことができず、下の画像の箇所で問題が発生します。 クラウドアクセスのパフォーマンス不足 拠点から DC へのネットワーク帯域不足 ローカルブレイクアウトを実現するための管理・セキュリティ機能不足 ネットワークがブラックボックス化 ボトルネックとなっている回線や FW をアップグレードすればいいのかもしれませんが、それはコストの観点から現実的ではありません。グローバル企業になるとそれをサポートする FW の価格は億を超えることもあります。コストを抑えつつ ① から ④ の問題をワンボックスで解決できるのは MX だけです。 Meraki MX を利用した解決策 下の画像のように MX … Continue reading O365 (ローカルブレイクアウト) なら Meraki MX →

MS は他の Meraki の製品よりも機能の違いが分かりにくいと感じます。また、SFP やスタックケーブル等のアクセサリの種類も豊富なので、多くの人が MS の型番の見方に苦悩しているのではないでしょうか。Cisco Catalyst よりも勝る部分があるのにも関わらず、なんだか分からないという理由で考慮されないのは非常に勿体無いです。より様々なところで MS が使用されることを願い、この記事ではどのように最適なモデルを選定すればいいのか紹介します。 機能 Cisco Catalyst に L2 や L3 があるように、Meraki にも L2 や L3 スイッチが存在します。しかし、モデルによって一部の L3 機能しか対応していないこともあるので注意が必要です。MS のモデルは以下の機能が必要かで 99% 決まります。 UPoEスタック冗長電源10G (ファイバー) アップリンクmGig (銅線 10G)スタティックルーティングダイナミックルーティング (OSPF) 上記の中で UPoE は注意が必要です。なぜならば、公式ドキュメントには MS350-24X と MS355 が UPoE に対応していると記載があるが、実際に対応しているのは MS390 のみとなります。 各モデルが対応している機能を表にまとめると下記のようになります。MS450 で設定できるスタティックルートの数は現在不明です。判明次第更新します。 モデルUPoEスタック10G冗長電源mGigスタティッルーティングOSPF40G100GMS120✖️✖️✖️✖️✖️✖️✖️✖️✖️MS125✖️✖️◯✖️✖️✖️✖️✖️✖️MS210✖️◯✖️✖️✖️16✖️✖️✖️MS225✖️◯◯✖️✖️16✖️✖️✖️MS250✖️◯◯◯✖️256◯✖️✖️MS350✖️◯◯◯△24X のみ256◯✖️✖️MS355✖️◯◯◯◯256◯◯✖️MS390◯◯△MA-MOD-4/8X10G◯△X/X2 のみ?◯△MA-MOD-2X40G✖️MS410✖️◯◯◯✖️256◯✖️✖️MS425✖️◯◯◯✖️256◯◯✖️MS450✖️◯△CVR-QSFP-SFP10G◯✖️?◯◯◯モデルUPoEスタック10G冗長電源mGigスタティッルーティングOSPF40G100G アクセサリ MS のアクセサリも少し癖があります。MS210 より上位のモデルがスタック可能となりますが、スタッキングケーブルが付属するのは … Continue reading Meraki MS のモデル選び方 →