VPN & メッシュネットワーキング 2026 完全ガイド — Tailscale · WireGuard · Twingate · ZeroTier · NetBird · Nebula · Mullvad · Headscale · Pangolin 深掘り

プロローグ — 「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 つに分かれる。

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

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 がなぜゲームチェンジャーかを理解するには、その前世代を簡単に見るとよい。

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 年の価格(米国基準)。

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 年価格。

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 / 自前ホスト両方で提供するツールが多い。意思決定基準。

典型的な進化パス。

• 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 年の価格。

追加考慮点。

• 退職者処理: 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 ページで見る推奨。

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

• モニタリング —メッシュノード状態、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
• WireGuard whitepaper — Jason Donenfeld
• Linux kernel 5.6 WireGuard merge
• Tailscale Documentation
• Tailscale Pricing
• Tailscale DERP servers explainer
• Headscale GitHub — juanfont/headscale
• NetBird GitHub — netbirdio/netbird
• NetBird Documentation
• ZeroTier GitHub — zerotier/ZeroTierOne
• Nebula by Defined Networking
• Nebula GitHub — slackhq/nebula
• Twingate Documentation
• Cloudflare Zero Trust Docs
• Cloudflare Tunnel
• Pangolin GitHub — fosrl/pangolin
• OpenZiti
• DefGuard GitHub — DefGuard/defguard
• Innernet GitHub — tonarino/innernet
• Wesher GitHub — costela/wesher
• Tinc VPN
• Netmaker
• Mullvad VPN
• Mullvad Browser
• ProtonVPN
• IVPN
• Cisco Secure Client
• Palo Alto GlobalProtect
• Fortinet FortiClient
• F5 BIG-IP Access
• Zscaler ZPA
• Netskope
• Palo Alto Prisma Access
• Cato Networks
• Gartner SASE definition
• Mercari Engineering Blog
• LINE Engineering Blog
• CyberAgent Developers Blog
• Toss SLASH