2026/01/22：Geminiによって叩き台を作成
マンション共有インターネット、古いOSのNAS、そして二重ルーター。リモートアクセス構築における「三重苦」の環境下で、いかにして安全な通信経路を確保するか。試行錯誤のプロセスと、論理的な到達点を技術ログとして残す。
1. ネットワーク環境の現状分析
まず、ターゲットとなるデバイスとネットワーク構成を特定した。
- デバイス: QNAP NAS (TSシリーズ)
- CPU: Intel Atom D525 (x86_64アーキテクチャ)
- IPアドレス:
aaa.bbb.c.ddd(ローカル固定済) - ルーター: TP-Link AX1800
- 外部環境: マンション共有インターネット (Carrier-Grade NAT / 二重ルーター)
ターミナルによるスキャン結果
Bash
# ARPテーブルからNASを特定
arp -a
# ? (aaa.bbb.c.ddd) at e:f:g:h:i:j on en0 ifscope [ethernet]
2. 失敗の記録：Tailscale直接インストールの限界
当初、最もスマートな解決策としてTailscaleのNAS直接導入を試みたが、OSの世代差という物理的障壁に衝突した。
実施した手順と結果
- パッケージ選定: 公式配布ページより
Tailscale_x.x.x_x86_64.qpkgを取得。 - App Centerからの手動インストール:
- エラー発生:
Installation package is incompatible. Use the correct package. - ログ解析:
Upgrade QTS to 5.0.0 or a newer compatible version.
- エラー発生:
分析
Intel Atom D525搭載機はレガシー環境であり、QTS 5.0以上へのアップグレードパスが存在しない。最新のTailscaleバイナリはQTS 5.x（モダンなLinuxカーネル）を要求するため、NAS本体での終端は論理的に不可能であると結論づけた。
3. 失敗の記録：OpenVPNとマンション回線の壁
次に、境界ルーター（TP-Link AX1800）によるVPNサーバー構築を検証。
事象
書き出した .ovpn プロファイルで接続を試みるも、ハンドシェイクが成立せずタイムアウト。
原因の特定
OpenVPN設定ファイル内の接続先を確認したところ、IPアドレスが aaa.bb.c.dd となっていた。これはマンション共有回線の内部ネットワークが割り振ったプライベートIPである。
結論: 典型的な 「二重ルーター (Double NAT)」 状態。外部インターネットからこのIPにパケットを投げても、マンション側の基幹ルーターで全て破棄される。ポート開放の権限がない以上、この経路でのアクセスは不可能である。
4. 最終戦略：Tailscale Subnet Routerによるオーバーレイ構築
本体が拒絶し、入り口（ルーター）が閉ざされている現状、残された唯一の勝機は**「内側から外側へトンネルを掘る」**ことにある。
Subnet Router戦略の概要
LAN内に存在する、別のモダンなOS（macOS / Windows / Linux）を「中継点」として利用し、TailscaleのネットワークをLAN全体に広報する。
実装コマンド（Macを暫定中継機とする場合）
Bash
# 自宅のサブネットをTailscaleネットワークに広報
tailscale up --advertise-routes=aaa.bbb.c.d/24
論理的メリット
- NAT貫通: TailscaleのSTUNプロトコルにより、マンション回線のNATを無効化。
- プロトコル透過性: VPN接続後、外出先から
ssh admin@aaa.bbb.c.dddを叩くだけで、あたかも自宅にいるかのような透過的アクセスが可能。 - レガシーの救済: 古いNASを一切改造せず、セキュアなVPN経路に乗せることができる。
5. 結論と次なるステップ
今回の検証により、「マンション共有回線 × レガシーNAS」環境における外部アクセスの正解は、サブネットルーターの構築であることが確定した。
今後のタスク
- 常時稼働環境の構築: メイン機（Mac）を持ち出すため、Apple TV (第2世代4K以降) または Raspberry Pi をサブネットルーター専用機として導入。
- 運用フロー: 外出先でTailscaleをONにするだけで、SMB共有・SSH管理をシームレスに行う環境へ移行。