Netmaker とは — Tailscale のオンプレミス代替として何ができ、何が足りないか

2026年10月25日

Netmaker とは、WireGuard を土台にしたオーバーレイネットワークの管理ソフトウェアである。複数拠点・複数端末の間に WireGuard のトンネルを張り、鍵・アドレス・経路を一元的に管理する。サーバ（管理プレーン）を自前でホストできるため、「Tailscale のオンプレミス版」と説明されることが多い。

結論から書くと、この理解は半分正しく、半分足りない。正しい部分は、Netmaker が WireGuard を使って Tailscale と同種のことを実現し、しかも管理サーバを自分の環境に置けるという点である。足りない部分は、両者が解こうとしている問題の重心が違うという点だ。Tailscale は「端末をいかに楽に参加させるか」に重心があり、Netmaker は「ネットワークをいかに自分で制御するか」に重心がある。本稿はこの違いを、構成要素・実測値・運用責任の3つの面から整理する。

Netmaker とは — WireGuard を土台にしたオーバーレイ管理ソフトウェア

WireGuard 単体では、端末ごとに鍵を生成し、サーバ側の設定ファイルへ 1 台ずつピアを登録する作業が必要になる。5 台なら手作業でも回るが、50 台になると破綻する。鍵の台帳管理、アドレスの重複回避、追加・削除の反映漏れ、といった作業が人の注意力に依存するからだ。

Netmaker はこの管理を肩代わりする。管理サーバが、ホスト（ノード）の登録、IP アドレスの割り当て、WireGuard の鍵の生成、ピア設定の配布、接続状態の監視を担う。ノード側には netclient というエージェントを入れ、参加トークンを使って管理サーバに登録する。netclient を入れられない端末（スマートフォン、ルータ、一部の組込み機器）には、WireGuard の設定ファイルと QR コードを生成して配る「ext client」という仕組みがある。

私の環境でも、自宅の Windows 機とラボの Proxmox ホスト群を 100.65.0.0/16 のオーバーレイで接続している。自宅は NURO 光、ラボはフレッツ光クロスで、両者は物理的に別の回線・別の L2 にある。その間を WireGuard のトンネルで結び、100.65.0.1 を管理サーバと ingress gateway として運用している。この構成自体が、Netmaker の典型的な用途である。

「Tailscale のオンプレ化」という理解はどこまで正しいか

比較のために、両者の違いを軸ごとに並べる。ここで重要なのは「どちらが優れているか」ではなく「どちらが何を引き受けるか」である。

比較軸	Netmaker	Tailscale
土台のプロトコル	WireGuard	WireGuard
管理プレーンの置き場所	自前でホスト可能	原則として提供されるサービス
端末側エージェント	netclient（Go 製）	tailscaled
エージェントを入れられない端末	ext client（設定ファイル／QR）	共有機能・一部はアプリ必須
認証	参加トークン、管理サーバのユーザー管理	ID プロバイダ連携（SSO）が中心
閉域・オフライン運用	可能（外部依存を減らせる）	管理プレーンへの到達が前提
運用責任	サーバの可用性・更新・バックアップまで自分	管理プレーンは提供側
日本語情報量	少ない	比較的多い

この表から言えるのは、Netmaker が Tailscale の上位互換でも下位互換でもないということだ。管理プレーンを自分で持てることは、閉域要件や外部サービス依存の回避という場面では決定的な利点になる。同時に、管理サーバの可用性、証明書、バックアップ、バージョンアップを自分で引き受けることでもある。Tailscale では提供側が担っていた仕事が、Netmaker では自分の仕事になる。

「オンプレ化」という言葉が正しいのは、この管理プレーンの所在についてである。端末の参加体験や SSO 連携の作り込みまで同じになるわけではない。

構成要素 — server / netclient / ingress gateway / ext client

Netmaker の全体像は、4 つの役割に分けると理解しやすい。

管理サーバ（netmaker server） は、ノードとネットワークの定義、鍵とアドレスの割り当て、設定の配布を行う。API と Web UI を持ち、状態はデータベースに保存する。

netclient は、各ノードで動くエージェントである。管理サーバから設定を受け取り、WireGuard インターフェースを構成する。接続状態を報告するため、管理サーバ側から見て「どのノードが生きているか」が分かる。

ingress gateway は、オーバーレイの外側と内側をつなぐ入口である。拠点の LAN に置いた 1 台が gateway になり、その背後にある機器へオーバーレイ経由で到達できるようにする。私の環境では 100.65.0.1 がこの役割を担っている。

