Googleスピードテスト
ブラウザを用いた Google によるインターネット速度テストの結果。契約自体は、丹南ケーブルテレビの nextr 2Gbps だけど、こんなもんでしょ…。(^^;
2018-06-06 職場より激速だった。
EdgeRouter-X Firmware v1.10.3
自宅サーバの EdgeRouter ER-X の最新ファームが5/14に出ていた。
ということで、早速適用。職場の昼休みなのでリモート接続越しなんだけど、なかなか無謀だよな。あんど、無事に接続できることを確認。接続時に確認のメールを出すための設定ファイルを書き込んで、無事更新完了。
IPv6パススルーをOFF
自宅内では、外部とはつながっていないけど、IPv6 の管理を行っていて、それなりにうまく動いていると思っていた。(自宅内のみの、IPv6 DNS , DHCPv6 , ssh) しかし、久々に持ち帰った PC が、自宅サーバに繋がらない。原因は、根っこの自宅ルータが、IPv6 機能を持っていて RA 情報を流してくれるため、DHCPv6 を動かしているのに無視されている。
根っこのルータの配下につながっている、Buffalo のルータの IPv6 パススルーの設定をOFF にした。これで、自宅サーバの DHCPv6 情報を使ってくれるようになった。
MauiBotって何?
何気なく、webalizer の結果を確認していたら、/wp/wp-json/oembed/1.0/embed のアクセスが急増している。MauiBot なる crawler も急増。関係あるのかな。
FA:8F:CA:XX:XX:XXはGoogle Homeのゲストモード用
WiFi中継器を置いても子供から無線LANに繋がりにくいとの指摘で、自宅WiFiを調べていたら、得体のしれないMACアドレス「FA:8F:CA:XX:XX:XX」が見える。MACアドレス検索をしても該当するものはない。試しに自宅WiFiのチャンネルを切り替えたら追従してくる。(粘着かっ!)
あまりにもストーカーっぽいものを仕掛けられたかと心配になったけど、普通にGoogleでFA:8F:CAと検索をかけたら、Google Home Mini のゲストモードが原因との情報がでてくる。オープン接続なのも不気味だし、来客にGoogle Home触られるのも不気味(そもそも来客来ないけど)なので、携帯のGoogle Homeアプリにて、ゲストモードを止めてみた。
でも、Google さんも、FA:8F:CA をVendor リストに入れておいてほしいよな…と思ったけど、MACアドレスにもローカルアドレスってあるんだな。先頭オクテットが0x02のビットが立ってると、ローカルなのか。
うーん、ゲストモードをオフにしても、2.4GHz帯のが消えないんだけど…。
WiFi中継機を設置
奥さんに「1階でWiFi取れない…」と言われ、auのhomespot入れてたけど、ファーム更新対象外になっててしかも2階のWiFiルータと相性があんまり良くなかった。
WEX-733Dを購入</h3
ということで、2FのWiFiルータと同じBuffaloで、WiFi中継機WEX733Dを、Amazonの中古品で購入。
ただ、親機のWiFiルータはステルス設定をしているから、繋がらず四苦八苦。一時的にANY接続許可にして設定していたら、中継機のMACアドレスの一部変更された機器を見つけ、ようやく設定のキモが見えてきた。
仕組みが見えてきたので、改めてステルス設定に戻すことができた。
親機のMACアドレスの整理
WEX733Dのステルス設定では、MACアドレスが20台しか登録できない。しかし、親機の登録MACアドレスをみると、30台超え。といっても、それぞれの機器が「何だっけ?」状態で、ほったらかしだったので、改めて1台1台機器を調べて使われていない機器とか、1Fで使わない機器を消して大掃除となった。
postfix,dovecotのSSL化
子供の進学で自宅を離れ、出先でも自宅サーバにメールの読み書きがあれば、様子を伺えるんだけど、自宅サーバのメール関連のSSL化が不完全だったので、子供の引っ越し先に泊まった際に見直し。
すでに、dehydrated を Web サーバで導入済みなので、それを postfix , dovecot に利用させるだけなんだけど、一度失敗してたのでリトライ。
((/etc/apache2/site-enable/010-default-ssl.conf)) - SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem - SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key - SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt + SSLCertificateFile /var/lib/dehydrated/certs/MYDOMAIN/cert.pem + SSLCertificateKeyFile /var/lib/dehydrated/certs/MYDOMAIN/privkey.pem + SSLCertificateChainFile /var/lib/dehydrated/certs/MYDOMAIN/chain.pem ((/etc/postfix/main.cf)) - smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem - smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key + smtpd_tls_cert_file=/var/lib/dehydrated/certs/MYDOMAIN/cert.pem + smtpd_tls_key_file=/var/lib/dehydrated/certs/MYDOMAIN/privkey.pem ((/etc/dovecot/conf.d/10-ssl.conf)) - ssl_cert = </etc/ssl/certs/ssl-cert-snakeoil.pem - ssl_key = </etc/ssl/private/ssl-cert-snakeoil.key + ssl_cert = </var/lib/dehydrated/certs/MYDOMAIN/cert.pem + ssl_key = </var/lib/dehydrated/certs/MYDOMAIN/privkey.pem
これで、メールサーバのアカウント登録で、「登録されていない安全でない証明書を使うか?」といった表示もなくなるし、Windows の標準メールでも登録ができるようにできた。
Google Home mini のカレンダー機能バージョンアップ
Google Homeのカレンダー読み上げ機能、動かなかったけど、原因は「共有カレンダーはダメ」だった。
# 我が家では、家族間でカレンダーを共有かけてます。
で、しかたがないので、gcalcli + google-home-notifier で実装しようと遊んでいて、「これで完成、IFTTTと連動前に他の読み上げのキーワードと親和性のいいのは何かな…」と「OK Google, カレンダーを読んで」と命令したら、まだ IFTTT 連動していないのにカレンダーを読み上げやがった。
ということで、Google Home のカレンダー読み上げ機能、共有カレンダーでも動くようにバージョンアップされてます。
ただし、時間指定のカレンダーしか読み上げてくれません。終日イベントは無視してくれます。
標準入力をcurl経由でgoogle-home-notifierを呼び出す
上記のカレンダー読み上げをgoogle-home-notifier で呼び出すために、curl を使うスクリプトを書いた。無駄になったけど…。
((curlからgoogle-home-notiferを呼び出す方法)) $ curl -X POST -d "text=おはよう" \ http://192.168.xx.xx:8091/google-home-notifier
これだと、話す内容を引数に渡せないので、”man curl” する。
#!/bin/bash
/usr/bin/curl -X POST --data-urlencode "text@-" \
http://192.168.xx.xx:8091/google-home-notifier > /dev/null 2>&1
MoneyForward の CDN 導入トラブルか? – 解決済み
解決済み(2018/03/01加筆)
Twitterを使うという技を交えたとは言え、CDN導入に伴う参照元IPアドレス間違いの問題は、翌日3/1には対応頂けたようで、正しいアドレスが表示するようになりました。メールでの問い合わせにもきちんと報告を頂きました。(お疲れ様でした)
接続元 IP アドレスが違う(2018/02/28掲載)
銀行とかカードの状況をひとまとめに見れるということで、最近は MoneyFoward を使っている。しかし、今日ログインしたらいつも届く、「ログイン履歴」に記載されている、接続元の IP アドレスが変。
下記時刻にお客さまのアカウントにてログインが行われましたので通知いたします。
ログイン時刻:
2018/02/28 12:28:2
クライアント情報:
iOSアプリ
アクセス元IPアドレス:
43.249.72.35
loginしたらすぐに届くので、自分のパスワード情報が盗まれているというのも違うだろうし、すぐさま思いつくのは、フィッシングサイトに誘導され、間に偽装サーバが入ってる…!?!?。とはいえ、メールで送られた URL でアクセスしている訳でもないし、フィッシングも疑わしい。あるとすれば、DNSポイズニングされて、偽装サーバを介入されているというのがあるだろうけど、nslookup host 8.8.8.8 しても、同じ結果。
ということで、表示された IP アドレスや、moneyforward.com のアドレスを調べてみると、fastly.net とか fastly.com といった企業にたどり着く。この会社は、CDN(相手に合わせて近くのネットワークを使う技術)を扱っている。ということは、MoneyForward が、クラウド最適化のために CDN を導入してユーザのIPアドレスを引き間違えていると予想。
Money Forward に調査依頼
お金に絡むサービスだし、Money Forward のお問い合わせ窓口にメールを送ったんだけど、自動応答システムからの「数日のうちに返事します」が届く。うーむ。繰り返すけど、お金でフィッシングされている可能性を疑うネタは、数日待てるもんじゃない。
ということで、最も確実な手段として、Twitter の @MoneyForward に、公開の @ メッセージを送る。同様のトラブルがあってヤバイと思う人が多ければ、SNS 的に騒がれるだろうし、真っ先に対応してくれるだろう。