SSLの設定を見直しました

どうも、imo@入江です。
かなりお久しぶりです。
色々やってはいましたが、書けず終いでした…

ということで表題の通りですが、サイトのSSL設定を全体的に見直しました。
具体的には接続を受けるプロトコルをTLS 1.2だけにして、cipherの設定も単純化しています。

TLSに関して、今まで古いOSからのアクセスも考慮してTLS1.1までは許可していましたが、ふと
「TLS1.1までサポートのブラウザとTLS1.0までのとではほぼ変わりない」
と気づきました。
TLS1.1までは脆弱性もあるので、この機会にTLS1.2のみ有効に変更してあります。
apacheでは
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
ですね。
Windows XPやVistaのIEサポートを切った格好ですが、さすがにそろそろいいでしょう。

次はcipherについて。
今まではSSLCipherSuiteに EECDH+AESGCM+AES128:EECDH+AES128:… といったように直指定などしていたものの、見直してみると穴だらけでした。
実際Qualys SSL Labsで見ても指摘点が多かったです。
それを今後のメンテナンス性も考えて下記に変更しています。
SSLCipherSuite AESGCM:HIGH:!ADH:!aNULL:!eNULL:!EXP:!DES:!3DES:!MD5:!DSS:!RC4:!PSK:!SRP:!KRB5:!DH:!kRSA
要はOpenSSLのHIGH設定をベースにして無効方式を列記しただけですね。
RSAでの鍵交換はForward Secrecyがサポートされないので !kRSA で無効化しています。
この方法だと、今後HIGHに推奨されるものが増えたときにも、コンフィグを触らなくていい利点があります。
(非推奨を追加する際は修正が必要ですが)
先のSSL Labsで見ると使える方式が6つだけになってしまったのでちょっとやりすぎかとは思いましたが、ほとんどの環境が
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
あたりを使ってくれているのでひとまずこれで様子を見ようと思います。
もし問題が発生しましたら都度対処しますので教えてください。

サーバー負荷を考えると将来的にはECDHE-ECDSAも使ってみたいのですが、これは後からゆっくり考えることにします。

そんな感じの。
CentOS8への移行に向けて、全体的にコンフィグを見直していきます。
変更点は都度お知らせできればいいなと。

ポケットチェンジで微信支付にチャージするレートの話

どうも、imo@入江です。
GWは仕事です。

さて、以前に書いたことあるような気がしますが、中国では支付宝（Alipay）と微信支付（WeChat Pay）のQRコード決済が主流で、深圳とかではだいたいどこでも使えます。
それこそ屋台の支払い、自動販売機でも使えます。
上海でも個人商店を中心に使えるところが増えてるような。
で、中国は体制がすぐ変わる国なので今はどうなっているか不明ですが、日本人でも登録しやすいのは微信支付ですね。
中国現地の銀行口座なしでクレジットカードで本人確認ができる時期がありました。

今回はそのチャージのお話、
微信支付、日本で手軽にチャージできるポケットチェンジというサービスがあるのですが、そのレートが悪いのです。

空港とかにある緑のアレ（写真はセントレアに設置されているもの）、最近は池袋のブックオフにも設置されててたまげました。

取引のレートを見ているとその時点最新のCNY-JPYのレートより12%ほど悪く…要は12%分は手数料として持っていかれてるみたいです。
まあサービスがある以上手数料はやむなしですが、できれば手数料は安くしたいのが人心。
どうやら下のクーポンコードで2%くらい手数料が減らせるみたいです。

コード：9982782

対応国の硬貨や紙幣なら混ぜて入れても対応してくれる優れもの、中国に旅行する前にチャージして準備しておきましょう。

とかいう、久しぶりに広告のようなものです。
日本でもPayPayとかのQRコード決済いっぱい出ましたね。
個人的には日本のQRのどっかが中国国内の店舗決済も対応してほしい、と思っていたり。（どこか支付宝あたりと相互提携しませんかね？）

利用者サイトのIPv6対応について

どうも、imo@入江です。
無事じゃないです。

さて、タイトルについてですが、うちのサーバーでホストしてるサイトをIPv6対応にします。
というより、該当ドメインのDNSにIPv6アドレスを追加します、というのが正しいです。
このサイトで検証してる限り特に問題なさそうなので、GW前にしれっと作業しちゃいます。

