proxyサーバヒット率1%
以前より、自宅内のCache Proxyサーバって、ヒット率低いのはわかっていたけど、一応動かしていたSquid。これまた気まぐれに cache のヒット率確認したら、1%。意味ないね。
自分しか使ってないだろうと、これまた気まぐれにばっさりと、aptitude purge squid したら、子供と奥さんが「ネット切れた」と駆け込んできた。proxy自動設定のproxy.pacとかも置いといたので、想定外に使ってたのね。
ということで、家族に「proxy はずしてね」と伝え、proxy.pac を、return “DIRECT”; に修正しておく。
EdgeRouter-X v2.0.9 をインストール
Edgerouter-X の新しいファームウェア ver 2.0.9 が 11/19 に公開されていた。
v.2.0.9 インストール
EdgeRouter-ERX は、HDD? 領域が不足しているので、インストール前に古いバージョンのイメージファイルを消す必要がある。
$ slogin ubnt@edgerouterx ubnt:~# delete system image
EdgeRouter の管理画面を開き、v2.0.9 をインストール
v2.0.9の新機能
リリースノートを見ると、
CLI - Add new CLI command "add system image" to automatically download and install latest stable firmware.
と書いてあるので、今後は firmware 更新作業は、以下の様にするだけ…ということかな。便利。、
$ slogin ubnt@edgerouterx
ubnt:~$ sudo add system image ubnt:~$ sudo bash
ubnt:~# add system image
再起動 自作の l2tpd 接続通知の設定ファイルのインストール
$ scp /...../edgeos_ubnt_20180914-notify-l2tpd.tar.gz ubnt@edgerouterx $ slogin ubnt@edgerouterx ubnt:~$ sudo bash ubnt:~# cd / ubnt:~# tar zxvf ~ubnt/edgeos_ubnt_20180914-notify-l2tpd.tar.gz
bind9でfilter-aaaaがpluginになる
自宅サーバを使っていて、raspberry-pi の更新をかけていたら、IPv6アドレスにつながらないトラブル発生。
我が家では、上流が IPv4-only だけど、自宅内の機器間のに IPv6 も使えるようにしている。このため、DNS の設定では、bind9 に、filter-aaaa-on-v4 の設定を加え、IPv4 の機器からの問い合わせには、IPv4 のみを返答することで、対応していた。
しかし、改めて “nslookup www.google.com 192.168.xx.xx” を実行したら、IPv4からの問い合わせの癖に、しっかり IPv6 が返ってきている。
調べてみると、bind9 (9.14)から filter-aaaa 機能は plugin になるみたい。んで、自宅サーバは 9.11→9.16 により filter-aaaa がoffになったのが原因…と思ったけど、syslog をみると “–enable-filter-aaaa”付きでcompileされてるし、”option ‘filter-aaaa-on-v4’ is obsolete and should be removed” と表示されてるから、現状では、まだ使えているはず。
ひとまず IPv6 オフ
ラズバイは、ひとまず下記の設定で、IPv6 をオフにしておく。
$ sudo /etc/sysctl.conf ((下記を追加)) net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 $ sudo sysctl -p
これは、IPv6 が戻ったら、元に戻そう。
bind9 に plugin の filter-aaaa 設定
plugin になったら、下記のような設定をするようだけど、うまくいかないので近日中に要対応。
$ sudo vi /etc/bind/named.conf.options plugin query "/usr/lib/x86_64-linux-gnu/named/filter-aaaa.so" { filter-aaaa-on-v4 yes ; filter-aaaa-on-v6 yes ; filter-aaaa { any ; } } ;
mineo繰越し
mineo接続、子供用3GB/月×2回線+自分のデータ通信用0.5GB/月×1回線。
遠隔授業で、自宅にいる機会が増え、WiFiが使えたもんだから、 月末にパケットを相互に移動しながら繰越しさせていたら、 3人のトータルが29GB。本来は6.5GBなんだけどね。
arpに169.254.x.xが出てくる
自宅サーバの状況を見ていたら、169.254.185.142 という IP アドレスが ARP の一覧に出てくる。
MACアドレスを見ると、設置している Raspberry-Pi と同じ。
リンクローカルアドレス
以前にも同様のエントリーが出てきたことがあったので、改めて原因をしらべると、こちらに該当すると思われる解説記事。
DHCPの異常で、アドレスが得られない時に、暫定で割り振るIPアドレスみたい。その他の原因も考えられると説明があるが、実際数日間に DHCP の設定を触っていたから、出てきてもしかたがないかな。
間違ったARPエントリを消す
“arp -d 169.254.x.x”で、エントリーを消そうと思うがうまく消えてくれない。深く考えてもキリがないので、夜中にサーバの再起動させよう。
うまく消えないので、色々調べながら、以下のコマンドで消せた。
“ip -4 neigh del 169.254.x.x lladdr yy:yy:yy:yy:yy:yy dev eth0″
Apple WatchのProxyダメだな
最近、少しでもキャッシュの効果が出ることもあるかと、squid のキャッシュproxyを動かしていた。
また、自宅内アクセス時に、proxyがかかると、不都合もあったので proxy.pac の自動設定を設定したけど、その頃からApple Watchの天気のコンプリケーションが表示されなくなった。
どうもproxy.pacをうまく処理できないのか現在地情報がとれないようで、天気情報が出てこない。
ということで、iPhoneでApple Watch使うなら、proxyは使っちゃダメだな。
WiFi中継機WEM-1266の増設
気まぐれの1Fのネットワーク環境の改善ということで、WiFi中継器 WEM-1266 を増設してみた。
今までは、WiFi中継器 WEX733D を使っていたが、動作が不安定だし、WEX733Dの先のHUB配下の機器の MAC アドレスが正しく取得できないので、DHCPでMACアドレスにあわせたIPアドレス配布に失敗していた(このため固定IP設定していた)が、WEM1266であれば問題ナシ。
Google Home セットアップ中はiPhoneのProxyはオフ
Google Home アプリの設定を確認していたら、ファームウェアの更新みたいな表示が出たので Google Home mini の初期化(本体裏のスイッチ長押し)を行う。
# たぶん、これもproxy経由が原因だったんだろうな。
Google Home 初期化に失敗
普通に初期化を行うが、最終段階でエラーの表示で「…セットアップされているようですが、iPhoneからの通信に応答しませんでした。Google Home mini と iPhone が相互に通信出来ないネットワークに接続されている可能性があります…」といったエラーが表示され、初期化に失敗する。いろいろと試したが、失敗するが、ふと自宅内で Squid の キャッシュProxyサーバを運用しているのを思い出した…。
Proxyをオフにしたら、無事接続成功となった。
Proxy 自動設定Scriptの適用
他にも色々と試すと、Proxy設定がONだと、iPhone から Google Home mini へのストリーミングもできなくなっている。
最終的には、iPhone の WiFi 設定で、Proxy 設定の自動化で、Proxy設定のJavaScript(proxy.pac: 同じサブネット内は Proxy を使わない)を設定となった。