プロローグ —「自宅 PC に ssh したいだけ」から始まった市場

2026 年に最も静かに、しかし最も広く起きているインフラ置換のひとつは **会社 VPN の死** だ。

10 年前なら「自宅から社内ネットに入りたい」の答えは決まっていた。**社内 VPN サーバに OpenVPN または IPsec クライアントで接続する**。ユーザーは毎回再認証し、トラフィックは社内ゲートウェイを経由してインターネットに出ていき、ルーターは「昔はな」みたいな顔でパケットを処理していた。

今は違う。ノート PC を開けると自動的にメッシュネットワークに参加する。会社データセンターのサーバ、同僚のノート PC、クラウド VPC、自宅のラズパイ — 全部が同じプライベート IP レンジに入っている。誰が誰にアクセスできるかは **ACL ファイル 1 枚** で決まる。**誰も「ゲートウェイ」を経由しない。** 2 ホスト間の最短経路は P2P 直通で、それが不可能なら最寄りのリレーが自動で間に入る。

この変化の震源地はひとつの会社 — **Tailscale**。そしてその周囲にセルフホスト勢(Headscale・NetBird・Innernet)、エンタープライズ ZTNA(Twingate・Cloudflare Zero Trust)、別の信頼モデル(Nebula・ZeroTier・Yggdrasil)がそれぞれ位置を占めた。

本稿はその地図を描く。WireGuard という共通基盤、Tailscale が定義した UX、まわりの代替案、そして「あなたの組織は何を選ぶべきか」まで。

1 章 · 2026 年のオーバーレイ VPN 地図 — 三勢力

まず全体像。2026 年のオーバーレイ VPN / メッシュ市場は三つに分かれる。

| 勢力 | 代表的な製品 | コントロールプレーンを誰が運営するか | 性格 |

| --- | --- | --- | --- |

| **マネージド SaaS** | Tailscale, Twingate, Cloudflare Zero Trust, NetBird Cloud, ZeroTier Central, Defined Networking | ベンダー | 導入が速い、無料枠あり、エンタープライズには SSO / SCIM / 監査 |

| **セルフホスト OSS** | Headscale, NetBird (self-host), Innernet, Nebula | 自分 | コントロールプレーンも自前、データ主権、サプライチェーン統制 |

| **DIY / 基盤技術** | WireGuard, IPsec, OpenVPN, Yggdrasil | 自分(ルーティングまで) | 最も自由、最も手間がかかる |

「勢力」と書いたが、実際は **ほぼ全員が WireGuard の上に立っている**。違うのは「鍵配布、NAT トラバーサル、ポリシー、ユーザー認証を誰が担うか」だ。

一行サマリ

- **個人 / ホームラボ** → Tailscale 無料枠。終わり。

- **セルフホスト派** → Headscale + Tailscale クライアント。

- **SMB / スタートアップ** → NetBird または Tailscale Teams。

- **エンタープライズ** → Cloudflare Zero Trust、Twingate、Tailscale Enterprise のいずれか。

- **特殊要件(IPv6 メッシュ、ルーティング自体がゲーム)** → Yggdrasil、Nebula。

これが結論で、残り 14 章で「なぜそうなのか」を見る。

2 章 · NAT トラバーサル — STUN / TURN / DERP / ホールパンチング基礎

オーバーレイ VPN の本当の魔法は暗号化ではなく **NAT の後ろにいる 2 台のコンピュータを直接つなぐこと** だ。WireGuard は「どうやって安全に送るか」を解くが、「どこへ送るか、その IP が NAT の裏にあるときどう届かせるか」はまったく別の問題だ。

NAT の種類と親切さ

| NAT タイプ | 親切さ | ホールパンチング可? |

| --- | --- | --- |

| Full Cone | とても親切 | とても簡単 |

| Restricted Cone | 親切 | 簡単 |

| Port-Restricted Cone | 普通 | 双方の協力が必要 |

| Symmetric NAT | 非協力的 | とても困難、リレー必須のことも多い |

| CGNAT(キャリアグレード) | 敵対的 | ほぼ常にリレー必須 |

日本の OCN、韓国の LTE/5G モバイル、米国の T-Mobile、ほぼ CGNAT。**現実世界のインターネットの相当部分は「P2P できない場所」だ。** だからすべてのオーバーレイ VPN は **リレーフォールバック** を持つ。

STUN / TURN / DERP

伝統的な WebRTC の世界では:

- **STUN**(Session Traversal Utilities for NAT):「自分のグローバル IP / ポートは何か」を尋ねるサーバ。両者がお互いのグローバルエンドポイントを知れば、ホールパンチングが始まる。

- **TURN**(Traversal Using Relays around NAT):STUN で済まなければ TURN サーバが両側のトラフィックをリレー。

Tailscale は独自の派生を作った:

- **DERP**(Designated Encrypted Relay for Packets):HTTPS / 443 上で動くリレー。ファイアウォールが最も確実に通すポートが 443 だという現実への適応。トラフィックは両端で WireGuard 鍵により暗号化されているので、DERP は **暗号文しか見ない** — リレーが「読む」ことは物理的に不可能。

