Meraki ダッシュボードには様々なログを確認するページが含まれています。これは Meraki の売りでもあります。ダッシュボードに備わっているデータを他の機器で閲覧しようとすると、複数のサーバを立てなければいけません。トラフィック分析のためには NetFlow サーバ、ロケーション分析のためには Connected Mobile Experience (CMX)、イベントログのためには syslog サーバや simple network management protocol (SNMP) サーバが必要になります。そんな各種ログですが、日本語ではまとまったページがどこにも存在しません。Aaron Willette がそれらのログを英語でまとめている記事がありますが、その日本語版あっても便利なのではないかと思い、作成することにしました。Willete の許可を頂いています。 概要 下表に Meraki ダッシュボードで確認できるログの簡単な説明、保存期間、エクスポート形式をまとめました。 種類 説明 保存期間 エクスポート形式 クライアント情報 特定のクライアントがどのようなトラフィックをどのくらい生成したか表示 ３０日 CSV XML トラフィック分析 検出したトラフィックの詳細 (宛先、ポート番号、プロトコル、セッション数等) を表示 ３０日 CSV サマリーレポート オーガナイゼーションの総合的な情報を表示 ６ヶ月 XLSX メール ロケーションヒートマップ フロアマップのどこが混雑しているのか表示 ６ヶ月 ✖️ ロケーション分析 アクセスポイントが検知した端末の数、その場に滞在した時間、リピート率を表示 １年 CSV イベントログ 各 Meraki … Continue reading Meraki ダッシュボードの各種ログとその保存期間 →

Meraki は複雑化された information technology (IT) をシンプルにしようというコンセプトで製品が開発されています。シンプルにしようと言っても色々な方法がありますが、端末を削減することによって IT インフラをスリム化し、管理を簡易化することが可能です。そのソリューションの一つとして、Meraki MR を導入すれば外部サーバなしで 802.1X 認証を実現できる機能があります。これを実現するためには 2 通りの方法があります。 Sentry Wi-Fi を使用し、EAP Transport Layer Security (EAP-TLS) で認証 Meraki 認証を使用し、Protected Extensible Authentication Protocol (EAP-PEAP) で認証 サーバなしで 802.1X 認証を実現するために Meraki 独特のプロトコルを使用しているわけでもなく、Meraki のクラウドに存在する radius サーバを使用し EAP-PEAP もしくは EAP-TLS を実現します。ただし、Meraki のクラウドに存在する radius サーバを使用するので、インターネット断発生時には使用できないのは注意しなければなりません。 Sentry Wi-Fi システムズマネージャーを Meraki MR と一緒に導入すれば、一番セキュアな認証方式で無線に端末を接続させることができます。これは Meraki 独特なソリューションとなっていて、Sentry Wi-Fi と呼ばれています。証明書認証は radius … Continue reading Meraki MR で Radius サーバなしで 802.1X 認証を実現 →

Meraki MR にはほとんどの型番に Bluetooth Low Energy (BLE) のラジオが備わっています。MR20 と MR70 はエントリーモデルとなっているため、このラジオは付いていません。BLE はアプリ開発のために使用されます。Meraki のダッシュボードではこの BLE の機能を有効にする事ができ、各 MR に固有の major 値 と minor 値を自動で設定する事ができます。しかし、問題なのは 0 も自動で振られる数字に含まれてしまう事です。BLE の世界でも 0 は特別な意味を持つ事があり、any と解釈するアプリも存在します。よって、major 値 と minor 値で 0 を避けるのが一般的です。Meraki では全て自動で固有な major 値と minor 値を配るか、全て同じの major 値と minor 値を配るの 2 肢しかないので、「Meraki で 0 を避ける方法はないのか。」とお客さんから聞かれた事があります。これが理由で Meraki の MR が採用されないのは心苦しいので、回避策を模索しました。 Major 値と minor … Continue reading Meraki MR の BLE で major 0 minor 0 を避ける方法 →

単刀直入に言うと、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 アドレス認証 →