うちのサーバー回線自体はPOIを通らないので問題ないのですが、各利用者側から見るとやっぱり夜間はPOIが渋滞してるようです。
もちろんv6プラス等のサービスは普及しつつありますが全員が全員すぐ飛びつくかというと…
ですがIPv6 IPoE自体はだいたいの利用者回線で使えると思うので、IPv6で公開すれば夜遅いのは減るかなーと。

そんな感じで。
1週間くらいのうちにアクセスログ中にIPv6アドレスが出てき始めると思いますが、びっくりしないでください。

引っ越し予定のおしらせ

どうも、imo@入江です。
WordPressを5にアップしてみました。
なかなかエディタに慣れません。

ところで、まだ先のお話なのですが表題の通り引っ越すことにしました。
まあ同区内での引っ越しなので遠く離れるわけではないのですが。
実際の引っ越しは2019/2の予定、その作業日前後にメインサーバーが止まります。
日程がちゃんと決まったら改めてご連絡します。

今回は、それまでに準備ができればですが
期間中は別箇所にあるサーバーでアクセスを捌こうと思っています。
要は西日本の実家にあるサーバーです。
引っ越し前に実家側を最新データに更新して公開、
数日後ひと段落ついたら再度自宅にデータを戻す、といった具合。
元々実家環境とは常時VPNで繋いであるので、何とかなるのではないかと。
事前に実験しておいて、うまくいきそうならこちらもご連絡します。

今のところ考えている日程が、ちょうどコミティア前後なんですよね。
ので、早めにメンテして影響少なくなるようにはしておくつもりです。

そんな感じの。

–2019/01/12追記
日程が決まったので。2/19に引っ越しとなります。
データが飛ぶのも困りものなので、今回はおとなしく一時停止します。
当日朝6時くらいに止めて、夕方に再開予定です。
その前にラックをバラす作業をするため、当日とは別に、1月末あたりに一時的に停止するタイミングがあります。

IPv4とIPv6どちらでのアクセスか表示

どうも、imo@入江です。
もっとIPv6が普及してくれればいいと思っています（突然）。

ということで、サイト右側のウィジェットに、IPv4、IPv6どちらでのアクセスか表示するようにしてみました。
取得できるリモートアドレス中に「:」があるかで判断しています。
あればIPv6、なければIPv4として表示。

IPv6でのアクセス環境について、
このサイトの回線はNTT東日本のフレッツですが、v6プラスの固定IPなので
IPv4、IPv6含めてネットに出られるようになっています。
また、NTT東日本フレッツないしそのコラボ光からのアクセスだと、
網内折り返しでアクセスすることになるので双方のISPを通らず繋がることになると思います。
レイテンシや転送量の関係でもメリットが大きいです。

本当は西日本のフレッツからもNGN網内接続できればいいのですが、東西でNGNは繋がってないんですよね…
管轄も東西で分かれているので仕方ないですが、NGNの相互接続されることを願っております。

そんな感じで、変なことをしてみました。
自分のネット環境がIPv6でネットに出られているかの確認にも使ってください。

v6プラス固定IP ヤマハルーター編

どうも、imo@入江です。
前の記事からつながるお話です。
読んでない方はぜひ導入の紆余曲折からどうぞ→https://lowfreq.info/archives/23625

サーバー側ネットワークを11/3にv6プラス固定IPに変更した際、IX2105だと160Mbpsくらいで頭打ちというお話をしました。
繋がりましたしレイテンシもいい。
ですがその速度では物足りなかったのです。

ということで、RTX830買ってきました。
こらえ性がないから仕方ない。
RTX830はARM系1.33GHzのデュアルコアCPUです。
PowerPC系とは単純な周波数での比較はできませんが、webで他の方の記事を見る限り速度出そうだなーと。

で、設定していきます。
ヤマハのサイトにIPIPトンネリングとしてコンフィグ例が載っています→コンフィグ例
ですが、こちらについてはIPv6パススルー設定がありませんので他の設定とミックスして噛み砕く必要があります。