DERP の何が天才的か:

1. **HTTPS はどこでも通る**。5G CGNAT、ホテル WiFi、企業ファイアウォール、すべて通過。

2. **コントロールプレーンと分離**。DERP は純粋なリレーで「誰に送るか」は知らない。

3. **自動フォールバック**。P2P が可能になった瞬間に切り替わる。ユーザーは気づかない。

ホールパンチングの動作

A(自宅、NAT 裏) B(オフィス、NAT 裏)

| |

| --- STUN --> 「自分の公開 EP」 | --- STUN -->

| Coordinator |

| <--- B の公開 EP --- | <--- A の公開 EP ---

| |

| --- UDP パケット (A->B) --> X(B の NAT で落とされる)

| <--- UDP パケット (B->A) --- X(A の NAT で落とされる)

|

| → 双方が「同時に」送るとお互いの NAT にマッピングができる ←

|

| --- UDP パケット --> OK 直通 P2P

**核心のトリック**:両側が *同時に* パケットを送ると、両 NAT は「外向きトラフィックがあるから応答を入れよう」というマッピングを作る。一度マッピングができればその後は直通。

Tailscale の DERP は「このトリックが失敗したときのセーフティネット」だ。

3 章 · WireGuard — すべての基盤

2020 年に Linux カーネル 5.6 にマージされた WireGuard は **VPN 世界を書き換えた**。あまりに綺麗で、あまりに小さくて、前世代の VPN(OpenVPN、IPsec)の位置を一気に奪った。

WireGuard が単純な理由

/etc/wireguard/wg0.conf

[Interface]

PrivateKey = ...

Address = 10.0.0.1/24

ListenPort = 51820

[Peer]

PublicKey = ...

Endpoint = 203.0.113.42:51820

AllowedIPs = 10.0.0.2/32

これがすべて。鍵、IP、エンドポイント。ネゴシエーションプロトコルは 1 ラウンドトリップ(1-RTT)。暗号スイートは固定 — Curve25519、ChaCha20-Poly1305、BLAKE2s、HKDF。**選択肢がない = 誤設定の余地もない。**

OpenVPN との比較:

- OpenVPN:コード約 10 万行、設定オプション数百、TLS、多様な cipher suite、複雑なルーティングモード。

- WireGuard:コード約 4 千行(カーネルモジュール)、固定の一種類の cipher suite。

WireGuard が *解決しない* こと

こちらのほうが重要だ。WireGuard は **データプレーン** であって **コントロールプレーン** ではない。

WireGuard が *提供しない* もの:

- **鍵配布**。新しいノードが入ってきたら、すべての他ノードのピアセクションを更新する必要がある。手動で。

- **NAT トラバーサル**。`Endpoint` が NAT の裏にあれば単純に動かない。

- **DNS / 名前解決**。IP しか知らない。

- **ACL / 認可ポリシー**。すべてのピアは `AllowedIPs` に書かれた IP に自由にアクセスできる。

- **ユーザー認証**。鍵 = 身元であって、ユーザー ↔ 鍵 のマッピングは外部システムの仕事。

- **ローテーション、失効、メンバーシップ管理**。

オーバーレイ VPN 市場のすべての製品は **「WireGuard の上にコントロールプレーンを乗せて、上記 6 つを自動化したもの」** だ。Tailscale、Headscale、NetBird、Innernet、Cloudflare WARP、全部そう。

> WireGuard は「VPN プロトコル」ではなく「安全なトンネルのプリミティブ」だ。その上に何を積むかが本物の製品。

素の `wg-quick` で足りる場合

- ノード数 5 以下

- 片側がグローバル IP のサーバ

- メンバーシップがほぼ変わらない

この条件下では `wg-quick` は完璧。1 行ものの conf、カーネルデータパス、ほぼゼロのオーバーヘッド。小さな自宅サーバとノート PC 数台なら、それが最適なこともある。

条件が崩れた瞬間 — 5 名を超え、両側が NAT 裏で、毎週新しいノードが入る — **コントロールプレーンが必要になる**。それが次章のテーマ。

4 章 · Tailscale — 事実上の標準

2019 年創業の Tailscale は「WireGuard の上に、ユーザーが本当に欲しかったすべて」を載せて市場を定義した。2026 年には **事実上の標準** だ。

Tailscale = WireGuard + コーディネーションサービス

+--------------------------+

| Tailscale Control |

| (Coordination Server) |

| - ノード登録 |

| - 公開鍵配布 |

| - ACL 評価 |

| - どの DERP を使うか |

+--------------------------+

^ ^

| 制御 | 制御

| |

+-------+---+ +-----+-----+

| ノード A | | ノード B |

+-----+-----+ +-----+-----+

| |

| WireGuard P2P |

| <-----------> |

| |

| または |

| +------------+ |

+>| DERP リレー |<+

+------------+

**コントロールプレーンはメタデータしか見ない。** 実トラフィックはノード間で直接(または DERP 経由で)流れ、両端で WireGuard により暗号化されている。Tailscale 社ですらユーザーのトラフィック内容を見られない。

コア機能(2026 年時点)

| 機能 | 何をするか |

