VPN、まだ手動で繋いでますか？ — WireGuard が変える社内ネットワークの常識

はじめに

ここ数年、インターネットに公開したサーバーを取り巻く状況は厳しさを増しています。公開した IP アドレスは直後から世界中のスキャナーに見つかり、さらに AI を使った攻撃の高度化で、脆弱性の公開から悪用までの時間は日単位から時間単位に縮みました（例：GitLab の CVSS 10.0 脆弱性）。本記事では、この流れの中で整備される社内 VPN の悩みを、Tailscale でどう解消できるかを解説します。

その結果、公開サーバーを減らし、業務システムは社内ネットワークか同等に守られた閉じた網に置く流れが、規模を問わず強まっています。そして、その中心にあるのが社内 VPN の整備です。

ところが、その VPN が新しい悩みを生む

社内 VPN を整備した企業の多くは、次の二つの悩みに直面します。

• 普段の作業中は VPN を繋ぎたくない。 全通信を社内経由にすると Web 会議や SaaS が遅くなります。かといって「必要なときだけ手で繋ぐ」運用は、繋ぎ忘れと切り忘れを量産して定着しません。
• VPN 装置そのものが攻撃の入口になる。 従来型 VPN はインターネットに入口を公開する作りで、その脆弱性を突かれた侵入事例は近年の重大インシデントでも目立ちます。つまり、公開サーバーを減らすために入れた VPN が、新しい公開サーバーになる構図です。

この二つを同時に解決する設計として、本記事では Tailscale（公式サイト）を取り上げます。

そもそも WireGuard とは何か、なぜ注目されているのか

まず、Tailscale を理解するには、土台である WireGuard を知る必要があります。WireGuard は 2015 年頃に Jason Donenfeld 氏が設計を始め、2020 年に Linux カーネル 5.6 に取り込まれた VPN プロトコルです。つまり、1990〜2000 年代初頭に設計された IPsec や OpenVPN を、「現代の暗号技術で、ゼロから、できるだけ小さく作り直したもの」と言えます。

WireGuard はなぜ優れているのか

• 圧倒的に小さい。 Linux カーネル内の実装は約 4,000 行で、十数万行の OpenVPN や数十万行規模の IPsec の 100 分の 1 程度です。小さいコードは読んで検証でき、バグの入る余地が少なく、監査が現実的にできます。
• 暗号方式を固定し、交渉しない。 IPsec や TLS 系 VPN が接続のたびに行う暗号方式の交渉は、ダウングレード攻撃や設定ミスの温床でした。一方、WireGuard は Curve25519、ChaCha20-Poly1305、BLAKE2s を固定で使い、交渉が無いので間違った設定ができません。
• SSH と同じ「公開鍵が身元」のモデル。 端末ごとに鍵ペアを作り、相手の公開鍵を登録すれば繋がります。そのため、証明書の発行機関も複雑な設定ファイルも要りません。
• 接続の状態を持たない。 UDP の上で動き、Wi-Fi から携帯回線に切り替わって IP アドレスが変わっても通信は続きます（ローミング）。また、通信していない間はパケットを出さず電池もほとんど使わないため、後述する「繋ぎっぱなし」の運用が成り立ちます。
• 速い。 カーネル内で動き処理も単純なので、OpenVPN や IPsec より高速で低遅延です。その結果、回線の速度がそのまま出ます。
• 設計が形式的に検証されている。 Noise プロトコルフレームワークに基づく鍵交換は、数学的な検証ツールで安全性が確認されています。

なぜ最近注目されているのか

• まず、Linux カーネル採用時に Linus Torvalds 氏が「OpenVPN や IPsec の惨状と比べれば芸術作品だ」と評して一気に知られ、以後 Windows、macOS、iOS、Android の公式クライアントが揃いました。
• Cloudflare WARP、Mullvad、NordVPN の NordLynx、そして Tailscale と、商用サービスが相次いで WireGuard を土台に採用し、「新しい VPN を作るなら WireGuard から」が業界の既定になりました。
• さらに、従来型 VPN 装置の脆弱性が立て続けに悪用され、「巨大で古い実装を公開面に置くこと」自体が見直されました。

WireGuard だけでは足りない、Tailscale が足すもの

一方で、WireGuard が引き受けるのは「暗号化されたトンネルを張る」ことだけです。例えば、鍵の配布、端末の登録と失効、NAT の向こうの端末の発見、誰が何に繋いでよいかの管理は解いてくれません。そして、社員と端末とサーバーが増えると、この管理こそが VPN の本当の仕事になります。その層を丸ごと提供するのが Tailscale です。

Tailscale とは何か

Tailscale は、WireGuard を土台に「鍵の配布」「端末同士の発見」「誰が何に繋いでよいかの管理」を肩代わりするサービスです。まず端末に小さなクライアントを入れると、同じ組織（tailnet）の端末同士が直接暗号化通信できます。

