ホームラボ構築・HTTPS対応

やろうとしたこと

• 内部DNSと外部公開（Cloudflare Tunnel）でURLを統一したい
• https://hoge.fuga.com のような「覚えられるURL」で家庭内サービスへ安全にアクセスしたい
• Synology をリバースプロキシ兼TLS終端として運用

発生した不具合・課題

• Chromeで ERR_CERT_COMMON_NAME_INVALID が発生しHTTPS接続が警告扱いになる
• Let’s Encrypt証明書は取得できているのに解消しない
• 内部DNS・Cloudflare・リバースプロキシのどこが原因か切り分けが困難
• Synology GUIからの証明書取得はMAP-E環境のためHTTP検証に失敗
• acme.sh のDNS-01 challengeも最初は失敗（Cloudflare API設定ミス）
• さらに成功後も警告が残り、証明書割り当て済みにも関わらずエラー継続

解決方法

1. Cloudflare APIを利用して DNS-01 challenge（acme.sh）で証明書取得
2. ワイルドカード証明書を作成 fuga.com + *.fuga.com
3. Synologyへ「既存証明書のインポート」
4. DSM / リバースプロキシ / Webサービスへ証明書を再割当
5. NAS再起動

結果：

• 内部LAN
• 外部（Cloudflare Tunnel）

両方でHTTPS警告が解消し、同一URLでアクセス可能になった。

なぜ解決できたか（理論）

1. HTTP検証が失敗した理由

   自宅回線は IPv6 MAP-E のため、外部からポート80へ到達できずLet’s EncryptのHTTP-01認証が成立しなかった。

   → DNS-01 challenge に切替で解決

2. 証明書エラーが消えなかった理由

   SynologyのnginxはTLSハンドシェイク時、

   1. SNI確定前にデフォルト証明書を提示
   2. その後にリバースプロキシで振り分け

   という動作をする。

   そのため*.fuga.com のみの証明書では初期提示証明書とホスト名が一致せずブラウザが拒否した。

   つまりブラウザは「アクセスしたドメイン」ではなく「最初に提示された証明書」を検証していた。

   → fuga.com をSANに含めたことで一致し解消

3. Cloudflareでは問題が出なかった理由

   外部アクセスでは

   ブラウザ → Cloudflare → 自宅

   となり、証明書はCloudflareが提示するためNAS側の証明書問題が隠れていた。

成果

• 内外どちらでも同一URLアクセスを実現
• 家庭内通信はローカル接続（トンネル回避）
• 安全なHTTPS通信確立
• リバースプロキシ基盤完成（サービス追加可能な状態）

学び

• HTTPSの検証は「どの証明書をサーバが最初に提示するか」で決まる
• ワイルドカード証明書はルートドメインを包含しない
• MAP-E環境ではDNS-01 challengeが実質必須
• リバースプロキシ運用では証明書設計がネットワーク設計と同じくらい重要

参考

masao-tec.com

Surface再生とホームラボ基盤整備（OMV・DNS・リバースプロキシ）

やろうとしたこと / 目的

• Surface Pro + OpenMediaVault を常時稼働サーバとして利用
• 無線LAN接続で設置場所の自由度を上げる
• Docker コンテナ（Dashy等）の運用開始
• 家庭内向け名前解決（home.arpa）の構築
• LAN内サービスをドメイン名でアクセス可能にする

発生した課題・問題

Surface / OS 周り

• 無線LANドライバが認識されない
• 画面消灯すると Wi-Fi も停止してサーバが切断される
• ログイン情報を忘れてログイン不能

Docker / アプリ

• Dashy コンテナが起動失敗
• not a directory マウントエラー
• Dashy が頻繁にクラッシュ
• ERR_HTTP_HEADERS_SENT

DNS / ネットワーク

• 名前解決が不安定
• dig では解決するが ping では解決しない
• Mac のスリープ復帰後に接続失敗
• Synology DNS が外向き名前解決できていない
• デュアルNIC（メインLAN + 隔離LAN）で誤ったIPが返る
• immich.home.arpa → 192.168.10.21
• 隔離側からは 192.168.20.21 に居るため到達不可

⸻

解決方法

Surface

• rootログインから設定修正
• サスペンド（スリープ）を無効化
• 画面消灯のみ有効に設定

→ Wi-Fi接続を維持したまま省電力化

nano

• Ctrl + O 保存
• Ctrl + X 終了

