lowfreq on Web
どうも、imo@入江です。
本題です。代理管理しているドメインの期限更新しました。利用されてる方には今日明日でご連絡予定です。
whoisで見ていただくと期限が2022年までになっていると思います。
んで、今回の更新料(と次回の更新料)は事前に策を講じていたのでちょっとだけ安いです。
具体的には5%OFF。
普段だとコミケ等でお会いしたときにいただくのですが情勢がこんななので、いただく方法は別途相談で(実は振込以外にも色々いけます)。
いつも通り急いでいないので落ち着いたころに、でも大丈夫です。
そんな感じのご連絡でした。
気兼ねなく集まれるような状況に戻ってくれるのを切に待ってます。
お久しぶりです。imo@入江です。
旅行に行けてなくて禁断症状が出っぱなしです。
台湾に行きたい、2週間くらい行きたい。
仕方ないので、空いた時間に買い貯めた軽小説読んでます。
さて、タイトルの件です。
現在このサーバーはPHP 7.2系とMariaDB 5.5系が動いていますが、PHP 7.2が11月末でサポート切れするのと、MariaDBも10系が出て久しいのでバージョンアップする予定でいます。
PHP 7.4とMariaDB 10.3へのアップグレード予定です。
MariaDBの最新は10.5系なのですが、CentOS7上の5.5からのアップグレード事例が多く、また将来的に移行するCentOS8の標準がこの10.3系なので一度こちらを挟みます。→バージョン変更あります、詳しくは下記
CentOS8移行への布石でもあります。
正直なところapacheも更新をしたいのはありますが、モジュールを組みなおす必要があるのが手間なので今回は見送ります。
ということでスケジュールです。作業予定日: 2020/11/22(日) 07:00～
すいません、個人的事情でリスケします。決まりましたら再度ご連絡します。
チェック途中でCentOSのバージョンアップがあり、再評価しているのもあります。(今のところ問題ないです)
11/22追記：日程決めました。12/5(土) 07:00～の予定です。
MariaDBについては10.5へのアップになります。
事前にVM上で検証して挙動確認する予定です。各ユーザーのスクリプトに関してはブラウザとapacheログでの確認をします(ファイル内容を直接見ることはしません)。
検証時エラーが起きる場合は個別にご連絡しますのでご協力ください。
よろしくお願いします。
今のうちにCentOS8への移行予定についても。
8へは来年の2月前後を目途として移行予定です。移行時の最新版を新規インストールで対応します。
近づいてきたら改めてここでご連絡します。
どうも、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のどっかが中国国内の店舗決済も対応してほしい、と思っていたり。（どこか支付宝あたりと相互提携しませんかね？）
どうも、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月末あたりに一時的に停止するタイミングがあります。
どうも、imo@入江です。
もっとIPv6が普及してくれればいいと思っています（突然）。
ということで、サイト右側のウィジェットに、IPv4、IPv6どちらでのアクセスか表示するようにしてみました。
取得できるリモートアドレス中に「:」があるかで判断しています。
あればIPv6、なければIPv4として表示。
IPv6でのアクセス環境について、
このサイトの回線はNTT東日本のフレッツですが、v6プラスの固定IPなので
IPv4、IPv6含めてネットに出られるようになっています。
また、NTT東日本フレッツないしそのコラボ光からのアクセスだと、
網内折り返しでアクセスすることになるので双方のISPを通らず繋がることになると思います。
レイテンシや転送量の関係でもメリットが大きいです。
本当は西日本のフレッツからもNGN網内接続できればいいのですが、東西でNGNは繋がってないんですよね…
管轄も東西で分かれているので仕方ないですが、NGNの相互接続されることを願っております。
そんな感じで、変なことをしてみました。
自分のネット環境がIPv6でネットに出られているかの確認にも使ってください。
どうも、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設定も入れてこれなので、余裕がありますね。
ということで、自宅回線の安定化、高速化もひと段落しました。
新しいルーターは設定してると楽しくなります。
どうも、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
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台とも中古で入手した個体なのでその間のファームで確認できないのです。
そんなこんなで、インターネットへの接続方法としては宅外のボトルネックを極力排したものになったかと思います。
今後ともよしなに。
–下記完了しています 具体的な内容はこちら—
どうも、imo@入江です。
実家帰省しておりました。
さて、タイトルの通りですが、11月初旬にサーバーの回線変更を行います。
といってもフレッツ回線自体はそのままです。
現在グリーンネットをIPv4 PPPoEで終端してますが、やはり混雑時のレイテンシ悪化が激しいので
別プロバイダで提供されているv6プラス固定IPに切り替えます。
POIを経由せずJPNEまでIPoEなので速度上下はあれど応答は安定すると思います。
ドメインも入江で代理管理していますので、ユーザーでの作業内容はありません。
処理は午前中予定、その間接続できない時間帯があることご承知おきください。
作業日は開通タイミングで変動しますが、現在のところ11/3ないし11/5の07:00～を予定しています。
–11/2追記
回線が無事開通し、テストも終わりましたので変更処理します。
11/3 07:00〜の作業となります。
DNS内容更新が入るのでアクセス環境によっては30分程度の接続断が考えられます。
