拠点をつなぐなら：VPN、Tailscale、NetBird、Cloudflare Mesh？

私は企業ネットワークをつなぐ仕事に多く関わっています。そこで繰り返し聞かれるのが、拠点を結ぶには何が最適か、パブリックIPは必要か、安全なのか、という質問です。支店が増えたり、インターネット回線を変更したり、従業員が増えたりしても使い続けられるのか、という話にもなります。

答えは企業の実際の要件によります。既存のファイアウォールがある固定の2拠点と、接続条件が変わる複数の小規模拠点では出発点が違います。トンネルだけでなく、誰が運用するか、どこでアクセスを制御するか、どの依存関係を維持するかも考える必要があります。

そのため私は、製品を選ぶ前に構成を理解したいと考えています。従来の拠点間VPNが適することもあります。TailscaleやNetBirdは管理や接続確立を簡素化できます。Cloudflare Meshは通信経路を事業者ネットワークに移します。この違いから、それぞれの使いどころを判断します。

ここでは拠点ネットワーク全体の接続を扱います。在宅勤務者の個別端末からのアクセスは、追加のリモートアクセス用途として後で分けて説明します。

例：3つの拠点ネットワークを接続する

本社は 10.1.0.0/24、支店は 10.2.0.0/24、ホームラボは 10.3.0.0/24 を使用します。各拠点のゲートウェイが他拠点への接続を提供するため、その背後のプリンターやNASにはVPNクライアントが不要です。どの方式も、この3つのネットワークを制御された形でつなぐことが目的です。

構成されるのはレイヤー3でルーティングされるネットワークです。拠点が自動的に同じブロードキャストドメインになるわけではなく、ローカル探索プロトコルもすべてが拠点をまたいで動くわけではありません。DNSによる内部名の解決と、ローカルルーターの遠隔ネットワーク向けルートが必要です。

最初に知りたいのは、どのネットワークにどのサービスが必要かです。支店にはファイルサーバーが必要でも、ラボの管理画面は不要かもしれません。バックアップサーバーには保存先が必要ですが、相手拠点の全端末へのアクセスは不要です。この判断はどの製品でも必要です。

拠点間接続は接続対象を表し、トポロジーを限定しない

Site-to-siteはネットワーク同士を結ぶことです。すべての通信を中央ファイアウォールに通す必要はありません。本社を中心とするハブアンドスポークは一般的ですが、拠点ペア間の直接トンネルも拠点間接続です。Tailscale、NetBird、Cloudflare Meshの拠点ゲートウェイも同じ役割を担えます。

TailscaleとNetBirdは、登録や調整が集中管理でも、データ経路は可能な限り直接接続にします。Cloudflareのネットワークは地理的に分散していますが、拠点間通信はCloudflareを通過します。拠点間の直接的なピアツーピア接続ではありません。自社の中央ファイアウォールに代わり、事業者ネットワークが中継点になります。

パブリックIPと変化する要件

パブリックIPの話は早い段階で出てきます。私は外部から到達できるかと、アドレスが固定かを区別します。固定パブリックIPがあれば到達可能なVPN終端を計画しやすくなりますが、全拠点に必要ではありません。支店から到達可能な中央ゲートウェイへ発信してトンネルを作れます。構成によってはダイナミックDNSもアドレス変更に役立ちます。

両端が制限の厳しいキャリアグレードNATの背後にあり、直接到達できる終端がないと難しくなります。特にモバイル回線では、事業者が実際に提供するアドレスと着信接続条件を確認すべきです。TailscaleとNetBirdはNAT越えで直結を試み、必要ならリレーを使います。Cloudflare Meshは事業者ネットワークへの発信接続を確立します。

次の変更にも対応できることが大切です。拠点追加、事業者変更、着信できない回線への変更によって、小さな構成が別の課題になることがあります。動いている方式を先回りで置き換える必要はありませんが、トポロジーを決める前に検討すべき可能性です。

従来の拠点間VPN：ゲートウェイが接続を担当

2台のファイアウォールやルーターが、IPsecや手動設定したWireGuardなどで暗号化トンネルを作ります。ローカルのルーティングが遠隔ネットワーク宛てのパケットをトンネルへ送り、相手のゲートウェイが復号して宛先ネットワークへ転送します。

3拠点なら本社をハブにし、支店とラボが接続できます。構造は単純ですが、支店とラボの通信も本社経由です。フルメッシュではすべての拠点ペアを直接つなぎます。n拠点の接続数は n × (n − 1) / 2 で、3拠点なら3本でも10拠点では45本になります。コントローラーや動的な仕組みで作業を減らすこともでき、従来型VPNが手動のハブ構成に限られるわけではありません。

