Lycolog

R86S U1のNICについているSFP+ポートの片方が不安定という問題があり、これがずっと悩みの種だった。

しかしR86S U1のNICはOCP2.0のメザニンカードという特殊な規格であり、入手が難しかった。あと最近なんでも高いことや、ここ一年近く財政が悪く資金がショートしていたこともあり、中々購入のタイミングがなかったが、偶然安いのを見つけたので交換を決意した。

• 購入したもの
• 配送
• 開封の儀
• OpenWrt上でのセットアップ
• そのまま使うと温度が上がりすぎた
• 冷却対策
• ベンチマーク
  • Windows → Ubuntu
  • Ubuntu→Windows
  • まとめ
• 交換前のConnectX-3が改造品だった話
• あとがき

購入したもの

ほぼ新品 Mellanox ConnectX-4 CX4421A MCX4421A-ACQN ネットワーク インターフェイス PCIe カード (OCP2.0 用)

ほぼ新品とあるが中古なのは間違いない。

写真を見る限り左右でコネクタが異なるといったこともなく、3,745円でConnectX-3からConnectX-4に上げられて不調もなくなるならアリではないか？と思い、購入することにした。

配送

荷物はいつも通りCainiaoから発送され、国内ではエスポ便という聞いたこともない業者に引き渡された。軽く調べたところ株式会社エスポリアという越境ECのサービス会社がやっているようで、ここ最近のアリエクに増えているらしい。ここ自体は仲介業者で配送はしてないらしい。

そういえば最近中華特有のテカテカしたプチプチ袋減った気がする。

実際の配送はかつてAmazon便で悪名を馳せたTMG、椿本グループだった。久々に見たので、一般消費者向け宅配便事業で生きてたのかお前…となった。

開封の儀

結構ちゃんとした箱に入っていた。

中身。緩衝材が底にあり、本体も一応元袋らしきものに入っていた。いい感じのヒートシンクがついているのが素晴らしい。

賞味期限ラベルみたいなものが貼ってあったが非常に強力なシールで、爪でカリカリすると爪が削れるレベルで剥がせなかったため剥がすのを諦めた。

新旧比較をすると上が今まで使っていたやつで、下が今回新たに買ったやつだ。

裏返したところ。裏面には薄いアクリルフィルムが基板を保護するように付いていた。短絡防止用だろうか？ヒートシンクを支えるプッシュピンも見えた。

ラベルを見る限り2019年6月製とみられ、比較的新しい製品なのも嬉しい。以前使っていたConnectX-3は製造時期不明だがCX342Aは2015年のモデルらしいので、だいぶ古い。

どこで見たか記憶にないがConnectX-3はサポート切れが近いか、切れていることもあるという話も見た気がするのでConnectX-4を入手できたのはよかった。メイン機もサーバー機もNICはConnectX-4なのでお揃いになった。

装着は既存のConnetX-3を外し、カードを刺す場所に元々ついてたチップクーラーを除去して取り付けたら、そのまま何事もなく普通に装着できた。

このクーラーがあるとヒートシンクに干渉するので、外す必要があった。

OpenWrt上でのセットアップ

OpenWrt 24.10.0にはドライバがなかったのでドライバを入れるのをやっていく。

SFP+以外に接続手段のない私の環境ではルーターのSSHに繋ぐ術がなかったので、R86S U1本体にキーボードとモニタを接続して作業した。

# まずはNIC周りの調査ツールを入れる
opkg update
opkg install pciutils ethtool

# ドライバの状態とかが見れる
# Kernel driver in use: igcならドライバがない
lspci -nnk

# ドライバを入れる。kmod-mlx4-coreは後で消した
opkg install kmod-mlx5-core
# JISキーボードだとアンスコが出せないので頑張って探して打った
modprobe mlx5_core

あとはこのまま再起動したら普通に繋がった。

そのまま使うと温度が上がりすぎた

現状片側のSFP+しか使っていないうえ、それも初日なので不具合は何もない。以前使っていたのも最低でも一週間は使ってないと不安定化しなかったので、まだ安定性は不明だ。

