2026/01/14 4:53
**HNに質問：** 「WireGuard上でVxLANを使うか、VxLAN上でWireGuardを使うか？」
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、趣味のホームラボ（Hetznerから自宅への~20 ms RTT）でWireGuard上にVXLANを重ねる実験を行っています。動作はしますが、この構成はMTU断片化とパケットサイズ制限によりNATホールパンチングが必要になるため、本番環境には適していません。その結果、WireGuard内のVXLANや逆にVXLAN内のWireGuardなど、ネストされたVPNは、別々のリージョン間トラフィックが必要でない限り過剰になります。
議論では代替発見方法についても触れられており、WireGuardによる自動ピア検出は不確実です。BGP‑EVPNはVXLANエンドポイント発見の潜在的な置き換え手段として挙げられています。Google の社内ネットワークでは GRE/GENEVE に似たカプセル化とジャムフレーム（> 9000 B）を使用していますが、L3 セマンティクスは維持されています。
著者は、ルート WireGuard トンネルを完全に排除し純粋な VXLAN/Flannel に切り替える試みも失敗したと指摘しており、ホールパンチングがまだ必要だったためです。再帰的ネスティング（WireGuard→VXLAN→WireGuard）は一般的には推奨されませんが、文脈によっては例外があります。
公開ネットワーク上で分離された L2 ドメインを必要とするユーザー（例えば複数のハイパーバイザー）に対しては、WireGuard 上の VXLAN は実用的なアプローチとなり得ますが、より広範な本番環境では、L2 を WAN に拡張するよりもルーティングを採用することを推奨しています。
最後に、著者は BGP を WireGuard 上で実行し探索的な週末プロジェクトとして発見性を向上させる試験を提案しており、EoIP over WG や単純 IP/VXLAN といった他の Layer‑2 相当プロトコルも検討していますが、結局はほとんどの場合でルーティングソリューションを優先する方針です。
本文
私は趣味用のセットアップでWireGuard上にVXLANを乗せています――本番環境では推奨されないかもしれません。主な理由は、私のホームラボがHetznerから自宅へと構成されており（約20 msの往復遅延）、それが影響しているためです。rootレベルのWireGuardを落としてFlannelだけでVXLANを使うことも検討しましたが、NATホールパンチングが必要なのでWireGuard層は残しています。WireGuardをVXLAN（Flannel）内にネストすると、異なるリージョン間のノード間トラフィックをネットワーク上の他のピアから分離したい場合以外では過剰になるでしょう。そのようなケースがどこで有用かは不明です。ピアをブロックする方が「root」レベルのWireGuardで簡単です。
ネストされたWireGuardネットワークにはMTUの問題が発生し得ます。L3ではなくL2で動作するWireGuard相当のものはありますか？これはホームラボ環境で仮想メッシュネットワークを構築するために必要です。現在の設定はTalos LinuxのKubeSpanを使って、WireGuardトンネル上にVXLANまたはGENEVEを走らせていますが、L2アクセスを持つとロードバランシングが簡素化されると思います。
ディスカバリーメカニズム：
WGで自動ピア管理ができるものは何か不明です。VXLANエンドポイントのディスカバリにBGP‑EVPNを使うなら、WG over VXLANの方が管理しやすいでしょう。VXLAN IDでL2ドメインを分離したい場合――例えばパブリックネットワーク上で異なるVMグループを実行しているハイパーバイザーを区別するなど――ならばWireGuard上にVXLANを乗せる方が適切です。
結論：
WAN上でL2を伸ばす理由はほとんどないので、VXLANは捨てましょう。単にトラフィックを経路転送するだけで十分です。
「WireGuard inside VXLAN inside WireGuard（再帰的）になるのは悪いアイデアだ」と合意しましょう――しかし、状況によっては必ずしもそうとは限りません。パブリックネットワークを横断していても同様です。
私は長らくWireGuardを使っていますが、BGP over it を考えたことはありませんでした。週末のプロジェクトとして試す価値はあるかもしれません。MTUが減ると余分なヘッダーやオーバーヘッドで最大パケットサイズが切り捨てられます――Googleは内部ルーティングをこのように行っています。IPSec相当、VXLAN相当、IPSec相当：脆弱層がトラフィックの詳細を知ることを防ぎます。
あなたがそのアイデアを思いついた背景は何ですか？Google内部では「脆弱性防止」のためではなく、メタデータ（トレース、遅延予算、請求IDなど）を運ぶためにGRE/GENEVEのような仕組みを使っています。カプセル化は単なる輸送手段――本質的にはL3セマンティクスが下位まで継続しています。L2は大規模では扱いづらく、ブロードキャスト／マルチキャストが機能しないためです。そのためGoogleは独自のソリューションとカスタムプロトコルを用いていますが、依然としてL3セマンティクスに基づいています。
さらに学びたい方へ：
データセンター間の内部リンクはジャムフレーム（MTU > 9000）を使用します。WireGuardはL3トランスポート、VXLANはL3上に乗るL2ライクなトランスポートです。EoIP over WireGuardで好きなVLANを使ったり、VXLAN over plain IP, EoIP, WireGuard, IPSec などの構成も可能です。ただし暗号化が必要ならWireGuardと非NULLセキュリティ付きIPSecのみが転送中に暗号化を提供します――そして必須のX/Y問題は依然として適用されます。