| --- | --- |

| **MagicDNS** | ノード名が DNS のように動く — `ssh laptop` がそのまま通る。`*.ts.net` の自動サブドメイン。 |

| **Subnet Router** | 一台のノードが「自分の後ろのサブネットもルーティングする」と宣言。社内 192.168.x をメッシュに公開。 |

| **Exit Node** | ノードをインターネットゲートウェイに昇格。すべてのトラフィックがそこを通る。 |

| **ACL(Tailnet Policy)** | HuJSON ファイル 1 枚で `user:alice@example.com → tag:server` のような規則。 |

| **Tailscale SSH** | SSH 鍵そのものを tailnet に委譲。鍵配布が不要になる。 |

| **Tailscale Funnel** | メッシュ内のノードを公開インターネットに露出。HTTPS 自動。 |

| **Tailscale Serve** | ノード上のサービスをメッシュ内部にだけ公開(TLS 自動)。 |

| **Mullvad 統合** | Mullvad の出口を exit node に → 本物の「インターネット VPN」モード。 |

| **App Connector** | SaaS(Slack、Notion)宛トラフィックを特定ノードが代理。SaaS 側の IP 許可リストに 1 ノードだけ登録すれば済む。 |

| **ACME / TLS** | メッシュ内ノードに本物の Let's Encrypt 証明書を自動発行。 |

| **Auto-update** | クライアントの自動更新。セキュリティパッチの取りこぼし防止。 |

Tailscale Funnel —「localhost をインターネットに出す」

自宅サーバから 1 時間だけデモを外部に見せたい。昔は ngrok 、今でも ngrok はよいが、Tailscale 加入者なら:

tailscale funnel 8080

https://my-laptop.tail1234.ts.net が作られる

Let's Encrypt の証明書も自動

Cloudflare Tunnel とちょうど同じカテゴリ、ただし「すでに tailnet 内にあるノードをそのまま露出する」やり方。

Mullvad 提携 — 2 種類の VPN の結婚

2023 年から Tailscale の有料ユーザーは追加コスト(または小額)で Mullvad の 38 か国の出口を Tailscale exit node として使える。

- 「業務用メッシュネットワーク」→ Tailscale

- 「スタバ WiFi で安全にインターネット」→ Mullvad

- 「1 つのクライアントで両方」→ 2026 年の標準セットアップ

価格と無料枠

- **Free**(Personal):3 ユーザー、100 デバイス、全機能。個人と小規模ホームラボには事実上無限。

- **Starter / Premium / Enterprise**:ユーザー単位で月額。SSO / SCIM / 監査 / SLA は上位プラン。

2026 年時点で無料枠は **世界で最も気前のいい SaaS 無料枠のひとつ**。それが「Tailscale を触ったことのない開発者がいない」理由だ。

弱点

- **コントロールプレーン依存**。Tailscale のコントロールが落ちると新規接続・鍵ローテーションが止まる(既存セッションはしばらく持つ)。

- **ベンダーロックイン**。キラー機能はクライアントとコントロールプレーンが共設計 → 次章 Headscale。

- **データ主権**。メタデータは Tailscale のサーバに残る。規制業界には負担。

5 章 · Headscale — Tailscale のセルフホスト

Headscale は **Tailscale のコントロールプレーンを OSS で再実装したプロジェクト** だ。クライアントは Tailscale 公式 OSS クライアントをそのまま使い、サーバ側だけ自前で運営する。

作者:Juan Font(Tailscale 社員ではないが、Tailscale 側は「健全な外部実装」として歓迎してきた)。

何が同じで何が違うか

| 機能 | Tailscale(SaaS) | Headscale |

| --- | --- | --- |

| WireGuard データプレーン | 同一 | 同一 |

| MagicDNS | あり | あり |

| ACL | あり(HuJSON) | あり(互換形式) |

| DERP | Tailscale 運営 | 自前で運営、または Tailscale 公開 DERP を使う |

| Funnel / Serve | あり | 部分的(バージョンによる) |

| Mullvad | あり | なし(Mullvad との契約) |

| SSO / SAML / SCIM | あり | 部分的(OIDC は可) |

| 運用負荷 | ゼロ | 自分 |

構築

docker run -d --name headscale \

-v ./config:/etc/headscale \

-v ./data:/var/lib/headscale \

-p 8080:8080 \

-p 9090:9090 \

headscale/headscale:0.25.0 \

serve

クライアントはこれだけ

tailscale up --login-server=https://headscale.example.com

**その先の使い勝手はほぼ同じだ。** `tailscale status`、`tailscale ssh`、`tailscale ping`、全部いつも通り動く。

誰が Headscale を選ぶべきか

- **データ主権** 要件の強い組織(欧州規制、金融、政府)

- **ベンダーロックインに耐えられない** 人(インフラ哲学)

- **インターネットから隔離された環境**(Tailscale のコントロールに到達できない)

- **趣味として** — 実際にホームラボで Headscale を動かす人は多い。UI / UX は非公式 Web UI(例:headscale-ui)が埋めている。

弱点

- Tailscale が新機能を出すたびに Headscale は追随に数ヶ月かかる。