ただソケットが両方とも同じ形に見えるので、以前使っていたものよりは安定するのではないかと考えている。

温度については高くなりがちなようで、R86S U1本体のCPU温度が51度に達することもあった。

以前のNICの温度はデータがなく比較できないのだが、ここまで上がっていることはなかった気がしている。

NIC本体の温度は取得する方法が今のところ分かっていない。mstflintでmstflint -d xxxx -reg_name MTMPとかしたら、提供されていないとか出た気がするがログは取っていない。

参考までに以下の手順でレジスタの値が取れるっぽい。参考：man/mstreg

# 必要なツールのインストール
opkg install lspci mstflint
# MellanoxのデバイスIDの取得
lspci | grep Mellanox | awk '{print $1}'
# レジスタ名一覧
mstflint -d <デバイスID> -show_regs
# レジスタ値の取得
mstflint -d <デバイスID> -reg_name <レジスタ名> -g

関係ないがデータがないのはGrafanaに出しているデータを永続化していないため、tmpが吹き飛ぶと消える状態なので、ここはそのうち何とかしないといけない。

冷却対策

端的に言うとヒートシンクを剥がし、R86S U1に元からついてるクーラーを装着した。

まずはConnectX-4を取り出し、ヒートシンクを外し、グリスを塗りなおす。この時ついでに裏のフィルムも剥がし、熱が溜まらないようにした。

R86S U1に元々ついてたチップクーラー（前述の奴）を持ってきて、付け直した。

ファンレス冷却（ヒートシンク）とファン冷却（クーラー）で同時刻に温度を比べたところ、5度ほど下がるという結果が出たので、かなり効果があった。

新しい奴のヒートシンクの方が目が細かく作りもしっかりしているように見えるが、風のあるなしがそれほどまでに大きいということだろう。

しょぼいヒートシンクと小さいファンの組み合わせなのであまり意味がないだろうと侮っていたが、結果は歴然だった。恐らくこれはケースが小さく通気の余地が少ないこともあり、自然対流には期待できないということの表れなのだろう。

ベンチマーク

以下の構成で速度を計測した結果。そもそもLAN内でパケットがルーターの中を通っているかが謎なのでルーターNIC交換の影響があるかどうかは不明である。

Windows - R86S U1 - MikroTik CRS305-1G-4S+IN - Ubuntu

以前の計測結果はこっち。

Windows → Ubuntu

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  1.07 GBytes  9.13 Gbits/sec
[  5]   1.01-2.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   2.01-3.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   3.00-4.00   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   4.00-5.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   5.01-6.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   6.00-7.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   7.01-8.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   8.01-9.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   9.01-10.00  sec  1.08 GBytes  9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec                  sender
[  5]   0.00-10.00  sec  10.9 GBytes  9.33 Gbits/sec                  receiver

Ubuntu→Windows

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.08 GBytes  9.30 Gbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.62 MBytes       
[  5]   2.00-3.00   sec  1.08 GBytes  9.27 Gbits/sec    0   1.70 MBytes       
[  5]   3.00-4.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   4.00-5.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   5.00-6.00   sec  1.08 GBytes  9.29 Gbits/sec    0   1.78 MBytes       
[  5]   6.00-7.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   7.00-8.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec                  receiver

まとめ

前回と比較すると若干速度が落ちているが、サーバーとして動かしてて帯域を食っている分減っているのかもしれない。

交換前のConnectX-3が改造品だった話

以前使っていたPCB000620は元々SFP+片ポートモデルで、どうやらR86S U1では2ポートに改造していたようだ。

その影響なのか明らかに片方だけソケットの形が異なる。上側のほうが綺麗で、下側は使いこまれているのか、ややぼろ目に見える。

裏面を見ると片方ははんだ付けされているが、片方は差し込んであるだけ。シールも一度剥がしたものを貼り付けているのか、ペラペラしていてすぐに剥がせた。

おそらく上側（PORT 0）のはんだ付けされていた方が本来のソケットで、後から付けたやつ、つまり下側（PORT 1）が差し込んだだけの奴と思われる。

本来のソケットがぼろい方、後付けのが綺麗な方である。