従来型 VPN との最大の違いは構造です。従来型は全員が 1 台の VPN サーバーに集まるハブ型です。一方、Tailscale は端末同士が直接つながるメッシュ型です。また、中央の調整サーバー（coordination server）は鍵と設定を配るだけで、業務の通信は通りません。

直接つなげない環境では Tailscale の中継（DERP）を経由しますが、暗号化されたままで中身は読めません。また、NAT 越えは自動で、ポート開放や固定 IP は不要です。

Tailscale は「必要なときだけ繋ぐ」を繋ぎ直しなしで実現する

Tailscale のもっとも実務的な利点は、「普段は繋ぎたくない、社内のサービスのときだけ通したい」を、利用者が何も操作せずに満たせることです。

• 既定が分割トンネルです。 Tailscale を通るのは tailnet 内の宛先への通信だけで、Web 会議や SaaS などインターネット宛ては従来どおり直接流れます。そのため、VPN による遅さが構造的に起きません。
• 繋ぎっぱなしでもコストがほぼゼロです。 WireGuard は使われていない間ほぼ無音で、電池も CPU もほとんど消費しません。だから、「常に繋がっていて、社内宛てのときだけ自動で使われる」状態になります。
• 全通信を通したいときだけ、出口ノードを選びます。 例えば公衆 Wi-Fi で全通信を社内経由にしたいときは、社内の端末を「出口ノード（exit node）」としてワンタップで選ぶだけです。

その結果、従来型 VPN の「繋ぎ忘れ」「切り忘れ」「繋いでいる間は何もかも遅い」が、設計の段階で消えます。

企業の VPN 管理に効く Tailscale の機能

Tailscale が小規模から中規模の企業に向く理由は、「VPN の機能」より「管理の機能」にあります。

1. 認証は会社の ID 基盤に任せる

Tailscale 自体はパスワードを持たず、Google Workspace、Microsoft Entra ID、Okta、GitHub など既存の ID 基盤（SSO）でログインします。また、多要素認証もそのまま効き、退職者を ID 基盤で止めれば VPN からも同時に締め出されます。

2. アクセス制御をコードで書く

「誰が、どの端末から、どのサーバーのどのポートに繋げるか」を、ひとつのポリシーファイル（JSON 形式）で宣言します。例えば、利用者はグループ、サーバーはタグ（例: tag:prod、tag:dev）に束ね、「開発グループは開発用サーバーの 22 番と 443 番だけ」のように書きます。また、変更履歴が残りレビューできる設定になり、既定は「すべて拒否」です。

3. 端末の承認と鍵の期限

新しい端末の参加に管理者の承認を必須にできます。また、各端末の鍵には有効期限があり、期限が来れば再認証が要ります。紛失した端末は管理画面から即座に外せます。

4. 名前で繋ぐ（MagicDNS）

端末には自動で名前が付き、http://wiki や ssh db-01 のように名前で到達できます。また、社内 DNS があれば、特定ドメインだけをそちらに向ける分割 DNS も設定できます。

5. 既存のサーバー群をそのまま取り込む（サブネットルーター）

クライアントを入れられない古いサーバーや機器は、同じネットワークの 1 台を「サブネットルーター」にすれば、tailnet からネットワーク全体に到達できます。そのため、段階的な移行が可能です。

6. SSH の鍵管理をなくす（Tailscale SSH）

サーバー側で Tailscale SSH を有効にすると、SSH の認証を Tailscale の ID とポリシーで行えます。その結果、公開鍵の配布と棚卸し、退職者の鍵の削除という漏れやすい作業がなくなります。

7. 記録が残る

誰がいつ、どの端末でどこに接続したか、設定を誰が変えたかのログを取得でき、SIEM にも送れます。

8. どうしても公開が必要なものは最小限で（Funnel / Serve）

社外に一時的に見せたいサービスは、Funnel を使えば固定 IP やポート開放なしにその 1 つだけをインターネットに出せます。一方、Serve は tailnet の中だけに HTTPS で公開し、証明書は自動発行です。

ルーター内蔵の VPN と Tailscale を比べると

多くの企業の社内 VPN は、ルーター付属の VPN 機能（L2TP/IPsec や機器独自の SSL-VPN）で作られています。手軽な反面、使い続けるほど次の不便が積み重なります。

入口・認証・利用者管理の違い

• 入口を公開しなければならない。 固定 IP か DDNS で入口を公開し、ポートを開けて待ち受けます。更新は手作業で、脆弱性が出れば真っ先に狙われます。一方、Tailscale は公開するポートがありません。
• 利用者の追加がルーターの設定作業になる。 利用者ごとに事前共有鍵や証明書を作り、OS 別の手順を配り、辞めたら消します。Tailscale では「クライアントを入れて会社のアカウントでログイン」で終わります。
• 多要素認証が使えない、または別仕組みになる。 ルーターの VPN の多くは ID とパスワードか事前共有鍵だけです。Tailscale は会社の SSO と多要素認証をそのまま使います。
• 誰が何に繋げるかを細かく決められない。 「繋がれば社内全体に入れる」作りが多く、細かな制限は別のファイアウォール設定になります。Tailscale では、ポート単位の許可をひとつのポリシーファイルに書けます。
• 記録が乏しい。 接続の記録はルーターのログにしか残らず、保存期間も短く検索しにくい。Tailscale では接続と設定変更の記録を外部にも送れます。