他の設定について、v6プラスをご利用の他の方がいくつか設定例出してくださっていますが、
オープンサーキットさんがそのものズバリな設定例を記載してくださっています。
https://www.open-circuit.ne.jp/isp/settei/v6direct-rtx1210-ip1.html
設定例の中の”v6direct-rtx1210-config-ip1-filter.txt”を元にするのがいいでしょうか。
RTX1210向け設定なのでLAN3がWANになっています。
RTX830ではLAN3→LAN2に読み替えてください。

また、プレフィックス変更時、IX2105はddnsコマンドで更新をかけていましたがRTX830には汎用のddnsコマンドはありません。
そのため、Luaスクリプトで更新をかけることになります。
これは上記ヤマハサイトのほうのコンフィグ例を参考にするのがいいと思います。

私はRTX1100以来のヤマハルーターだったのでなかなか思い出せず勝手が掴めませんでした。
IX2105と比較したとき、現在のヤマハルーターにはコンソール上でコンフィグをまっさらにして設定する機能はないようです。
コンフィグをまとめて入れる場合はtftpを使います（設定中に思い出しました）
tftp putの際、clear configurationを入れておくと何もない状態に設定を入れることができます（これがないと追記になります）。
最近のファームバージョンでtftp getでコンフィグを吸い出したときには記載がないので、覚えておくと便利です。

設定して運用してみると、夜中1時前で下のスループットが出ました。

本当にフレッツ回線なんですかね…

速度もですがPINGが2msというのが驚愕です。
今まで一般回線で2msはNUROでしか見たことありません。
これがv6プラスの実力なんですね。

また、CPU使用率についてもIX2105とは大きく違う挙動です。
RTX830では、上記測定中でもCPU使用率コア1-63%、コア2-14%が最高値でした。
IX系と比べて負荷はかなり低いです。
サーバー公開用にフィルタやnat設定も入れてこれなので、余裕がありますね。

ということで、自宅回線の安定化、高速化もひと段落しました。
新しいルーターは設定してると楽しくなります。

v6プラス固定IPのあれこれ

どうも、imo@入江です。
先日告知しましたIPアドレス変更は本日朝に完了しました。
ご協力ありがとうございました。

–後日談があります。

現在フレッツ光の回線を利用していますが、POIに起因する混雑時間帯のレイテンシ悪化が酷かったので根本的な解決をしたかったのです。
そこでJPNEのv6プラス固定IPサービスを利用することにしました。
設定の際にあった紆余曲折を備忘録として書き起こしておきます。

v6プラス固定IP自体の特徴を簡単に書くと
・付与IPアドレスは占有となり、ポートの制限はなし
・IPv4アドレスは固定だがIPv6アドレスは半固定、ONU等の変更で変わる可能性がある
・対応ルーターはHGW、もしくはヤマハRTX/NVR系やNEC IX系等の業務向け機種
・JPNEのBRに対してトンネルを張って利用する
というものです。

■ルーター側のコンフィグ
利用したのはNECのIX2105、今まで別ISPのPPPoE終端で利用していたものです。
NECのサイトに設定ガイドがあるので比較的敷居が低いのですが、
記載コンフィグの対象ファームバージョンが記載されていないのでコマンドリファレンスと見比べる必要があります。（後述）

＞設定ガイド

当初利用した個体のファームは9.1.10
一部相違はあるもののだいたいは設定ガイドのコンフィグで通ります。
ですが、proxy-dns ip enable request bothだけは通らず。
というのも、request bothはファーム9.2台から実装されているようで、9.1台にはv4とv6に同時に転送する機能はないようです。
また、記載コンフィグ上ddns内のsource-interface BVI0も、9.1ではsource BVI0となります。
一部書き換えることで9.1.10でもトンネル接続可能です。

その後、10.0.14の個体にしてみましたら今度はrequest bothが別行への記載に変更になっていました。
以上から、設定ガイドのコンフィグはファーム9.2～10未満が対象のようです。

あと、ISPから提供される情報にインターフェイスID、IFIDがありますが、
IFIDの表記がxxxx:xxxx:xxxx:xxxxとなっていることがあります。
IXシリーズではxx:xx:xx:xx:xx:xx:xx:xxという表現方法になるので、
例： dead:beef:dead:beef → de:ad:be:ef:de:ad:be:efのように書き換えて設定ください。

