-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize wireguard kernel mode #2757
base: main
Are you sure you want to change the base?
Conversation
@hax0r31337 It is better for your design on WireGuard server sides? 另外失败的 jobs 应该不是代码问题,rerun 一下应该就好了。 |
@kunsonx thanks for your pr. Although I think it is too complex to maintain code to deal with iptables. Is this needed only by the kernel mode tun? If so I think it is reasonable for user to ask for root access if they need it. We just need to make sure the gvisor tun doesn't need it and we clearly document it. |
BTW are you sure this tun implementation Xray-core/proxy/wireguard/tun_linux.go Line 118 in 2570855
need privilege access like disable rp_filter? |
@yuhan6665 主要的问题是 如果在容器里跑 就会遇到权限问题 还需要给容器特权才可以正常运行 已经有不少反馈这种问题了 |
@yuhan6665 The user space WireGuard tun device require container device "/dev/net/tun". current version of "kernelMode" implementation create proxy socket and bind to wireguard device so when socket packet come back kernel will check reverse path and drop it(Cause no any changes on routes). I'm plan to implement native WireGuard device (no userspace device) it also require iptables operation. So considering the implementations of current and plan. I think it is better way to do that. iptables operation package copy from kuberneters so I think maintain thing is ok? |
Current implementations: Planning: |
Thanks for your info. Seems a rather big question for @RPRX :) |
The WireGuard outbound non userspace optimization version just created pull request on #2762. |
b11fcf0
to
7e24239
Compare
docker container 运行最低条件