Tailscale × Docker で NAS を公開しないリモート開発環境を作る方法【ポート開放ゼロ】

更新日：2026年5月13日｜カテゴリ：NAS応用

1. なぜ NAS をインターネットに公開したくないのか

「自宅にいない時にも NAS の中で開発したい」という要件を素直に解くと、最初に思いつくのは ルーターでポート開放して、外から SSH や VPN で入れるようにする方式です。私も以前は別用途で 22 番を開けていた時期がありますが、認証ログを見るたびに気持ちが重くなるのが本音でした。ポートを 1 つでも開けた瞬間に NAS が「インターネット上の総当たり攻撃の正当な標的」になるからです。家庭用ネットワークの典型的な攻撃面を整理するとこうなります。

fail2ban やポート番号ずらしは有効ですが、それでも「公開されていること」自体は変わらず、攻撃ログ監視やパッチ追従が永続タスクとして残ります。さらにルーターの UPnP が有効だと、LAN 内のアプリやコンテナが勝手にポート開放することもあり、「開放した覚えがないのに開いていた」を防ぐためにも家庭ルーターの UPnP は OFF が無難です。

そこで方針を切り替えました。そもそも外向きに 1 ポートも開けない。代わりに外から「VPN で内側に入ってもらう」だけにする。これを家庭用ルーターと Docker で素直に実装する手段が Tailscale でした。

2. Tailscale が解決してくれること

Tailscale は WireGuard ベースの mesh VPN サービスです。同じアカウントで紐づいた端末同士がコントロールプレーン経由で鍵交換し、デバイス間で直接（または中継経由で）暗号化通信します。家庭用ルーターから見ると、NAS が外向きに送り出す UDP トラフィックだけが見えていて、外からの受信ポートは 1 つも開いていません。それでも Tailscale クライアントを入れた PC やスマホからは、Tailnet 内のプライベートアドレス（100.x.x.x）で NAS にアクセスできます。

個人運用の無料枠も十分で、私の場合は PC 2 台 + スマホ 2 台 + NAS の 5 デバイス程度ですが、無料プラン範囲内に収まっています（2026 年 5 月時点）。

3. 全体アーキテクチャ：tailscale コンテナと開発用コンテナの 2 段構成

採用した構成を絵にするとこうなります。

[ Win11 PC / Mac / スマホ / 他PC ]
  ↓ Tailscale VPN（WireGuard, tag:client 付きデバイスのみ）
[ Tailscale Tailnet（100.x.x.x プライベートIP空間）]
  ↓
[ DXP2800 NAS ]
  ├─ ts-sandbox コンテナ（Tailscale 本体、ネット入口）
  └─ claude-workspace コンテナ
       └ network_mode: service:tailscale（独自NIC無し、ts-sandbox に相乗り）
       ├─ /workspace ← /volume1/sandbox/projects（bind mount）
       ├─ /home/yamakashi/.claude ← claude-config volume
       └─ /home/yamakashi/.ssh ← ssh-keys volume（700）

注目してほしいのは claude-workspace が独自のネットワークインターフェースを持たない点です。tailscale コンテナのネット名前空間に相乗りしており、IP も Tailscale のものを共有します。ホスト OS の eth0 経由で claude-workspace に直接到達する経路は物理的に存在しません。ACL 設定ミスや Tailscale の不具合があっても変わらない、構成上の保証です。Tailscale 側と開発環境側で責務が分離されるため、開発環境のビルド失敗で Tailscale 接続が巻き込まれて落ちる、といった事故も起きません。

4. キモ：network_mode: "service:tailscale" の妙

本構成の核心は、Compose で書ける 1 行に集約されます。

claude-workspace:
  build: .
  container_name: claude-workspace
  network_mode: "service:tailscale"
  depends_on:
    tailscale:
      condition: service_healthy

これは Docker の機能としては「指定したサービスのネットワーク名前空間を共有する」という意味で、Linux ネットワーク名前空間の概念をそのまま使っているだけです。独自の魔法ではありませんが、これにより「独自 NIC を持たないコンテナ」が作れます。

独自 NIC を持たないとはどういうことか

普通の Docker コンテナは docker0 ブリッジ経由で eth0 が自動割り当てされますが、network_mode: "service:tailscale" を指定すると、NIC が一切作られず、tailscale コンテナの tailscale0 だけが見える状態になります。コンテナ内で ip addr を叩くと tailscale0 と lo しか出てきません。sshd を起動しても listen するのは tailscale 側のインターフェースだけで、NAS のホスト OS から見ると claude-workspace のポートはどこにも露出していない状態です（docker ps の PORTS 欄も空）。

