欢迎来到我的博客

Hugo 使用ガイド 対象バージョン：Hugo v0.168.0（Extended）。コマンドは macOS/Linux のシェル例を記載。Hugo 公式ドキュメントに基づき整理。テーマ固有の非公開設定は実際のテーマリポジトリに従ってください。 1. インストールとバージョン確認 macOS（Homebrew）： brew install hugo hugo version hugo env Linux では、対応するディストリビューションのパッケージ、または Hugo 公式がリリースするバイナリを利用できます。SCSS/Sass や一部テーマのアセットパイプラインを使う場合は、インストールしたバージョンに Extended 機能が含まれているか確認してください。 2. プロジェクトの作成 hugo new project myblog cd myblog git init 典型的なディレクトリ構成： myblog/ ├── archetypes/ # 新規記事のテンプレート ├── assets/ # リソースパイプラインで処理するアセット ├── content/ # Markdown コンテンツ ├── data/ # データファイル ├── i18n/ # テーマ UI の翻訳 ├── layouts/ # カスタムテンプレート（テーマを上書き可） ├── static/ # サイトのルートへそのままコピーされる ├── themes/ # ローカルテーマ／Git サブモジュール ├── hugo.toml # サイト設定（YAML など他形式も可） └── public/ # ビルド成果物（hugo 実行後に生成） Hugo 本体にはブログ用の完成した外観テーマは付属しません。利用可能なテーマや独自レイアウトがない場合、found no layout file for "html" のような警告が出ることがあります。 ...

Mac と iPhone でクライアント証明書を使用して mTLS サイトにアクセスする 本稿では、macOS と iPhone でクライアント証明書を使用して内部ネットワークの mTLS サイトにアクセスする方法を記録する。内容には CanoKey PIV、step-ca、Nginx、および iOS システムへの証明書のインストールが含まれる。 1. 環境と認証フロー 現在の環境は以下のとおりである。 CA：既存の CX-Homelab-CA Root CA と CX-Homelab-CA Intermediate CA。 証明書の発行：step-ca。 Web サーバー：Nginx 1.25.0。 テストサイト：https://www.home.arpa。 Mac クライアント：CanoKey PIV 9A。 iPhone クライアント：PKCS#12 ファイルを介してクライアント証明書と秘密鍵をインポート。 mTLS と通常の HTTPS の違いは、サーバーがクライアント証明書を検証し、クライアントもサーバー証明書を検証する必要がある点である。クライアント証明書には対応する秘密鍵が含まれている必要があり、.crt ファイルだけをインストールしても、通常はクライアント認証を完了できない。 基本フロー如下： クライアントが HTTPS サイトにアクセスする。 Nginx がクライアント証明書を要求する。 ブラウザーまたはシステムがクライアント ID を選択し、対応する秘密鍵を使用して TLS ハンドシェイクを完了する。 Nginx がクライアント証明書の有効性、証明書チェーン、用途を検証する。 検証に成功すると、サーバーは保護されたリソースへのアクセスを許可する。 需要注意すべき点として、クライアント証明書とサーバー CA の信頼は別々の問題である。クライアント ID をインストールしただけでは、デバイスがウェブサイトサーバー証明書の発行元であるプライベート CA を信頼できる状態になるわけではない。 2. Mac：CanoKey PIV 9A の使用 2.1 現在の構成 Mac では CanoKey の PIV 9A スロットにクライアント ID を保存している。macOS はスマートカード関連の仕組みを通じて証明書と秘密鍵を認識し、ブラウザーは TLS ハンドシェイク時にその ID を使用する。 ...

