Lycolog

Xperia 1 VIからXperia 1 VIIIに買い替えてからファイルマネージャー＋でのSDカードの読み込みが露骨に遅くなった。今までならSDカードの中身が瞬時に表示されていたところ、数秒かかるようになったのだ。

そこでSDカードを買い替えてみたらよくなったので、その記録。

• 買い替えようと思った切っ掛け
• 今回買ったSDカード
• これまで使ってたSDカードとの比較
• 高くなってしまったSDカード
• 増えた謎のメーカー
• あとがき

買い替えようと思った切っ掛け

ふとカメラアプリを眺めていたら高速書き込み可能なSDカードという表記があり、もしや使っているSDカードの規格が古すぎて最新のスマホだと相性で遅くなるのかもしれないと思い、SDカードを買い替えることにした。

今回買ったSDカード

SDカードといってもスマホ用なのでmicroSDカードだが、一般的にSDカードと呼ばれていると思うので、本記事ではSDカードで統一する。

Biwin microSDカード MS210 128GBというのを買った。 210MB/s読出・170MB/s書込らしい。

聞いたことのないメーカーだったがググると企業サイトが存在し、実在の企業でありそうなこと、価格コムに掲載のあるメーカーであることから問題ないと判断した。それに仮に問題があったとしても安いし、地雷踏みと思って買えばいいレベルの値段なので気にならない。

他のメーカーだと6,000円から1万円強ほどするグレードの製品だと思うが、Biwinのは私が買った時点では3,781円と安価だった。というか他が高すぎるだけな気もするが…。

これまで使ってたSDカードとの比較

左が今回新しく買ったBiwin、右がこれまで使ってたSanDisk。

スピードクラス10のマークが消え、ビデオスピードクラス30が増え、UHSスピードクラスが1だったのが3になり、アプリケーションパフォーマンスクラスも1から2に増えている。かなりのスペックアップだ。

SanDiskの方は購入当時1,880円で、買ったときは余りの安さにAmazonから偽物が送られてくるという噂があったほどの人気モデルだった。購入履歴を見ると、SanDiskのやつを買ったのは6年前だったようだ。

高くなってしまったSDカード

AmazonでSDカードを見てみるととんでもない価格になっている。メモリ高騰の影響をしみじみと感じる価格だ…。

以前使っていた1,880円で買ったSDカードも今見たら6,801円にもなっていて、中々えげつない。

今回の購入品はビデオスピードクラス30・UHSスピードクラス3・アプリケーションパフォーマンスクラス2の128GBで3,781円なので大変お買い得と言える。レキサーメディアのなんか5,880円もする。

余談だがSONYストアでは、かつて今回買ったものと同一グレードの品が2,680円で売られていたようなので、今回の3,781円でも高い方なのかもしれない。

増えた謎のメーカー

今回見ているとBiwinを始め、GIGASTONEやNextorageといった聞いたことがないメーカーが目立った。Biwinについては先述したが、どれもしっかりしたメーカーのようだ。

例えばGIGASTONEは日本法人を持っていて、オフィスがあるようだし、NextorageはSONYのメモリストレージ部門が独立してできた会社らしい。

しかしかつてSamsungやTranscendが辿ったように、SanDiskもすっかり激安メーカーから普通のメーカーになってしまった。今はかつてのSanDiskの地位にBiwinがいる感じだろう。時代の変遷を感じざるを得ない。

あとがき

ひとまず様々な記憶媒体が高騰する中、そこそこお安い価格でSDカードを買うことができ、読み込みの遅さも解決したので良かった。ついでに今時のストレージメーカー事情も知れて一石二鳥だ。

そういえば小学生の頃に、いつしか小指の先程の大きさで1TBのストレージが出るというのを吹聴していたが、いつの間にかmicroSDに1TBが出ていたので現実になっていることに気がついた。SDXCの規格上は2TBが上限なので、存在すること自体に不思議はないが、あくまで大きい方のSDカードの話だと思ってただけに意外だった。

