特定サーバーからメールが届かなくなった(TLSv1.1廃止の影響)

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 だったのですが、このパターンは今後結構出てきそう…

nginx webサーバーをIPv6対応にするときSSLでハマった

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が設定されていたので、増設分が必要だったわけだな。

オフィスのIPv6、v6プラス、DS-Lite設定でハマった2件

最近立て続けにIPv6というかフレッツ光でのv6プラス、DS-Lite(transix)の設定でハマったので記します。どちらもYAMAHAのRTシリーズをルーターで使用。

リモートワーク需要もあり、より高速にインターネット接続したいという要望があり、だったら固定IPの件はなんとか回避するとして、v6プラス/DS-Liteでいかがですか、ということで設定することになりました。
ひかり電話装置の下の場合はルーターのIPv6アドレスはDHCPv6-PDで取得する、ひかり電話装置じゃない場合はRAプロキシで、という基本的な理解とあとは豊富な設定例でなんとかなるんだろ!と思っておりましたが、環境がそれを許さなかった…!

その1: 西日本と隠れOCN

西日本エリア、ひかり電話オフィス、OCNのv6プラスでのRTX830設定。
実は最初、Interlinkを使っていたのでDS-Liteの設定を準備、Interlinkの申込時に「既に使用されています」と表示されるため、おかしいと思いクライアントさんに契約を確認してもらったところ、プロバイダとしてはOCNを利用していないがメールアドレス維持のために契約を残しており(PPPoEのアカウントは生きている状態)、かつ回線がOCN光での契約で、なおかつこの6月からOCNはデフォルトでv6プラスを有効にしているというのです。

ニュース 2020年6月11日:「OCN 光回線サービス」において、IPoE接続を標準機能として提供開始 | NTTコミュニケーションズ 企業情報

既にCAF番号とアクセスキーはOCNで使われているので、InterlinkではDS-Liteを申し込めません。じゃぁOCNを使いましょう。InterlinkのIPv4は固定IPアドレスのため引き続き使います。

西日本ではHGW(ホームゲートウェイですかね)の配下では、DHCPv6-PDではなくRAプロキシで取れという話はなんとなく覚えていたのですが、ここの環境ではひかり電話オフィスのαA1という主装置の下です。主装置下ではDHCPv6-PDだと思っていたのでそのようにしますが、繋がりません。

もしかして、αA1もHGWと同じ挙動か?と思って試してみたら当たり。
RTシリーズのv6プラス対応機能の「設定例その3」の通り、HGW配下と同じRAプロキシの設定にしたところ、無事に接続できました。
v6プラス対応機能

IPv4のデフォルトゲートウェイをIPIPトンネルとし、LAN内のwebサーバーの公開のため、webサーバーからの通信のみInterlinkのPPPoEを通すように書きました。
filter11に合致した通信はpp1、その他はtunnel1ということができます。
nat descriptorはpp1とtunnel1の2つ分必要です。

ip route default gateway pp 1 filter 11 gateway tunnel 1
ip filter 11 pass 192.168.0.200 * * * *

その2: 古いひかり電話主装置を避けたかった

東日本エリア、ひかり電話オフィス、InterlinkのDS-LiteでのRTX1200設定。
こちらもInterlinkの固定IPv4アドレスを使用しており、またパートナー会社との接続のためIPv4アドレスを変えたくないということで、こちらもPPPoEは残します。

このクライアントさんではInterlinkしか契約がないのと、フレッツ光も東日本純正の契約なので、DS-Liteの対応でトラブることはありませんでした。
しかし、ひかり電話主装置がαGX type Lという古いもので、WAN側が100Mbpsです。そのためこの主装置の下にルーターを接続しても、外向きが100Mbpsになってしまいます(実効値はもっとはるかに低いでしょう)。ということで、ONUの下にHUBをおいて、ひかり電話主装置とRTX1200に分配して使用しておりました。