macOS と iOS でクライアント証明書を使用して mTLS Websitesにアクセスする 本文では、macOS および iOS デバイスでクライアント証明書を設定し、双方向 TLS（mTLS）を有効にした HTTPS ウェブサイトにアクセスする方法を説明します。例では、プライベート CA、step-ca、Nginx、PKCS#12、および PIV スマートカードを使用します。以下のドメイン名、証明書名、ファイル名、IP アドレスはすべて例なので、実際の値に置き換えてください。 1. mTLS 認証フロー 通常の HTTPS では主にクライアントがサーバー証明書を検証しますが、mTLS ではさらにサーバーがクライアント証明書を検証します。 基本フロー： クライアントが HTTPS サイトにアクセスする。 Nginx が TLS ハンドシェイク中にクライアント証明書を要求する。 ブラウザーまたはシステムがクライアント ID を選択し、対応する秘密鍵で署名する。 Nginx が構成に基づいてクライアント証明書、証明書チェーン、有効期限を検証する。 検証に成功すると接続は HTTP レイヤーに入り、サイト側のポリシーによってアクセスが許可されるかどうかが決定される。 クライアント ID とサーバー CA の信頼は、それぞれ独立した構成です。 クライアント ID：クライアント証明書およびそれに対応する秘密鍵。サーバーに対して自身を証明するために使用します。 サーバー CA の信頼：クライアントがウェブサイト用サーバー証明書の発行者を信頼する CA。HTTPS サーバーの同一性を検証するために使用します。 クライアント証明書をインストールしても、デバイスがプライベート CA を自動的に信頼するようになるわけではありません。 2. macOS：PIV ハードウェアキーの使用 クライアント秘密鍵が PIV 対応ハードウェアキーに保存されている場合は、秘密鍵をハードウェアデバイス内に保持し、秘密鍵ファイルのエクスポートを回避できます。ブラウザーがこの ID を使用できるかどうかは、macOS、スマートカードミドルウェア、鍵デバイス、およびブラウザーのサポート状況に依存します。 一般的な確認手順： PIV ハードウェアキーを挿入する。 macOS がスマートカードとその証明書を認識できることを確認する。 ブラウザーを開いて mTLS サイトにアクセスする。 ブラウザーがクライアント証明書を要求する場合は、対応する ID を選択する。 指示に従って PIN を入力する、またはハードウェア上の操作を完了する。 ページの表示結果とサーバーログを照合し、認証に成功したか確認する。 次のコマンドでシステムの状態を確認できます。 ...

Git のリポジトリ認証とコミット署名は 2 つの独立した段階です。前者はコードのプルやプッシュが可能かどうかを決め、後者は受信者がどのキーによってコミットが署名されたかを検証できるようにします。本文では 2 組の独立した FIDO2 SSH キーを使用し、この 2 つの用途を分けて管理します。 Git は SSH キーによるコミットとタグの署名をサポートしているため、Git の開発だけを行う場合は、YubiKey の FIDO2 機能を直接使用でき、GnuPG を追加で導入する必要はありません。OpenPGP による署名検証手順に従う必要があるプロジェクトでは、プロジェクトの要件に従って GPG 署名を選択してください。 ...

WAN6 は IPv6 アドレスを取得済みだが、OpenWrt でインターネット上の IPv6 に ping すると、直ちに次のエラーが返る： ping: sendto: Network unreachable 調査の結果、現場には mwan3 と一致するマーク付き unreachable ルールが1つ存在していた。そのルールを削除すると IPv6 が復旧した。このケースから、デフォルトルートが存在していても、実際のトラフィックがそれを使うとは限らないことが分かる。 本稿では実際の調査を記録する。インターネット上のソースアドレスはドキュメントの例示アドレスに置き換えている。デバイス名、ルール優先度、mark は自分のデバイスに合わせて確認すること。アンインストールコマンドは opkg を使用する OpenWrt 向けである。 デフォルトルートが存在しているのに、なぜまだ到達できないのか 最初の調査ではデフォルトルートが存在しないことを疑ったが、その後の出力にはソースアドレス条件付きのデフォルトルートがすでに表示されていた： default from 2001:db8:1234:5600::4 via fe80::1 dev eth1 proto static metric 512 pref medium default from 2001:db8:1234:5600::/64 via fe80::1 dev eth1 proto static metric 512 pref medium 調査中は一時的に通常のデフォルトルートも追加した： ip -6 route add default via fe80::1 dev eth1 metric 1024 それでも ping は直ちに Network unreachable を返した。この時点でデフォルトルートをさらに追加しても効果が已经没有なるため、実際の経路選択とポリシールールを確認する必要があった。 ...

