メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その3)

Lyra mini に関するエントリーの第三弾。

実際に主となる方を書斎代わりの部屋に、従となるほうをキッチンに置いて使ってみているわけですが、 iPhone つないで使っている限りでは、家の中どこにいてもちゃんと繋がってくれるようになったな、というぐらいの感想しかない、というのが正直なところ。
実際、どのぐらいのパフォーマンスが出るのかは、ちゃんと測定してみたいと思います。

[From メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その2) - Soukaku's HENA-CHOKO Blog]

前回の予告とおり、トラフィック測定してみましたので、その結果など。

測定の方法と機材について

さて、どうやってトラフィック測定しようか、と考えたときに「サイズの大きなファイルのダウンロードでいいかな?」と思いつついろいろ調べてみたところ、「Linux( Debian )動かしているノート PC もサーバもあるんだし、 iperf 使うのがいいじゃね?」ということで、iperf3 を使うことに。

iPerf3 is a tool for active measurements of the maximum achievable bandwidth on IP networks. It supports tuning of various parameters related to timing, buffers and protocols (TCP, UDP, SCTP with IPv4 and IPv6).

[From iPerf - The TCP, UDP and SCTP network bandwidth measurement tool]

Debian であれば、root 権限で

# apt install iperf3

を実行すれば、インストール完了。
測定も、サーバ側で

$ iperf3 -s

クライアント側で

$ iperf3 -c サーバのIP

と実行すれば、OK。この場合は、クライアント→サーバの測定になりますが、 -R オプションを付けると サーバ→クライアントの測定ができるので(実際の測定時には、少しオプション付きで実行してますが。)

nsd でセカンダリDNSを構成しなおす

unbound でセカンダリ DNS を構築したものの、

今回の例だと、unbound 自身はほんと最低限の動けばいいレベルでしか設定していないので、実運用時はもう少し考える必要があるので、ご注意を。

[From unboundをbind9のスレーブとして設定してみる - Soukaku's HENA-CHOKO Blog]

設定面に不安もあったし、「なんで unbound なの?オープリゾルバにしたいの?」といったご指摘も頂いたので、いろいろ調べ直して、 nsd をセカンダリとして使うように構成を変更たので、そのメモ。

nsd は

NSD (Name Server Daemon) は高性能で簡単なオープンソースの権威ネームサーバです。

[From NSD 4 – 日本Unboundユーザー会]

と謳い文句にある通り、DNS コンテンツサーバに特化している DNS サーバの実装の一つです。

インストールと基本的な設定

インストールするのは、 unbound をスレーブとして設定した自宅側のサーバ。

HomeNetwork_DNS-20190121.png

これを unbound ではなく nsd に置き換える、と…。(正確には、ちょっと違うので、その点については後述。)

unboundをbind9のスレーブとして設定してみる

bind9 使っている宿命というか、どうしても定期的なセキュリティアップデートを実施しないといけない、というのが結構運用面での負荷になっていて、「どうしても bind でないといけないというところ以外、 unbound に切り替えてもいいのでは?」と思い始めたので、スレーブに unbound を使ってみよう、ということで設定をしてみた次第。

しばらく前から、unbound も権威サーバとして使えるということは、知ってたんですけどねぇ。

インストールと設定

うちのネットワーク的には、さくらの VPS でマスタ、自宅側サーバでスレーブという形で DNS を配置しているので、自宅側を unbound で置き換えるという形に。

/images/network

サーバは、いつもどおりの Debian で構築したものなので、 インストール自体は root で "apt install unbound" なり "aptitude install unbound" で完了。一応、-s オプションつけてシミュレーションモードで確認してみると、こんな感じ。

nexus01:~# apt -s install unbound
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
libpython3.7 libunbound8 unbound-anchor
以下のパッケージが新たにインストールされます:
libpython3.7 libunbound8 unbound unbound-anchor
アップグレード: 0 個、新規インストール: 4 個、削除: 0 個、保留: 25 個。
Inst libpython3.7 (3.7.2-1 Debian:unstable [amd64])
Inst libunbound8 (1.8.1-1+b1 Debian:unstable [amd64])
Inst unbound-anchor (1.8.1-1+b1 Debian:unstable [amd64])
Inst unbound (1.8.1-1+b1 Debian:unstable [amd64])
Conf libpython3.7 (3.7.2-1 Debian:unstable [amd64])
Conf libunbound8 (1.8.1-1+b1 Debian:unstable [amd64])
Conf unbound-anchor (1.8.1-1+b1 Debian:unstable [amd64])
Conf unbound (1.8.1-1+b1 Debian:unstable [amd64])

unbound インストールの時点は、bind9 の削除がいきなり行われたりはしないようです。(というか -s オプション効くの、初めて知った…。)

メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その2)

