💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「VPN クライアント入れてください」が消える時代

2026年、新人エンジニアの初日。

新人: 「社内システムに繋ぐ VPN クライアントは入れたほうがいいですか?」

プラットフォームエンジニア: 「ん? ノートパソコンに会社アカウントでログインするだけだよ。VPN はないよ。」

新人: 「...VPN がない?」

この短い会話に 2026 年のネットワーキング地図の半分が詰まっている。Cisco AnyConnect や GlobalProtect を入れ、トークンをもらい、社内 IP が割り当てられるのを 30 秒待つ時代は縮小している。その場所を Tailscale, Cloudflare Zero Trust, Twingate が埋めた。

ただし、逆方向の流れもある。**Mullvad** や **ProtonVPN** のようなプライバシー VPN は人口比でユーザー数を伸ばしている(検閲・監視の懸念が大きい地域では特に)。**WireGuard** はカーネルに入り、OpenVPN を急速に置き換えている。自前ホスト陣営では **Headscale · NetBird · Pangolin** が GitHub スターを吸い込んでいる。

この記事では 2026 年の VPN とメッシュネットワーキングを一度に整理する。WireGuard の技術的優位、Tailscale を中心とするメッシュオーバーレイの爆発、SASE/ZTNA の商用スタック、自前ホストの選択肢、プライバシー VPN、そして韓国・日本のビッグテックが実際に何を使っているか。

1. 2026 年のネットワーキング地図 — 5 つのパラダイム

VPN という単語にまとめるには違うものを呼びすぎている。2026 年は次の 5 つに分かれる。

| パラダイム | 意味 | 代表 |

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

| Site-to-site VPN | 2 つのネットワークを IPsec/WireGuard で接続 | Cisco ASA, FortiGate, AWS Site-to-Site VPN |

| Remote access VPN (レガシー) | ユーザーが社内 LAN に接続 | Cisco AnyConnect, GlobalProtect, FortiClient |

| メッシュオーバーレイ | 全ノード P2P で通信 | Tailscale, NetBird, ZeroTier, Nebula |

| ZTNA / SASE | アプリ別 zero-trust アクセス | Twingate, Cloudflare Access, Zscaler |

| プライバシー VPN | 単一ゲートウェイで外に出るトラフィック | Mullvad, ProtonVPN, IVPN |

最初の問いは「ユーザーは誰で、何を守りたいか」だ。意思決定ツリー。

1. **個人のプライバシー・検閲回避** → Mullvad, ProtonVPN, IVPN。

2. **開発者のノート PC から自宅ラボ / クラウド VPC へのアクセス** → Tailscale, NetBird, ZeroTier。

3. **複数拠点(本社 - 支社 - AWS - GCP)の接続** → WireGuard を直接、Tailscale subnet router、NetBird。

4. **社員の社内アプリアクセス、SSO 統合** → ZTNA(Twingate, Cloudflare Access)。

5. **数万人規模の大企業、全トラフィック検査・DLP** → SASE(Zscaler, Netskope, Palo Alto Prisma)。

6. **K8s クラスタのノード / Pod アクセス** → Tailscale Operator, NetBird K8s。

2026 年のベテランはこう言う ——「50 人以下のチームが Zscaler 入れるな。Tailscale なら 2 時間で終わる」。逆に 5 万人規模の企業が Tailscale Free で運用すると ACL 管理が地獄になる。ツールは規模に従属する。

2. VPN の進化 — PPTP / L2TP / OpenVPN / IPsec / WireGuard

WireGuard がなぜゲームチェンジャーかを理解するには、その前世代を簡単に見るとよい。

| プロトコル | 登場 | 特徴 | 2026 年の状況 |

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

WireGuard の魅力は **コード量** だ。OpenVPN(140K LOC) + OpenSSL(数十万 LOC) に対して、WireGuard は約 **4,000 行**。監査可能性・攻撃面・性能のすべてで圧倒的。Linux 5.6 でメインラインのカーネルモジュールに入ったのが 2020 年。それ以降、ほぼ全てのメッシュオーバーレイのデータプレーンは WireGuard に収束した。

WireGuard 自体は **単一の UDP ポート(デフォルト 51820)** で動く。TCP カプセル化がないので head-of-line blocking もなく、ハンドシェイクは Noise framework ベースの 1-RTT。最も単純なコマンド。

最も単純な WireGuard インターフェースを起動

wg-quick up wg0

wg0.conf で [Interface] / [Peer] を定義

`wg0.conf` の例。

[Interface]

PrivateKey = my_private_key_here

Address = 10.0.0.1/24

ListenPort = 51820

[Peer]

PublicKey = peer_public_key_here

AllowedIPs = 10.0.0.2/32

Endpoint = peer.example.com:51820

PersistentKeepalive = 25

`AllowedIPs` がルーティングと暗号化の両方を定義する。この最小モデルが、すべてのオーバーレイが WireGuard を採用した理由だ。

3. WireGuard 単体でメッシュを作れるか — 限界

WireGuard だけでメッシュを作れるか? 可能だが、N ノードあれば NxN の peer 設定を手で管理することになる。ノードの追加・削除のたびに全ノードの設定を更新。鍵交換の自動化なし。両側 NAT 配下での同時接続時の hole punching なし。DNS 統合なし。ACL なし。

これを解決するために生まれたのが **コントロールプレーン + WireGuard データプレーン** の組み合わせだ。Tailscale · NetBird · Headscale · Innernet · Wesher はすべて同じ発想。

- **コントロールプレーン** — ノード登録、鍵交換、ACL、DNS、NAT 越えコーディネーションを担当する別サーバー。

