Lycolog

さくらのレンタルサーバーにLet's EncryptのDNS-01 チャレンジの証明書を持ち込む方法。自動更新できないので実用性はないが、一時的に使う場合に有用。

前提条件

DNS-01 チャレンジの証明書を既に作っている。

やり方

1. 発行した証明書をhomeに移す

   sudo cp /etc/letsencrypt/live/<サイトディレクトリ>/*.pem .
   sudo chown $USER:$USER privkey.pem fullchain.pem
   

2. さくらのコンパネから設定するドメインのSSL設定を開く
3. SSL証明書の種類を選択→独自SSL
4. 秘密鍵にprivkey.pemをアップロードする
5. SSL証明書インストールでfullchain.pemの中身を張り付けて登録する

本記事はここ昨今のOpenWrtセットアップシリーズの続きである。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境であれば理論上IPv6ポートは全部使えるので、そんならポート指定なしでサーバーを建てられるのでは？というのでやってみた。

• 確認環境
• 前提条件
• 今回の要件
• やり方
  • サーバーとDNSの設定
  • ルーターのファイアウォールに穴をあける
• 備考
  • OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない
  • IPv4アクセスをどうするか？
  • Cloudflare Tunnelを使わない理由
• 関連記事

確認環境

前提条件

IPv4環境下でのHTTPSアクセスが可能で、かつ以下のセットアップが終わっているものとする。

• 自作ルーターを作っていくのにR86S U1を買ったのでOSのインストールをした
• R86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモ

今回の要件

ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりNATの再現を行うことで、関係ない端末が攻撃されないようにする。

やり方

サーバーとDNSの設定

1. nginxの設定を開きlisten [::]:443を追加して再起動
   1. sudo service nginx restart
2. サーバーマシンのIPv6を控える

   ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
   

3. Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する

ルーターのファイアウォールに穴をあける

1. LuCIに入りNetwork→Firewall→Traffic Rulesを開く

2. Addボタンを押し、次の要領で入力して保存
   General Settings

   項目	値
   Name	適当につける
   Protocol	TCP│UDP
   Source zone	wan
   Destination zone	lan
   Destination address	さっき控えたサーバーのv6IPアドレス
   Destination port	開けたいポートを半角スペース区切りで入れる

   Advanced Settings

   項目	値
   Restrict to address family	IPv6 only

3. 穴をあけたIP以外が外部から疎通しないことを確認

4. 穴をあけたIPが外部から疎通することを確認

備考

OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない

結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。

v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。

つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。

IPv4アクセスをどうするか？

現状は2案検討している。

1. どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
2. SNSなどのOGP対策で、簡単なプロキシを組んでおき、OGPだけ出るようにしておくのが無難に感じる。

2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。

Cloudflare Tunnelを使わない理由

Cloudflare Tunnelを使えば確かにこんなことはしなくて済むが、次の理由で使っていない。

一つは、オンプレなのに外部サービスに頼りたくない思いがあること、もう一つはCloudflareでドメイン管理する必要性があるはずだが、Cloudflareでドメイン管理すると今使っているメールサーバーのSPFレコードが正しく登録できない問題があることだ。

関連記事

• OpenWrtでOCNバーチャルコネクトのIPv6でポートを開ける方法のメモ
• OpenWrtを使ってLAN内DNSを設定する
• R86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモ
• 自作ルーターを作っていくのにR86S U1を買ったのでOSのインストールをした

OCNバーチャルコネクトはIPv6を使う限り全ポート使えるはずなので、これを利用してサーバーを立てる。

• 確認環境
• 手順
  • ルーター側の設定
    • 設定ファイルを編集する方法
    • LuCIでやる方法
  • サーバー側の設定
• 備考
  • 疎通検証に使える簡易サーバー
  • 疎通確認に使えるcurl例
  • 複数ポートの開き方
• 特定端末向けだけにポートを開けたい場合どうするか（未解決）

確認環境

• OpenWrt 24.10.0
• OCNバーチャルコネクト
• Windows 11 Pro 24H2
• Ubuntu 22.04.5 LTS
• nginx 1.26.1

手順

ルーター側だけでなくサーバー側も対応が必要。ファイアーウォールの穴をあけていても、IPv6でlistenしてないと受けられない。

ここでは一旦80番ポートを開けるものとして進める。

ルーター側の設定

設定ファイルを編集する方法

1. vi /etc/config/firewallで以下の行を追加

   config rule
           option name 'Allow-Server-IPv6'
           option src 'wan'
           option dest 'lan'
           option proto 'tcp udp'
           option dest_port '80'
           option family 'ipv6'
           option target 'ACCEPT'
   

2. service firewall restartでfirewallを再起動する

LuCIでやる方法

1. Network→Firewall→Traffic Rules

2. Addから次の要領でルールを追加
   General Settings

   項目	値
   Name	適当な名前
   Protcol	TCPとUDPにチェック
   Source zone	wan
   Destination zone	lan
   Destination port	開けるポートをスペース区切り

   Advanced Settings

   項目	値
   Restrict to address family	IPv6 only

3. 保存してSave & Apply

サーバー側の設定

ufwやWindowsファイアーウォールの穴は開いているものとする。IPv6向けに穴が開いている必要があるが、通常、ufw addやWindows ファイアーウォールの追加では勝手にv6の穴が開くはずなので意図的に塞がない限り追加時に開いていると思われる。

1. nginxの設定を開きlisten [::]:80を追加する
2. 外部から疎通確認して通ればOK

備考

疎通検証に使える簡易サーバー

PHP

php -S "[::]:80"でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。

Node.js

http-serverだとhttp-server -p 80 -a "[::]"でいける。serveは未対応っぽい。

疎通確認に使えるcurl例

IPv6はURL形式が特殊なのでアドレス部分を[]で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。

例：

curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"

複数ポートの開き方

option dest_portに値を半角スペース区切りで追加すればよい。

例：

option dest_port '80 443 8080'

連番で開ける場合は公式ドキュメントによると、'1024:65535'のような書式にすれば、連番で開けられるようだ。

例：

option dest_port '8000:8999'

特定端末向けだけにポートを開けたい場合どうするか（未解決）

設定にoption dest_ipを追加し、これで制御できると思うがIPv6が変わる特性上、基本的に難しいと思う。勿論、端末側でIPの変更を検知しOpenWrtの設定を書き換えるバッチを組むなどは出来ると思うが、ややこしい。

VLANを使って隔離するとかできればよいのかもしれないが、具体案は検討できていない。

基本的な考え方としてはWindowsマシンをWiFiのAPにした時と同じと思われる。ゲートウェイのDNSを参照するのでhostsを書き換えると成立する。

現状IPv6で行うのは現実的ではなさそうだ。

IPv6ではやる意味自体がないので本記事はIPv4向けだ。

確認環境

• OpenWrt 24.10.0

手順

SSHでやる方法

1. hostsを開いてIPとドメインを紐づける
   vi /etc/hosts
2. DNSを再起動する
   service dnsmasq restart

LuCIでやる方法

1. Network→DHCP and DNSを開き、DNS Recordsタブを選択
   

   

2. Addボタンを押し、紐づけるドメインとIPを設定する
   

   

3. Save & Applyボタンを押す

IPv6ではやる意味がない

IPv6だと外部DNSに登録したGUAとドメインの紐づけを利用してLAN内のアクセスが出来るためやる必要性がない。IPv6ではGUAを打っても、相手がLANの中にいれば外に出ずに、そのままつながる。これはtracertを打てば分かる。

今までLLMを使う場合、文書校正や整理、ERP辺りが多かったが、そろそろコード作成にも必要だなと感じたので取り組んでみた結果の初回の雑感。

Claude Opus 4との直接対話

LLMエージェントを使わない、チャットインターフェースでの直接対話で行ってみたこと。これはClaude Opus 4で行っている。

簡単なボイラープレートやプログラムが関の山

正直、LLMとの単純な対話で作れるのは3カラムのハンバーガーメニュー付きのような画面のボイラープレートや、WebでJSを使った画像判定スクリプトあたりが関の山だと感じている。

それ以上のものも作れる可能性はあるが、要件定義とコードレビューが大変なので厳しい気がしている。

プログラムの変換は苦手

まず私はTampermonkeyで5分ごとにAPIをポーリングし、結果をパースして条件に応じてOSに通知トーストを出す、400行ほどのスクリプトを作っている。

そこで、このソースコードを丸っと渡して、C#.NETに変換してほしいと頼んでみたが、これは失敗した。根本的にビルドが通らないコードが出てきて多少の修正でどうにかなるレベルでもなく、全くダメだった。

ファイル構成もよくなく、ModelやControllerレベルではファイル分割されているものの、1ファイルの中に複数クラスが納められていたり、何ともな結果だった。

TSDocを書いているため、上手く推論できればInterfaceやClassも作れると思ったが、これは難しいようだった。

特定の設定方法を書くのは得意

OpenWrtの特定の設定を書かせることは得意だった。これはそのまま適用できた。やはりスコープが限定されているのが得意だと感じた。

Claude Codeを少しつついてみた感想

ファイル保存などの手間がいらなくなる

当たり前だがローカルマシン上に結果を出力するため、チャットインターフェースのように頑張ってファイルを保存したり、ディレクトリを切る必要は全くなくなる。

ボイラープレートの作成は得意

PHPを利用したMVC構成で簡単なブログをフルスクラッチで作ってほしいといえば、それらしい形のものは出してくれた。

動くかどうかは全く試していないが、大まかなスケルトンを作って貰って、そっからいじっていくベースとしては使えるような気がした。

やっぱりプログラムの変換は苦手

adiaryのテンプレートエンジン部分をPHPに書き換えてほしいと依頼してみたが、やはり動かないものが出てきた。adiaryの設計が極めて複雑でコンテキストが読み取りづらいのはあると思うが、やはりこの手の作業は苦手なようだ。

現状で見えてきたこと

そこまで大して使ったわけではないが、とりあえず所感として。

恐らく小規模でコンテキストの薄いコードを書かせるのが筋がよさそう。これは複雑な要件をLLMに伝えるのは難しいし、考えるのも大変なのと、コード変換も400行レベルでも厳しいと感じたからだ。

つまり、既存システムの移行は苦手なのではないかと思っている。なのでWordPressをGoで作り直すみたいなことは相当難しいと思う。逆にSOLID原則やClean Architectureのような、スコープが狭く責務が明確なものは作りやすいのではないかと感じた。

また仮にLLMが全て書いてくれるとしても、人がレビューしないとバグがあった時に当たりをつけるのが大変とか、知らない仕様が紛れ込んだりとかもあるため、LLMに書かせすぎるべきではなく、あくまで補助ツール程度に留めておくのが良いと考えている。

LLMの制約を味方にする開発術という記事を見た感じ、複雑なタスクを段階的に分解し、LLMの処理可能な単位に分解することが重要だと感じている。つまりこれは疎結合のほうが向いているということだ。また標準化されていて、属人性がないコードのほうが制約が少なくなるので、LLMもやりやすくなるだろう。これは標準化されておらず、属人性が高いコードは往々にしてカオスで、判断軸がなく、LLMの思考がぶれるからだと思われる。

結局どうしていくか

正直まだどう実用化していくかの展望は見えていない。

何はともあれ使い続けていくことが大切な気はしているので、個人的にはClaude Codeを使い続けていきたい。少なくとも面倒なボイラープレートを書く部分については非常に優秀なので、大まかに作らせて微調整するみたいな用途では間違いなく活路がある。こういうのは引き出しが多ければ多いほど活用できるだろうから、基礎を忘れないように自学していくことも引き続き重要で、LLMに教えてもらうのもいいだろう。適切に使えばLLMからは多くの学びを得られる。