Docker / Dashy

• ホスト側に 実ファイルを作成してから bind mount
• conf.yml を正しく配置
• Dashy設定修正によりクラッシュ解消

DNS

• Synology DNS Server に home.arpa のプライマリゾーン作成
• DHCPでDNS配布をSynologyに統一
• DNSフォワーダを有効化
• フォワーダ方式を「先にフォワード」に設定

名前解決不安定の対処

原因：

• 内向きDNSのみ解決
• 外向きDNS解決不可
• Macがキャッシュした失敗を保持

対策：

• Synology DNSで外部DNSへフォワード設定

→ 内外両方の名前解決が可能になり安定

デュアルネットワーク問題

• Synologyが2つのIPを持つためAレコードが片側IPになる問題発生
• Split horizon DNS 相当の問題と判明
• 完全な自動解決は困難なため、必要に応じIP直打ち併用の方針

理論的説明

サスペンドと画面消灯

LinuxのサスペンドはCPU・NIC・USBバスへの給電が停止するため、Wi-Fiインターフェースも停止する。画面消灯は単なるDPMSでありネットワークは維持される。

digとpingの差

• dig → DNSサーバへ直接問い合わせ
• ping → OSの名前解決キャッシュを使用

このためDNSが修正されても、OSキャッシュが残っている間は失敗する。

DNSフォワーダ

ローカルゾーン（home.arpa）以外の問い合わせを上流DNSへ転送することで

• 内部サービス名
• 外部インターネット

の両方を1台のDNSで解決できる。

デュアルNIC問題

1台のホストに複数ネットワークがある場合、DNSは「接続元ネットワーク」を判断できないため不適切なIPを返すことがある。これは企業ネットワークでいう Split DNS 問題に相当する。

現在の状態

• Surface OMV サーバ常時稼働
• Wi-Fi接続維持（画面消灯OK）
• Docker運用開始
• Dashy 安定稼働
• home.arpa による家庭内名前解決成功
• LAN内サービスをドメイン名でアクセス可能
• DNS安定化完了

Surface Pro + OpenMediaVault 省電力サーバー化対応

やろうとしたこと / 目的

• Surface Pro 初代に導入した OpenMediaVault を無線LAN接続で常時稼働させたい
• 有線接続を外し、設置自由度を上げる
• 消費電力を抑えるため画面は消灯させたい
• NAS用途として安定運用できる状態にする

発生した課題・問題

1. 無線LANが認識されない（過去は接続できていた）
2. 画面消灯設定を入れると Wi-Fi も停止して OMV に接続不能になる
3. Linuxのログイン情報を失念し、設定変更ができない
4. nano エディタの操作方法が分からない
5. 文字化けにより設定ファイル編集が困難

解決策・対応内容

1. rootログインの確保

• リカバリ的手順で root にログイン成功
• これにより設定ファイル編集が可能になった

2. サスペンド無効化

• 画面消灯とスリープ（サスペンド）が別物であることを確認
• サスペンドに入ると無線LANデバイスの電源が落ちるため通信断が発生していた

対応： - systemd の電源管理設定を変更 - 自動サスペンドを無効化

3. 画面のみ消灯させる設定

• コンソールのブランク設定を使用
• 画面表示だけ停止し、OSは稼働を継続させた

4. Wi-Fi維持の確認

• サスペンドに入らなくなったことで、無線LANインターフェースの電源断が解消
• OMVへ無線接続で継続アクセス可能になった

なぜ解決できたか（理論）

Linuxには以下の電源状態がある：

状態	内容
画面消灯（console blank）	表示のみ停止、OSは動作継続
idle	CPU低電力化、通信維持
suspend (mem)	RAMのみ保持、デバイス電源断
hibernate	メモリ内容をディスク保存して停止

今回の問題は「画面消灯」ではなく
自動サスペンド（suspend to RAM）に入っていたこと が原因。

サスペンド時は - PCIe - USB - Wi-Fiチップ

の電源が切れるため、ネットワークが消失し NAS が停止したように見えていた。

サスペンドを禁止し、画面消灯のみ有効にしたことで：

• OSは稼働
• ネットワーク維持
• 消費電力低減

が同時に成立した。

現在の状態

• 無線LAN接続で OMV 稼働可能
• 画面消灯中もネットワーク維持
• 常時稼働NASとして利用可能
• 低消費電力運用を実現

今後の利用想定