前回の予告どおり、まずは Lyra mini だけでメッシュネットワークを構成してみます。

「ASUS AiMesh 対応ルーターにメッシュ Wi-Fi ルーター ASUS Lyra シリーズが加わった」ということで、一緒に送られてきた RT-AC68U と Lyra mini を組み合わせてメッシュ化することも出来るのは簡単に確認してあるので、詳しくは別エントリーにて。

Lyra mini をセットアップ

セットアップに関しては、スマホアプリを使って設定する方法と、PC の Web ブラウザでアクセスして設定する方法の二通りがあるんですが、今回はアプリからやってみることに。

スマホアプリのアイコン

ASUS の場合、 Lyra シリーズ専用のアプリと それ以外も設定可能なアプリの 2 種類あるんですが、今回は専用アプリの方でやっていきます。
Lyra mini は直接インターネットではなく、下の図にある Wi-Fi AP (ここが現在 TP-LINK Deco M5 に)と並列に接続される形でセットアップしていきます。

我が家のネットワーク構成概要 2017/12/16版

ネットワークへの(物理的な)接続に関しては、同梱されている「かんたんセットアップガイド」を参考にしてネットワークに繋ぎます。
あとは、だいたい以下の順番で進めていきます。

  1. マスターにしたい Lyra の LAN ポート(AC アダプタの差込口側)に LAN ケーブルを接続し、反対側も既存ネットワークの HUB に接続する。
  2. Lyra に AC アダプタを接続し、電源を投入する。(2 台とも)
  3. 電源投入後、本体の LED が色を変えながらゆっくりと点滅を繰り返すので、白色の常時点灯になるまで待つ。
  4. スマホにダウンロードした Lyra アプリを起動する。
    • アプリは、予めダウンロードしておく。

メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その1)

Deco M5 導入より、ずっと前のこと…。
10月の終わりに、「こういうのって、なかなか当たらないよねぇ…」と思いつつ応募したキャンペーン。

すっかり応募していたことすら忘れていた12月の終わりに、「おめでとうございます!キャンペーンに当選しました!」というメールを受信しまして…。
#いや〜、応募してみるもんデスネ。

自宅内Wi-Fi環境を Deco M5 で再構築しました

最近までは 802.11a/b/n 対応の機器しかなかったので、自宅内の Wi-Fi 環境もそれに合わせて用意していたんですけど、半年ほど前に妻が iPhone8 Plus に替えたあたりから、「そろそろ 802.11ac も考えるか〜?」と思い始めてました。ただ現状でもそう不便があったわけでもないので導入に踏み切るまでには至らず、うだうだやっていたんですが…。
自分も iPhone XR に替えたことと、Amazon のサイバーマンデーセールで TP-LINK の Deco M5 の 2 台セットが安くなっていたのをポチったので、我が家もようやく 802.11ac 環境への移行を果たすことに。

単に、 802.11ac 対応するだけなら、Deco M5 のようなメッシュルーターでなくても良かったわけですが、第一に「メッシュルータ使ってみたい!」というのがあったのと、家の中でも微妙に Wi-Fi の電波受信状況が悪いところがあったのでそれも改善したかったのと、タイミング良く安くなっていた、というのがあったので、 Deco M5 になったというわけ。