- **データプレーン** — ノード間の実トラフィック。99% は WireGuard そのまま。

この分離がメッシュ VPN の本質だ。次節からは各実装がコントロールプレーンをどう設計したかを見る。

4. Tailscale — WireGuard 上の zero-config メッシュ

2019 年に Avery Pennarun らが立ち上げた Tailscale は 2026 年現在、メッシュ VPN の事実上の標準だ。GitHub スター約 25,000、マネージドユーザーは数十万チーム。

**Tailscale のコア設計**。

1. **コントロールプレーン**(coordination server)は SaaS。鍵交換・ACL・DNS・認証を担当。

2. **データプレーン** は WireGuard ベース。ノード間で直接通信。

3. **NAT 越え** — STUN で外部 IP・ポートを発見、可能な限り hole punching、失敗したら **DERP リレー**(Designated Encrypted Relay for Packets)経由。DERP は終端まで暗号化されたトラフィックを中継するだけ。

4. **MagicDNS** — `nodename.tailnet-name.ts.net` の形式でノードにアクセス。

5. **認証** は OIDC SSO。Google, GitHub, Microsoft, Okta, Apple。パスワード・鍵配布なし。

最も単純な開始。

Linux

curl -fsSL https://tailscale.com/install.sh | sh

sudo tailscale up

ブラウザでログインして終わり

`sudo tailscale up` 一行でノート PC・サーバー・NAS すべてがメッシュに入る。その後はノード名で ssh, http, db すべて到達できる。

**Subnet router** と **exit node** が 2 つの強力な機能。

- **Subnet router**: Tailscale を入れていない LAN 内デバイス(ルーター、プリンター、レガシーサーバー)をメッシュからアクセス可能にする。例: `sudo tailscale up --advertise-routes=10.1.0.0/24`。

- **Exit node**: あるノードをインターネット出口として使う。カフェ wifi から自宅・会社回線で出る。`sudo tailscale up --exit-node=home-server`。

**ACL** は JSON で宣言。