ext client は、netclient を入れられない端末のための仕組みである。管理サーバが WireGuard の設定ファイルと QR コードを生成し、端末側はそれを読み込むだけで参加する。スマートフォンで overlay に参加する場合は、この方式が現実的である。

このほか、離れた拠点間を中継する relay、オーバーレイから外部ネットワークへ出るための egress gateway といった役割がある。名前は違っても、やっていることは「WireGuard のピア設定を、人手を介さず配る」ことに集約される。

実測 — ext client の MTU は ingress gateway ホストの MTU を継承する

Netmaker を使ううえで、見落としやすい仕様が MTU の継承規則である。私はこれを推測せず、上流のソースコードを実測で確認した。

upstream_v1.7.0/controllers/ext_client.go:371-373
    defaultMTU := 1420
    if host.MTU != 0 { defaultMTU = host.MTU }

この数行が示すのは明快である。ext client の設定ファイルに書き込まれる MTU は、所属する ingress gateway ホストの MTU フィールドを継承する。host.MTU が 0 のときだけ既定の 1420 が使われる。つまり、個々のクライアント設定を書き換えるのではなく、ホスト側の 1 項目を変えれば、配下の ext client すべてに反映される。

実際に変更前後を実測した結果が次の表である。

#	測定内容	変更前	変更後
1	ingress gw host の `mtu`	1420	1280
2	host `listenport`	443	443（不変）
3	host `wg_public_listen_port`	443	443（不変）
4	host `endpointip`	133.242.153.63	同一（不変）
5	ext client 件数（対象ネットワーク全体）	—	1件（影響範囲は限定的）
6	ext client レコードの `mtu`	null	null（＝host 継承）
7	生成 conf の `MTU`	1420	1280
8	gateway node の `ingressmtu`	—	1280
9	gateway node の `connected`	—	true（生存）

注目すべきは #2〜#4 である。host レコードを PUT で更新すると、サーバ側が計算するフィールドが一時的にリセットされる挙動が過去に観測されていた。今回は再計算されて 443 のまま維持されたが、これは環境依存であり、更新後は必ず読み戻して確認するべき項目である。

この仕様は、Netmaker を使うときに効いてくる。拠点の回線が PPPoE やモバイル回線で MTU が小さい場合、ホスト側の MTU を下げれば配下の端末すべてに反映される。逆に、サーバ側だけ直しても端末に配布済みの設定ファイルは古いまま残るため、再配布の要否を必ず判断する必要がある。この切り分けの実測手順は、WireGuard の MTU 不一致でつながらない — 1420 と 1280 を実測で切り分けるに詳しく残した。

Tailscale との違い — 管理プレーン、ACL、運用責任

Netmaker を検討するとき、実際に判断を分けるのは次の3点である。

第一に、管理プレーンの所在。 Tailscale は管理プレーンが提供サービスであり、端末はそこへ到達できることが前提になる。閉域網や、外部サービスへの常時接続を避けたい環境では、この前提が制約になる。Netmaker は管理サーバを自前で置けるため、この制約を外せる。代わりに、そのサーバの可用性と更新を自分で引き受ける。

第二に、アクセス制御の作り込み。 Tailscale は ACL をポリシーファイルとして記述し、ユーザー・グループ単位の細かい制御ができる。Netmaker も ACL の仕組みを持つが、ID プロバイダ連携を前提とした作り込みの思想は異なる。ここは「どちらが高機能か」ではなく「自組織の要件に合うか」で判断する領域である。

第三に、運用責任の範囲。 管理サーバを持つということは、データベース、証明書、バックアップ、バージョンアップ、監視の対象が増えるということである。私の環境でも、管理サーバの死活は overlay の健全性と直結するため、監視対象を「アプリのアドレス」ではなく管理サーバ 100.65.0.1 に寄せている。管理プレーンが落ちれば、個別ノードの断ではなく基盤の問題として扱う必要があるからだ。

Headscale という第3の選択肢

「管理プレーンを自前で持ちたい」という要求に対しては、Headscale という選択肢もある。Tailscale のクライアントを使いながら、管理サーバだけをオープンソース実装で自前運用するものである。

Netmaker と Headscale の違いは、既存クライアントとの互換性を取るか、WireGuard の設定を直接扱うかにある。Tailscale クライアントの使い勝手を維持したまま管理プレーンだけ自前化したいなら Headscale、WireGuard の設定を自分で制御したいなら Netmaker、という整理になる。どちらも「オンプレ化」の解だが、解いている問題が異なる。

Netmaker が向くケース／向かないケース

向くケースは明確である。管理プレーンを自前で置きたい、外部サービスへの依存を減らしたい、拠点 LAN への入口を自分の管理下に置きたい、WireGuard の設定を直接確認・制御したい。いずれかに該当するなら、Netmaker は第一候補になる。