11/4追記：
9.1.10での運用について当初うまくいっていなかったのですが、解消できたので書いておきます。
すぐ下の5秒遅延-に関するところです。

前提になる話として、「v6プラスが提供しているDNSサーバーはIPv6でのみreachableです」
proxy-dns ip enable request bothがない状態だと、IPv4でのDNS問い合わせが不可能なのでタイムアウトまで待っていただけだったんですね。
当初AAAAレコードだけかと思っていましたが、tcpdumpしてよく見てるとAも引けていませんでした…
コンフィグに他にDNS設定を書いていないので、当たり前の挙動です。

で、要はv4 rechableなDNSがあればいいということで、
proxy-dns server 1.1.1.1
を追加して平穏が訪れました。
1.1.1.1はCloudflareが提供しているパブリックDNSです。
Google Public DNSでもVerisign Public DNSでも好きなのを入れていいと思います。
サーバー系の設定にパブリックDNSを入れる是非については少し悩みましたが、他にあてもないので。
–追記ここまで

■サーバー側の設定
利用目的がwebサーバー公開なので、そこでも気になった点を。
RHEL6/CentOS6以降ではDNS問い合わせする際、標準ではAレコードとAAAAレコードの問い合わせに同じソケットを利用するようです。
そのため、一部ファイアウォールでは後の応答を遮断してしまう模様。
CentOS7の自分の環境ではWordPressにアクセスする際サーバー側からDNS問い合わせが発生するため、
遮断が入っていたのかタイムアウトが発生しページ表示が5秒程度遅延していました。

従来の問い合わせ方法を使うにはnmcliで下記を投入します。
nmcli con modify ipv4.dns-options single-request-reopen
systemctl restart network

single-request-reopenというのがリクエストごとに別のソケットを開くオプションになります。
/etc/resolv.confを編集する方法もありますが、CentOS7の場合はNetworkManagerがオーバーライドしていくので
上記nmcliのほうが良いと思います。

■使用感
ひとまず結果から。
記事公開日に数回だけチェックした数値なので参考程度に。

Ookla speedtest.net（DL/UL、相手はOPEN Projectを選択）
　PPPoE：平時PING15ms 290/410Mbps、混雑時PING40ms 28/60Mbps
　v6プラス：平時PING3ms 140/138Mbps、混雑時PING3ms 138/143Mbps

正直なところ、PPPoEでも平時は問題ないのです。
速度も出ますしPINGも悪くありません。
ですが、POIにトラフィックが集中する混雑時には速度が大きく下がります。
実際のところ、上の計測結果は以前と比べるとかなりマシなほうで
ひどい時には下り10Mbps切ることもありました。
また、レスポンスも悪化するので、その分が応答時間に乗ってきます。
もちろんwebサーバーとクライアント間は複数のセッションを張るのでレイテンシ×コンテンツ数ではありませんが、
速度も相まってもっさり感じることが多くなります。

一方、v6プラス固定IPだと速度、PINGともにほとんど変動しません。
特にPINGが一定かつ短いのはサーバー公開用途として理想的です。
夜間にクライアント用途として利用しても、サイトへのアクセスは快適です。
もちろんv6プラスについても終端のBRが混雑すると遅くなる可能性はありますが、
POIと比べるとJPNE内部の機材なので対処しやすいのではないかと。
各ISPがIPv4 over IPv6でトラフィックをIPoEに逃がすサービスをしていますが、その意味は大いにあると思います。

ところで、上記の速度結果で、v6プラスが遅いことに気づくと思います。
これはIX2105のCPU性能によるものです。
上記の速度計測の際に確認すると、v6プラス時はCPU使用率が100%に張り付きます。
IX2105はPowerPC系の400MHzシングルコアなので、このCPUの限界ということですね。
4-over-6の処理はPPPoEより重いようです。
昨年にCPUが800MHzになったIX2106が発売されているので、そちらだとさらに高速だと思います。

ちなみにファームバージョンによっても速度差があり、計測すると9.1.10のほうが速いです。160Mbps程度出ます。
先に書いたDNSまわりの挙動があったので私は今のところ10.0.14で運用入れていますが、9.1.10でもコンフィグ見直せばいけると思います。
2台とも中古で入手した個体なのでその間のファームで確認できないのです。