奥の方の作りも異なる。左がPORT 0、右がPORT 1。

R86S U1のNICについているSFP+ポートの片方が不安定だった話で不安定だったのはPORT 1の方なので、改造して無理に取り付けていた方が不具合を発していたのだろう。本来できないことをしているので無理もない。

裏面の形も異なる。

恐らくよくある片ポートの奴にソケットを増設したのだと思う。

ソケットが片ポートしかなくても回路が実装されていることはよくあるので、この回路を流用しているのだと思う。回路もあるし、チップも恐らく同じなので原理的には問題なく動きそうに思える。

R86S U1のSFP+を使い始めたのは2025年の9月17日からだった^[1]が、同年12月13日にはリンクアップとリンクダウンが繰り返される事象を確認していて、同年12月25日にSFP+差し込みポートの変更を行ってからは一度も起きていない。

この時の気温が落ちたので金属製のSFP+ソケットの接触不良になったのではないか？と考えていたが、恐らくソケットではなく、基板本体との接触が寒暖差でダメになったのかもしれない。実際、先ほどの写真を見ても基板の穴からピンが出たり出ていなかったりするので、寒暖差でここが僅かに狂った結果、基板と接触不良になり、回路がチャタリングした結果、リンクアップとリンクダウンをミリ秒単位で繰り返す状態が起きていたのかもしれない。

もし、この理屈が正しければ強く押し込んではんだ付けすれば改善しそうではある。

あとがき

NIC交換の時に取り出した時、酷い埃まみれになっていたのでいい加減、冷却面をどうにかしたい気がしている。

普段は上に80mm角ファンを載せて運用しているため、埃の元凶はこれである。一旦はファンフィルターを買ってその場を凌ぎたいところだが、本質的にはちゃんとしたケースに収めてちゃんとしたクーラーをつけるのが最良だと思っている。

R86S U1を冷やそうとした作業の残渣にも書いているが、R86S U1の冷却機構は耐久性があるように見えず、また大して冷やしてもくれない。上にファンを載せて風を入れていると、いつの日か中が埃まみれになってしまうし、このケースはメンテナンス性が良くないので清掃も面倒だ。

理想論としてはこんな感じのケースに組み込めればよいだろう。これならメンテナンスがしやすいし、NICのヒートシンクも元の奴が生かせそうだ。ファンも40mm角ファンだろうから壊れても交換が容易である。

まぁこれは行き過ぎとしても、ラズパイのタワークーラーを載せるとか、そういうのができるとよいなとは思っている。基板むき出しは埃が溜まってショートしそうなので、ケースもあった方がいいだろう。

ただそれをどう実現するかが難しいところで、まず本来的には3D CADでケースやCPUクーラーをモデリングし、CNCで金属を削るという工程が必要だろうが、そんなものはないし、仮に3Dプリンタである程度何とかするにしても、3D CADの使い方を学ぶところからだと気が遠くなる話で、なかなか難しい…。

そもそもノギスで測っても測るたびに数ミリ単位の誤差が出るので、アナログな図面を書くことすら困難だ（多分ノギスの角度が微妙に毎回ズレてる）

こんなことであれば去年アリエクのセールでファンレスのR86SであるR86S-FLN100を買っておけばよかった。今は22.7万もするが、去年は11万くらいで、セールでは9万にまで落ちていて、買いだった。まぁあとからは何とでも言えるし、そもそも9万でも安くないわけで、言ったところで仕方がない。

現実案としては厚紙にボードを固定して外枠をペンで引き、ネジ穴については基板のネジ穴スレスレの何かを差し込んでマーキングすればそれなりに正確なものが取れるだろうから、一度手書きで図面を書き、それを基にアクリル板を加工し、簡単なケースを作るのが一段階目としてはよさそうな気がする。

ただCPUクーラーをどうするかという問題が根深く、ここが難点になると思う…。これはCPUクーラーを作るにはCPUのヒートスプレッダに乗ってくれるヒートシンクを持ったファンと、そのファンと基板のネジ穴を繋ぐ足が必要になるからだ。ヒートシンクと基板のネジ穴がマッチしないとならないので、恐らくこれが一番の難関だろう…。