ちょっと調べてみたら、Deco シリーズは M5 の上位機種としてトライバンド対応(2.4G + 5G×2)の M9 Plus と下位機種として M4 (2.4Gが300Mbpsまで)の 2 モデルが最近追加されていたのですね…。

セットアップと実際の使い心地

で、実際のセットアップに関しては、大まかには以下の通り。

  1. iPhone XR (などのスマホ)に、Deco アプリをインストール
  2. Deco アプリを起動して、 TP-LINK IDを取得
  3. 1 台目の Deco M5 に LAN ケーブルと AC アダプタを接続
  4. Deco アプリで、1 台目の Deco M5 の登録を実行し、メインの Deco として設定
    • ファームウェアのアップデートを要求されるので、アップデートしておく(これは 2 台めも同じ)
    • SSID や動作モード(ルーター or ブリッジ)の設定は、メインとなる Deco M5 に対して実行する
  5. メインの Deco M5 に接続して、Web アクセスが出来ることを確認
  6. 2 台目の Deco M5 に AC アダプタを接続
  7. Deco アプリで、 2 台目の Deco M5 を登録

Deco M5 3台(またはそれ以上)でメッシュネットワークを構成する場合は、6. と 7. を追加したい台数分の繰り返しになります。

格安MVNOに転出してまるっと1年

au から OCN モバイル ONE へ乗り換えて、1 年経過しました。

MNP の手続きの方ですが、前のエントリーを書いた翌日 10:30~10:40 の間ぐらいに、無事手続き完了して、切り替わりました。