調べたら今はSDUCと言って32TBまでの規格があるらしい。NANDは基本的に本来の容量より過剰にセルを積むことで書き込み回数を増やしてるので、32TBなんてすぐ壊れそうだが、大丈夫なんだろうか…。

あと全然関係ないけど既に今年の記事数が156記事に達し、2024年の153記事を超え、2025年の165記事に迫っていることに軽く戦慄している。まだ今年の半分が過ぎ去ったばかりだというのに、何とも恐ろしいペースだ…。主に先月が凄まじいが、今月も既に1日1記事ペースを超えてるので、恐ろしいペースである…。

書きたいネタが無尽蔵にあるので減速するかどうかは謎だが、幸い今週末は土日とも遠征予定があり、来月にも遠征予定があるので減速するかもしれないし、しないかもしれない…。

Mastodonの方にはちょろっと書いたけど、サイト設立から25周年経過したというネタも記事に出来てないんだよなぁ…。

折角LAN内10GbEにしたし、WiFi7が出てずいぶん経つし無線LAN環境も充実させたいよなぁ…と思い、WiFi7対応のWANポート10GbE対応ルーターとしてASUS RT-BE92Uを買ったので、その関連のログ。

• 今回買ったもの
• 開封の儀
  • ASUS RT-BE92U
  • ASF-10G-T80
• 設置後の風景
• セットアップの儀
• 速度計測
  • AP・サーバー間の通信測定
    • [物理線経由] AP → サーバー
    • [物理線経由] サーバー → AP
  • ノートPC
    • [WiFi経由] ノートPC → サーバー（旧AP）
    • [WiFi経由] ノートPC → サーバー（新AP）
  • スマホ
    • [WiFi経由] スマホ → サーバー（旧AP）
    • [WiFi経由] スマホ → サーバー（新AP）
  • まとめ
• あとがき

今回買ったもの

• ASUS RT-BE92U
  • 10GbE WANポートを1口搭載したWiFi7対応ルーター
  • 箱が質素だが、ナフサ不足の影響だろうか…。台湾とて例外ではないはず
• 10Gtek SFP+ to RJ-45トランシーバー ASF-10G-T80
  • RT-BE92UはRJ-45しか対応してないので変換用
• 10Gtek 10GbE SFP+ DAC Twinaxケーブル SFP-H10GB-CU0.5M
  • これは間違えて買ったので使わなかった

開封の儀

ASUS RT-BE92U

箱を開けるとこんな感じ。紙の繊維を圧縮したようなケースや紙箱に入った、最近ではよくある梱包。

付属品は壁掛けフック、ACアダプタ、壁掛けフックを固定するネジ、CAT6 LANケーブル。

LANケーブルは同梱品にありがちな極太で硬そうなやつ。

ASF-10G-T80

トランシーバーは金属製の缶に入っており、やたら凝っていた。

手持ちのCAT6Aケーブルを挿すとこんな感じ。

設置後の風景

Before	After

びふぉーの写真が去年のものなので完全に前後の写真という訳ではないが、大体こんな感じということで…。

例えばBeforeとAfterでは右側から伸びているコンセントの本数が違うが、これは今回の施工とは関係なく、もっと前に配線変更で減らしたものである。

セットアップの儀

地味にハマるポイントがあり、苦労した。

1. まずL2スイッチにWANポートを接続しセットアップを始めた
2. 192.168.50.1が初期IPで、このIPがあることを確認して、http://192.168.50.1に接続するものの何故か繋がらない
3. http://www.asusrouter.comに繋げとマニュアルにあったので繋ぐが繋がらない
4. http://192.168.50.1:8443/に繋ぐといい情報を得たが繋がらない
5. http://www.asusrouter.com:8443/にも繋がらない
6. https://192.168.50.1:8443/にもhttps://www.asusrouter.com:8443/にも繋がらない
7. 有線だから悪いのかと思い、WiFi経由で接続を頃見るが繋がらない
8. WANポートの線を抜きスタンドアロンにして、WiFi経由で同じことをやり直したがやはり繋がらない
9. しかしWiFiのデフォルトゲートウェイは192.168.50.1を挿していた
10. ブラウザ経由で操作できないのはなんとも承服しがたいがASUS Routerアプリを試すことにした
11. アプリを起動しルーターに接続すると「モデルをルーターのWANポートに接続したことを確認してください。」というメッセージが表示され、プログレスバーが100%になるとエラーで死んだ
    

    