LAN 直接到達が「物理的に」遮断される理由

同じ LAN にいる別の PC から NAS の LAN IP の 22 番に SSH しても、その経路には claude-workspace の sshd が存在しません。NAS 本体の sshd（UGOS Pro のもの）が応答するだけで、コンテナの中まで届く経路は定義上存在しないのです。ACL や fail2ban のように「ルールで弾く」のではなく、「そもそも到達するパケット経路がない」というレイヤーの話で、設定ミスでうっかり穴が空く事故が起きません。

inbound / outbound の非対称性を意識する

本構成の通信ポリシーをまとめます。

outbound はフリーなままにしているのは、Claude Code・npm・pip・apt・git push・外部 API 呼び出しがすべて普通に動かないと開発体験が成立しないからです。引き換えに「フル権限の Claude Code が悪意あるコードを実行したらデータが外に出る経路は技術的に残る」というリスクは残ります。これは別記事「フル権限 Claude Code を安全に運用する 5 つの運用ルール」（公開準備中）の領域で、本記事では「ネットワーク設計だけで全部解決しようとしない」のが現実的、と考えます。

5. Tailscale ACL：grants 文法でタグベース制御

Tailscale で複数デバイスを束ねる時、ACL を書かないと「同じアカウントの全デバイスが互いに自由に通信できる」状態になります。本構成では「クライアント PC からだけ sandbox コンテナへの SSH を許可する」制約を入れたいので、ACL を最初に整えます。

ここで一度ハマりました。ネット上のサンプルは acls セクションを使った旧文法が多いのですが、私の Tailscale テナントは新しい grants 文法がデフォルトでした。旧形式で書いて Save しようとすると、Admin Console がエラーで弾きます。Tailscale 側は段階的に grants へ移行中らしく、テナントによって受け付ける文法が違うようです（2026 年 5 月時点）。本記事は grants 文法のサンプルを載せます。

Admin Console → Access controls に貼り付ける JSON です。

{
  "tagOwners": {
    "tag:sandbox": ["autogroup:admin"],
    "tag:client":  ["autogroup:admin"]
  },

  "grants": [
    // 自分自身（管理者）からは全デバイスへフルアクセス
    // （ACL ミスで自分が締め出される事故を防止）
    {
      "src": ["autogroup:admin"],
      "dst": ["*"],
      "ip":  ["*"]
    },
    // tag:client → tag:sandbox のみ許可
    {
      "src": ["tag:client"],
      "dst": ["tag:sandbox"],
      "ip":  ["*"]
    }
  ],

  "ssh": [
    {
      "action": "check",
      "src":    ["autogroup:member"],
      "dst":    ["autogroup:self"],
      "users":  ["autogroup:nonroot", "root"]
    }
  ]
}

各セクションの役割は、tagOwners が「tag を誰が付与してよいか」の定義、grants が「src から dst への ip 通信を許可」のルール、ssh は Tailscale 提供の SSH 機能用（本構成では使いませんが、自デバイス間 SSH の利便のため残しています）。

ACL を Save したあと、Admin Console → Machines で手元の PC とスマホに tag:client をチェック。tailscale コンテナ用の Auth Key は Settings → Keys → Generate auth key で発行し、Tags: tag:sandbox のチェックを忘れずに付けます。

6. 実装ステップ概略：ACL 先・Auth Key 後の順序がなぜ重要か

細かい構築手順はメインガイド側に譲りますが、ネットワーク設計上どうしても外せない順序だけ書いておきます。

原因は、ACL で tag:sandbox を tagOwners に登録していないと、Auth Key 発行画面の tag チェックボックスが選択不可になる仕様だからです。正しい順序は次の通り。

1. ACL を書く（tagOwners に tag:sandbox と tag:client、grants で tag:client → tag:sandbox）
2. クライアントデバイスに tag:client を付与
3. Auth Key を発行（tag:sandbox をチェック、Reusable: ON, Ephemeral: OFF）
4. Auth Key を .env に書き、docker compose up -d --build でコンテナ起動

docker compose up でハマった --reset ループ

