Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

WireGuard as a VPN option on the Virtual Router

未关闭
#14,003 3 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
28/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃

调研方向

首先查看已关闭的 PR #9977 以及 CCC 2024 的幻灯片和视频,然后跨越 Virtual Router、Network、API 和 UI 组件追踪尚未解决的 API 设计问题。完成的标准是确定一条可行的实现路径,以及在未来版本中添加 WireGuard 支持的范围。

由索引模型根据 Issue 内容生成。

描述

component:networking component:virtual-router type:new-feature

ISSUE TYPE
  • Improvement Request / Feature Idea
COMPONENT NAME
Virtual Router, Network, API, UI
CLOUDSTACK VERSION
4.22.1.0
SUMMARY

CloudStack today offers L2TP for remote access and IPsec for site-to-site. We run CloudStack in production and a large share of our customer VPN problems come from the limits of these options. WireGuard would solve most of them:

Single UDP port. One port to allow, in and out, instead of IKE plus ESP and the NAT-T handling that comes with IPsec. It is far simpler to manage on customer-side firewalls, and much easier for us to support.

Works without a fixed public IP. Many of our customers sit behind dynamic addressing or carrier NAT and cannot establish an IPsec tunnel as the current IPsec S2S doesn't support authentication by Id, which has an open issue 13512. WireGuard traverses NAT with a single port and re-establishes on its own when the address changes. This is our single most common VPN complaint.

No negotiation matrix to get wrong. Bringing up an IPsec site-to-site tunnel means both ends agreeing on IKE version, DH group, encryption, hashing, authentication, PFS and lifetimes, in two separate phases. A single mismatch anywhere produces a tunnel that will not come up, often with no useful error on either side, and the customer equipment is usually out of our control. This is where most of our site-to-site setup time goes. WireGuard has no negotiation at all: exchange public keys and the tunnel is up.

Lower CPU cost. In our experience an IPsec tunnel pins encryption to one core and saturates it, capping tunnel throughput well below the link. WireGuard is noticeably lighter for the same traffic due to its modern encryption algorithms.

One protocol for both use cases. Remote access and site-to-site with the same configuration model, instead of two separate stacks.

Home routers already support it. A large number of consumer and SOHO routers now ship WireGuard. That lets a customer connect their whole home or small office to their tenant directly from the router, and route only the tenant prefixes over the tunnel while normal internet traffic stays local. Split routing like this is not workable with the current L2TP client setup, and this is exactly what many of our customers are asking for.

PRIOR ART

This has already been proposed and partly implemented in the project:

The PR did not stall because the feature was rejected. It stalled on an open API design question, then on rebase conflicts, and finally on the author's availability.

Is it feasible to revive this and get WireGuard support into a future release? There is real demand for it among our customers, and the groundwork already exists in the closed PR and the CCC material.

主要语言
Java
星标
3.1k
派生
1.4k
平均合并
6 天 20 小时
30 天内合并 PR
27

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/cloudstack 的其他 Issue

查看 apache/cloudstack 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。