Lycolog

昨年フレッツ光クロス、10Gbps対応に関する覚書を書いてしばらく経つが、いよいよ10GbE対応のための環境を作ろうと思ったので、その記録を残していく。

第一弾はR86S U1を買ったので、その購入録を書いていく。今回は端末の起動試験程度に留め、本格的なセットアップは次の記事で書こうと思う。

• 買ったもの
• セットアップ時にあるといいもの
• 初回起動
• OS導入
• 開梱の儀
• 分解
• あとがき

買ったもの

今回購入したのは中華性の怪しい10GbE自作ルーターマシンとして名高いR86S U1だ。もう話題になって数年経っているので旬は過ぎていると思うが、依然として10GbEルーターとして安価な選択肢としてアリだと思う。

買った後で気が付いたが、U2のほうがスペックが上で値段同じなのでU2を買ったほうがいい。

セットアップ時にあるといいもの

• HDMI to Micro HDMI変換アダプタ
• SDカード or USBメモリ
• rufusやbalenaEtcherなどのイメージを焼く手段
• MSYS2

初回起動

私が購入したものはeMMC内にOSが上手く入っていないのかgrubが表示されるだけで、マニュアル操作でも起動イメージが見当たらずｍOSを起動することができなかった。

どの道プリインストールされているOSは中国語で役に立たないという話だったのでOSのセットアップを行うことにした。

OS導入

汎用PCへのインストール手順は公式情報である、[OpenWrt Wiki] OpenWrt on x86 hardware (PC / VM / server)が参考になる。

1. リリース一覧を開き最新の安定板を辿り、x86→64に進む
2. generic-ext4-combined-efi.img.gzをダウンロードする
3. sha256sum openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzでハッシュを確認
4. gunzip openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzで展開する
   • Explzhだと上手く解凍できなかったのでMSYS2からgunzipを叩いて対処した
5. 展開して出てきたimgファイルをSDカードかUSBメモリに焼く
6. imgファイルを焼いたメディアをR86Sに差し込む
7. R86Sの電源を入れPOST画面が出たらDELキーでBIOSに入る
   • 通電時に勝手に電源が入るため注意
8. 起動順序の優先順位を差し込んだメディアに変更する

開梱の儀

梱包状態。安い中華製品にしてはなかなか丁寧だ。

箱もしっかりしている。

横の小さな箱にはMicro HDMI -> HDMIケーブルが付属していた。これは少し親切だ。

開梱すると本体とACアダプタが見えた。やはり梱包が丁寧だ。

箱の底にはマニュアルと検査証、六角が入っていた。この六角は本体を開けるためのものだが、なめてしまい役に立たなかった。

ネットワークインターフェースはSFP+が2口、2.5GbEイーサーが3口。他に電源用USB-C、USB3.0x2、USB2.0x1、SDカード、Micro HDMIといった感じだ。

表面にはケースファンと冷却用のフィンがついている。デザインも悪くない。

裏面と片側面にはゴム足がついており横置きにも縦置きにも対応している感じだ

分解

付属の六角がなめてしまい役に立たなかったのでちゃんとしたのを買ってきた。対応するのは1.5mmだった。

表のふたを開けるとNVMeSSDスロットが見える。ネジ穴的に一番長い奴しか無理だろう。

本体をパカっと二つに。どうやらマザーボードは三枚くらいに分割されているようだった。

あとがき

EFIイメージかBIOSイメージかは、好みで選んでいいという記事を何個か見たが、BIOSイメージだと起動しなかったため、EFIイメージのほうがいいかもしれない。

参考までに手持ちのAMD64マシンにBIOSイメージを刺したところ、そもそも認識すらしなかったためダメなのかもしれない。24.10固有の問題なのかどうかはわからないが、今時はUEFIが推奨される環境であると思われるため、EFIイメージで問題ないと思われる。

ひとまずこれで10GbE環境への一歩を踏み出せたと思う。LANが構築でき、現状の環境でWAN込みで安定稼働させられたら実際に10GbE契約もしていきたいところだ。

次回は内臓のeMMCにOSを入れていきたい。

このコマンドをcronとかで回し続けてれば行けそう

事前準備

Value-Domainのコンパネから登録対象のDNSレコードにaaaaレコードを足しておく。

コマンド

ipaddr=$(ip a | grep 'scope global temporary dynamic' | perl -ne '/inet6 ([^\/]+)/; print $1')
echo 'https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=<ドメイン>&p=<パスワード>&h=<ホスト名>&i='$ipaddr