もう一つ、Tailscale 特有の「設定保護機構」によるハマりがあります。私は最初 TS_EXTRA_ARGS=--ssh --advertise-tags=tag:sandbox と書き、後で Tailscale SSH を使わない方針に変えて --ssh を外して再起動したところ、tailscale コンテナが起動しません。

tailscale up failed: changing settings via 'tailscale up' requires mentioning
all non-default flags. To proceed, use --reset.

これは Tailscale の安全機構で、「前回起動時に指定したフラグが今回省略されていると、意図しない設定変更を防ぐために起動を止める」仕組みです。解決は 1 回だけ --reset を付けて起動し、成功後に外す流れ。

# 一度だけ：--reset を付けて起動
environment:
  - TS_EXTRA_ARGS=--reset --advertise-tags=tag:sandbox

# 成功後：--reset を外して通常運用に戻す
environment:
  - TS_EXTRA_ARGS=--advertise-tags=tag:sandbox

--reset を付けっぱなしだと毎起動で state を巻き戻すことになるので、成功確認後は忘れずに外しておきます。気付かず残したまま何度も起動して時間を溶かした、というのが私の体験談です。

7. 動作検証：「Tailscale を OFF にして接続不可」を確認する

構築が一通り終わったら、やっておきたい検証があります。クライアント側の Tailscale を OFF にして、SSH 接続が失敗することを確認する、というシンプルなテストです。これをやらないと「ポートを開けていないつもりが、実は別経路で繋がっていた」を見逃すリスクがあります。

# 1. Tailscale ON で接続成功を確認
ssh yamakashi@dxp2800-sandbox

# 2. クライアント PC で Tailscale を OFF（タスクトレイから Disconnect）

# 3. 同じコマンドを再実行 → Could not resolve hostname / Connection timed out
ssh yamakashi@dxp2800-sandbox

ホスト名 dxp2800-sandbox は Tailscale の MagicDNS で解決される名前なので、Tailscale OFF だと名前解決自体が失敗します。仮に NAS の LAN IP を直接指定しても、network_mode: "service:tailscale" によりコンテナの sshd は LAN 経由で listen していないため到達できません。「想定通り接続できない」ことを目視確認するまでがセットアップです。

8. 他の選択肢との比較

「外から NAS に繋ぐ」要件を満たす手段は他にもあります。私が検討した結果を比較表にまとめます。

正直に書くと、Tailscale に依存する分「Tailscale サービスが落ちたら」という単一障害点は残ります。Tailscale はコントロールプレーンが落ちてもデータプレーン（端末間 WireGuard 通信）は維持される設計ですが、新規 Auth Key 発行や新規デバイス追加は止まります。家庭用途ではこのリスクを受け入れる代わりに運用負荷の低さを取った、というのが私の判断です。

9. よくある質問（FAQ）

10. まとめ：「ポート開放しない」をデフォルトに

「NAS をリモートで触りたいけれど、ポートを開けるのは怖い」という感覚は、個人運用ならむしろ正しい直感だと思います。本記事の構成なら、その直感を曲げずにほぼ無料の範囲で実用的な開発環境が作れます。Claude Code のようなフル権限 AI エージェントを、自宅 PC ではなく専用の隔離環境に置きたい時の選択肢として参考にしてもらえると嬉しいです。実際の構築手順はメイン記事「自宅 NAS に Claude Code 専用サンドボックスを作った全記録」（公開準備中）、永続化パターンは「Docker × OpenSSH で公開鍵を永続化する正しい設計」（公開準備中）、運用ルールは「フル権限 Claude Code を安全に運用する 5 つの運用ルール」（公開準備中）で補完予定です。

関連記事：Claude Desktop の Code タブで Permission denied (publickey) が出る本当の原因と解決法／自宅 NAS 上に Claude Code 専用サンドボックスを構築した全記録（公開準備中）／Docker × OpenSSH で公開鍵を永続化する正しい設計（公開準備中）／フル権限 Claude Code を安全に運用する 5 つの運用ルール（公開準備中）

yamakashi（クラウドじゃない人）

絶対保存領域の継承者

自宅やオフィスでのNAS活用をもっと身近に、わかりやすく伝えることを目指して「ありがとNAS」を運営しています。IT企業でサーバー・ストレージの導入や運用を経験し、現在は趣味と実務を活かして記事を執筆。初心者でも安心してNASを使いこなせるよう、最新機種レビューからトラブル解決まで実際に検証した情報を発信しています。