• 検証用NAS
• ファイル共有
• ネットワーク実験環境
• 常時起動サーバーとしての運用テスト

参考

nisshingeppo.com

家庭内ネットワークの信頼度モデルを確定する

やろうとしたこと

• 旧PCを家庭内LANに安全に参加させる構成を決める
• VLANを導入せず、現行機材でどこまで安全性を確保できるか整理する
• SSID構成と役割分担を明確化する
• パスワード運用の妥当性を検討する

発生した課題

• 旧PCをLANに入れた場合の横移動（ラテラルムーブメント）リスク
• VLANを導入するかどうか未決定（＝選択が必要な状態）
• UDR7購入というコスト判断が未確定
• SSIDごとの役割分離が言語化されていない
• パスワードを共通にするか分離するか未決定
• 旧端末・IoT機器の扱い方針が曖昧

※いずれも不具合ではなく、「選択が必要な状態」を課題として扱う

解決策（決定事項）

• VLANは導入しない（現状機材で成立させる方針）
• 信頼度レベルでネットワークを分離する思想を採用
  • メイン系
  • ゲスト系
  • 旧端末／制限系
• 旧PCとのファイル共有はNAS経由に限定する
• NASの構成を中継点として活用する設計を許容
• SSIDは役割ごとに明確に分離し維持する
• 2.4GHz帯は20MHz固定で安定性優先

理論・背景

• 横移動対策としてネットワーク境界を作る
• VLANがなくても、論理的な信頼度分離でリスクは低減できる
• 帯域幅拡張は再送増加リスクを伴うため、2.4GHzは安定重視とする
• 家庭内LANも「単一ネットワーク」ではなく、信頼度の異なるセグメント集合として扱うのが妥当

参考

support.apple.com

家庭内ネットワーク運用方針の確立

やろうとしたこと・やりたかったこと

• 自宅ネットワークの整理・運用方針の確立
• Tailscaleのアカウント運用の見直し（家族端末への影響対策）
• Wi-Fi接続ポリシー（6GHz / 5GHz(11ac/ax)）の考え方整理
• 名前解決（.local / mDNS / ホスト名）周りの理解整理
• Windowsワークグループの意味の理解
• NASやIoT機器を含めた「家庭内LANの設計思想」の言語化

発生した課題・疑問

• TailscaleをGoogleアカウントでログインすると、他人のスマホに自分のGoogleアカウントがOSレベルで見えてしまう
• mDNS探索コマンドでサービスが見えない（dns-sdワンライナー不発）
• 「.localの名前」と「IPアドレス」の関係が曖昧
• IPアドレスとポートを人間に分かる形で扱えない（URL化の問題）
• Windowsワークグループの存在意義が不明
• 6GHzを優先すべきか、5GHzを維持すべきかの判断基準
• ネットワークの説明でNAT越えの通信理解に混乱が出た

解決策・方針

1. Tailscaleアカウント
   • Google認証をやめ、GitHubアカウント等に分離する方針
2. Wi-Fi運用方針
   • 基本は6GHzを優先
   • 通信が安定しているなら5GHz(ga/ax)を掴み続けても問題なし
   • 体感速度が落ちたときのみ6GHzへ手動切替
3. 名前解決の整理
   • .local は mDNS による「IPアドレスの名前解決」
   • URLのホスト名はIPに対応する（ポートには対応しない）
   • ポート問題は リバースプロキシで解決する設計が正解
4. Windowsワークグループ
   • 認証やネットワーク接続には関係ない
   • 役割は「Windowsのネットワーク一覧表示のグルーピング（ブラウジング用）」

理論的説明（なぜそうなるか）

mDNS / .local

mDNSはDNSサーバーを使わず、LAN内ブロードキャストで「この名前の機器いる？」と問い合わせる仕組み。したがって、

ホスト名  →  IPアドレス

の対応だけを解決する。

つまり

http://nas.local:5000

の nas.localはIPに変換されるが、:5000 はアプリケーション層（HTTP）の話であり、mDNSの管轄外。

なぜポートは名前にできないのか

名前解決（DNS/mDNS）はOSI参照モデルの

• 第7層：アプリケーション → HTTP
• 第4層：トランスポート → TCPポート
• 第3層：ネットワーク → IP

のうち、第3層(IP)の情報しか扱わない。そのため

名前 → IP は可能
名前 → IP:ポート は不可

ここで必要になるのがリバースプロキシ。