通信性能と拠点展開の違い

• 繋ぐと全部の通信が会社経由になる。 その結果、Web 会議や SaaS が遅くなり、利用者は繋ぎ忘れと切り忘れを繰り返します。Tailscale は社内宛てだけを自動で通します。
• 速度と同時接続数がルーターの性能で決まる。 全員の通信が 1 台の暗号化処理を通るので、在宅勤務が増えると遅くなります。一方、Tailscale は端末同士が直接通信します。
• 拠点が増えると設計が難しくなる。 拠点間 VPN と個人用 VPN が混在し、経路設計が複雑になります。Tailscale では全部が同じ tailnet なので、サブネットルーターを置くだけで拠点を取り込めます。

利用者が数人で繋ぐ先が 1 か所のままなら、ルーター内蔵の VPN でも十分です。しかし利用者と拠点とサーバーが増える組織では、上の不便が運用コストとリスクとして積み上がります。

Tailscale が従来の VPN サーバーより優れている理由

観点	従来型 VPN	Tailscale
インターネットへの露出	VPN の入口（IP とポート）を公開する。入口の脆弱性が侵入口になる	公開するポートが無い。端末は外向きにだけ通信し、調整サーバーが仲介する
通信経路	すべて VPN サーバーを経由。サーバーの性能と回線が上限	端末同士が直接。サーバーの性能が上限にならない
普段の作業への影響	全通信が通るか、手で繋ぎ分ける	社内宛てだけ自動で通る。それ以外は影響なし
認証	VPN 専用のアカウントや証明書を別管理	会社の SSO と多要素認証をそのまま使う
アクセス制御	機器ごとの画面やルールで管理	1 つのポリシーファイルで宣言。履歴とレビューが可能
端末の追加	設定ファイルや証明書を配布	クライアントを入れてログインするだけ
退職・紛失時	機器側でアカウントと証明書を失効	ID 基盤で止めれば連動。端末は管理画面から即除外
性能	プロトコルと機器に依存。老朽化した装置がボトルネックになりがち	WireGuard の軽さと直接通信で、回線の限界まで出る
可用性	VPN サーバーが落ちると全員が止まる	調整サーバーが落ちても、既に繋がっている通信は続く

要するに、従来型 VPN は「インターネットに新しい入口を作って守る」仕事を増やすのに対し、Tailscale は「入口を作らない」設計です。そのため、公開サーバーを減らすという本来の目的と向きが揃っています。

Tailscale 導入前に知っておくべき注意点

ただし、採用前に確認しておきたい点もあります。

• 調整サーバーは Tailscale 社のサービスです。 業務の通信は通りませんが、鍵の配布とポリシー管理をクラウドに預けます。なお、許容できない組織には、自前で動かせるオープンソース実装 Headscale があります。
• 直接つなげない環境では中継を通ります。 暗号化されたままですが遅延は増えます。そのため、NAT の作りによっては直接通信の割合を上げる調整が要ります。
• 料金は利用者数で決まります。 無料枠と有料プランの範囲は変わるので、最新情報は公式サイトで確認してください。
• 端末そのものの管理は別です。 例えば、OS の更新やディスク暗号化などの端末の健全性は MDM など別の仕組みの役割で、組み合わせて初めて「ゼロトラスト」と呼べる水準になります。

Tailscale を小さく始める三つの手順

1. 管理者 1 人と端末 2 台で試す。 まず、ノート PC とサーバー 1 台にクライアントを入れ、名前で ping と SSH が通ることを確認します。30 分で終わります。
2. ポリシーを書いてから広げる。 次に、「既定は拒否」のまま必要な通信だけをグループとタグで許可します。この時点で、誰が何に繋げるべきかが文書になります。
3. 既存の VPN と並行運用し、切り替える。 サブネットルーターで既存サーバー群を取り込み、部門ごとに移行して、最後に従来型 VPN の入口を閉じます。

まとめ

公開サーバーを減らす流れの中で整備される社内 VPN は、「普段は繋ぎたくない」「VPN 自体が入口になる」という矛盾を抱えがちです。しかし、Tailscale は、社内宛てだけを自動で通す分割トンネルと、入口を公開しないメッシュ型の設計で、この矛盾を構造から解消します。つまり、小規模から中規模の企業が、担当者を増やさずに安全な社内ネットワークを持つための現実的な選択肢です。

✨ このカテゴリーのAIまとめ記事を見る