たぶん厚紙→アクリル板がいければ図面を起こせるので、カスタムアルミケース業者に発注すれば、きちんとしたものも作れると思う。そこまでやるかどうかは未定だが…ｗ

接続端末の追加・変更などでDHCPの変更をしたいときに、既存の払い出し期限を待たずに即座に新しい設定を反映させる方法。

確認環境

やり方

1. DHCPの設定を必要に応じて変更する

   • LuCIからやってもいいが、ファイルベースでやる場合は/etc/config/dhcpを開いて直すとよい。形式は次のような感じ

     config host
            option name 'hoge'
            list mac '12:23:34:55:56:1A'
            option ip '192.168.12.10'
            option leasetime 'infinite'
     
     config host
            option name 'piyo'
            list mac 'F3:BB:11:22:34:2F'
            option ip '192.168.12.15'
            option leasetime 'infinite'
     

2. 接続している機器をすべて切断する

3. DHCPキャッシュを消して、dnsmasqを再起動する

   rm /tmp/dhcp.leases
   /etc/init.d/dnsmasq restart
   

4. 接続している機器を再接続する

Apacheでは.htaccessに以下の形式で書けばphp.iniの内容をサーバーの再起動なしに設定できるが、それと同等のことをnginxでもやる方法。

php_value key value

確認環境

やり方

1. PHPの設定を変えたいフォルダに.user.iniというファイルを作成する
2. php.iniと同じ形式で設定を書く
   例：

   upload_max_filesize = 20M
   post_max_size = 20M
   memory_limit = 256M
   display_errors = Off
   

3. 該当のPHPスクリプトにアクセスすると反映されている

管理領域など、自分以外などにアクセスを許可したくない場所にパスフレーズ付きクライアント証明書で制限を掛け、自分以外アクセスできないようにしたので、そのログ。

• 確認環境
  • サーバーと証明書作成環境
  • クライアント証明書を設定してアクセスした環境1
  • クライアント証明書を設定してアクセスした環境2
• 手順
  • CAやクライアント証明書の作成
  • WindowsのEdgeからアクセスする
  • AndroidのEdgeから確認する
• メモ
  • genrsaよりgenpkeyを使った方がいい
• トラブルシューティング
  • 証明書の選択画面が出ない
  • HTTPSでアクセスしているのに400エラーが出る
  • ED25519で証明書を作ったらなんか動かない
• 参考記事

確認環境

サーバーと証明書作成環境

クライアント証明書を設定してアクセスした環境1

クライアント証明書を設定してアクセスした環境2

手順

CAやクライアント証明書の作成

ここから行うコマンドはその全てでパスワード入力プロンプトが出るため、個別に流す必要がある。

1. 判別しやすくするためにファイル名の頭に付与する接頭辞を決める

   file_prefix=lyco_
   

2. CA（認証局）を作成する

   1. CAの秘密鍵の作成

      # -pass=pass:<PASSWORD>でもパスワードを掛けられるが平文になるらしいので-aes-128-cbcでパスワードを掛ける
      openssl genpkey \
        -algorithm EC \
        -pkeyopt ec_paramgen_curve:P-256 \
        -out ${file_prefix}ca.key \
        -aes-128-cbc
      

   2. CAの証明書署名要求の作成

      # 適当に好きな値を設定（以下は私の設定例）
      # 最低限CommonNameさえあればあとは何でもいいらしい？
      
      CountryCode=JA # 国コードを指定するっぽいが多分何を指定してもいい
      Province=Hyogo # たぶん県を指定するっぽいが多分何を指定してもいい
      Location=Kobe # たぶん市区町村を指定するっぽいが多分何を指定してもいい
      Organization="Lycolia Rizzim" # 組織を設定を指定するっぽいが多分何を指定してもいい
      CommonName=lycolia.info # FQDNを指定するっぽいが多分何を指定してもいい
      
      # CA証明書署名要求作成
      
      openssl req \
        -new \
        -key ${file_prefix}ca.key \
        -out ${file_prefix}ca.csr \
        -subj "/C=${CountryCode}/ST=${Province}/L=${Location}/O=${Organization}/CN=${CommonName}-CA"
      

   3. CAの証明書の作成

      openssl req \
        -new \
        -x509 \
        -key ${file_prefix}ca.key \
        -out ${file_prefix}ca.crt \
        -subj "/C=${CountryCode}/ST=${Province}/L=${Location}/O=${Organization}/CN=${CommonName}-CA"
      

