2021年10月からLet’s Encryptの使っているルート証明書が切れた（変更になった）関係で、古いシステムでは使えない話が出てきていましたが、それはクライアントの話。CentOS6のサーバーではcertbot(-auto)を継続利用できないのでさて困ったねと。
あともう1つオマケでfullchain.pemとiOSでの問題も最後に。
元々certbot-autoを使ってLet’s Encryptの証明書を更新していましたが、使えなくなりました。
1つはyumの問題。CentOS6はサポートが切れたのでアップデートを提供してくれてたリポジトリも閉じてしまいました。このへんは各リポジトリに使われていた mirrorlist.centos.org を vault.centos.orgに変えてやれば一応使えます。
そしてcertbot-autoが「Your system is not supported by certbot-auto anymore.」と言ってきて終わります。
バーチャファイターeSports、ランクマッチが全然マッチングしない！ということでPS4のMTUを調整してみたらどんどんマッチングするようになりました。
しっかりとマッチングできてる人はいじる必要ありません。あまりに繋がらないためにネットワークを疑った場合の話です。
MTU調査はこちらで https://www.speedguide.net/analyzer.php
このMTUの値をPS4の
設定＞ネットワーク＞インターネット接続を設定する＞（うちの場合）LANケーブルを使う＞カスタム
で進めていった先の、MTU設定を「手動」にして、入力してやります。
うちはフレッツ光ネクストのIPoE+transix(DS-Lite)固定IPという環境もあって、1280でした。
すると、設定前には1分2分かかって当たり前だったマッチングが、10秒未満に。
調子がいいと何度も6秒でマッチングするように。
そもそもフレッツ光(東日本)でPPPoEだとMTUは1454だった覚えがあったのですが、DS-Liteだと1460になるようで。うちはtransixの固定IPv4アドレスなので、その影響で1280になっているようです。
当然、環境毎に異なるので確認サイトで見てみてください。
環境がIPoE+transix(DS-Lite)固定IPv4という状況かつ、ルーターRTX810でデフォルトのtunnel MTUが適用されており、1280になっていました。
MTU値を詰めていくと…1460で通る。ルーターで明示的にIPv4用のIPIPトンネルのMTUを1460に設定してやったところ、当然PS4側も1460で通信できるようになりました。
ルーターがMTU 1460の状態だと、PS4側はMTU自動設定でも大丈夫みたいです。
自作PCを組んで常に電源入れっぱなし的に使っていますが、やはり暑い夏には単なる熱源である時間も多いので、使わないときにはスリープもしくは休止状態にしてやりたいと思い、そのように運用を開始したところ、休止状態でもなぜかすぐ復帰してしまう。
マウスとかキーボードが動いちゃうのかなーなんて思いましたが、デバイスの電源を切ってもすぐ復帰する。こりゃ別の原因だと思ってあれこれしてるうちに見つけたのがNIC。LAN。
Wake On Lan(WOL)なんて設定してないのになーと思ってNICのプロパティを見たら「このデバイスで、コンピューターのスタンバイ状態を解除できるようにする」にチェックが入ってました。そして「Magic Packetでのみ、コンピューターのスタンバイ状態を解除できるようにする」にはチェックなし。
WOLするにはマジックパケットが必須だと思っていたのですが、調べたらそうじゃないpingなんかでも起きてしまうんだそう。Magic Packet限定にしないとすぐ起きてしまう。
ということで「Magic Packetでのみ、コンピューターのスタンバイ状態を解除できるようにする」にチェックを入れたら、スッキリとスリープ・休止状態になってくれました。
Magic Packet以外でも起きる設定がデフォルトってどういうことだい…たまたまデバイスとドライバの組み合わせがそうなっていただけかもしれませんけども。
CentOS7,8あたりでpostfixによるメールサーバーを運用中。
最近いくつかのサーバーからメールが届かなくなったということで調査したら、TLSv1.1以前が廃止された影響だったようです。
受信サーバーのpostfixは smtpd_tls_security_level = mayとしているので、STARTTLSしなければ平文のSMTPでメールが受信できます。
問題は送信元がSTARTTLSしてしまうけれどもTLSv1.1以下だった場合。バージョンアップされていないメールサーバー（今回は某レンタルサーバーのqmail）がSSL3で通信しようとしてきて、STARTTLS→失敗・切断という流れだったようです。
相手からreturn mailが来たと連絡をもらったときの内容は以下↓
TLS connect failed: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version; connected to XXX.XXX.XXX.XXX.
I'm not going to try again; this message has been in the queue too long.
受信側postfixをsmtpd_tls_log_level = 2 にして様子見したときのログ↓
connect from mxXXX.example.com[XXX.XXX.XXX.XXX] setting up TLS connection from mxXXX.example.com[XXX.X.XXX.XXX] mxXXX.example.com[XXX.XXX.XXX.XXX]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL3 alert write:fatal:protocol version SSL_accept:error in error SSL_accept error from mxXXX.example.com[XXX.XXX.XXX.XXX]: -1 warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1661: lost connection after STARTTLS from mxXXX.example.com[XXX.XXX.XXX.XXX] disconnect from mxXXX.example.com[XXX.XXX.XXX.XXX] ehlo=1 starttls=0/1 commands=1/2
SSL3 alert writeって出てますね。
解決策としては、先方のバージョンアップをお願いするか、手元のサーバーで半端にTLSさせないように、そもそもSTARTTLS非対応にしてしまうか。
今回はレンタルサーバーということで先方が即時に対応できないため、postfixで smtpd_tls_security_level = none としました。
master.cfでsubmissionポートの場合はTLSになるようにしておいたし、不正リレーもないことをあらためて確認。
受信メールサーバーだからある程度は開いておかないといけないということで may だったのですが、このパターンは今後結構出てきそう…
CentOS8 + nginxの環境で、もともとIPv4のみ対応だったサーバーをIPv6対応にすることにした。
OSレベルでのIPv6有効化は結構環境というかそのときのバージョンに左右されているので随時資料を見ることにする。（さくらのVPSではデフォルトでIPv6無効だが、有効にする手順も提供されていた。「再起動してください」とか雑な感じではあったが）
nginxではconfのserverディレクティブ内で listen [::]:80; listen [::]:443 ssl;を追加すればすぐ動く。ファイアウォールもfirewalldでサービス単位で通しているのでIPv4/IPv6を意識しなくても良い。
しかし、動かなかった…。
正確に言えば、ポート80でのIPv6通信はOKだったが、443でのSSLがダメ。ERR_CONNECTION_RESETやERR_CONNECTION_CLOSEDが返ってくる。
これ、IPv6かつ443 SSLのなかでのdefault_serverが決まっていないと起こる。
適当なserverディレクティブにdefault_serverを書くと期待通りに動いた。IPv4では既にdefault_serverが設定されていたので、増設分が必要だったわけだな。