12. リトライすると通ったので無視することにした。WANに直接刺さってないと上手く動かないのかもしれない
13. ISPがどうのこうのなどWAN前提のメッセージが何度か出たが全部無視した
    

    

14. WANの種類を選べと言われたがAPにWANもクソもないのでDHCPのまま進めた
    

    

15. 「ネットワークを再アクティブ化」というのが出たので数分見守った。再起動してるだけだと思う
    

    

16. 動作モードをタップ
    

    

17. アクセスポイントモードを選択し適用
    

    

18. ここまで行うとブラウザからhttp://192.168.50.1への接続に成功したが、あんまり納得できなかった
19. 管理画面に入ったら詳細設定→LAN→スイッチ制御に遷移しジャンボフレーム有効をON
20. 管理→システム→サービス→SSHを有効にする、で「LAN only」
21. SSHのポートを適当に指定し、パスワードログインを許可「いいえ」、認証済みキーに公開鍵を貼り付けて設定
22. ここから先はSSHに入れた
23. OSはBusyBox v1.24.1で、何故かIPv6がなく、iperf3が最初から入っていた。どうやらこのルーターにはIPv4でアクセスするしかなさそうだ
24. ホームディレクトリは/tmp/home/rootで、再起動したら消えそうな勢い
25. ルートディレクトリは以下の構成で、ルートにはASUS関連のファイルが直置きで散らばっていた

    /.diag
    /.sdn
    /asusdebuglog
    /asusfbsvcs
    /avahi
    /bwdpi
    /cfg_mnt
    /confmtd
    /dm
    /etc
    /home
    /mnt
    /nc
    /netool
    /notify
    /share
    /var
    

速度計測

AP・サーバー間の通信測定

APからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

なお、このケースではAPのCPU使用率が100%に張り付いていた。

1. [AP] RT-BE92U (OUT RJ-45 10GbE)
2. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
3. [トランシーバー] ASF-10G-T80 (10GbE)
4. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
5. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
6. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
7. [サーバー] Ubuntu 24.04.4 LTS

[物理線経由] AP → サーバー

[ ID] Interval Transfer Bitrate Retr
[ 4] 0.00-10.00 sec 4.42 GBytes 3.79 Gbits/sec 0 sender
[ 4] 0.00-10.00 sec 4.42 GBytes 3.79 Gbits/sec receiver

[物理線経由] サーバー → AP

[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.99 GBytes 2.56 Gbits/sec 135 sender
[ 5] 0.00-10.00 sec 2.98 GBytes 2.56 Gbits/sec receiver

ノートPC

ノートPCとサーバーをAPを挟んで繋いだ時のiperf3の測定結果。

[WiFi経由] ノートPC → サーバー（旧AP）

従前のAPを利用し、ノートPCからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

1. [ノートPC] Windows 11 Home (WiFi 6E)
   • NEC Lavie PC-GN20D72DYEDYH2YAA
2. [旧AP] WSR-1800AX4P (IN Wi-Fi 6→OUT 1GbE LAN)
3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A)
4. [L3SW] R86S U1 (IN RJ45 2.5GbE→OUT SFP+ 10GbE)
   • ここでRJ45とSFP+をソフトウェアでブリッジしている（こいつにはNICが2枚刺さってる
5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
8. [サーバー] Ubuntu 24.04.4 LTS

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec   148 MBytes   124 Mbits/sec                  sender
[  5]   0.00-10.03  sec   147 MBytes   123 Mbits/sec                  receiver

[WiFi経由] ノートPC → サーバー（新AP）

今回購入したAPを利用し、ノートPCからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

1. [ノートPC] Windows 11 Home (WiFi 6E)
   • NEC Lavie PC-GN20D72DYEDYH2YAA