rclone でローカルファイルを OpenList の WebDAV インターフェース経由でクォークのクラウドドライブにアップロードすると、OpenList のメモリ使用量が明らかに増加し、コンテナ OOM を発生させるすることもあります。調査の結果、重要なのは、クォークドライバーがアップロード前にファイル全体をキャッシュすることと、コンテナの統計値にファイルページキャッシュが含まれていることでした。 本稿では、OpenList v4.2.7、通常のクォークドライバー、Docker、cgroup v2 を対象として分析します。 다른ドライバーやその他のバージョンを使用する場合は、実装を再確認する必要があります。 クォークのアップロードでキャッシュが必要な理由 OpenList の WebDAV エントリーポイントは HTTP リクエストボディをファイルストリームにラップし、対象のストレージドライバーに渡します。この処理自体は、ファイル全体を一度にメモリへ読み込むものではありません。 しかし、通常のクォークドライバーはまずファイルの MD5 と SHA1 を取得します。WebDAV アップロード経路では、ファイルオブジェクトにこの 2 つのハッシュ値が提供されないため、ドライバーは次を呼び出します。 stream.CacheFullAndWriter(&up, io.MultiWriter(writers...)) この呼び出しは、ハッシュを計算する一方でファイル全体をキャッシュします。続いて、ドライバーはクォークに事前アップロードとハッシュの要求を送信します。即時アップロードができない場合は、キャッシュからデータを読み出し、分割してアップロードします。 ハッシュの計算にはごく少量のメモリしか必要ありませんが、実際に大きな領域を占めるのは、後から読み戻すために保持されるファイル内容だからです。 クォークが分割アップロードに対応していても、先ほどのファイル全体キャッシュが存在しないことを意味しません。 v4.2.7 の HybridCache には、メモリとファイルという 2 種類のバックエンドがあります。メモリが許可されている場合、キャッシュの拡張を試み、割り当てが制限された後でファイルに切り替えます。そのうち一部は匿名 mmap によって管理されています。そのため、Go の GC パラメータを調整するだけでは、すべてのキャッシュ使用量を制約することはできません。 rclone の --transfers は同時に転送されるファイル数を制御します。2 つのファイルを並行してアップロードすると、ファイル全体のキャッシュが 2 つ同時に存在する可能性があります。rclone 自身の --buffer-size を小さくしても、OpenList プロセス内のこの部分のキャッシュを直接制限することはできません。 一時ディレクトリがあってもメモリを消費する理由 たとえば次のとおりです。 "temp_dir": "data/temp" これは一時ファイルの保存場所を指定するだけで、毎回キャッシュをディスクへ書き込むことを強制するものではありません。この相対パスの実際の場所は、OpenList の作業ディレクトリと Docker のマウントを組み合わせて判断する必要があります。 さらに、v4.2.7 のキャッシュ拡張チェックではシステム全体の空きメモリ統計を使用しますが、このチェックではコンテナの memory.max と memory.current を直接読み取りません。そのため、ホストに空きメモリが残っていても、コンテナはまず自分自身のメモリ上限に達する可能性があります。 ディスク上の一時ファイルを使用するように変更 まずアップロードを停止し、設定をバックアップしてください。config.json のトップレベルに次を設定します。 ...

バイパスルーティングとして使う Armbian 上で、sing-box と WireGuard を同時に稼働させている。このルーター自身は社内ドメインを解決できるのに、その IP を DNS サーバーに指定した下流クライアントは毎回タイムアウトする。原因は DNS のマッチングルールではなく、sing-box が上位 DNS へ送るトラフィックが誤った出力インターフェースを選んでいたことにあった。 本稿のアドレスはすべて書き換えた架空の値であり、実際のネットワーク設定ではない。プライベートネットワークのトポロジ関係とプロトコルの挙動はそのまま保持している。 トポロジと症状 役割 例示アドレス 用途 下流クライアント 192.168.10.20 DNS クライアント バイパスルート LAN 192.168.10.254 / eth0 sing-box DNS の待ち受けアドレス バイパスルート WireGuard 10.77.0.11 / wg0 トンネルクライアント 社内 DNS 10.77.0.1:53 WireGuard ピア側の DNS トポロジは次の構成になる。 クライアント 192.168.10.20 │ DNS クエリ ▼ バイパスルート 192.168.10.254:53 (sing-box DNS 受信) │ 期待: wg0 から 10.77.0.1:53 へ問い合わせ ▼ WireGuard ピア側 DNS 10.77.0.1:53 社内テストドメインは service.home.arpa（例示）を使用した。観測された症状は以下のとおり。 ...

