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

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

  • 自宅ネットワークの整理・運用方針の確立
  • 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を常用するものではなく「高速レーン」