凡例

参考

• ダイナミックDNS機能 | バリュードメイン ユーザーガイド

どういう条件の時にCookieがサブドメインに送信される状態になるかについてのメモ。

要約

レスポンスヘッダにdomainディレクティブがあると送信される。なければされない。

Set-Cookie: hoge=piyo; domain: example.com

EdgeやChromeのDevTools上ではApplicationタブのCookieのDomainが.example.comならサブドメインに送信される状態、example.comならされない状態で区別できる。

サブドメインに送信されないパターン

以下のようにdomainディレクティブがなければ、そのドメインでしか使えない。

Set-Cookie: hoge=piyo

WSL上のUbuntuで動作するnginxでHTTPSに対応したサーバーを作る方法。実機でも同様の手順でいける

確認環境

手順

1. Windows側にmkcertを入れる
2. mkcertで証明書を作る
   • mkcert sandbox.test
3. 以下のpemファイルが生成される
   • sandbox.test.pem
   • sandbox.test-key.pem
4. 生成されたpemファイルを/etc/nginx/conf.d/ssl/に移動する

5. /etc/nginx/conf.d/sandbox.test.confを作成し、以下のような記述をする

   server {
       listen       443 ssl;
       client_max_body_size 100m;
       server_name  sandbox.test;
   
       ssl_certificate     conf.d/ssl/sandbox.test+1.pem;
       ssl_certificate_key conf.d/ssl/sandbox.test+1-key.pem;
   
       access_log   /var/log/nginx/sandbox.access.log;
       error_log    /var/log/nginx/sandbox.error.log;
   
       # ファイルホスト用
       #  location / {
       #    root /usr/share/nginx/html/sandbox;
       #    index index.html;
       #    try_files $uri /index.html =404;
       #  }
   
       # APサーバーへのリバプロ用
       location ~ ^/.*$ {
           rewrite ^/.*$ / break;
           proxy_set_header X-Request-Path $request_uri;
           proxy_set_header X-Host $host;
           proxy_pass  http://127.0.0.1:9999;
       }
   
       # fastcgi用
       location ~ \.php$ {
           root  /usr/share/nginx/html/sandbox;
           fastcgi_pass unix:/run/php/php8.0-fpm.sock;
           fastcgi_index index.php;
           include fastcgi_params;
           fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
       }
   }
   

6. nginxを再起動する
   • sudo service nginx restart

他の端末に証明書を撒く方法

mkcertのRoot CAをエクスポートして他の端末に突っ込めば、他の端末でもpemが流用できる

• mkcertで作ったCA証明書をエクスポートする方法
• mkcertで作ったCA証明書をインポートする方法

日頃仕事で開発をしていたり、そこら辺のWebサービスの振る舞いを眺めていると不思議というか、奇妙というか、端的に言うとありえないリクエストを投げているものを見かける。

一例としては次のようなものを見たことがある。

フロントエンドで第三者サービスに問い合わせクライアントIPを取得し、それをバックエンドに送る

これの問題点はまずクライアントのIPを幾らでも捏造できることだ。

クライアントからバックエンドに投げている値など幾らでも偽装できるため、その中にクライアントのIPアドレスを含めるのは何の価値もない。

他にも第三者のサービスを利用しているので、そこが落ちてたり、仕様変更があったりすると使えなくなる。

サーバー間のHTTP通信でクライアントのIPをREMOTE_ADDRヘッダーに入れて送る

具体的にはSSRを利用しているNext.jsのサーバーサイドレンダリング側で、クライアントのIPを取得し、後ろにいるAPサーバーにHTTPで投げるときにREMOTE_ADDRヘッダーに入れて送っていたケースだ。curlで表すと次のような形式だ。

curl -H 'REMOTE_ADDR: <ここにIP>' http://example.com

サーバー側はクライアント側のIPをサーバー側が設定するので、このリクエストには意味がない。トラフィックと実装コードの無駄といえる。

サーバー側が何を基にして設定しているかは実装依存だと思うが、恐らく一般的にはトランスポート層より下ではないだろうか？

あとがき

いわゆるフロントエンドエンジニアや、プログラミングスクール卒などの意識が低いエンジニアらが書いたコードを見ているとこのようなものが散見される印象だが、もう少しちゃんと考えて実装して欲しいと思う。

なんというか、最低限常識とされている部分は理解しておいてほしいなというのはすごく思う。