- 運用はすべて自分の責任 — DERP の運営、DB バックアップ、アップグレード。

- エンタープライズ機能(高度な ACL UI、監査ログ UI、自動デバイス posture チェック)は弱い。

6 章 · ZeroTier — WireGuard 以前の時代の覇者

ZeroTier は 2011 年スタート。**WireGuard が存在するずっと前** だ。独自プロトコル、独自暗号スイート、独自データプレーン。「全世界の仮想イーサネットスイッチ」という比喩を最初に広めた会社の一つだ。

モデル

Network ID(16 桁の 16 進数)に参加

v

グローバルコントローラ(ルートノード)が ID / 鍵を配布

v

全ノードが Layer 2 仮想 NIC を持つ

v

L2 フレームが P2P で流れる(P2P 失敗時は root 経由でリレー)

WireGuard との違い:

- **Layer 2(イーサネット)**。WireGuard / Tailscale は Layer 3(IP)の上だけを見る。ZeroTier はブロードキャスト、マルチキャスト、非 IP プロトコルも流せる。**「1 つの LAN のように」** 振る舞う。

- **独自プロトコル**。WireGuard のようなカーネルモジュールではなく、ユーザー空間デーモン。

- **コントローラのセルフホストが可能**。ZeroTier Central(SaaS)を使うか、ZTNCUI などでセルフホストするか選べる。

2026 年に ZeroTier がなお意味を持つケース

- **レガシーな非 IP トラフィック**(古い産業用プロトコル、NetBIOS、一部のゲーム)

- **すでに ZeroTier で組まれた環境** — 移行コスト

- **Layer 2 セマンティクスが必要なシナリオ**(例:VM クラスタの vMotion、一部のクラスタリング製品)

- **単一の無料ネットワークに 25 人以下**の小規模(無料枠の上限)

弱点(Tailscale 時代を基準に)

- UX が Tailscale より一世代古い。MagicDNS、SSH、Funnel 相当のものがない。

- WireGuard より性能が劣る(ユーザー空間 = コンテキストスイッチ)。

- L2 をメッシュに流すのはセキュリティ的に危険なことが多い(ブロードキャスト嵐)。

ほとんどのユースケースで「2026 年に新規導入する理由」は薄い。とはいえ、**「L2 セマンティクスが必要か?」を真剣に問う人にとってはほぼ唯一の答え** だ。

7 章 · Nebula(Slack OSS)— 異なる信頼モデル

Nebula は Slack が自社サービスメッシュ(数百万ホスト規模)を運用するなかで生まれた。2019 年に OSS 化。表面的には Tailscale と同じ「WireGuard 系メッシュ」に見えるが、**モデルそのものが違う**。

コアアイデア — PKI

Nebula は **独自の PKI** を持つ。運用者が CA を作り、各ノードに証明書を発行する。証明書には以下が含まれる:

- ノード名

- グループメンバーシップ(例:`web`、`db`、`staging`)

- 許可された IP

- 有効期限

**認可は証明書の中に焼き込まれている**。「このノードは誰だ?」と毎回コントロールサーバに尋ねる必要はない — 証明書こそが身元であり、ノード同士で直接検証する。

Tailscale vs Nebula

| 軸 | Tailscale | Nebula |

| --- | --- | --- |

| 鍵配布 | コントロールプレーンが動的に | PKI、証明書を事前発行 |

| 身元 | ユーザー ↔ 鍵 マッピング(SSO 可) | 証明書のグループ / 名前 |

| ポリシー評価 | コントロールプレーン(中央) | ノード上(分散) |

| スケーラビリティ | 数万ノード OK、コントロール依存 | 数十万ノードの本番事例(Slack) |

| 運用モデル | SaaS or Headscale | 自分(lighthouse ノードを運営) |

| NAT トラバーサル | DERP など | UDP ホールパンチング + lighthouse リレー |

lighthouse — ディスカバリ

Nebula では「あるノードのグローバルエンドポイントは何か」を **lighthouse** という特殊ノードが知っている。ノードたちは lighthouse に自分を登録し、他ノードを探すときに lighthouse に尋ねる。小さなサーバ 1 〜 2 台あれば十分。

どこで輝くか

- **大規模インフラメッシュ**(数千〜数万ノードのサーバ間接続)

- **すでに社内で PKI を運用している組織** — Vault、Step-CA などと自然に結合

- **コントロールプレーンが死んでもメッシュは生きていなければならない環境** — 証明書が有効である限り通信は続く

- **ユーザーのノート PC ではなくサーバインフラ中心** の利用

弱点

- **人間に優しい道具ではない**。CLI / 設定ファイルが多い。Tailscale の「入れたら終わり」UX とは遠い。

- **MagicDNS 系の利便性がない**。

- **SSO 統合が弱い**。ユーザーワークステーションをメッシュに入れるシナリオには向かない。

8 章 · Defined Networking — 商用 Nebula

Nebula のオリジナル開発者たちが立ち上げた会社が **Defined Networking** だ。OSS Nebula の上に「マネージドコントロールプレーン + UI + 証明書発行の自動化」を載せる。