2. [新AP] RT-BE92U (OUT RJ-45 10GbE)
3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
4. [トランシーバー] ASF-10G-T80 (10GbE)
5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
8. [サーバー] Ubuntu 24.04.4 LTS

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  1.28 GBytes  1.09 Gbits/sec                  sender
[  5]   0.00-10.03  sec  1.27 GBytes  1.09 Gbits/sec                  receiver

スマホ

スマホとサーバーをAPを挟んで繋いだ時のiperf3の測定結果。

[WiFi経由] スマホ → サーバー（旧AP）

従前のAPを利用し、スマホからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

1. [スマホ] Xperia 1 VIII (WiFi 7)
2. [旧AP] WSR-1800AX4P (IN Wi-Fi 6→OUT 1GbE LAN)
3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A)
4. [L3SW] R86S U1 (IN RJ45 2.5GbE→OUT SFP+ 10GbE)
   • ここでRJ45とSFP+をソフトウェアでブリッジしている（こいつにはNICが2枚刺さってる
5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
8. [サーバー] Ubuntu 24.04.4 LTS

[ ID] Interval           Transfer     Bitrate         Retr
[433]   0.00-10.00  sec   312 MBytes   261 Mbits/sec   18            sender
[433]   0.00-10.01  sec   311 MBytes   260 Mbits/sec                  receiver

[WiFi経由] スマホ → サーバー（新AP）

今回購入したAPを利用し、スマホからサーバーに飛ばしたiperf3の測定結果。構成は以下の通り、速度はその口がサポートしている最大を記載。

1. [スマホ] Xperia 1 VIII (WiFi 7)
2. [新AP] RT-BE92U (OUT RJ-45 10GbE)
3. [LANケーブル] CAT 6A RJ45 LAN (CAT6A 10GbE)
4. [トランシーバー] ASF-10G-T80 (10GbE)
5. [L2SW] MikroTik CRS305-1G-4S+IN (SFP+ 10GbE)
6. [DAC] 10Gtek CAB-10GSFP-P0.5M-30 (SFP+ DAC 10GbE)
7. [NIC] Mellanox ConnectX-4 Lx (SFP+ 10GbE)
8. [サーバー] Ubuntu 24.04.4 LTS

[ ID] Interval           Transfer     Bitrate         Retr
[512]   0.00-10.00  sec  1.40 GBytes  1.20 Gbits/sec    1            sender
[512]   0.00-10.01  sec  1.40 GBytes  1.20 Gbits/sec                  receiver

まとめ

公式商品ページには「最大9700Mbpsの超高速トライバンドWiFi 7」とあり、10GbEのWANポートがあることから10Gbpsを期待したものの、10Gbps出ることはなかった。所詮無線は無線ということか…。

とはいえ、以前のAPと比べたときの速度は4～8倍と格段に上がっており、WiFi経由での写真の転送もかなり早くなっており、全体的な満足度は高い。

今までルーターと言えば数千円のものを常用してきており、これは3万円強したが、よい買い物だったと思う。

あとがき

ルーターの置き方やアンテナの方向に無理があるので、ラックにぶら下げておけるような紐か何かがあると便利かもなぁと思ったので、そのうち整備したいところだ。

或いは壁美人を使って壁に付けるのもなくはないかもしれないが、ケーブルを伸ばすとケーブルに埃が溜まって嫌なので、それはしないかもしれない…。

旧AP (1GbE, WiFi6)	新AP (10GbE, WiFi7)

ひとまず10GbEネットワークが広がったので満足度は高まった。

上図ではWiFi APの部分以外も微妙に変わっているが、これはConoHa VPSを前段に置く対応を取りやめたことでPPPoEが復活したことを反映しているためだ。要するに別件の変更がごっちゃになっている（）

あとは無線は破線の方が分かりやすいというのでWiFiを破線化している。というか、これは元来破線だったのがいつの間にか消失していたのを戻している感じである。

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

• 確認環境
  • サーバーと証明書作成環境
  • クライアント証明書を設定してアクセスした環境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万とかになるので眩暈がしそうだが…ｗ