[From MNPその後と、Wiko tommyの使い心地 - Soukaku's HENA-CHOKO Blog]

開通直後から 110 MB/日コースにしていますが、特に不満もなく使えています。スマホで帯域を必要とする事、殆どやってないのもあって、実際通信量の制限がかかるターボモード OFF のまま、ほぼ 1 年過ごしましたけど、それでも困ったことはなかったなぁ。
この 1 年の月ごとの利用量の推移は、以下の通り。

月別の利用量:2018年4月版

チャイルドフィルターを信用することが出来ない、いくつかの理由

サイバーセキュリティ財団が運営するサービスであるチャイルドフィルター、前のエントリも含めて何度か取り上げているわけですが、自分的に最も信用ならない点をまとめてみました。

チャイルドフィルターには、そもそも仕組み的な疑念点があるので、その点についても判りやすくまとめておきたいな、とは思うのですが…。

[From チャイルドフィルターとあんしんフィルター for ✕✕を比較してみた - Soukaku's HENA-CHOKO Blog]

「ソフトウェア」ではなく「サービス」である

サイバーセキュリティ財団は、チャイルドフィルターのことを「ソフトウェア」と説明しています。
しかし、実際にはソフトウェアはインストールさせることはなく、CSF が指定するVPNサーバと接続するための設定用プロファイルを読み込ませることで、 CSFの用意した VPN サーバと iPhoine/iPad の間でVPN 接続を行い、その VPN セッションを経由してプロキシーサーバを利用させる「サービス」というのが実態ですから、まずチャイルドフィルターの説明が実態と齟齬のある状態になっています。

VPN 接続であるゆえの懸念事項

VPN (Virtual Private Network) は、公衆網である Internet の上に通信路に対する暗号化を行い、擬似的な専用線接続環境を構築する技術です。外出先のネットワークを経由してノート PC から社内システムへ安全にアクセス出来るようにする、離れた拠点間でデータ送受信するのをインターネット経由で安全に行いたいといった場合に、そのノート PC と社内システムの間や拠点間の通信路の安全性を確保するために利用されることが多いものです。
実際、外出先から社内システムに接続するために VPN を利用しているという人は多いんじゃないでしょうか?

curl コマンド使って、Webサイトの挙動を確認する

年末に流れた、以下の tweet。

確かに、Google の検索結果に表示されるリンクをクリックすると、新しい URL へ転送されるので、旧サイト→新サイトへの転送は正しく設定されていることはわかるのだけど、どうやら Google などのクローラが望む形での転送設定ではないようなので、どうなっているのかを調べてみた。
サイト自体は10月までに新しい URL に移行しているそうで、

未だに旧サイトしか検索結果に上がってこないのは如何なものか、という事もあったりするんですけど。

こういう時、Web ブラウザだけでは挙動を追いきれないので、自分は curl コマンドを使って確認することがほとんど。
curl コマンドは、URL 形式で表現( http://〜 や ftp://〜 のような表記のやつ)されるサーバのロケーションへのアクセスしてデータを取得するためのものなのだけど、単純にデータを取ってくるだけ以外の用途でも使えるので、今回は Web サイトの挙動をチェックする際の使い方に絞って、簡単に解説してみる。

まずは、手始めに Web アクセスした時のクライアントからのリクエストの内容と、それに対して返ってくるサーバからのレスポンスの内容をチェックする方法。
これは、 -v オプションを付けて curl を実行すれば OK。

soukaku@vhost01:[~]$ curl -v http://law.e-gov.go.jp/htmldata/H11/H11HO042.html
* Trying 2400:4040:5013:b::13...
* TCP_NODELAY set
* Trying 210.232.23.44...
* TCP_NODELAY set
* Connected to law.e-gov.go.jp (210.232.23.44) port 80 (#0)
> GET /htmldata/H11/H11HO042.html HTTP/1.1
> Host: law.e-gov.go.jp
> User-Agent: curl/7.57.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: close
< Cache-Control: no-cache
< Content-Type: text/html; charset=shift_jis
< Pragma: no-cache
< Content-Length: 189
<
* Closing connection 0
<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 10052633866947281389</body></html>

行頭に ">" があるのがリクエストヘッダの内容で、"<" があるのがレスポンスヘッダ。この場合の最後の1行が、実際に Web サーバ側から送られてきたコンテンツの中身(= HTML 形式のデータ)というわけなんだけど、そこを見ると "Request Rejected" とあるので、どうも curl でアクセスすると、上手くアクセスがが出来ないようにサーバ側が設定されているっぽい。

VyOS を Rolling Version へとアップデート

VyOS を Rolling Version へとバージョンアップしてみた。
Rolling Verison は、いわゆる開発版、ベータ版とも言えるもので、現行の安定版が Debian squeeze ベースなのに対して jessie がベースになっているため、カーネル含めて色々新しくなっているし、 Debian パッケージを持ってきて機能を追加したい時にも新しいものが使えるというのもありがたいところ。

アップデートすること自体は、それほど難しいことではなく、公式サイトの Wiki に記載されている通りにやれば、既存設定の引継ぎも自動的に行われるので、ISO ファイルのダウンロード時間+αの時間で完了。

ただ、今回は単純に旧バージョンの設定を引き継いだ状態では PPPoE セッションが正しく張られないというのにハマりまして、色々調べてみた結果、PPPoE のセッション自体に固定的に割り当ててた IP アドレスの設定を削除してみたところ、上手く繋がった次第。

旧バージョン時代の設定を比較した(抜粋)のが、以下のもの。

--- /lib/live/mount/persistence/boot/VyOS-1.1.8/live-rw/config/config.boot      2017-12-29 00:30:09.499208506 +0900
+++ /config/config.boot 2017-12-29 03:32:47.239589856 +0900
<<中略>>
@@ -134,17 +134,17 @@
hw-id xx:xx:xx:xx:xx:xx
pppoe 0 {
default-route auto
- local-address 218.219.149.233
mtu 1492
name-server auto
password **********
service-name editnet
user-id ********@218.219.149.232@edit.ne.jp
}
- smp_affinity auto
+ smp-affinity auto
speed auto
}
- loopback lo
+ loopback lo {
+ }
tunnel tun0 {
address 2001:470:23:94::2/64
description "HE.NET IPv6 Tunnel"
<<後略>>

んと、"local-address" の 1 行の有無だもんなぁ。(他にも差分出ているけど、バージョン変わったことで自動的に変更されたところだけど、VyOS 動作自体には影響しない部分。)