色々と適当に
Qualys Lab ツールでテストしたところ、
h2oはB、apacheはA-となったのでapacheに戻しました。
あとipv6でのアクセスができなくなってたっぽい。
設定で同レベルにできるかもしれないが、今は詳しく調べてる時間がないので応急処置。
追記：
apacheと同レベルのA-にする設定があったので適用してh2oに戻しました。
sslの設定に以下を追加、
cipher-suite: AES128-SHA:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:MEDIUM:!aNULL:!MD5:!RC4
ipv6が機能していなかったのは ipv4 の host のみ設定していたため。
バインドするインターフェースを制限する意味がないので host 指定を削除したところ ipv6 でもアクセスできるようになった。
21ipのほうは本当に何もしなくてもそのままつながってる。
speedtestここで計測してみたところ、
朝8時くらいに計測、こんな感じ(577.75Mbps/708.48Mbps)
アップが爆速になってます、元は100Mbps上限だったので回線切り替えはできてるようです。
しかし・・・未だにJavaアプレットの計測サイトが多くて困る、
64bit版のwebブラウザは対応してないし、
そもそもあの手のプラグインは廃止方向に向かってるので使うのはやめていただきたい。
ちなみにサーバのログを確認してみたところ PPPoE 接続の Dix は午前5時過ぎに接続が切れた模様、
こちらは dix の会員メニューから 回線契約変更、フレッツ光ギガ、に変更
その後接続アカウントを *@n.dix.jp から *@g.dix.jp に変更して ifup、
fedora 23で手動設定の場合は5カ所くらい書き換える必要あり、grep -r dix /etc/* で探して片っ端から書き換えた。
dix側も speedtest-cli(linuxのコンソールアプリ)で計測してみたところ、90Mbps/188Mbps
うーむ、これは接続先のサーバーが遅いのかな、アップが100Mbps超えてるから回線の切り替えはできてるっぽいけど。
別のサーバー試してみたら 368.41/147.05、こっちはアップもファミリーハイスピードの上限である200Mbpsを超えた、
やっぱちゃんとギガラインに切り替わってはいるけど、計測先のサーバーが遅いみたいですね・・・
電話しないといけないかと思ったら、今は普通にネットから申し込めるようになってますね、
フレッツ光メンバーズクラブにログインして回線種別変更するだけ、
局内工事のみなのでメールの連絡のみ、14日の午前4時くらいに工事するとの事。
よくわからないのが午前7時以降にルーターの電源切って6分待ってから電源入れてくれという・・・
4時に工事するならそれ以降なら大丈夫なんじゃないの？よくわからん・・・
サーバー用で使ってるDixは会員ページから変更してログインIDを一文字書き換える必要がある、
v6プラスで使ってる21ipのほうは何もしなくてもいいらしい。
結局設定変更が面倒なのでv6プラスはそのまま残すことにしたｗ
おー、いつの間にか割安な無線LANなしタイプが出てたんですね、
DIXもいつのまにかギガ対応してるみたいだし、
プラン変更でもIP変わらないみたいだからイイね、接続時の設定一文字変更するだけか。
工事費2000円と月額200円プラスで上下1Gbpsにできる、局内工事のみなのでお手軽、
申し込みが電話だけというのが面倒だが。
下りはIPv6トンネルで1Gbps化してあるので下りは変わらないけど、
トンネル化に払ってる分の月額料金が不要になるのと上りも1Gbpsになるというメリットはある、
しかし、これをやってしまうとISPの関係でIPv6が使用できなくなる。
現状なくても困らないからIPv6廃止してもいいかな・・・
今までApacheを使用していたのですが、
DeNAで開発されている H2O と入れ替えてみました。
とりあえず使用するデータやwebサーバ以外の設定を極力維持する方向で入れ替え。
ログを確認してみたらちゃんとhttp2で通信してるみたいだ。
h2o の設定ファイルって結構独特ですね、
tabはng、インデントはスペース、redirect等のパラメータはインデントしていないとエラーになる。
追記：yamlって形式なんですね、知らなかったよ・・・
うちの設定、まぁ消す意味のあるところは無いのでそのまま載せている。
ポイントは http2-casper: ON 、これがないとキャッシュ機構の一部がうまく動かなかった。
W3 Total Cacheの Minify、jsとcssを無効にしないとキャッシュが読めなくてレイアウトが悲惨な事になる。
この辺りも後で調べておかないとなぁ。
2016/4/19追記:
jsとcssはそのままだとgzipが無効になってるので file.mime.settypes を追加。
user: apache
http2-casper: ON
file.custom-handler:
extension: .php
fastcgi.connect:
host: 127.0.0.1
port: /run/php-fpm/www.sock
type: unix
file.mime.settypes:
"application/javascript":
extensions: [".js"]
is_compressible: yes
"text/css":
extensions: [".css"]
is_compressible: yes
file.index: [ 'index.php','index.html' ]
hosts:
"op.cx:443":
listen:
port: 443
host: 202.75.235.198
ssl:
certificate-file: "/etc/letsencrypt/live/op.cx/fullchain.pem"
key-file: "/etc/letsencrypt/live/op.cx/privkey.pem"
paths:
"/":
file.dir: /home/kdsoft/public_html/wp
file.dirlisting: on
redirect:
url: /index.php/
internal: YES
status: 307
"op.cx:80":
listen:
port: 80
host: 202.75.235.198
paths:
"/":
redirect:
status: 301
url: https://op.cx/
access-log: /var/log/h2o/access.log
error-log: /var/log/h2o/error.log
pid-file: /var/run/h2o/h2o.pid
DBから設定消去とwebからリセットかけて再設定してみたらなんかレスポンスが早くなったような？
ついでに各種リダイレクトも仕込んでみた、
http→https
ip直やop.cx以外のホストを指定した場合→op.cx
いろいろと過去の遺産（別名ゴミ）が残ってるので一度掃除したほうがいいかなぁ。
フリーでsslが使えるということで早速導入してみました。
やり方は検索すればいくらでもあるので省略（ヲイ
相変わらず本文日本語っぽく書いてはあるが日本語じゃない、いかにも外国人が書いたというような文章。
セブン銀行を語ってますが、差出人がyahoo.co.jp、宛先がhotmail.com、届いてるのは nc.cx(届くようにはしてあるが長い事使ってない)
ぱっと見ただけでも突っ込みどころが多すぎて頭痛くなってきます。
こんなのに引っかかる人いるんですかねぇ・・・
ソース見たらbase64エンコードしてあるし、URLは添付ファイルだし、
銀行が添付ファイルにURLとか普通にあり得ません。
バイナリエディタで添付開いてみたけどただのURLっぽいけど、普通の～co.jpの後に更にナニカ書いてあって・・・まぁわかりやすすぎる。
こんなのに引っかかる人がいるとも思えませんが、一応注意しましょう。
キャッシュとかが原因かと思ってプラグイン切ってみたけどやっぱりまだ壊れるな・・・
とりあえず、cron.hourlyに修復用スクリプト突っ込んでみた。
ログを調べてたら結構な量が長期にわたって記録されてました、
IPは微妙に変わってたりするものの、
whoisで調べたアドレス範囲内なのでおそらく同一犯と思われる。
しかし、そもそもうちのは特定IP以外は受け付けないようにしてあるんでどんなに頑張っても接続すら出来ずにログが残りまくるだけ。
お粗末なボットだなぁ、refuse されたら入れるわけないんだから再アタックするだけ無駄なのに、
無駄なトラフィック発生させてるし、その分他へ侵入試みたほうがはるかに効率がいい。
よほど脳みそ足りない奴が作ったボットなんだろうな。