RTX1200にRAプロキシの設定でのIPv6設定を行い、transix終端点へのIPIPトンネルを設定しました。transix経由のIPv4とPPPoE経由のIPv4の使い分けはあっさり動きますが、v6通信が通らない。
さらに、数時間するとtransix経由の通信もできなくなり、ルーター再起動で直るという現象が起きます。何かがおかしい
なおその間、ひかり電話はなんの支障もなく通話できている。

やたらとググったんですがアドレス保存してなかった。たぶんこのへんをさんざん読んで理解したような気になっているところ。
フレッツ光ネクスト (ひかり電話あり) 回線において、ひかり電話と自前の設備を IPoE IPv6 的な意味で仲良くさせる – diary.sorah

結論としては、ひかり電話契約があり、かつ主装置αGX-LとRTX1200が並行にある状態だと、どちらもDHCPv6-PDを受けようとして奪い合いになってしまう。NGNからのm-flagつきRAは3時間毎に配られるらしく、奪い合いが発生して通信が停止するのもそのタイミングと合致する。
つまり、遅いαGX-Lの下でDHCPv6で動かすか、並行でのv6利用は諦めるしかない。あとは主装置を買い換えてください…

ちなみに、DHCPv6-PDの奪い合いをしているのにひかり電話が途切れなかったのは、主装置からのひかり電話はNGN内でのIPv4通信だからだそうだ。じゃぁv6やめてくれてもいいじゃんとか思ったけど、v6はv6なりにファームウェアのアップデートとかで使っているようです。資料はどっか忘れました。ダメだということだけは確認した段階で疲れて閉じちゃった。ごめん。

もしかしたらRTX1200のLAN3ポートに主装置を繋いでIPv6やらNGN内の通信をスルーしてあげればいけるのかもしれないけど、主装置に対してのv6通信は削ることになるし、その場合の電話の挙動がどうなるかわからん(&電話は止められない)ので、やめました。

リモートワーク全盛なので

中小企業様よりVPNとかv6化とかの注文をいただいております。安価かどうかは知りませんが、あんまり大規模にお高くやるやつじゃない感じで対応しております。環境毎に異なる場面が結構ありますので、上記はその一部の例です。
社内SEがいるぐらいの会社だったら自前でできることだとは思いますが、そうでない規模のところをお手伝いしております。

m3u8の動画を保存する

某オンライン動画をオフラインでも見たいなーということでローカルに保存する。
動画のページを辿るとJavaScriptやらなんやらで呼び出されていて、htmlソースを見てもファイルの実態の在処はわからない。
Google Chromeのデベロッパーツールで辿ると拡張子.m3u8が動画の指定ファイルのようだ。

m3u8をダウンロードしてみると、中身はテキストで、さらに細かくファイルが指定されている。プレイリストファイルのutf8ということでm3u8という拡張子になっているようだ。
これを全部ダウンロードしろというのか、DL後の結合も面倒だなと思っていたら、ffmpegでできるという。

ffmpeg -i (m3u8のURL) -movflags faststart -c copy (出力ファイル名.ts)
(参考)ffmpegでm3u8ファイル(HLS)から動画をダウンロードして保存するコマンド – 動かざることバグの如し

ffmpegがない場合はVLCでもできるようだが(ctrl+Rでメディアを開く→ネットワーク、URLにm3u8を入れて保存)、バッチファイル的に書いて連続実行させたいのでffmpegがラクだった。

これで飛行機や新幹線の移動中にも回線に依存しないで済むぞ…

sambaがアップデートしたら動かなくなったので修復

CentOS7でずいぶん触ってなかったサーバーをyum updateしたらsambaが止まってしまった。
systemctl status smbで見てみると、WBCLIENT_0.13が見つからないとか、バージョン違いが原因のようだ。
/etc/samba/smb.conf をコピー退避してから、sambaを入れ直す。
yum remove samba
yum install samba
systemctl start smb
systemctl status smb
で起動確認。
configを書き戻してもそのまま起動した。
たまにライブラリ違いみたいなのが出てくるなぁ。