- 「Nebula の Tailscale」と呼べる立ち位置。

- ただし **ユーザーノート PC よりもサーバインフラ** 寄りの市場に集中。

- SSO、ポリシー UI、監査ログをコントロールプレーンから提供。

- 価格はデバイス単位の月額。

選び方:

- うちは「人 < サーバ」比率 → Defined Networking が自然。

- うちは「サーバ < 人」比率 → Tailscale が自然。

9 章 · NetBird(OSS)— Tailscale + SSO

NetBird は 2022 年ごろ登場した「**OSS + SSO ファースト**」のメッシュ VPN だ。WireGuard ベース、MagicDNS 相当、ACL、そして最初から **OIDC / SAML 統合が中心**。

主な違い

- **セルフホストが本当に第一級扱い**。Headscale は「Tailscale 互換のコントロールプレーン」だが、NetBird は最初から「セルフホストをメインパス」として設計された。Docker Compose 一発で動く。

- **SSO が標準装備**。Keycloak、Auth0、Authentik、Google Workspace、Okta すべて対応。

- **ポリシー UI**。グループ・タグ・ポリシーを Web UI で視覚的に編集。

- **SaaS もある**。NetBird Cloud(マネージド)も運営。価格は Tailscale より少し安め。

NetBird vs Tailscale vs Headscale

| 軸 | Tailscale | Headscale | NetBird |

| --- | --- | --- | --- |

| ライセンス | コントロールプレーンはクローズド | 100% OSS | 100% OSS |

| マネージド版 | あり | 非公式 | あり(NetBird Cloud) |

| SSO | エンタープライズ枠 | OIDC のみ | 強力(主要 IdP 全部) |

| MagicDNS | あり | あり | あり |

| ACL UI | あり | 限定的 | 強力 |

| セルフホスト難度 | 不可 | 中 | 簡単 |

| クライアント網羅性 | 最強(全 OS) | Tailscale クライアント利用 | 主要 OS 網羅 |

誰が NetBird を選ぶべきか

- **セルフホスト要件** あり + **社内 SSO** が既にある SMB / ミッドマーケット

- **Tailscale の価格が負担** で + セルフホスト運用人員がいる

- **OSS 原則** が強い組織

弱点

- 機能の成熟度は Tailscale 未満。Funnel のような「ワオ機能」は弱い、もしくはない。

- コミュニティ規模が Tailscale より小さい。

- DERP のような精巧なグローバルリレー網は自分で作る必要がある。

10 章 · Twingate — ゼロトラストエンタープライズ

Twingate は **オーバーレイ VPN ではなく「Zero Trust Network Access(ZTNA)」のカテゴリ** に自社を位置づけた。この違いは何を意味するか。

モデルの違い

伝統的メッシュ VPN(Tailscale、NetBird):

- ユーザーが「メッシュに参加」する

- 参加すれば ACL が許すすべてのノードが見える

- IP ベースのポリシー

Twingate(および Cloudflare Access、Google BeyondCorp と同じ ZTNA カテゴリ):

- ユーザーが「リソースへのアクセスを要求」する

- 要求ごとに身元、デバイス posture、時間、条件が評価される

- リソース単位のポリシー(例:「このユーザーはこのホストの 443 だけ」)

- 通常 **TCP プロキシ** モデル — メッシュ IP ではなく「名前ベース」

Twingate の構成要素

[ユーザーデバイス + Twingate クライアント]

|

v(TLS、認証トークン)

[Twingate Controller(SaaS)] -- ポリシー評価

|

v

[Twingate Connector(社内に設置)]

|

v

[保護対象(DB、内部 Web アプリ、SSH)]

ポイント:**Connector は outbound のみで Controller に接続する**。社内に inbound ポートを開ける必要がない。これは Cloudflare Tunnel と同じパターン。

強み

- **ポートを開けない**。社内リソースをインターネットに露出せずアクセス可能。

- **リソース単位 ACL**。「Alice は staging の jenkins:8080 だけ」のように書ける。

- **デバイス posture**。Mac のディスクは暗号化されているか? OS は最新か? でなければブロック。

- **拠点間 VPN の代替**。ユーザー → リソース モデルなので「拠点間 VPN ルーティング」を書かなくていい。

弱点

- **メッシュではない**。ノード同士は見えない。ユーザー → リソース の一方向。

- **ベンダーロックインが強い**。コントロールも connector も会社のコード。

- **SaaS 価格帯**。SMB には高価になりうる。

誰が選ぶか

- 既に社内に OpenVPN / Cisco AnyConnect で「拠点間 VPN」を運用していて **それを終わらせたい** エンタープライズ。

- コンプライアンス(SOC 2、ISO 27001)が「セッションごとの認証、デバイス posture、監査ログ」を要求するとき。

- コールセンター / サポート組織のような「短時間入って 1 リソースだけ見る」パターン。

11 章 · Cloudflare WARP / Zero Trust — 消費者 + エンタープライズ

Cloudflare は 2 つの異なる製品を 1 つの傘の下にまとめている。

WARP — 無料コンシューマ VPN もどき