3. クライアント証明書作成

   1. クライアントの秘密鍵の作成

      # -pass=pass:<PASSWORD>でもパスワードを掛けられるが平文になるらしいので-aes-128-cbcでパスワードを掛ける
      openssl genpkey \
        -algorithm EC \
        -pkeyopt ec_paramgen_curve:P-256 \
        -out ${file_prefix}client.key \
        -aes-128-cbc
      

   2. クライアントの証明書署名要求の作成

      openssl req \
        -new \
        -key ${file_prefix}client.key \
        -out ${file_prefix}client.csr \
        -subj "/C=${CountryCode}/ST=${Province}/L=${Location}/O=${Organization}/CN=${CommonName}-CLIENT"
      

   3. クライアント証明書の作成

      openssl x509 \
        -req \
        -in ${file_prefix}client.csr \
        -CA ${file_prefix}ca.crt \
        -CAkey ${file_prefix}ca.key \
        -CAcreateserial \
        -out ${file_prefix}client.crt \
        -subj "/C=${CountryCode}/ST=${Province}/L=${Location}/O=${Organization}/CN=${CommonName}-CLIENT"
      

4. クライアントに食べさせる用の証明書を作る（PKCS12形式）

   openssl pkcs12 \
     -export \
     -out ${file_prefix}client.pfx \
     -inkey ${file_prefix}client.key \
     -in ${file_prefix}client.crt
   

5. CA証明書の配置

   sudo mkdir /etc/nginx/ca
   sudo cp ${file_prefix}ca.crt /etc/nginx/ca
   

6. nginxのsnippetsの作成

   cat <<EOF | sudo tee /etc/nginx/snippets/ssl_verify_client.conf
   ssl_verify_client on;
   ssl_client_certificate "ca/${file_prefix}ca.crt";
   EOF
   

7. 各vhostの設定に埋め込む。https環境でないと設定しても意味ないので注意

   server {
     ...
     include snippets/ssl_verify_client.conf;
     ...
   }
   

8. 設定を再読み込み

   sudo systemctl reload nginx
   

9. 疎通確認

   curl -v \
     --cert ${file_prefix}client.crt \
     --key ${file_prefix}client.key \
     --cacert ${file_prefix}ca.crt \
     https://hoge.example.com/
   

WindowsのEdgeからアクセスする

1. 作成したPKCS12形式の証明書をWindowsにもってきてダブルクリックする。保存場所→現在のユーザーで次へ
   

   

2. 何もせず次へ
   

   

3. パスワードを入力して次へ
   

   

4. 何もせず次へ
   

   

5. スマートカードを挿入をキャンセルする
   

   

6. プライベートモードでEdgeを開き設定したvhostにアクセスして証明書を選択しなかったときに400エラーが出ることを確認
   

   

7. プライベートモードを閉じて再度アクセスしたときに証明書を選択したときに正常にアクセスできることを確認

AndroidのEdgeから確認する

1. 作成したPKCS12形式の証明書をAndroidにもってきて開く
2. 適当にインポートする
3. プライベートモードでEdgeを開き設定したvhostにアクセスして証明書を選択しなかったときに400エラーが出ることを確認
4. プライベートモードを閉じて再度アクセスしたときに証明書を選択したときに正常にアクセスできることを確認

メモ

genrsaよりgenpkeyを使った方がいい

Generation of RSA Private Key. Superceded by genpkey.

https://linux.die.net/man/1/openssl

トラブルシューティング

証明書の選択画面が出ない

httpsになってないと出ない。

http://localhostとかhttp://dev.localみたいなアクセスをしていると出てこない。

HTTPSでアクセスしているのに400エラーが出る

CAの証明書とクライアントの証明書でCNの値が同じだと自己署名証明書扱いされて上手くいかないのでCNの値を変える。