そんなこんなで、インターネットへの接続方法としては宅外のボトルネックを極力排したものになったかと思います。
今後ともよしなに。

IPアドレス変更のお知らせ

–下記完了しています 具体的な内容はこちら—

どうも、imo@入江です。
実家帰省しておりました。

さて、タイトルの通りですが、11月初旬にサーバーの回線変更を行います。
といってもフレッツ回線自体はそのままです。
現在グリーンネットをIPv4 PPPoEで終端してますが、やはり混雑時のレイテンシ悪化が激しいので
別プロバイダで提供されているv6プラス固定IPに切り替えます。
POIを経由せずJPNEまでIPoEなので速度上下はあれど応答は安定すると思います。

ドメインも入江で代理管理していますので、ユーザーでの作業内容はありません。
処理は午前中予定、その間接続できない時間帯があることご承知おきください。
作業日は開通タイミングで変動しますが、現在のところ11/3ないし11/5の07:00～を予定しています。

–11/2追記

回線が無事開通し、テストも終わりましたので変更処理します。

11/3 07:00〜の作業となります。

DNS内容更新が入るのでアクセス環境によっては30分程度の接続断が考えられます。

サーバー更新完了と最近のいろいろ

どうも、imo@入江です。
サーバーの更新は無事完了しました。ご協力ありがとうございました。
メインストレージをSSDに変更、PHPも7.2系に変更しているので以前と比較してかなり高速化しているはずです。
今後ともよしなに。
私がドメインを代理管理している方には、折を見てDMとかメール投げます。見てね。

　さて、サーバー更新以外ではかなり久しぶりです。
前回はいつだ？と思ったら2017/02の記事でした…
そっからのお話を駆け足で。だいたい旅行のことです。

■また台北日帰りする@2017/04
1月に行ったというのにまた台北へ行ってました。
peachの日帰り弾丸が安いのが悪い。

ちょうどこのころ桃園MRTが開通したのでそれを使って台北市内へ。かなり便利です。

台北駅で駅弁食べて、西門町で麺線食べて、アニメイト行って光華商場行ってとまあ代わり映えしませんでしたが
適当にうろうろするのは楽しいです。

あ、お米もらいました。

■日帰りで京都にたかめ少女を見に行く@2017/06
6/8に高雄メトロと嵐山電鉄が観光連携協定を結ぶとリリースがあったんです。
そこでたかめ少女のラッピング電車がお披露目されるということで、よし行くか、と。

式典は超フレンドリーでとても楽しかったです。

また、他のファンの方にもお会いできて貴重な一日でした。

■ぶち切れて連休取って中国とか行く@2017/07
勤務先でいろいろあり上司と面談になったのです。
で、紆余曲折あり7月に12連休を取って国外逃亡してました。
上海→香港→高雄というルート。




上海はもちろん訳わからなくて最高でしたが、香港とお隣の深圳が居心地よくてハマりました。

このときの高雄は台風の直撃を食らいわりと消化不良…

■JALの工場見学に行く@2017/10
羽田空港至近にあるJALの整備工場が、工場見学を受け付けているんです
JAL SKY MUSEUM
ちょうど機会が合い行ってきました。

もちろん整備工場部分も大迫力ですが、座学前の博物館スペースが見るものめっさあって満足。
興味を持たれた方はぜひ。受付開始時間すぐに行って座学始まるまで展示品を見ておくのがいいですよ。

■台北に高捷戀旅やりに行く@2017/11
最近台北の夜市行ってない…ということでパパっとチケット取って台北へ。
直前に決めたこともあって宿はドミトリーを使いました。
Starbox Hostel 星盒青年旅館

ちょうどそのころ、GPS/ARゲーである高捷戀旅に台北編がリリースされていたので、Youbikeで移動しながらポイント埋めてました。
みんな高捷戀旅やろう。
＞高捷戀旅

■香港で長話をする@2018/01
副業の絡みで、香港に行ってました。といってもほぼ観光でしたが。
香港エクスプレスが羽田深夜1時発というナイスな便を飛ばしているので、香港で朝から活動できるのです。