{

"tagOwners": {

"tag:prod": ["group:sre@company.com"],

"tag:dev": ["group:eng@company.com"]

"acls": [

{ "action": "accept",

"src": ["group:eng@company.com"],

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

{ "action": "accept",

"src": ["group:sre@company.com"],

"dst": ["tag:prod:*"] }

]

}

2026 年の価格(米国基準)。

| プラン | 価格 | ユーザー | デバイス |

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

| Personal | 無料 | 3 | 100 |

| Starter | 6/user/mo | 無制限 | 無制限 |

`Tailscale Funnel` はメッシュ内部サービスをインターネットに公開する機能。自宅ラボで 80/443 を開けずに外部 HTTPS 公開ができる。

**知っておくべきこと**。コントロールプレーンにメタデータが流れる ——ノード名、公開鍵、IP、接続時刻。データパケット自体は通らない(P2P か DERP 中継)が、メタデータを外部企業に預けるのが受け入れ難い場合は次節の Headscale へ。

5. Headscale — Tailscale コントロールプレーンのオープンソース

**Headscale** は Tailscale コントロールプレーンのオープンソース再実装。Juan Font が始め、2026 年現在 GitHub スター 25,000+。Tailscale クライアントをそのまま使いつつ、コントロールプレーンだけを自前ホストする。

Docker で Headscale を立ち上げる(最小例)

docker run -d --name headscale \

-p 8080:8080 -p 9090:9090 \

-v /etc/headscale:/etc/headscale \

headscale/headscale:latest \

headscale serve

ユーザー / ネームスペース作成

docker exec headscale headscale users create alice

ノード登録用 pre-auth key

docker exec headscale headscale preauthkeys create -u alice

クライアント側。

Tailscale クライアントを Headscale に登録

sudo tailscale up \

--login-server=https://hs.example.com \

--authkey=PRE_AUTH_KEY_HERE

Headscale のトレードオフ。

- **メリット**: メタデータを自前保管、外部依存ゼロ、無料。

- **デメリット**: 一部機能(高度な ACL 機能の一部、クライアント自動更新、レポート) は未対応。SSO・SCIM は別途設定が必要。DERP リレーも自前運用(または公式 Tailscale DERP に申請)が必要。

Headscale + 自前 DERP + 自前 SSO を一度組めば、Tailscale Free に相当する無制限ユーザー・デバイスを自前運用できる。運用負荷 vs コスト・プライバシーのトレードオフだ。

2025 年リリースの **Headscale 0.24** から ACL JSON 互換性、IPv6 対応、HA モードが安定化。Mercari、Cloudflare、一部の韓国スタートアップが自前運用事例をブログで公開している。

6. NetBird — 自前ホストフレンドリーなメッシュ

**NetBird**(旧 Wiretrustee)は 2021 年にベルリンのチームが始めたオープンソースメッシュ。2026 年現在 GitHub スター 13,000+。Tailscale と比べて自前ホストが一級市民だ。

NetBird の差別化ポイント。

1. **自前ホストが第一シナリオ**。Docker Compose 一発でコントロールプレーン + シグナルサーバー + Coturn(STUN/TURN) + 管理 UI が全部立ち上がる。

2. **WebUI が初日から充実**。ACL、peer グループ、route、exit node すべて GUI で操作可能。

3. **SSO** は Auth0, Keycloak, Authentik, Zitadel, JumpCloud, AWS Cognito, Microsoft Entra など広範囲に対応。

4. **K8s 統合** — NetBird Operator で Pod 単位のアクセス可能。

5. **クラウドもある** — netbird.io。無料 100 peers、5+/user/mo から。

典型的な自前ホスト起動。

NetBird 自前ホスト(簡易版)

curl -fsSL https://github.com/netbirdio/netbird/releases/.../getting-started-with-zitadel.sh | bash

NetBird の NAT 越えはシグナルサーバー(WebSocket) + STUN + Coturn TURN で構成。Tailscale の DERP に相当するのが Coturn relay。

**ACL 例**。グループベースのポリシー。

NetBird ポリシー(概念表現)

rules:

- name: dev-to-staging

sources: [group:engineering]

destinations: [group:staging-servers]

ports: [22, 80, 443]

protocols: [tcp]

Tailscale より NetBird を選ぶ理由。

- **自前ホスト優先**: メタデータすべて社内。

- **EU GDPR 懸念が大きい組織**: ドイツの会社、EU ホスティング可能。

- **K8s 環境**: NetBird Operator が活発に開発中。

- **OIDC SSO の幅広いサポート**。

短所は、Tailscale に比べてエコシステムが小さく、エッジケースの安定性検証が浅いこと。ただし 2025 年 v0.30 以降、本番投入事例が急速に増えている。

7. ZeroTier — 古めのメッシュ、独自プロトコル

**ZeroTier** は 2014 年から運営されているメッシュ VPN。WireGuard より先に登場し、独自プロトコルでノード間 P2P メッシュを作る。2026 年現在 GitHub スター 14,000+。

ZeroTier の特徴。

- **L2 仮想イーサネット** を提供。単純な L3 ルーティングではなく仮想 NIC を作り、マルチキャスト・ブロードキャストが動く。Wake-on-LAN, mDNS, NBT のような L2 依存プロトコルがメッシュ越しに動作する。

- **独自プロトコル** — WireGuard ではない。C++ 製のデータプレーン。性能は WireGuard よりやや劣るというのが一般的な評価。

- **無料 25 nodes** + **5/mo Business**(50 nodes) + **50/mo Pro**(200 nodes)。

- **自前ホスト可能** — コントローラーを自前運用可能。だが Tailscale ほど運用ツールはフレンドリーでない。

ZeroTier が今も選ばれる理由。

- **L2 が必要なとき** — ゲーム LAN パーティ、Windows ドメイン、レガシー産業用機器。

- **既に導入済み**: 2018-2022 年に ZeroTier で始めたチームがそのまま運用。

新規プロジェクトなら WireGuard ベース(Tailscale/NetBird)が一般的な推奨。

8. Nebula — Slack 発、証明書ベースのオーバーレイ

**Nebula** は Slack が社内インフラ用に作り、2019 年にオープンソース化したメッシュオーバーレイ。その後 **Defined Networking** という会社にスピンアウト。GitHub スター 14,000+。

Nebula の設計思想。

- **mTLS に似た PKI モデル** — 全ノードが証明書を持ち、CA が発行する。SSO なし。

- **コントロールプレーンが軽量** — Lighthouse という単純なノードディスカバリ。ACL は分散。

- **WireGuard ではない** — 独自 UDP プロトコル(Noise framework ベース)。

- **自前ホストが基本**、Defined Networking の SaaS もあり。

Nebula の強みは **スケーラビリティ**。Slack 社内で数万ホスト規模で運用されたトラックレコード。証明書ベースなので SaaS コントロールプレーン依存がなく、Lighthouse が死んでも既存 peer は通信を継続。

設定は YAML。

nebula ノード設定例

pki:

ca: /etc/nebula/ca.crt

cert: /etc/nebula/host.crt

key: /etc/nebula/host.key

static_host_map:

"10.0.0.1": ["lighthouse.example.com:4242"]

lighthouse:

am_lighthouse: false

hosts:

- "10.0.0.1"

firewall:

inbound:

- port: 22

proto: tcp

groups: [admin]

短所は **ユーザビリティ**。SSO・MagicDNS・WebUI がないか弱い。証明書の発行・ローテーションを自前運用する必要がある。だから「エンジニアリングチームが PKI に慣れている場所」が主要ユーザー。

9. Twingate — 商用 ZTNA

**Twingate** は 2019 年設立の ZTNA(Zero Trust Network Access)商用ソリューション。メッシュ VPN とは性格が異なる ——ノード間 P2P メッシュではなく **アプリ別プロキシ** だ。

Twingate の構成。

1. **Controller**(SaaS): ポリシーと認証。

2. **Connector**: 保護対象ネットワーク内部に配置。クライアントリクエストを受けて内部リソースにプロキシ。

3. **Client**: ユーザーデバイスに導入。全トラフィックではなく **リソース別に** ルーティング。

このモデルの利点。

- **アプリ別アクセス制御** — `git.internal.example.com` は許可、`kibana.internal.example.com` は拒否、のように設定可能。

- **ユーザーデバイスに社内 IP 範囲が漏れない**。メッシュ VPN はデバイスが内部 IP を受け取るが、Twingate は DNS フック + プロキシ。

- **SSO + MFA + デバイスポスチャー** が一級。Okta, Google, Microsoft, OneLogin, JumpCloud。

2026 年価格。

| プラン | 価格 | 制限 |

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

| Starter | 無料 | ユーザー 5、リソース 10 |

| Teams | 5/user/mo | ユーザー 100 |

| Business | 10/user/mo | + audit log, SCIM |

| Enterprise | 問い合わせ | + SLA, dedicated support |

Twingate は「メッシュ VPN の利便性を持つ ZTNA」のポジション。50-500 人規模のチームで社内アプリアクセスによく採用される。Cloudflare Access の代替。

10. Cloudflare Zero Trust(Access + Tunnel + WARP)

**Cloudflare Zero Trust** は 2026 年 ZTNA 市場の最大プレイヤーの一つ。命名はよく変わるが(Argo Tunnel → Cloudflare Tunnel, Access, Gateway, WARP for Teams など)、コアは一貫している。

中核要素。

- **Cloudflare Tunnel**(cloudflared): 社内ネットワークから Cloudflare へのアウトバウンド TLS トンネル。インバウンドポートはゼロ。

- **Cloudflare Access**: 認証ポリシー。Cloudflare が OIDC IdP の前面に立ち、ユーザー検証後にリクエストを通す。

- **WARP / WARP for Teams**: クライアント側エージェント。DNS over HTTPS、ポリシー適用、split tunnel。

- **Gateway**: DNS/HTTP フィルタリング、DLP。

最も一般的な使い方。

内部サービスを Cloudflare Tunnel で外部に公開

cloudflared tunnel create homelab

cloudflared tunnel route dns homelab grafana.example.com

cloudflared tunnel run homelab

config.yaml

ingress:

- hostname: grafana.example.com

service: http://localhost:3000

この一行で Cloudflare のグローバル anycast でサービスが公開され、Access ポリシーで「Google Workspace の example.com ドメイン + MFA 通過 + 会社デバイスのみ」のようなルールを強制できる。

2026 年の価格 ——**無料**は 50 ユーザーまで。それ以上は **Pay-as-you-go**。トンネルトラフィック自体は無料。

自宅ラボ・小規模チームは事実上無料で ZTNA + グローバル公開を得られる。短所はすべてのトラフィックが Cloudflare を経由すること。メタデータ懸念が大きいなら次節の Pangolin。

11. Pangolin — 自前ホスト版 Cloudflare Tunnel 代替

**Pangolin** は 2024 年に登場し急速に人気を得た自前ホストのトンネル + リバースプロキシ。Cloudflare Tunnel と同じモデルを社内インフラで運用する。GitHub スター 5,000+。

Pangolin の構成。

- **Pangolin**(中央): パブリック IP/ドメインを持つサーバー。WireGuard で着信するアウトバウンド接続を受ける。

- **Newt**(クライアント): 社内ネットワークから Pangolin に WireGuard アウトバウンドトンネル。

- **Traefik 統合**: 着信 HTTPS を Traefik が受け、社内にプロキシ。

- **Auth**: 自前のユーザーシステム + OIDC/Authentik。

Cloudflare を使わず自宅ラボサーバーで外部 HTTPS 公開したい時に。典型的なセットアップ。

Pangolin 本体(VPS 上)

docker compose up -d # pangolin + traefik + crowdsec

Newt(社内ネットワークから)

docker run -d \

-e PANGOLIN_URL=https://pangolin.example.com \

-e NEWT_ID=NEWT_ID_HERE -e NEWT_SECRET=NEWT_SECRET_HERE \

fosrl/newt:latest

メリットは **完全自己保有**。Cloudflare のポリシー変更や ToS 違反で遮断されても影響ゼロ。無料。メタデータが社内。短所は本体 VPS の運用、DNS/証明書更新を自前で行うこと。

Reddit r/selfhosted で 2025-2026 年に最もホットな自前ホストプロジェクトの一つ。

12. OpenZiti / DefGuard / Innernet — その他のメッシュ選択肢

それ以外に知っておくべきメッシュ・VPN プロジェクト。

OpenZiti

NetFoundry のオープンソース zero-trust オーバーレイ。**アプリ組み込み可能な SDK** が差別化点 ——コードに zero-trust メッシュを直接統合できる。K8s, IoT, edge シナリオに強い。コアオーバーレイは独自プロトコル。

DefGuard

WireGuard 中心の VPN 管理ツール。WebUI、ユーザー/グループ/デバイス管理、OIDC 統合。**無料・オープンソース**。ポーランドの teonite が開発。自前ホスト WireGuard を GUI で管理したい時。

Innernet

Cloudflare が作った Rust ベースの自前ホストメッシュ。WireGuard 上の軽いコントロールプレーン。簡潔でミニマル。一部の運用チームで採用。

Wesher

Costela が作った gossip ベースの WireGuard メッシュ。中央サーバーなしでノード同士の合意で peer 一覧を維持。K3s クラスタノード接続で人気。

Tinc

2003 年からあるクラシックなメッシュ VPN。独自プロトコル。今も一部の ISP・研究所で使われているが、新規導入はほぼない。

Netmaker

WireGuard ベースの自前ホストメッシュ。Tailscale + Headscale 代替。Pro ライセンスモデル。

このグループはメインストリームではないが、特定ニーズ(組み込み SDK、gossip 分散、Rust 志向、ポーランド GDPR など)で選ばれる。

13. プライバシー VPN — Mullvad / ProtonVPN / IVPN

ここまでは「チームのメッシュ」だった。今度は **単一ゲートウェイから外に出る** プライバシー VPN。

Mullvad

スウェーデンの会社。2009 年スタート。2026 年プライバシー陣営の金字塔。

- **アカウント番号だけ** ——メール・名前・決済情報を受け取らない。16 桁のアカウント番号一つが ID。

- **現金・暗号通貨決済可能** ——郵送で現金を受け取ってアカウントを有効化。

- **No logs** ——外部監査レポートを公開。

- **5/mo フラット** ——単一価格。

- **WireGuard と OpenVPN**。

- **完成度の高いクライアント** Linux/macOS/Windows/iOS/Android。

2024 年 Mullvad は自製ブラウザ **Mullvad Browser** もリリース(Tor Project 協力)。プライバシー陣営の総合ソリューション。

ProtonVPN

スイス ProtonMail の子会社。無料プランが強い(帯域無制限、3 か国サーバー)。Proton Pass · Proton Mail · Proton Drive とバンドル。ユーザーフレンドリーな UI。

IVPN

ジブラルタル登記の会社。Mullvad と似た no-log 哲学。AntiTracker 機能。価格は少し高め。

Surfshark / ExpressVPN / NordVPN

大衆市場。マーケティングが強い会社群。無制限デバイス(Surfshark)、高速サーバー網(ExpressVPN)、ダブル VPN(NordVPN)。プライバシー陣営では「監査が弱い」との批判があるが、一般ユーザーには最も親しみやすい。

選択基準。

- **検閲・監視懸念が最大** → Mullvad(現金決済、no email)。

- **メール・生産性とバンドル** → Proton。

- **ストリーミング(Netflix 地域回避)** → ExpressVPN/NordVPN(サービス次第)。

- **安い、多数デバイス** → Surfshark。

企業ユーザーが社内データ保護目的でこのカテゴリーを入れてはいけない ——これは個人用。企業は ZTNA へ。

14. レガシー企業 VPN — Cisco / Palo Alto / Fortinet / F5

大企業・金融・政府網には今もこの陣営が圧倒的だ。

Cisco AnyConnect / Secure Client

Cisco のクライアント VPN。2026 年現在の正式名称は **Cisco Secure Client**。SSL VPN + IPsec + AnyConnect VPN。AAA 統合(ISE, RADIUS)、posture assessment。

Palo Alto GlobalProtect

Palo Alto Networks の NGFW に統合。デスクトップ・モバイルクライアント。最大の強みは **PAN-OS ポリシーと単一画面** ——ファイアウォールポリシーと VPN ユーザーポリシーが一画面。

Fortinet FortiClient

FortiGate と統合。コスパ。中小企業・教育機関に多い。ただし 2022-2023 年の複数の CVE(特に FortiOS SSL VPN)で評判には浮き沈みがある。

F5 BIG-IP Access(APM)

大企業データセンター陣営。SSL VPN + 豊富なポリシーエンジン + iRules。運用が複雑な分、大規模サイトに適合。

OpenVPN Access Server

OpenVPN の商用版。中小企業が OpenVPN プロトコルをマネージドで使いたい時。

この陣営の共通点。

- **ユーザー端末に重いクライアント** を導入。

- **社内 IP を端末に割り当て** ——メッシュ VPN と正反対。

- **コンプライアンス認証**(FIPS, Common Criteria, FedRAMP)。

- **数十〜数百万ユーザー運用のトラックレコード**。

- **価格が高い** ——ライセンス、アプライアンス、コンサルティング。

2026 年のトレンドはこの陣営から **SASE/ZTNA への移行**。Cisco は Secure Connect、Palo Alto は Prisma Access、Fortinet は FortiSASE、F5 は Distributed Cloud でそれぞれ SASE 製品を推している。

15. SASE — Zscaler / Netskope / Cloudflare / Palo Alto Prisma

**SASE**(Secure Access Service Edge)は Gartner が 2019 年に命名したカテゴリ。ZTNA + SWG(Secure Web Gateway) + CASB + FWaaS + SD-WAN を一つのクラウドエッジに統合。

大企業が「VPN をクラウドに移す」と言うとき行き先が SASE だ。

Zscaler

**ZIA**(Internet Access) + **ZPA**(Private Access) + **ZDX**(Digital Experience)。2026 年市場リーダー。価格はユーザーあたり数十ドル/月から。グローバル PoP が多数、すべてのトラフィックが Zscaler クラウドを経由。

Netskope

Zscaler と最も近いポジション。CASB(クラウドアプリ制御)が強み。生成 AI 利用制御など新規機能の投入が速い。

Cloudflare Zero Trust + Magic WAN

既に見た Cloudflare Zero Trust が SASE カテゴリでも大きなプレイヤー。**Magic WAN** + **Magic Transit** で拠点間接続まで。コスパ。

Palo Alto Prisma Access

PAN-OS ポリシーをクラウドエッジでそのまま。NGFW を既に使っている所に自然。

Cato Networks

イスラエル発。SD-WAN と SASE を最初から一緒に作った。シングルベンダー SLA。

SASE 導入は通常 18-24 か月のプロジェクト。コストが大きく、全社トラフィックのリルーティングが必要。だが一度入れば「全社員がどこからでも会社ポリシー下のインターネットを使う」が成立する。メッシュ VPN とは違う世界。

16. NAT 越えの技術 — STUN / TURN / hole punching / DERP

メッシュ VPN のマジックの大半は **NAT 越え** にある。家庭用ルーター、キャリアグレード NAT、モバイルネットワーク配下の 2 つのデバイスがどうやって P2P 接続を結ぶか。

基本ツール。

- **STUN**(Session Traversal Utilities for NAT): 外から見える自分の IP・ポートを知る。インターネット上の STUN サーバーにパケットを送ると「あなたは 1.2.3.4:54321 から来た」と返答。IPv4 メッセージ内に内部 IP/ポートを保持しない NAT 環境でも動作する。

- **TURN**(Traversal Using Relays around NAT): hole punching が失敗した場合に中継サーバー経由。

- **ICE**(Interactive Connectivity Establishment): STUN/TURN の結果を交換・試行するアルゴリズム。

- **Hole punching**: 両側が同時にアウトバウンドパケットを送ることで NAT が「この流れは活性」とマッピングを維持。

Tailscale の **DERP** は TURN の変種だ。**エンドツーエンド暗号化されたパケットの中継のみ**。DERP はトラフィックの中身を知らない。コントロールプレーンに登録されたノード ID でルーティングし、IP/ポートと無関係。

成功率。

- **両側フルコーン NAT** → P2P hole punching はほぼ常に成功。

- **片側 CGNAT** → hole punching を試み、失敗時 DERP/TURN へフォールバック。

- **両側 CGNAT** → DERP/TURN がほぼ強制。

- **ファイアウォールが UDP を遮断** → DERP は TCP 上 TLS にフォールバック。

Tailscale は自前 DERP を世界 30+ リージョンで運用。Headscale 自前運用チームは自前 DERP クラスタを立てるか、公式 Tailscale DERP を申請して使う。NetBird は Coturn が同じ役割。

この部分がメッシュ VPN の本当の価値だ。WireGuard だけ入れても NAT 配下では動かない。

17. 認証 / SSO / ACL — メッシュ VPN の実務運用

機能がカッコよくても **運用の 90%** は誰が何にアクセスできるかの管理だ。

認証

- **OIDC SSO** — Google Workspace, Microsoft Entra(Azure AD), Okta, GitHub, Auth0, JumpCloud。2026 年のメッシュ VPN はすべて対応。

- **SAML** — 一部(Enterprise プラン)。

- **WireGuard pre-shared key** — バックアップ・組み込み用。鍵ローテーションポリシーが必要。

- **mTLS / 証明書** — Nebula のような PKI モデル。

SCIM プロビジョニング

ユーザーが IdP を離れたらメッシュ VPN でも自動で無効化。**Tailscale Premium**、**NetBird Cloud**、**Twingate Business** から SCIM 対応。

ACL 設計原則

- **タグベース** — デバイス/ユーザーに tag を付け、tag 間のポリシーを書く。ユーザー/デバイスを直接列挙しない。

- **グループベース** — IdP のグループをメッシュ VPN のグループとマッピング。

- **明示的 deny + 精密な allow** — デフォルト deny、必要な流れだけ allow。

- **production 分離** — `tag:prod` と `tag:dev` を明確に分ける。同じユーザーでもコンテキストが違う。

鍵管理

- WireGuard private key はデバイスに保存。デバイス紛失時はメッシュから即座に revoke。

- pre-auth key は有効期間を短く。

- Tailscale はデバイス期限切れ(例: 90 日)を強制できる。

監査

- すべての接続・ポリシー変更・ログインは audit log へ。SIEM(Splunk, Datadog, Sumo)に転送。

- Tailscale, NetBird, Twingate すべて audit API を提供。

ここを抜いて ACL を適当に書くと、2 年後に「退職者のノート PC から production DB にアクセス可能な状態」を発見する。見たことがある。

18. MagicDNS / split DNS / subnet router / exit node

メッシュ VPN を本当に楽に使えるのは **DNS とルーティング** のディテールだ。

MagicDNS(Tailscale)

`<nodename>.<tailnet>.ts.net` でノードにアクセス。別途 hosts ファイル・DNS 設定なし。100.x.y.z の CGNAT 帯域で IP が割り当てられるがユーザーは名前だけ使えばよい。

Split DNS

特定ドメインはメッシュ内部 DNS、それ以外は通常 DNS。例: `*.internal.example.com` はメッシュ DNS、`google.com` は通常 DNS。

設定例(概念):

- *.internal.example.com -> 100.64.0.1(メッシュ内の内部 DNS サーバー)

- それ以外 -> システムデフォルト DNS

Subnet router

メッシュにないデバイス(レガシーサーバー、NAS、プリンター、IoT、AWS VPC 内のプライベートサービス)をメッシュからアクセス。あるノードがルーター役。

AWS VPC 内の EC2 が subnet router

sudo tailscale up --advertise-routes=10.1.0.0/16

その後 admin が承認すれば適用

この一行でノート PC から VPC 内の RDS, ElastiCache に直接アクセスできる。AWS Site-to-Site VPN がほぼ消える理由。

Exit node

すべてのインターネットトラフィックを特定ノード経由で出す。カフェから自宅・会社回線で。プライバシー VPN を自前運用するのと同じ。

自宅サーバーを exit node に

sudo tailscale up --advertise-exit-node

ノート PC で

sudo tailscale up --exit-node=home-server

App connector / Service connector

Tailscale 2024 年 GA。メッシュ内で DNS ベースで特定 SaaS(例: GitHub, Office 365)トラフィックを特定ノードへルーティング。SaaS の IP allowlist に単一 IP しか登録できないときに便利。

これらディテールがうまく動くと、ユーザーは「VPN をオン・オフする行為」自体を忘れる。それが良いメッシュ VPN の成功指標。

19. K8s 統合 — Tailscale Operator / NetBird Operator

K8s クラスタをメッシュに組み込む 2 つの方式。

Tailscale Operator

- Service に `tailscale.com/expose: "true"` アノテーションを付けると Operator が Tailscale に公開。

- クラスタ外部からメッシュ経由で Service にアクセス。

- 逆方向: メッシュ内ノードをクラスタ内からホスト名でアクセス可能。

- K8s Ingress / Egress プロキシとしても動作。

apiVersion: v1

kind: Service

metadata:

name: api

annotations:

tailscale.com/expose: "true"

spec:

ports: [{ port: 80, targetPort: 8080 }]

selector: { app: api }

この一行でクラスタ内の Service が `api.tailnet.ts.net` としてメッシュに公開される。

NetBird Operator / K8s モード

NetBird はノード(EC2/VM)ごとにクライアントを入れるか、K8s sidecar で Pod 単位のメッシュ参加が可能。CRD でポリシー管理。

Cloudflare Tunnel for K8s

`cloudflared` Deployment をクラスタにデプロイ。Service をトンネル経由で外部に公開。Tailscale Operator の Cloudflare 版。

K8s メッシュは 2026 年に非常に一般的なパターン。ClusterIP は普通外部から見えないが、Operator 一つでメッシュ認証されたユーザーが直接 ClusterIP にアクセスできる。

20. 自前ホスト vs SaaS — 意思決定

同じ機能を SaaS / 自前ホスト両方で提供するツールが多い。意思決定基準。

| 基準 | SaaS 寄り | 自前ホスト寄り |

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

| チームサイズ | 小(< 50) | 大(100+) |

| 運用人員 | なし | 1+ FTE |

| 月額コスト | 小規模利用 → SaaS | 大規模利用 → 自前ホスト |

| コンプライアンス | GDPR/HIPAA が弱い | 強い、データを外に出さない |

| ダウンタイム許容 | 外部依存 OK | 自社 SLA |

| メタデータ懸念 | 低 | 高 |

| グローバルノード | グローバル必要 → SaaS | 単一リージョン OK → 自前 |

典型的な進化パス。

- Day 1(スタートアップ 5 名): Tailscale Free。5 分。

- Year 1(50 名): Tailscale Starter 6/user。月 300 ドル。問題なし。

- Year 3(300 名、コンプライアンス強化): Tailscale Premium 18/user または Headscale 自前 + DERP。

- Year 5(3,000 名、グローバル、SASE 導入): Zscaler/Netskope または Cloudflare Zero Trust。

ほとんどのチームは Year 1-3 に留まる。Year 5 への突入はコンプライアンスかスケール事情が強制する場合。

21. コスト比較 — 100 名チーム 1 年基準

100 名の会社が社内網に全ユーザーをメッシュ VPN で接続すると仮定。2026 年の価格。

| オプション | 月額 | 年額 | 備考 |

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

| Tailscale Starter | 600 | 7,200 | 6/user/mo |

| Tailscale Premium | 1,800 | 21,600 | SCIM/audit 含む |

| NetBird Cloud Business | 500 | 6,000 | 5/user/mo |

| NetBird 自前ホスト | VPS 40+ | 480+ | 運用人件費別 |

| Twingate Teams | 500 | 6,000 | ZTNA, 5/user/mo |

| Twingate Business | 1,000 | 12,000 | + SCIM |

| Zscaler ZPA | 1,500+ | 18,000+ | 見積もりベース |

追加考慮点。

- **退職者処理**: SCIM がないと IdP 無効化とメッシュ VPN 無効化が自動連携されない。手動運用時間 = 人件費。

- **インシデント対応**: SaaS は対応が速く責任分担。自前ホストは全て自社責任。

- **エンタープライズ割引**: 100 名以上は直接交渉で 30-50% 割引が普通。

企業の意思決定は通常「Tailscale Starter で 1-2 年、SCIM が必要になれば Premium または自前ホスト比較、コンプライアンスが強制すれば Enterprise/ZTNA」パターン。

22. 韓国の導入 — NAVER / Toss / Kakao / Coupang

NAVER

NAVER は社内インフラが非常に大きい(自社データセンター + AWS)。VPN は伝統的に社内 OpenVPN/IPsec + 自社認証。最近一部の子会社・スタートアップチームで **Tailscale** 導入事例。セキュリティチームは ZTNA 評価を進行中。

Toss

Toss はクラウドネイティブ + zero-trust 志向。社内アクセス制御に SAML SSO + デバイス証明書 + メッシュオーバーレイの組み合わせ。Tailscale-like メッシュと社内独自ソリューションを併用。SLASH カンファレンスでセキュリティ・インフラ発表多数。

Kakao / Kakao Enterprise

Kakao は自社 IDC が大きい。伝統的 VPN(OpenVPN ベース) + 社内 IAM。一部チームでメッシュ VPN 評価。Kakao Enterprise がセキュリティ SaaS カタログを運営し社内標準化を試みる。

Coupang

AWS ヘビー。VPC peering + Site-to-Site VPN + 社内 ZTNA(商用製品導入が知られている)。グローバル進出後 SASE 検討が活発。

共通点 ——韓国のビッグテックは **伝統的 VPN からメッシュ/ZTNA への部分移行** 段階。「全社単一ソリューション」より「チーム/シナリオ別の適正ツール」が一般的。スタートアップや小さいチームほど Tailscale 採用が速い。

23. 日本の導入 — Mercari / LINE Yahoo / CyberAgent / DeNA

Mercari

Mercari は GCP ヘビー + zero-trust 積極導入。**Tailscale + Headscale** 導入事例が社内エンジニアリングブログで公開されている。社内サーバーアクセス・開発環境メッシュに活用。

LINE ヤフー

LINE とヤフー合併後の巨大組織。伝統的社内 VPN + 社内 IdP。ZTNA・SASE 導入が活発(詳細は非公開が多い)。社内カンファレンスで zero-trust 事例発表が増加。

CyberAgent / AbemaTV / Ameba

CyberAgent グループはクラウドが多様(AWS · GCP · 自社)。メッシュ VPN · SASE · ZTNA をワークロードごとに使用。AbemaTV のようなライブサービスはグローバル CDN + Zero Trust の組み合わせ。

DeNA

ゲーム・ヘルスケアなど多角化。社内セキュリティは ZTNA + DLP の組み合わせ。Tailscale のようなメッシュは部分利用。

Smartbank / 新興スタートアップ

日本の小さなフィンテック・SaaS スタートアップは Tailscale を day 1 から採用するケースが多い。ZTNA コストを賄う人員がなく、メッシュ VPN の zero-config が魅力的。

日本はセキュリティコンプライアンス(PCI-DSS、金融庁ガイドライン)の影響が大きい。大きい所は SASE/ZTNA 商用、小さい所は Tailscale/NetBird ——韓国と似た分布。

24. 用途別推奨 — 決定表

1 ページで見る推奨。

| シナリオ | 第 1 候補 | 代替 |

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

| 個人自宅ラボ外部アクセス | Tailscale Free + Funnel | Cloudflare Tunnel, Pangolin |

| 5 名スタートアップ社内網 | Tailscale Free/Starter | NetBird Cloud, Cloudflare Zero Trust Free |

| 30-100 名 SaaS 会社 | Tailscale Starter または Twingate | NetBird Cloud, Cloudflare Zero Trust |

| コンプライアンス重視、自前ホスト | Headscale + 自前 DERP | NetBird 自前ホスト |

| 拠点間(本社 - 支社 - AWS) | Tailscale subnet router | WireGuard 直 + 自動化 |

| K8s クラスタアクセス | Tailscale Operator | NetBird K8s, Cloudflare Tunnel |

| Air-gapped 環境のメッシュ | Nebula(証明書ベース) | Innernet |

| 5,000+ 大企業、全トラフィック検査 | Zscaler / Netskope / Cloudflare ZT | Palo Alto Prisma |

| 個人プライバシー(検閲回避) | Mullvad | ProtonVPN, IVPN |

| ゲーム / Windows ドメイン / L2 必要 | ZeroTier | (代替ほぼなし) |

| 中国市場進出(社内アクセス) | 自前 IPsec、一部 Cloudflare CN | 商用 SASE の中国 PoP |

運用視点で忘れないこと。

- **モニタリング** —メッシュノード状態、DERP 利用率、ACL 違反試行。Prometheus exporter または SaaS dashboard。

- **インシデントプレイブック** —「ユーザーノート PC 紛失」 → デバイス即座に revoke + 鍵ローテーション。

- **バックアップアクセス経路** —メッシュ VPN コントロールプレーン障害時の代替は? Tailscale の場合、既存 peer は通信継続、新ノード追加不可。自前ホストなら SLA を自前設計。

- **ユーザー教育** —「VPN をオンにしてください」のような案内が消えるのがメッシュ VPN の価値。ユーザー体験をうまく作るとセキュリティポリシー回避の試みが減る。

エピローグ — VPN は消え、メッシュはインフラになる

2026 年 VPN とメッシュネットワーキングの本当の教訓は「**もはや VPN はセキュリティの第一線ではない**」という点だ。社内網の中にいるから安全ではなく、社内網の外にいるから危険でもない。zero-trust の本来の意味 —— すべてのリクエストを認証・認可する —— がメッシュ VPN、ZTNA、SASE の形で実装される。

ツールは変わる。5 年前 OpenVPN を入れていた人が今日 Tailscale を入れ、来年は Cloudflare Zero Trust かもしれない。だが **誰が何にアクセスできるかを明示的にモデリングしたチームはツールが変わっても生き残る**。そうでないチームはツールを変えても同じ事故を見る。

次の記事候補: **WireGuard 深掘り — Noise framework / 形式検証 / カーネルモジュール内部**、**DERP 自前運用 — Headscale + 自前リレークラスタ構築**、**Tailscale ACL パターン — 100 名から 5,000 名までスケールするポリシー設計**。

> 「VPN を入れるという行為はやがて消える。残るのは認証と認可、その上を流れる目立たないトラフィックだ。」

— VPN & メッシュネットワーキング 2026、終わり。

参考 / References

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

- [WireGuard whitepaper — Jason Donenfeld](https://www.wireguard.com/papers/wireguard.pdf)

- [Linux kernel 5.6 WireGuard merge](https://lkml.org/lkml/2020/3/29/55)

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

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

- [Tailscale DERP servers explainer](https://tailscale.com/blog/how-tailscale-works)

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

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

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

- [ZeroTier GitHub — zerotier/ZeroTierOne](https://github.com/zerotier/ZeroTierOne)

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

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

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

- [Cloudflare Zero Trust Docs](https://developers.cloudflare.com/cloudflare-one/)

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

- [Pangolin GitHub — fosrl/pangolin](https://github.com/fosrl/pangolin)

- [OpenZiti](https://openziti.io/)

- [DefGuard GitHub — DefGuard/defguard](https://github.com/DefGuard/defguard)

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

- [Wesher GitHub — costela/wesher](https://github.com/costela/wesher)

- [Tinc VPN](https://www.tinc-vpn.org/)

- [Netmaker](https://www.netmaker.io/)

- [Mullvad VPN](https://mullvad.net/)

- [Mullvad Browser](https://mullvad.net/en/browser)

- [ProtonVPN](https://protonvpn.com/)

- [IVPN](https://www.ivpn.net/)

- [Cisco Secure Client](https://www.cisco.com/c/en/us/products/security/secure-client/index.html)

- [Palo Alto GlobalProtect](https://www.paloaltonetworks.com/network-security/globalprotect)

- [Fortinet FortiClient](https://www.fortinet.com/products/endpoint-security/forticlient)

- [F5 BIG-IP Access](https://www.f5.com/products/big-ip-services/access-policy-manager)

- [Zscaler ZPA](https://www.zscaler.com/products/zscaler-private-access)

- [Netskope](https://www.netskope.com/)

- [Palo Alto Prisma Access](https://www.paloaltonetworks.com/sase/access)

- [Cato Networks](https://www.catonetworks.com/)

- [Gartner SASE definition](https://www.gartner.com/en/information-technology/glossary/secure-access-service-edge-sase)

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

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

- [CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/)

- [Toss SLASH](https://toss.tech/slash)