Armbian に sing-box TUN をデプロイした後、少し分かりにくい問題が発生しました：IPv6 の ping は通るのに、auto_redirect を有効化すると IPv6 の HTTPS 接続がタイムアウトする的情况です。 调查结果、障害の原因は IPv6 の公網ルートやプロキシノードではなく、Linux のループバックインターフェース lo に ::1/128 アドレスが存在しないことでした。本稿では、その切り分け Processes .Ordinal and 修正方法を記録します。 環境 Linux：Armbian、ARM64、6.18 系カーネル sing-box：1.14.x ネットワーク管理：Netplan + NetworkManager 透過プロキシ：TUN、auto_route: true、auto_redirect: true IPv6：上位ネットワークから自動設定され、インターフェースにはグローバル IPv6 アドレスと RA によるデフォルトルートが設定済み プライバシーを保護するため、実際の公衆アドレス、MAC アドレス、ルーターアドレス、ドメイン名、およびカスタム内部ルーティングテーブル番号は省略しています。以下の例にある ULA アドレスとテスト対象は説明용です。 障害的现象 IPv6 HTTPS を直接テストします。 curl --noproxy '*' -6 -v --connect-timeout 5 \ --resolve 'cloudflare.com:443:[2606:4700::6810:85e5]' \ https://cloudflare.com/ sing-box を有効化した後： * Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 比較テスト： ...

Docker がプライベート CA（例：step-ca）で発行した HTTPS 証明書を使用する場合、Docker Engine によるイメージの pull と コンテナ内のアプリケーションによる HTTPS アクセス の 2 つの状況を区別する必要があります。両者の証明書信頼ストアが同じとは限りません。 一、Docker Engine でプライベート CA を信頼する docker login、docker pull、docker push でプライベートレジストリにアクセスする場合に適用されます。 指定した Registry のみを信頼する（推奨） Registry のアドレスが registry.example.com:5000 であるとします。 sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000 sudo cp root_ca.crt /etc/docker/certs.d/registry.example.com:5000/ca.crt ディレクトリ名は、実際にアクセスする Registry のホスト名とポートに一致させる必要があります。デフォルトの HTTPS 443 ポートは通常省略できます。ca.crt は PEM 形式の CA 証明書にし、私鍵にしないでください。 確認： docker login registry.example.com:5000 Ubuntu / Debian ホスト全体で信頼する sudo cp root_ca.crt /usr/local/share/ca-certificates/my-root-ca.crt sudo update-ca-certificates Linux 上では、Docker は通常ホストのシステム CA 信頼ストアを使用します。通常 Docker を再起動する必要はありません。それでも有効にならない場合は、Docker のログと証明書設定を確認してから、再起動するかどうかを決めてください（再起動すると実行中のコンテナに影響する可能性があります）。 ...

Linux バイパスルーター上で UFW と sing-box TUN を同時に実行すると、誤診しやすい障害が発生することがあります。sing-box 自体は正常に動作しているのに、LAN 上のデバイスがバイパスルーター経由でインターネットにアクセスできない状態です。その時点で遮断されていた TCP ポートを許可したとしても、sing-box を再起動すると問題が再発することがあります。 本稿では、実際に観察された原因と、回帰検証待ちの修復方法を記録します。例はすべて文書予約アドレスを使用し、実際のネットワークには対応していません。 環境と症状 Linux バイパスルーター。LAN インターフェースは eth0、アドレスは 192.0.2.1（例示のみ）。 下流端末 192.0.2.20 は、IPv4 ゲートウェイとしてバイパスルーターを使用します。 sing-box の TUN インターフェース名は tun0 で、auto_route と auto_redirect を有効にしています。 UFW は既定で、許可されていない着信トラフィックを拒否します。 sing-box の主要設定： { "type": "tun", "interface_name": "tun0", "auto_route": true, "auto_redirect": true } 障害発生中のログは次のようなものです： [UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN DPT=24461 は一度の実行で観察された動的ポートにすぎないため、UFW に固定して書き込むべきではありません。OUT= が空であることから、このパケットは FORWARD 経路を通るだけでなく、本機の INPUT 経路に入り込んでいることが示唆されます。 NAT リダイレクトの追跡 sing-box の待ち受けを確認します： sudo ss -lntup | grep sing-box nftables を確認します： ...