元はモバイルアプリだった。「DNS を 1.1.1.1 に送り、全トラフィックを CF のグローバルネットワークに通す」無料サービス。伝統的 VPN との違い:

- IP を隠すことが主目的ではない(Mullvad とは別物)。

- 「遅い ISP ルーティングよりも CF の速いバックボーン」がセールスポイント。

- WireGuard 派生(Cloudflare 製の BoringTun)の上で動く。

WARP+(有料)は優先ルーティングと小さな追加機能。

Cloudflare Zero Trust — エンタープライズ ZTNA

同じクライアントが、実は **エンタープライズゼロトラストプラットフォームの入口** でもある。

- **Cloudflare Access**:SaaS / 内部アプリの前に SSO + ポリシーゲート(BeyondCorp パターン)。

- **Cloudflare Tunnel**(旧 Argo Tunnel):connector デーモンが outbound で CF に接続し、社内リソースを安全に露出。

- **Gateway**:ユーザー → インターネット トラフィックを DNS / HTTP / ネットワークフィルタで検査(SWG)。

- **Browser Isolation**:危険なサイトはクラウドブラウザでレンダリングし、ピクセルだけ送信。

- **Cloudflare One**:上記すべてを「SASE」傘の下にまとめる。

強み

- **グローバルバックボーン**。320+ 都市の PoP。どこから接続しても近い PoP がある。

- **DNS / CDN / DDoS / Workers が同じ会社**。統合度が高い。

- **無料枠が本当に使える**(Zero Trust は 50 ユーザーまで無料)。

- **DEX(Digital Experience Monitoring)** — ユーザー体験そのものを計測。

弱点

- **メッシュ VPN ではない**。モデルはノード同士ではなく「すべてが Cloudflare を通る」。

- **すべての信頼を Cloudflare に置く**。メタデータ、DNS、トラフィックパターンが CF に見える。

- **ベンダーロックインの最終形態**。Workers、R2、KV まで入れると抜け出しにくい。

誰が選ぶか

- すでに Cloudflare を CDN / WAF として使っている会社 — 自然な拡張。

- 分散したグローバル人材(時差の大きい拠点群)。

- 「SASE を 1 ベンダーで片付けたい」エンタープライズ。

12 章 · その他のオプション — Innernet、Yggdrasil、ほか

Innernet(Tonari)

東京の Tonari が作った **シンプルな WireGuard メッシュツール**。OSS。「Tailscale は多すぎ、wg-quick は少なすぎ」の中間を狙った。

- **1 台のサーバがコントローラ**。ノード追加は招待トークンで。

- **CIDR ツリー構造の ACL** — ネットワーク / CIDR で認可を表現。

- **DERP なし**。NAT トラバーサルは最低限。

- 小規模分散チームが「Tailscale をセルフホストする軽量代替」として使う。

Yggdrasil

**世界中の人が互いにルーティングするメッシュ IPv6 ネットワーク**。学術 / 実験プロジェクトみたいに見えるが、実際に動く。

- 各ノードが ed25519 鍵ペア → 鍵から決定的に IPv6 アドレスが導かれる。

- 任意の「ピア」と接続するだけでグローバルルーティングツリーに参加。

- 会社が運営していない。本物の P2P メッシュ。

用途:

- 「インターネットが壊れても自分たちでルーティング可能なバックアップネットワーク」

- 学術実験

- IPv6 メッシュへの政治的信念を持つ人

エンタープライズには不向き。コントロール、SLA、監査という概念自体がない。

その他、聞き流すな

- **Tinc** — 1998 年から存在する P2P VPN。WireGuard 以前の世代だが今も一部で使われている。

- **OpenZiti** — 「アプリ組み込み型ゼロトラスト」。SDK をアプリに直接組み込む。

- **Boundary**(HashiCorp)— 「ユーザー → DB / サーバ」のセッションブローカー。メッシュ VPN とは別カテゴリ。

- **GoodAccess、Perimeter 81(現 Check Point)** — エンタープライズ SaaS VPN、非米市場中心。

13 章 · ACL / MagicDNS / exit node / subnet router — 運用パターン

機能名は分かった。では **実戦でどう使うか** を、パターンを軸に押さえよう。例は Tailscale ACL 構文で書くが、NetBird・Headscale も実質同じ概念を持つ。

ACL — 本物のゼロトラストの形

{

"groups": {

"group:eng": ["alice@example.com", "bob@example.com"],

"group:ops": ["carol@example.com"]

},

"tagOwners": {

"tag:prod-db": ["group:ops"],

"tag:staging": ["group:eng"]

},

"acls": [

{ "action": "accept", "src": ["group:eng"],

"dst": ["tag:staging:22,80,443"] },

{ "action": "accept", "src": ["group:ops"],

"dst": ["tag:prod-db:5432"] }

],

"ssh": [

{ "action": "check", "src": ["group:eng"],

"dst": ["tag:staging"], "users": ["root", "ubuntu"] }

]

}

中核原則:

- **個別ユーザーではなくグループ・タグで表現**。入退社時はグループメンバーシップだけ更新。

- **ポート単位まで絞る**。「staging の 80 / 443 / 22 だけ」のように。

