RT-AC1200HP 使ってみました。

モニターに当選したのでRT-AC1200HP で遊んでみた。

ゲストネットワーク機能を試したいと言いながら、モニタリング機能のほうが興味深々だったので主にそちらを。

f:id:paihu:20170625221849j:plainf:id:paihu:20170625221901j:plain 青く×字に光るのがかっこいい。

使用感、普通に使う分には全く問題ない感じです。ロフトがあるのですが、床に置いておいても ロフト上でも問題なく使えています。

機能とか

個人的に便利だなぁと思ったところだけ。

  • ゲストネットワークが2.4G、5Gともに3つも作れる。個々にイントラネットへのアクセス許可/拒否設定を行ったり、個々に有効期限を決めたりできる。
    有効期限を決められるのが便利で、来客後、消し忘れるみたいなことがないです。 f:id:paihu:20170712211542p:plain
  • Firewall 機能として、一般的なIPaddress,portによるもののほか、HTTPに限ってはURLやキーワードでフィルタリングできる
  • ルータから ping,traceroute,nslookupが実行できる。
    何気に時々これは便利で、PC側の問題なのか、そもそもNW側が悪いのか、みたいな切り分けがしやすいです。

トラフィックモニタリング(本題)

まず、管理画面に複数個所からログインすると、 先行ログインした方のセッションが切れます。

一般家庭向けだし、それが安全だよねという気はしますが、こっちで(全画面で)グラフ表示させつつ、 別のところでちょっと設定いじろうとするとグラフが…… となるのが悲しいところ。

今回、主にトラフィックモニタリング機能を見てみたくて触っていたのですが、

  • リアルタイムデータはホントにリアルタイムに取得してきたデータを表示するもので、 開いた時点以降のデータしか表示されません。
  • 時間、日データについては、ルータの電源off/on でデータが消えてしまいます。 内部に静的に保持する仕組みではないみたい。
  • WANトラフィックと有線+無線 トラフィックの合計が一致しない。 有線接続PCでWebアクセスすると、WANトラフィックにどーんと出ますが、有線のほうには全然でない。 これは理由がよくわからない。f:id:paihu:20170712205635p:plainf:id:paihu:20170712205640p:plain なお、無線ではちゃんと想定した感じに出ている。 f:id:paihu:20170712230745p:plainf:id:paihu:20170712230753p:plain
  • トラフィックグラフ中をクリックするとクリックした時点での時間とか数値がポイントできるんですが、 時間とともにグラフは動いていきますが、クリックした点の物理的なx軸位置は変わらないので、なんだか微妙な感じに。 (y軸方向は、スケールが変わるとちゃんと移動する) それが良いみたいなときもあるのかもしれませんが、残念な感じでした。 f:id:paihu:20170712205857p:plain

リアルタイムデータを取得している部分から、定期的にデータを拾って手元PCとかに静的ファイルとして貯めればいいかなと思いましたが、 前述の、複数個所からログインすると先行ログインした方のセッションが切れる。という問題があって辛い感じです。

トラフィックモニタリングは、ついでにSNMPに対応してくれればなぁという感じでした。 中身linuxなのでsnmpデーモン入れて設定画面作ればなんとかなりそうな感じですし。

最近の新しい Google Chrome にストア以外から拡張をインストールする

はじめに

Google Chrome では、ストア以外から拡張をインストールすると、次回起動時に無効化されてしまいます。

(開発者モードでパッケージ化する前の状態の拡張をインストールすると、次回起動時でも有効になりますが、 起動のたびに開発者モードがonになってますよとポップアップで警告してくれます。)

社内で使うために手元で作ってるのに、登録してストアからインストールするのもつらいよなぁ (個人アカウントは使いたくない、会社用にアカウントを作るのは社内手続きが面倒)

みたいな状態だったので、なんとかしたいと調べてみた感じのことを書こうと思います。