向かないケースも明確である。端末の参加体験を最優先したい、SSO 連携を前提にしたアクセス制御を作り込みたい、管理サーバの運用を引き受けたくない。この場合は Tailscale のほうが総コストは低い。

「無料だから」という理由で Netmaker を選ぶのは勧めない。ソフトウェアの利用料はゼロでも、管理サーバの運用コストはゼロではない。可用性、更新、バックアップ、障害対応の時間が価格に置き換わる。

「Tailscale のオンプレ化」需要はどこにあるか — サジェスト実測

この記事を書くにあたり、需要の形を実測した。結果は次のとおりである。

「netmaker とは」= 0件
「netmaker」単独 = 10件（netmaker / netmaker wireguard / netmaker github / netmaker vs netbird / netmaker install / netmaker vpn など）
「netmaker vs tailscale」= 5件（netmaker vs tailscale / netmaker vs tailscale reddit / netmaker vs tailscale vs zerotier / netmaker vs tailscale vs netbird / netmaker tailscale）
「tailscale オンプレミス」= 1件、「tailscale 代替」= 1件

数字だけを見ると「Netmaker とは何か」という定義語の需要は小さい。しかしこれは、需要が無いという意味ではない。読み手は「Netmaker」という製品名を知ったうえで検索を始めるのではなく、「Tailscale を自前で持ちたい」「外部サービスに依存せずオーバーレイを運用したい」という目的から検索を始め、その結果として比較語にたどり着く。需要は製品名ではなく動機の側に立っている。

したがって、この領域の記事は「Netmaker とは」という定義から入るより、「Tailscale のオンプレ化という選択肢」として提示したほうが読者の意図に合う。本稿が比較を主軸に置いているのは、この実測に基づく判断である。定義語のサジェスト件数が 0 であることは、記事化しない理由にはならない。代替手段を探している読者に届く形にすることが条件である。

同時に、日本語の一次情報が少ないことは運用上のリスクでもある。障害時に日本語の事例を検索しても見つからない場面がある。上流のソースコードと API の実測を読む前提で採用を判断したほうがよい。

まとめ — Netmaker は「Tailscale のオンプレ版」だが、同じ製品ではない

Netmaker とは、WireGuard を土台にしたオーバーレイネットワークの管理ソフトウェアであり、管理サーバを自前でホストできる。
「Tailscale のオンプレミス代替」という理解は、管理プレーンの所在については正しい。端末の参加体験や SSO 連携まで同じになるわけではない。
構成要素は、管理サーバ、netclient、ingress gateway、ext client である。いずれも「WireGuard のピア設定を人手を介さず配る」ための部品である。
ext client の MTU は ingress gateway ホストの MTU を継承する（上流コード controllers/ext_client.go の実測で確認）。ホスト側 1 項目の変更で配下に反映される。
管理プレーンを持つということは、可用性・更新・バックアップ・監視の対象が増えるということである。利用料がゼロでも運用コストはゼロにならない。
日本語圏では「Netmaker とは」という定義語単独の需要は小さい（サジェスト 0 件）。ただし「Tailscale のオンプレ化」「vs Tailscale」という代替検討の文脈には需要がある（5件）。記事は定義からではなく比較から入る。情報量が少ないことは運用リスクとして織り込む。

道具を選ぶとき、機能表の比較より「どの仕事を自分で引き受けるか」を先に決めたほうが、後悔が少ない。Netmaker は、管理プレーンを自分で引き受けられる代わりに、その責任も引き受ける選択である。

参照した一次情報:

Netmaker 公式サイト https://www.netmaker.io/ （2026-10-25 参照）
Netmaker 公式ドキュメント https://docs.netmaker.io/ （2026-10-25 参照）
Netmaker ソースコード（controllers/ext_client.go の MTU 継承を実測 / upstream v1.7.0） https://github.com/gravitl/netmaker （2026-10-25 参照）
Tailscale 公式サイト（管理プレーンと ACL の説明） https://tailscale.com/ （2026-10-25 参照）
Headscale（Tailscale コントロールサーバのオープンソース実装） https://github.com/juanfont/headscale （2026-10-25 参照）
Google サジェスト実測（2026-10-25 / netmaker とは 0件・netmaker vs tailscale 5件・tailscale オンプレミス 1件）
関連記事: WireGuard とは — UDP 上で動く軽量な VPN の仕組みと、つまずきやすい3点
関連記事: WireGuard の MTU 不一致でつながらない — 1420 と 1280 を実測で切り分ける
関連記事: VPN は時代遅れなのか — モダン VPN とゼロトラストの現在地