- **デフォルト拒否**。明示的に許可していないものはすべて拒否。

- **マシンは人ではない**。マシンにはタグ(例:`tag:prod-db`)、人にはグループ。

MagicDNS — 名前がそのまま IP

`tailscale up` の後、`ssh laptop` がそのまま通る。ノード登録時に受け取った名前が `100.x.x.x` に自動解決される。短い名前は同一 tailnet 内のみ、フル名は `laptop.tail1234.ts.net`。

運用上の意味:

- **`/etc/hosts` や分散 DNS の管理が不要に**。

- **Headscale・NetBird も同等機能** を(別ドメインで)提供。

- **MagicDNS は ACL の可読性を爆上げする**。IP ではなく名前でポリシーを書ける。

Exit Node — メッシュ内の「デフォルトゲートウェイ」

特定ノードを exit node として宣言

sudo tailscale up --advertise-exit-node

クライアント側で出口として指定

tailscale set --exit-node=my-exit

用途:

1. **カフェ WiFi のフィルタ回避** — 会社メッシュの一台を経由してインターネットへ。

2. **ジオフェンス回避** — 他国にノードがあればその国に見える。

3. **Mullvad exit(Tailscale)** — 38 か国の出口。

4. **SaaS 側 IP 許可リストの単純化** — exit ノード 1 台分の IP だけ登録すれば済む。

Subnet Router — メッシュが届かない場所まで

社内 192.168.10.0/24 をメッシュに公開

sudo tailscale up --advertise-routes=192.168.10.0/24

管理者が管理 UI でルートを承認

用途:

- **レガシー機器**(メッシュクライアントを入れられない NAS、プリンタ、IPMI)

- **クラウド VPC** — VPC 内の EC2 1 台を subnet router にすれば VPC 全体がメッシュから見える。

- **拠点間 VPN の事実上の代替**。

High Availability Subnet Router

複数ノードが同じサブネットを広告すれば、Tailscale は自動フェイルオーバー。1 台のルーターが落ちても接続は切れない。

14 章 · 韓国・日本での導入 — トス、LINE、メルカリ

韓国・日本市場のゼロトラスト / オーバーレイ VPN 導入は急速に進んだ。公開されているいくつかの事例。

トス(Viva Republica)

トスは「inner network」という名で社内ゼロトラストモデルを運用している。要素:

- ユーザーノート PC → 社内リソースのアクセスには **デバイス証明書 + SSO** が必須。

- 拠点間 VPN を削減し、**ユーザー単位 ACL モデル** に移行。

- 社内発表(2024–2025)で「VPN ゲートウェイの廃棄 / メッシュモデルへの移行」を繰り返し言及。

- 自前ビルドと商用ソリューションのハイブリッド。

教訓:

- 「VPN を切ってゼロトラストに行こう」というポリシー判断が先。

- そのあと段階的に移行(1 リソース → 1 部署 → 全社)。

- 通常 1 〜 2 年かかる。

LINE

LINE の SRE / ネットワークチームは、グローバル分散(日本・韓国・タイ・インドネシア・台湾)という事情から、早期に **自社メッシュ / ゼロトラストモデル** を運用してきた。

- OSS コンポーネント + 自社コントロールプレーンの組み合わせ。

- 東京本社の社員がジャカルタ DC にアクセスするシナリオで **地理的に最も近い PoP を自動選択**。

- 社内発表で「OpenVPN ゲートウェイの整理 + ゼロトラスト傘」の話を定期的にしている。

メルカリ

東京のメルカリは「全社マイクロサービス + グローバル人材」モデル — このタイプはゼロトラスト導入コストが最も大きい部類だ。

- Cloudflare Access + 自社ポリシーエンジンの組み合わせで社内ツールをゲーティング。

- 「VPN を経由せず社内ツールに直接」という方向性をエンジニアリングブログで何度も公開。

- 日本企業の中ではゼロトラスト導入の先駆者としてよく引用される。

韓国・日本市場の共通パターン

1. **個人ノート PC の会社メッシュ参加は通常 SSO + デバイス証明書**。

2. **社内拠点間 VPN は縮小中**。Tailscale subnet router や ZTNA connector に置換。

3. **金融業** はデータ主権の懸念から **セルフホスト(Headscale、NetBird、自社構築)** を好む。

4. **モバイルゲーム / エンタメ** は **Cloudflare Zero Trust** の採用率が高い。

5. **スタートアップ** は Tailscale の無料 / Starter プランから始める。

15 章 · 誰が何を選ぶべきか — シナリオ別決定ツリー

最後にカタログを短い「判断」形式に圧縮する。

個人 / ホームラボ

**Tailscale Free**。終わり。3 ユーザー / 100 デバイスまで無料、全機能。Mullvad exit が必要なら最安の有料プラン + Mullvad アドオン。セルフホストの欲が出てきたら Headscale に移行。

避けるべき:2026 年に「ヒマだから OpenVPN を初セットアップ」。

1 〜 10 名のスタートアップ

**Tailscale Starter** または **NetBird Cloud**。SSO が要るなら前者。価格に敏感なら後者。

SMB(10 〜 200 名)

3 つの道:

