オフィスの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を書き戻してもそのまま起動した。
たまにライブラリ違いみたいなのが出てくるなぁ。

nginxでalias下のfastcgiへのパスの渡し方

nginx + php-fpm の環境。
最近はドメインのトップからWordpressのようなシステムを置くことが増えたので
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
で良かったのですが、
URI上の一部分を別のディレクトリに置いていたりするパターンでは、rootの定義し直しではなくてaliasを使ったほうがよさげらしい。
しかしaliasにしてしまうと不都合もあるようで

server {
  server_name example.com;
  listen 80;
  root /var/www/example.com/;
  location /somepath/ {
    alias /var/www/somepath/;
    index index.php index.html;
    location ~ \.php$ {
      fastcgi_pass unix:/run/php-fpm/www.sock;
      fastcgi_index index.php;
      # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param SCRIPT_FILENAME $request_filename;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      include fastcgi_params;
    }
  }
}

example.com/somepath/hoge.php をリクエストすると
$document_root$fastcgi_script_nameの場合 /var/www/somepath//hoge.php が渡されちゃう。スラッシュが2重になってしまうのでalias下では使えないことに。
$request_filenameの場合 /var/www/somepath/hoge.phpが渡る。こちらは望み通りの結果。

じゃあalias下じゃなくても$request_filename使えば良いのでは?と思って試した結果、
example.com/fuga.php のリクエストに対してどちらも /var/www/example.com/fuga.php となった。

大本がどこからのコピペだったか忘れたが、$request_filenameで良さそうだ。ただしrootとかaliasとかindexがしっかり定義されている文脈に限る。
rootのときは最後の/を調整してくれるけどaliasではしてくれないあたりからの違いってことか

参考
落とし穴とよくある間違い | NGINX 日本語訳
nginx $document_root$fastcgi_script_name と $request_filename の違い – Qiita

#TETRIS99 でチケット999枚を達成!その次はどうなる

2019年12月末から始めたTETRIS99のチケットためるチャレンジ、昨日無事に999枚を達成しました!
で、その後はどうなるの、999枚でカウンターストップなのか、4桁に繰り上がってしまうのか。

そんなわけでまだしばらくゆるゆる続けたいと思います。