本題

  1. なにはともあれ、拡張を作らないと始まらないので作りましょう。
  2. 作ったらパッケージ化します。
  3. パッケージ化したのをインストールしてappIDを確認しておきます。(パッケージ化前とはID変わります、バージョンアップのために鍵はなくさないようにしましょう)
  4. 拡張インストール用XMLを作成します。
  5. グループポリシを利用してレジストリに書きます。

以上で次回Google Chrome起動時に自動で拡張がインストールされ、使えるようになります。(アンインストールや無効化できません)

拡張インストール用XMLの作成

Autoupdating - Google Chrome

拡張インストール用XMLというよりは、拡張の自動アップデート用XMLなんですが、

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
    <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' />
  </app>
</gupdate>

調べておいたappIDを入力します、 codebase には、拡張の場所を記載します。 “c:\temp\xxx.crx” みたいなローカルパスも書けます。バージョンは実際の拡張(crxのmanifest)に書いてあるバージョンにしましょう。

レジストリへの記載

Policy List - The Chromium Projects

パスは HKLM\Software\Policies\Google\Chrome\extensioninstallforcelist です。 プロパティ名 1 とか 2 とかで REG_SZ なものに “appid;pat/to/xml” のような形で記載します。 ここでの path/to/xml についても c:\temp\xxx.xml みたいなローカルパスが指定できます。

デバイス用の Chrome ポリシーを設定する - Chrome for business and education ヘルプ こちらを参考にポリシーテンプレートをインストールしてActiveDirectoryなどを利用してレジストリ設定値をpush配信するほうが楽ですし、書き換えられてもログイン時に設定を強制できるので良いかと思います。

運用的な

XMLと拡張を何らかの管理ツールで各PCにpush配信するなり、Webサーバを用意して置くなりしましょう。

バージョンアップしたいときはXMLファイルを書き換えて再度 pushするなりWebサーバに配置するなりすれば、勝手にバージョンアップしてくれます。

終わりに

Firefox のWeb Extension APIはpromise対応していたりするのに Chrome のWeb Extension APIはpromise非対応な感じだったりしてつらいです。

この方法、個人のPCでも当然行えるので、オレオレ拡張を自分が使うだけなら有効だったりします。

ルータのDHCPサーバ性能

先日、ちょっとYAMAHAのルータを利用していて、DHCPサーバが死ぬということが起きました。

一斉にクライアントから再接続しに行ったところ、接続できなくなり、 確認してみたらDHCPでした、という感じです。

dhcpperfというDHCPの性能を測るツールを公開してくださっているので、 これを機会に調べてみたところです。

YAMAHAのルータ自体は、クリティカルなわけでもない箇所でDHCP/NAT箱として利用しているだけでしたので、 置き換えを検討しながら、いっそ仮想ルータに置き換えてしまっても問題ないのでは? ということで SEIL/x86VyOSDHCP性能も調べてみたところです。

仮想マシンは、AMD A10-7800 Windows10上のVMwareWorkstation上ですので、 もっと性能のいいサーバマシン上ではもう少し出るかもしれません。

結果だけ書いてしまうと

機器 性能 request/sec
RTX 3500 7, 8
SEIL/x86 96
VyOS 113

というところでした。 YAMAHAルータの圧倒的な性能のなさが見せつけられました。 CPU bound な処理だろうから、クロックの低いルータのCPUではつらいという感じでしょうか

計測には dhcpperf -v を用い、何も特殊なことはしていません。

DHCP pool は 172.16.0.0/16 を基準としています ただし、 SEIL/x86は pool の最大が 1021でしたので、 1021で計測しています。 計測中の状況を見るとに、SEIL/x86は clientのreleaseに応じてちゃんと解放しているようでしたので、 ちゃんと計測できているのではないかと思います。 VyOSの場合、clientのreleaseが来ても、どうも1日くらい(?)解放しないようで、poolサイズを小さくすると、 poolが尽きて応答が高速になるという現象に遭遇しました。

とりあえず3種比べてみましたが、手元に転がっているCisco Routerでも調べてみる予定です。

それはそうと、120秒間、100リクエストが来続けるとか、どんな環境でしょうね。 12000台のクライアントが2分の間に接続してくるような環境……