1. **Tailscale Premium / Enterprise** — 最速導入。

2. **NetBird(セルフホスト)** — セルフホスト要件あり、または予算削減。

3. **Cloudflare Zero Trust** — 既に CF 顧客、または SASE 一括傘を望むとき。

エンタープライズ(200 名 +)

ほぼ確実に **2 製品の組み合わせ** になる。

- ユーザー → 社内リソース / SaaS:Cloudflare Zero Trust または Twingate。

- サーバ間インフラメッシュ:Tailscale Enterprise、Headscale、または Nebula / Defined Networking。

- ノート PC に入るクライアントが 1 つだと嬉しい — それも 1 ベンダーに統一する理由。

規制業界(金融・政府・医療)

**セルフホスト Headscale または NetBird** + 自社 DERP。データもメタデータも国内に留める。コントロールプレーンが侵害されても影響範囲を制御可能。

大規模サーバインフラメッシュ(数万ノード)

**Nebula または Defined Networking**。PKI ベースの分散信頼モデルがコントロールプレーン依存を減らす。

グローバル分散人材(多数の PoP)

**Cloudflare Zero Trust** または **Tailscale + 自社運営 DERP**。PoP 近接性がユーザー体験の大きな割合を占める。

インターネット遮断環境(船舶、鉱山、僻地)

**Headscale + 自社 DERP**、または **Nebula**。外部コントロールプレーン依存ゼロ。

Layer 2 セマンティクスが本当に必要

**ZeroTier**。ほぼ唯一の合理的選択。

政治的・実験的メッシュ

**Yggdrasil**。または同種の P2P ネットワーク。

まとめ — 「VPN」という単語はそのうち使わなくなるかも

2026 年、私たちは「VPN を入れる」という言い方を徐々にしなくなっている。代わりに「**ゼロトラストネットワーク**」「**オーバーレイメッシュ**」「**デバイス ID**」と言う。

技術的にはほぼ同じことだ — ノード間の暗号化トンネル。違うのは **モデル** だ:

- 昔:「境界の中に入れば全部見える」

- 今:「身元 / デバイス / 文脈をリクエストごとに評価、権限はリソース単位」

このモデル移行のデータプレーンはほぼ WireGuard が押さえた。コントロールプレーンと UX は Tailscale が定義した。その隙間 — セルフホスト、SSO 統合、エンタープライズポリシー — を Headscale、NetBird、Twingate、Cloudflare Zero Trust、Nebula、Defined Networking が埋めている。

次に誰かに「自宅から会社サーバに ssh したい」の答えを返すとき、その答えが OpenVPN なら、もう遅い。Tailscale をひとまずインストールして ssh を 1 回打ってみるといい。5 分後に「世界はこんなに単純でいいんだ」という瞬間が来る。

それが 2026 年のオーバーレイ VPN の約束だ。

参考 / References

- WireGuard: [https://www.wireguard.com/](https://www.wireguard.com/)

- Tailscale: [https://tailscale.com/](https://tailscale.com/)

- Tailscale Funnel: [https://tailscale.com/kb/1223/funnel](https://tailscale.com/kb/1223/funnel)

- Tailscale Mullvad: [https://tailscale.com/kb/1258/mullvad-exit-nodes](https://tailscale.com/kb/1258/mullvad-exit-nodes)

- DERP(Tailscale): [https://tailscale.com/kb/1232/derp-servers](https://tailscale.com/kb/1232/derp-servers)

- Headscale: [https://github.com/juanfont/headscale](https://github.com/juanfont/headscale)

- ZeroTier: [https://www.zerotier.com/](https://www.zerotier.com/)

- Nebula(Slack): [https://github.com/slackhq/nebula](https://github.com/slackhq/nebula)

- Defined Networking: [https://www.defined.net/](https://www.defined.net/)

- NetBird: [https://netbird.io/](https://netbird.io/)

- NetBird(GitHub): [https://github.com/netbirdio/netbird](https://github.com/netbirdio/netbird)

- Twingate: [https://www.twingate.com/](https://www.twingate.com/)

- Cloudflare Zero Trust: [https://www.cloudflare.com/zero-trust/](https://www.cloudflare.com/zero-trust/)

- Cloudflare WARP: [https://1.1.1.1/](https://1.1.1.1/)

- Cloudflare Tunnel: [https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/)

- Innernet(Tonari): [https://github.com/tonarino/innernet](https://github.com/tonarino/innernet)

- Yggdrasil Network: [https://yggdrasil-network.github.io/](https://yggdrasil-network.github.io/)

- BeyondCorp(Google): [https://cloud.google.com/beyondcorp](https://cloud.google.com/beyondcorp)

- NIST SP 800-207 Zero Trust Architecture: [https://csrc.nist.gov/publications/detail/sp/800-207/final](https://csrc.nist.gov/publications/detail/sp/800-207/final)

- LINE Engineering: [https://engineering.linecorp.com/en](https://engineering.linecorp.com/en)

- Mercari Engineering: [https://engineering.mercari.com/en/](https://engineering.mercari.com/en/)

- トス Tech Blog: [https://toss.tech/](https://toss.tech/)