**利点：**既存のファイアウォールや明確な拠点境界に適合します。トンネル終端を自ら管理でき、追加のmesh事業者がデータ経路に入りません。ルール、ルート、ログを既存管理に統合できます。

**欠点：**拠点数とともにルート、鍵、運用の作業が増えます。NAT、動的アドレス、異なるベンダーが調査を複雑にします。モバイル利用者には別途リモートアクセス構成が必要になることが多いです。

全拠点の固定パブリックIPは普遍的な前提ではありません。到達可能なハブと支店発信のトンネルで十分な場合があります。ダイナミックDNSやNAT越えも役立ちます。ただし両端が厳しいCGNATの背後にある場合、到達可能な終端や仲介なしでの直結は難しくなります。

適切なファイアウォールがある安定した2拠点なら、今も妥当な選択です。別製品の設定項目が少ないというだけで、動いているVPNを置き換える必要はありません。

Tailscale：直接接続と中央調整

TailscaleはWireGuardに端末登録、調整、アクセス方針を加えます。制御サービスが参加者の発見を助け、データは可能ならピア間を直接流れます。NATやファイアウォールが妨げる場合はリレーが代替経路を提供します。DERP経由でも、Tailscaleピア間で暗号化は維持されます。

サブネットルーターがLAN全体をtailnetに接続します。Tailscaleの文書化された拠点間構成は両終端にLinuxを使用します。背後の端末にはエージェント不要ですが、適切なルートは必要です。元の送信元アドレスを残すため送信元NATを無効化する場合、戻り経路の計画が特に重要になります。

**利点：**既存LAN端末がサブネットルーター経由で参加できます。ゲートウェイ間の直接接続により中央拠点への必須の迂回を避けられます。個人端末も同じ基盤に追加できます。

**欠点：**常に直結できる保証はありません。リレー経由では遅延やスループットが異なります。ホストされた調整サービスへの依存は残り、プランと機能が導入条件に合う必要があります。

WireGuardの暗号化はピアで終わります。ピアがサブネットルーターなら、その先のLANはトンネルの外です。プライベート網の中でもHTTPSやSSHは有用です。

NetBird：自前運用も可能な同系統のmesh

NetBirdもWireGuardを基盤に直結を試み、必要時にリレーを使います。クライアントを動かさない端末のネットワークはルーティングピアが接続します。現行の拠点間ガイドではNetworks、Resourcesとアクセス方針を設定します。

**利点：**オープンソースのプロジェクトで、クラウドサービスの代わりに自前でホストできます。インフラと管理を自分の責任下に置く場合に重要です。グループと方針で意図的にアクセスを制限できます。

**欠点：**自前運用では更新、バックアップ、監視、調整とリレーの可用性に責任を持ちます。初期導入が簡単でも作業は消えません。文書化されたNetworksの拠点間構成はマスカレードを有効に保つため、宛先は元の送信元アドレスをそのまま見るわけではありません。他のルーティング方式は別に設計する必要があります。

TailscaleとNetBirdは似ていますが、設定をそのまま交換できません。必要なルーティングとIDモデルで評価します。オープンソースでも全機能が無制限に利用できるとは限らず、導入に必要なライセンスと機能を確認すべきです。

Cloudflare Mesh：事業者ネットワークを通信経路にする

参加者はCloudflareへ発信して接続します。拠点間データは同社ネットワークを通ります。全拠点を相互に直結したり、自前の中央VPNハブを運用したりする必要はありません。ただし信頼境界と経路は、直接のWireGuard meshとは異なります。

**利点：**接続と集中Gateway方針をまとめられます。Cloudflare Oneをすでに使う環境では特に検討しやすく、NAT配下の拠点やモバイルクライアントも発信接続で参加できます。

**欠点：**運用と経路が事業者に依存します。機密データの処理が信頼やプライバシー要件に合う必要があります。アプリケーションのTLSやSSHも有用です。個々のアプリに経路が有利かは測定が必要で、世界規模のバックボーンが常に高速とは限りません。

新規導入なら現行文書のクライアント方式に従います。CloudflareはMeshをベータとし、ノードのデバイスプロファイルにMASQUEを要求しています。WireGuardでは高可用性、IPv6、ホスト名ルートに制限があります。そのためWireGuard対応ルーターというだけで、同等のMeshノードとして扱えません。

個別アプリ向けの cloudflared トンネルとも区別が必要です。ここでは参加者とルーティングされたネットワーク間の双方向プライベートIP接続を扱っています。

違いの一覧

