WireGuard とは、暗号化されたトンネルを UDP 上に作る VPN プロトコルである。IPsec や OpenVPN と比べて実装が小さく、設定項目が「秘密鍵・公開鍵・相手の公開鍵・AllowedIPs」程度に絞られている点が特徴である。Linux カーネル 5.6（2020年3月29日リリース）で mainline に統合され、現在は Linux 以外の OS にも公式実装が提供されている（WireGuard 公式サイト / 2026-10-25 参照）。
結論から書くと、WireGuard を理解するうえで押さえるべき点は3つある。第一に、暗号処理の手順が Noise プロトコルフレームワークで固定されており、利用者が暗号方式を選ばないこと。第二に、AllowedIPs が経路表とアクセス制御を兼ねていること。第三に、UDP であるため「届かなかったこと」が送信側に分からず、MTU の不一致が静かな通信断として現れることである。本稿はこの3点を軸に、仕組みと実務でのつまずきを順に整理する。
WireGuard とは何か — カーネル内で動く VPN プロトコル
WireGuard は、暗号化されたトンネルインターフェースを作るためのプロトコルであり、同時にそのリファレンス実装の名前でもある。Linux ではカーネルモジュールとして動作するため、ユーザー空間で動く追加のデーモンを必要としない構成が多い。トンネルインターフェース（慣例的に wg0 や netmaker という名前が付く）に IP アドレスを振り、そこへ流れたパケットが暗号化されて UDP で送出される、という動きになる。
「カーネル内で動く」ことの意味は大きい。パケットがユーザー空間とカーネル空間を行き来しないため、コンテキストスイッチとメモリコピーが減る。OpenVPN がユーザー空間のプロセスとして動き、TUN/TAP デバイスとの間でパケットをやり取りするのに対し、WireGuard は経路の途中に余分な境界を持たない。この構造の違いが、後述するスループットと CPU 使用率の差につながる。
ただし「カーネル内で動く」は、設定変更に再起動が要らないという意味でもある。wg コマンドでインターフェースの設定を書き換えると、その場で反映される。サービスを止める必要がないため、運用中の変更がしやすい。
WireGuard が生まれた背景 — IPsec と OpenVPN の何が問題だったのか
WireGuard は、既存 VPN の「設定が複雑すぎる」という問題への回答として設計された。設計者である Jason A. Donenfeld は、IPsec の仕様群と OpenVPN の設定項目の多さを、運用上のリスク要因として捉えていた。設定項目が多いということは、それだけ誤設定の余地が広いということである。VPN の障害の多くは、暗号が破られたことではなく、設定の食い違いで起きる。
IPsec は IKE（鍵交換）と ESP（暗号化）という複数のプロトコルの組み合わせで、ネゴシエーションの選択肢が多い。OpenVPN は TLS を使って鍵交換を行い、暗号スイート・圧縮・再ネゴシエーションの設定を持つ。いずれも柔軟だが、柔軟さは「正解の組み合わせを選ぶ責任」を運用者に負わせる。
WireGuard はこの方向を逆にした。暗号スイートを固定し、鍵交換の手順を1つに定め、設定ファイルに書く項目を数個に絞った。選択肢を捨てる代わりに、誤設定の余地を減らしたのである。この設計判断は「設定が少ないぶん、症状から原因を推定する手がかりも少ない」という副作用を持つ。後の章で述べるつまずきは、この副作用と表裏の関係にある。
仕組み1 — Noise プロトコルフレームワークと暗号プリミティブ
WireGuard の鍵交換は、Noise プロトコルフレームワークの IK ハンドシェイクパターンを用いて構成されている（The Noise Protocol Framework / 2026-10-25 参照）。IK は、応答側の静的公開鍵を開始側が事前に知っている前提のパターンであり、WireGuard では「相手の公開鍵を知っている」という設定がそのままこの前提になる。
使われる暗号プリミティブは固定されている。鍵共有は Curve25519（RFC 7748）、認証付き暗号は ChaCha20-Poly1305（RFC 8439）、ハッシュは BLAKE2s（RFC 7693）、鍵導出は HKDF、ハッシュテーブルのキー付きハッシュには SipHash が使われる。いずれも既存の標準であり、WireGuard が独自の暗号アルゴリズムを発明しているわけではない。独自実装を避け、確立された部品を固定の手順で組み合わせる、というのが設計の中心にある。
ハンドシェイクは 1 往復（1-RTT）で完了し、その後は概ね 2 分ごとに再鍵交換が行われる。この周期は、前方秘匿性を保ちながら、モバイル端末のように頻繁に接続が切れる環境でも過剰な再ハンドシェイクを起こさない値として設定されている（WireGuard プロトコル解説 / 2026-10-25 参照）。
実務で重要なのは、この手順が「見えない」ことである。ハンドシェイクが成立したかどうかは、wg show の latest handshake の値でしか確認できない。逆に言えば、latest handshake が更新されていなければ、鍵・ピア設定・エンドポイント到達性のいずれかが原因であり、MTU の問題ではないと切り分けられる。この一手が、後の切り分けを大幅に短くする。
仕組み2 — AllowedIPs が経路表とアクセス制御を兼ねる
WireGuard に特有の考え方として、Cryptokey Routing がある。ピアごとに AllowedIPs という IP 範囲のリストを持ち、これが2つの役割を同時に果たす。
送信時の役割は経路表である。トンネルインターフェースに流れたパケットの宛先 IP が、あるピアの AllowedIPs に含まれていれば、そのピアへ暗号化して送る。受信時の役割はアクセス制御である。復号したパケットの送信元 IP が、そのピアの AllowedIPs に含まれていなければ、そのパケットは破棄される。
つまり「どの経路をどのピアに渡すか」と「そのピアから来てよい送信元はどれか」が、同じ1行で決まる。この設計は設定を短くする一方で、書き間違えたときの症状が分かりにくい。AllowedIPs を狭く書きすぎれば、宛先が一致せずパケットがトンネルに入らない。広く書きすぎれば、意図しない通信がトンネルに吸い込まれる。いずれもエラーを出さずに挙動として現れる。
自前で運用する場合、AllowedIPs = 0.0.0.0/0 を設定すると全通信がトンネル経由になる。これは「デフォルトルートを VPN に奪われる」状態であり、VPN 側の経路が壊れているとインターネットに出られなくなる。モバイル端末で「VPN をオンにしたら何もつながらない」という症状の多くは、この設定と後述の DNS・MTU の組み合わせで説明できる。
仕組み3 — UDP・ローミング・ハンドシェイクの不在
WireGuard は UDP 上で動作する。既定の待ち受けポートは 51820/UDP である（WireGuard Quick Start / 2026-10-25 参照）。TCP のような接続確立の手続きを持たないため、次の3つの性質を持つ。
第一に、状態は「最後に正しく復号できたパケットの送信元アドレス」で決まる。端末が Wi-Fi からモバイル回線へ切り替わり、グローバル IP が変わっても、端末から送られた正当なパケットが届けば、サーバ側はその新しいアドレスへ送るようになる。これがローミングであり、モバイル環境での使い勝手を支えている。
第二に、届かなかったことが分からない。TCP であれば接続要求に応答がなければ再送し、やがて失敗する。UDP は送りっぱなしであり、途中で破棄されても送信側には通知されない。アプリケーション層のタイムアウトとして初めて表面化する。
第三に、TCP のポート開放テストでは到達性を判定できない。telnet や nc -z は TCP を試すものであり、UDP の 51820 番が通っているかは別に測る必要がある。ここを取り違えると「ポートは開いているのに繋がらない」という誤った結論に落ちる。
性能と設計思想 — 「設定が少ない」ことの意味
WireGuard のトンネルには、カプセル化のオーバーヘッドがある。内側のパケットに WireGuard のヘッダと UDP/IP のヘッダが付くため、IPv4 では 60 バイト、IPv6 では 80 バイトが加算される。したがって、経路 MTU が 1500 の IPv4 環境ではトンネル内で使える MTU の上限は 1440、IPv6 では 1420 が目安になる。
この 1420 という値は、IPv6 を前提にした控えめな既定値として広く使われている。しかし経路上に PPPoE（MTU 1492）やモバイル回線のように MTU の小さい区間が挟まると、1420 でも超過する場合がある。そのときの受け皿が 1280 である。1280 は IPv6 の最小 MTU として規定された値であり（RFC 8200 / 2026-10-25 参照）、IPv6 では経路途中での分割を原則行わないため、すべてのノードが 1280 を通せることを要求している。逆に言えば、1280 以下にしておけば、規格を満たす経路では必ず通る。
ただし 1280 に下げるとスループットは落ちる。1 パケットあたりのペイロードが減り、同じデータ量を運ぶのに必要なパケット数が増えるためである。だから「常に 1280」ではなく、「通らないなら 1280 まで下げる」という順序で考えるのが正しい。この切り分けの実測手順は、別記事で詳しく扱っている。
WireGuard と IPsec / OpenVPN / Tailscale の違い
| 比較軸 | WireGuard | IPsec | OpenVPN | Tailscale |
|---|---|---|---|---|
| 動作位置 | カーネル内（Linux） | カーネル内（実装による） | ユーザー空間 | ユーザー空間（WireGuard を内包） |
| 設定項目 | 数個（鍵と AllowedIPs） | 多い（IKE/ESP のネゴシエーション） | 多い（暗号スイート・TLS 設定） | アカウント認証が中心 |
| 暗号スイート | 固定 | 選択制 | 選択制 | WireGuard に準ずる |
| 接続方式 | UDP・1-RTT | UDP（500/4500） | UDP/TCP | WireGuard + 管理プレーン |
| 向く用途 | 拠点間・端末のトンネル | 既存機器との相互接続 | 既存環境との親和性 | 端末の一元管理 |
Tailscale は WireGuard を土台に、端末認証と NAT 越えの調整を管理プレーンで行う製品である。WireGuard 単体では、端末ごとに鍵を生成し、サーバ側へ 1 台ずつピアを登録する作業が必要になる。Tailscale はその管理を肩代わりする。同じ位置づけのソフトウェアとして Netmaker があり、こちらは管理サーバを自前でホストできる点が異なる（Netmaker とは — Tailscale のオンプレミス代替として何ができるか）。
WireGuard を自前で運用すると必ず出会う3つのつまずき
WireGuard の設定が短いことは、障害時の切り分けを楽にするとは限らない。実際に運用すると、次の3層でつまずく。
第一層は鍵とピア設定である。公開鍵の取り違え、AllowedIPs の範囲誤り、サーバ側へのピア登録漏れ。これらはハンドシェイクが成立しないため、wg show の latest handshake が更新されないことで判別できる。
第二層はエンドポイント到達性である。UDP の待ち受けポートに届いているか、NAT やファイアウォールで落ちていないか。WireGuard は UDP であるため、TCP のポート開放テストだけでは判定できない。
第三層は経路 MTU である。ここが最も見落とされる。ハンドシェイクは成立し、小さいパケットは通る。しかし大きいパケットだけが静かに消える。ping は通るのに Web サイトが開かない、SSH は繋がるのにファイル転送で止まる、といった非対称な症状になる。
この第三層に落ちた実際の記録は、WireGuard の MTU 不一致でつながらない — 1420 と 1280 を実測で切り分ける にまとめた。ハンドシェイクが成立しているのに通信が止まる場合は、鍵ではなく MTU を疑う。その判断基準と実測手順を、失敗した測定も含めて残している。
よくある誤解
「WireGuard は企業向けのアクセス制御ができない」という指摘がある。正確には、WireGuard のプロトコル自体は ACL を持たない。持っているのは AllowedIPs による粗い制御だけである。「誰がどのサーバへ行けるか」といった粒度の制御は、上位の管理ソフトウェアが担う。Tailscale や Netmaker が存在する理由はここにある。
「暗号が独自で危険」という指摘は当たらない。前述のとおり、WireGuard は既存の標準プリミティブを固定手順で組み合わせている。独自なのは組み合わせ方と実装の小ささであり、暗号アルゴリズムそのものではない。
「速いので万能」も正しくない。UDP であるため経路 MTU と NAT の影響を受けやすく、TCP ベースの VPN より「静かに壊れる」傾向がある。性能の高さと引き換えに、観測の設計が要求されるプロトコルだと言える。
まとめ — WireGuard は「設定が少ない VPN」であり、切り分けの設計を要求する
- WireGuard とは、UDP 上に暗号化トンネルを作る VPN プロトコルであり、Linux カーネル 5.6 で mainline に統合された。
- 暗号スイートは固定で、Noise プロトコルフレームワークの
IKパターンにより 1-RTT でハンドシェイクする。再鍵は概ね 2 分ごとである。 - AllowedIPs は送信時の経路表と受信時のアクセス制御を兼ねる。書き間違えてもエラーにならず、挙動として現れる。
- UDP であるため、届かなかったことが送信側に分からない。到達性は TCP のポートテストとは別に測る必要がある。
- トンネルのオーバーヘッドは IPv4 で 60 バイト、IPv6 で 80 バイト。経路 MTU 1500 なら上限は 1440 / 1420、受け皿は IPv6 最小 MTU の 1280 である。
- つまずきは「鍵・到達性・経路 MTU」の3層に分かれる。層を分けて実測することが、最も速い復旧手順になる。
設定が少ないという長所は、切り分けの手がかりが少ないという短所と表裏である。だからこそ、どの層をどの順で測るかを先に決めておく。WireGuard を使いこなすとは、この順序を持っていることだと言ってよい。
参照した一次情報:
- WireGuard 公式サイト（プロトコルと実装） https://www.wireguard.com/ （2026-10-25 参照）
- WireGuard プロトコル解説 https://www.wireguard.com/protocol/ （2026-10-25 参照）
- WireGuard Quick Start（既定ポート 51820/UDP） https://www.wireguard.com/quickstart/ （2026-10-25 参照）
- The Noise Protocol Framework https://noiseprotocol.org/ （2026-10-25 参照）
- RFC 7748「Elliptic Curves for Security」（Curve25519） https://www.rfc-editor.org/rfc/rfc7748 （2026-10-25 参照）
- RFC 8439「ChaCha20 and Poly1305 for IETF Protocols」 https://www.rfc-editor.org/rfc/rfc8439 （2026-10-25 参照）
- RFC 7693「The BLAKE2 Cryptographic Hash and Message Authentication Code」 https://www.rfc-editor.org/rfc/rfc7693 （2026-10-25 参照）
- RFC 8200「Internet Protocol, Version 6 (IPv6) Specification」（IPv6 最小 MTU 1280） https://www.rfc-editor.org/rfc/rfc8200 （2026-10-25 参照）
- Linux 5.6 リリース情報 https://kernelnewbies.org/Linux_5.6 （2026-10-25 参照）
- 関連記事: WireGuard の MTU 不一致でつながらない — 1420 と 1280 を実測で切り分ける
- 関連記事: VPN は時代遅れなのか — モダン VPN とゼロトラストの現在地
- 関連記事: Netmaker とは — Tailscale のオンプレミス代替として何ができるか