今回手順に書いた内容ではCAとクライアント用でCNの値が相違するよう書いているので手順通りにしていれば起きない。

ED25519で証明書を作ったらなんか動かない

openssl genpkeyで-algorithm ed25519にするとEdgeは上手く解釈できないっぽいので-algorithm EC -pkeyopt ec_paramgen_curve:P-256として作る必要がある。

今回手順に書いた手順通りにしていれば起きない。

参考記事

• とほほのOpenSSL入門 - とほほのWWW入門
• OpenSSL Quick Reference Guide - digicert.com
• 自己署名でクライアント証明書の作成方法（オレオレ証明書） | VPS Life
  • #google_vignetteによる全画面広告出るので注意
• Module ngx_http_ssl_module - nginx.org
• openssl-genpkey - OpenSSL Documentation - openssl.org

ログを取っていないので記憶で書いているし、順序は効率よくなるように変えているため、上手くいかない可能性がある。

• 前提
• 1. ConoHa VPS側でSSH接続できるようにする
• 2. ConoHa VPS側でnginxの設定
• 3. 自宅サーバー側で疎通可能にする
• 4. DNSの切り替えをする
• 5. nginxの設定を再読み込みする
• 6. 疎通確認
• 7. 掃除
• あとがき

前提

• IPv4接続だけをConoHa VPSに移し、IPv4はConoHa VPSに立てたリバプロから受ける
• ConoHa VPSスペックとしてOSはDebian GNU/Linux 13、メモリは512MB、CPU 1コアの最安インスタンス
• ConoHa VPSから自宅サーバーへはIPv6でリバースプロキシする
• ConoHa VPSから自宅サーバーへはHTTP通信で接続する
  • つまりIPv4側のTLS終端はConoHa VPS、IPv6側は自宅サーバーという構成
• ConoHa VPSのIPv6アドレスは2400:8500:2002:3175:160:251:206:248

1. ConoHa VPS側でSSH接続できるようにする

この時点ではSSHで繋げないためWeb画面からすべて行う。

1. SSHとICMPが繋がるようにする
2. SSHDの設定方法
3. 秘密鍵を作成し、公開鍵を取り出し.ssh/authorized_keysに追加
   • rootユーザーに追加した

2. ConoHa VPS側でnginxの設定

ここからはSSHで快適操作！

1. nginxをインストールして証明書置き場を作る

   apt update
   apt upgrade -y
   apt install -y nginx
   
   mkdir -p /etc/nginx/cert/lycolia.info
   

2. 証明書をSFTPで移す

3. 自宅サーバーへのリバプロ設定の作成。メンテナンスを最小限にするためにワイルドカードで飛ばす

   cat <<'EOF' | tee /etc/nginx/conf.d/lycolia-info.conf
   map $http_upgrade $connection_upgrade {
     default upgrade;
     ''    close;
   }
   
   upstream backend {
     server [2400:4153:8f01:c800:c14b:3f7a:2b54:353a];
   }
   
   server {
     http2 on;
     listen 443 ssl;
     server_name lycolia.info *.lycolia.info;
   
     ssl_certificate   /etc/nginx/cert/lycolia.info/fullchain1.pem;
     ssl_certificate_key /etc/nginx/cert/lycolia.info/privkey1.pem;
   
     client_max_body_size 500m;
   
     location / {
       proxy_pass http://backend;
   
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
   
       proxy_http_version 1.1;
       proxy_set_header Upgrade  $http_upgrade;
       proxy_set_header Connection $connection_upgrade;
     }
   }
   EOF
   
   # enbaleは勝手にやってくれた気がする
   systemctl enable nginx
   systemctl restart nginx
   

3. 自宅サーバー側で疎通可能にする

1. OpenWrtで80番ポートを開く
   1. LuCIを開き、Network→Firewall→Traffic Rulesで443を開けてるところに80を追加
2. ufwにある既存の設定からIPv4で443に繋ぐ設定を消す

3. ufwに新しい設定を足す

   # IPv6のみ許可する
   sudo ufw allow to ::/0 port 443
   # ConoHa VPSからの接続のみ80で受けられるようにする
   sudo ufw allow from 2400:8500:2002:3175:160:251:206:248 to any port 80
   