シノセンターの本屋で店員さんと話し込んでました。
香港では普通語で話しかけるより英語で話したほうが相手もフレンドリーですね。
本当は広東語が話せればいいのでしょうが、英語がわかる方が多いので甘えてしまいます。

■名古屋でひつまぶしをいただく@2018/03
これまた副業で、名古屋にお呼ばれしたので日帰りでした。
というか1月の件の関連です。

お話している途中で、生まれて初めてひつまぶしをいただきました。
相手の手前写真はありませんが、これが超うまい。
そのあと帰る前に食べた担々麺もうまい。
あ、観光はろくにしませんでした。

■ナナ様の誕生日を祝いに高雄に行く@2018/05
たかめ少女のナナ（耐耐）様の誕生日が5/23なのです。
ナナ様ファンとしては祝わねば、ということで日程合わせて高雄に行ってきました。
もう皆さん気づいてると思いますがこの入江、気が付くと旅行してます。バカです。
で、そのころpeachが那覇-高雄便を就航させたので乗ってみたくて
羽田→那覇、那覇→高雄、桃園→羽田というルートとなりました。




高雄だけでなくお隣の東港にも足を延ばしたりと、活動範囲が広くなった気がします。

■深圳で情報収集する@2018/06
香港で知り合った方から、積もる話もあるのでおいでよとラブコール。
で、ホイホイ行ってしまったのでした。

待ち合わせの場所として言われたのがまさかの深圳、しかも本屋。
どういうことだ？と思っていたらどうやら世界最大の本屋とのこと。中国本土はスケールが違いすぎます。
深圳书城中心城
店内はイラストの描き方本がこれでもかと積んであったり、家電修理のガイドブックが置いてあったりととにかくパワーに溢れていました。

あとは華強北に行ったり香港で点心食べたり。
深圳では本当にどこでもWeChat Payが使えて衝撃的でした。

■台北に友人に会いに行く@2018/07
友人に会いにpeach日帰りで行ってきました。

台北にとらのあながオープンしたということでそこを見たかったのもあります。

会う前にカルフールで買ったカットパパイヤが感動的にうまくて、このために台北に住みたいと思ったほどでした。

あと、光華商場のところにでっかいオナホの広告があって爆笑したり。
行くところが決まっていると日帰りでもじゅうぶん楽しめます。

■車で大阪コミトレに行く@2018/09
コミトレに行くやで！ということで、友人が運転する車で京都と大阪へ。
ほんと運転お疲れ様でした。

各所のサービスエリアで食べたり京アニショップに行ったり清水寺に行ったり。

いづうさんの鯖寿司が美味すぎました。
京都は今までけっこう行ったことあるのですが、食べたことなかったのを本気で悔やみました。
また行きたいです。

もう訳の分からないペースで旅行してる気がしますが、きっと気のせいです。
おそらく今後も続くと思います。

2018/9/19 サーバー更新のおしらせ

–下記は完了しています–

大変お久しぶりです。imo@入江です。

現在運用している自宅サーバーがハードウェア、ソフトウェアともにさすがに古くなってきました。
ということで、来月にサーバーの更新を予定しています。

作業日時：2018/09/19水曜日 05:00(JST)～
作業時間は3時間程度を予定していますが、進捗により変動します。
更新中はアクセスが一切できなくなります。

更新時点で下記のような構成になる予定です。
■ハードウェア
CPU：Intel i7-6700
MEM：16GB
SSD：1TB RAID1
HDD：4TB バックアップ領域
NIC：Intel i350-T2
■ソフトウェア
OS：CentOS7.5
apache：2.4.6
perl：5.16.3
php：7.2.9
python：2.7.5
mariadb：5.5.60

更新に際して、perl、php、pythonはapache権限ではなく、ユーザー権限での実行になります。
そのため、各ユーザーディレクトリ中のapache作成のファイルは所有者を各ユーザーに変更します（ファイル内容は確認しません）。

また、各ユーザーのホームディレクトリは同じですが、FTPクライアントでアクセスした際の初期ディレクトリが変更となります。
現在：/server/users/<ユーザー名>/html/
更新後：/server/users/<ユーザー名>/

動作は各CMSで確認していますが、すべての動作が今までと同じ保証はできません。
不具合がありましたら都度ご連絡ください。

« Older Entries