最初に比較するのは次の点です。必要な契約と実際の経路は、対象環境で確認します。

安全な拠点間接続に求めるもの

最も安全な方式を聞かれたら、許可する通信とアクセス管理から確認します。暗号化トンネルでも過剰な権限を与えられます。どのネットワークがどのサービスへ到達できるか、管理者をどう保護するか、アクセスをどう取り消すかを決めたいのです。管理や個人登録ユーザーのMFA、最小限の権限、継続保守されるゲートウェイを評価します。

暗号化の境界も異なります。従来のVPNは拠点ゲートウェイで終端し、TailscaleとNetBirdはサブネットルーターを含むピア間で暗号化します。その先のLANまで自動的には暗号化されません。Cloudflareでは事業者網の処理が企業要件に合うことも必要です。アプリケーションにはHTTPSやSSHが引き続き役立ちます。

発信接続は設定を簡素化し、支店のVPNサービスを公開せずに済む場合がありますが、アクセス方針を代替しません。パブリックIPがあるだけでファイアウォールが危険になるわけでもありません。実際の公開サービス、その保護、継続運用がリスクを決めます。製品名だけで安全順位は付けません。

受け入れ前に確認したいこと

往復の経路が必要です。10.2.0.0/24 宛てルートは担当ルーターやクライアントに置きます。宛先が別のデフォルトゲートウェイから返信するなら、戻り経路も必要です。SNATは返信を簡単にしますが、ログやルールで見えるアドレスを変えます。意識的な設計判断にすべきです。

高可用性にはオーバーレイノードを2台置くだけでは足りません。障害後もLAN端末が次のゲートウェイへ到達できる必要があります。例えばKeepalivedとVRRPで仮想ゲートウェイアドレスを提供できます。遠隔ルートも正常ノードを選ばなければなりません。受け入れではゲートウェイやトンネルの故障時に、新規と既存TCPセッションがどうなるか確認したいです。プロセス稼働やping成功だけでは十分ではありません。

意図的に禁止した接続も機能試験に含めます。SSHを許可し、別アプリを禁止するなら、その動作を確認します。ICMP成功はTCPルールの適用を証明しません。登録、アクセス方針、宛先ホストのファイアウォールが一致する必要があります。

日常利用を左右する地味な要素も残ります。重複しないプレフィックス、内部名の解決、適切なMTUです。192.168.x.x でも 10.x.x.x でも衝突しない保証はありません。小さいpingが通っても大きな転送が止まるなら、接続完成とは判断しません。

性能を比較するには、実回線上で同じファイル転送と対話型アプリを使い、直接かリレーか、CPU負荷、回線変更後の挙動を記録します。ここで評価しているのは構成と運用の違いであり、製品の実測速度ランキングではありません。

リモートアクセス：個別端末を追加する

従業員が自宅からノートPCを企業網へ接続するのは、リモートアクセス、またはクライアント対サイトです。クライアントはPC上で動き、自宅網全体が自動的に本社へつながるわけではありません。中央ファイアウォールのサービスや比較した各基盤のクライアントを使えます。個人登録ならユーザーやグループ単位の権限も設定できます。

一方、在宅拠点もsite-to-siteにできます。ゲートウェイが許可されたネットワークやVLANを本社に接続します。違いは勤務場所ではなく、個別端末とネットワークのどちらを接続するかです。個人端末ならリモートアクセスの範囲が適切な場合が多く、意図せず私有ネットワーク全体を到達可能にする理由はありません。

私なら各方式をどう使い分けるか

既存ファイアウォールがある少数の固定拠点では従来VPNから検討し、ハブアンドスポークか直結かを明確に選びます。NAT配下の拠点で集中管理と可能な限り直接経路が欲しいならTailscaleとNetBirdを比較します。調整を自前運用する要件が強ければNetBirdを早期に評価します。Cloudflare Oneの方針がある環境ではMeshとベータ状態、事業者網の処理を確認します。追加リモートアクセスは別の判断基準です。

Headscaleも選択肢です。Tailscale調整サーバーのセルフホスト実装で、独立した機能範囲を持つ別プロジェクトです。ホスト型サービスの全機能を置き換えるものではありません。手動WireGuardは従来モデルに含まれ、少数のトンネルだけで十分なら追加管理層なしで使えます。

最良の方式を聞かれたとき、企業と次の変化に合うものを勧めたいと思います。既存ファイアウォールのある小規模環境では、従来VPNが引き続き適することもあります。接続条件や管理要件が違えばmeshを検討する価値があります。必要な接続を安全に運用し、理解し、故障後に復旧できるかを基準に選びます。

それでは、また次回。
Joe