4. nginx側でConoHa VPSを信頼するようにする

   set_real_ip_from 2400:8500:2002:3175:160:251:206:248;
   real_ip_header X-Real-IP;
   

5. ConoHa VPSから来たX-Forwarded-Protoがhttpsならhttps、それ以外なら$schemeと解釈できるようなmapを書く
   これはConoHa→自宅サーバーがhttpで結ばれており、標準ではスキーマがhttpになってしまうが、それを回避しつつ、IPv6からの自作場への直アクセスがhttpないしhttpsだった場合は、そちらを取れるように変換するためである

   map "$realip_remote_addr:$http_x_forwarded_proto" $real_scheme {
     default $scheme;
     "2400:8500:2002:3175:160:251:206:248:https" "https";
   }
   

6. 対応するスキーマのバインドを全部変更する。以下はMastodonの例（4.5.4では二箇所ある）
   CGIであればCGIヘッダを書き換えるとよいと思うが、今回は該当がなかった

   +    proxy_set_header X-Forwarded-Proto $real_scheme;
   -    proxy_set_header X-Forwarded-Proto $scheme;
   

4. DNSの切り替えをする

1. AレコードをすべてConoHa VPSのIPv4に変更

5. nginxの設定を再読み込みする

DNSレコードが伝播するまでの間に粉うことでダウンタイムを最小化できる！

1. nginxの設定を再読み込みする

   sudo systemctl reload nginx
   

6. 疎通確認

1. 現時点で一般公開しているサイトに対し疎通するかどうか確認する

   curl -4 https://lycolia.info
   curl -4 https://blog.lycolia.info
   curl -4 https://mstdn.lycolia.info
   curl -4 https://eco.lycolia.info/wiki/
   

2. 落ちてたら設定を見直し再試行

7. 掃除

1. OpenWrtでIPv4向けの443を閉じる
   1. LuCIを開き、Network→Firewall→Traffic Rulesで443を開けてるところを消す
2. OpenWrtのDDNSスクリプトを無効化
3. nginxの設定でIPv4で443をlistenしてるところを全部消す

あとがき

やるだけやったが、結果的に現時点では全部撤回したので実証実験みたいになってしまった。

元々はフレッツ光クロスに切り替えてIPv4が失われることを想定して行ったが、よくよく考えたら切り替えたところで、今使っているルーターであるR86S U1のSFP+ポートが片方不安定で現状活用できないことや、IPv4のポート枯渇のためレスポンスが返せなくなる恐れを考えると、今やることではないなと思い、全撤回することにした。

ただまぁせっかくだしログを残していれば将来役に立つこともあるだろうというので残したが、色々あり構築時のログが消え去っていたので記憶を頼りに書くことになってしまったのは反省点である。

しかしR86S U1のSFP+が片側死んでいるのはどうしたものか。最近は何もかもすべてが高いのでおいそれと買い替えなどできないし…。まぁ現状困ってないし、IPv4は無料で手に入るし、別にクロスに変えなくてもいい気はした。

ところで全然関係ないけどWiFi 7を入れようと思ったもののSFP+の口が付いてるWiFiルーターは価格が高く、そうでなくとも、まともに速度が出る奴はどれもこれもデカく場所も取るので難しいね…。ひとまずやるとしたら1WくらいのトランシーバーでRJ45に変換するのが無難そうだと思った。その場合、10GtekのASF-10G-T80辺りはいい選択肢になりそうだ。

ルーターも最低でもトライバンドないと速度が出ないっぽいのでWXR18000BE10P辺りが5万円程度で、比較的小さいので無難だろう。この製品は過去に設置したことがあるのでサイズ的には問題ないことは確認済みである。今は手放しているので持っていない。経緯としてはかつてクロスを入れようとして導入したが、結局入れなかったし、デカくて邪魔だったので売った。

とはいえWiFiの速度には大きな不満があるので再導入を検討するのはありかもしれない。トランシーバーとセットで6万とかになるので眩暈がしそうだが…ｗ