jellyfin.home → 192.168.0.10:8096
git.home      → 192.168.0.20:3000

のように「ホスト名でポートを振り分ける」のが本来の解法。

6GHzを最優先にしなくてよい理由

Wi-Fi 6Eの6GHzは

• 帯域：広い
• 速度：速い
• しかし減衰：非常に大きい（壁に弱い）

つまり速度は最大だが安定性は最弱の帯域。5GHz(11ac/ax)は逆に「速度と安定性のバランス帯域」。

したがって運用としては

• 普段：安定しているAPを使う（5GHzでもOK）
• 遅くなったときだけ6GHz

が合理的。

今日の結論

• 名前解決はIPまで、ポートはリバースプロキシの仕事
• Windowsワークグループは実質「表示ラベル」
• Tailscaleは個人IDと端末共有IDを分けるべき
• Wi-Fiは6GHzを常用するものではなく「高速レーン」

家庭ネットワーク固定IP整理

やりたかったこと

• 家庭内ネットワークの固定IP割り当てを整理し、機器ごとの役割が一目でわかるようにしたい。
• 特にサーバー系、周辺機器、メディア機器、ゲーム機の固定IPを管理しやすくすることが目的。

発生した課題

• 機器が増えるたびにIPアドレスの管理が煩雑になり、どれが固定でどれがDHCPか判別しづらい。
• 固定IPを手動で設定すると重複やトラブルのリスクがある。
• ゲーム機やメディア機器はIPが変わるとサービスや接続が不安定になることがある。

課題の解決方法

1. IPを役割ごとにゾーン分けして番号を振る

   範囲	用途	割り当て機器(例)
   .1	ゲートウェイ	ルーター
   .2–.19	ネットワーク機器	メッシュ中継機、スイッチ、APなど
   .20–.39	サーバー/ストレージ	仮想化サーバー、NASなど
   .40–.59	PC周辺機器	複合機、スキャナなど
   .60–.79	AV・メディア機器	テレビ、DVD/BDレコーダーなど
   .80–.89	ゲーム機	Nintendo Switch(有線)
   .90–.99	予備/IoT	スマート家電・カメラなど
   .100–254	DHCP	スマホ・PC・タブレットなど自動取得

2. 固定IPはルーターのDHCP予約で一元管理
   • 機器側で手動設定せず、MACアドレス単位で固定
3. 将来増えるIoTやスマート家電用に予備ゾーンを確保
   • 90〜99番など

解決方法の理論的説明

• ゾーン分けにより、IPを見ただけで機器のカテゴリが分かるためトラブル対応が容易。
• DHCP予約管理はIP重複のリスクを回避し、ルーター交換時でも設定を一元復元可能。
• 将来用予備ゾーンをあらかじめ確保することで、新規機器追加時も既存構成を乱さず運用可能。
• この整理により、家庭内のネットワークの安定性・可視性・拡張性が向上する。

IPアドレス特殊領域とDHCP設定

やりたかったこと

• 家庭内LANで使用するDHCPの範囲設定を安全にしたい
• 特殊なIPアドレス（127.0.0.1、192.168.0.0/24のネットワーク・ブロードキャストなど）を把握し、誤って端末に割り当てないようにしたい

発生した課題

• 特殊アドレス（ネットワークアドレス・ブロードキャストアドレス）をDHCPで誤配布すると通信が不安定になる
• 127.0.0.1などのループバックアドレスやAPIPA、マルチキャストアドレスも誤配布するとトラブルの原因になる

課題の解決方法

• DHCPで配布する範囲を明確に分ける
• ネットワークアドレス（例：192.168.0.0）とブロードキャストアドレス（例：192.168.0.255）は除外
• ルーターやサーバなど固定機器用のIPは予約
• 一般端末には安全な範囲（例：192.168.0.100〜199）をDHCPで配布

解決方法の理論的説明

• ネットワークアドレスはそのネットワーク自体を表す識別子であり、端末に割り当てると通信路が不明瞭になる
• ブロードキャストアドレスはネットワーク全体宛の通信に使われるため、端末に割り当てると全体通信やARP、DHCP Discoverが正常に機能しなくなる
• ループバックアドレスは自分自身向け通信専用であり、DHCPで配布すると内部通信が壊れる
• DHCPで安全に配布することで、これら特殊アドレスと端末のIPが競合せず、ネットワークの安定性が保たれる