3 ms·
This is when what makes WireGuard very performing also makes it very difficult to extend. Being in the kernel means extending it in userspace hurts its performa
by riobard 5y ago
This is when what makes WireGuard very performing also makes it very difficult to extend. Being in the kernel means extending it in userspace hurts its performance.
- oynqr 5y agoCheck out innernet, they seem to be doing just fine.
- touisteur 5y agoWhy extend when most of you might need can be built atop a very performant base layer. Combining wg and namespaces is quite the amazing swissknife.
- riobard 5y agoPlease let me know how to build an obfuscation layer on top of kernel-based WireGuard without sacrificing performance.
- touisteur 5y agoI'm curious what you mean by 'an obfuscation layer' and the use case around that?
- riobard 5y agoWell then how can you claim “most of you might need can be built atop a very performant base layer” without understanding what the grandparent comment (https://news.ycombinator.com/item?id=28579704 https://news.ycombinator.com/item?id=28579704) says about WireGuard lacking obfuscation? WireGuard encrypted UDP packets have obvious signature due to the packet type field in the header being in cleartext. DPI can easily filter/drop WG traffic just by checking the first few bytes of each UDP packet and doing simple statistics. To obfuscate in this context means to morph WireGuard encrypted UDP packets to look like something else (e.g. VoIP traffic). Current kernel-based official WireGuard implementations leave no possibility of doing so while staying in-kernel.
- tptacek 5y agoSo use the userland version. The "obfuscating" VPNs you're talking about all tend to be userland as well.
- riobard 5y agoThere goes the performance advantage.
- touisteur 5y agoI was answering to the first part of his comment, about bringing the whole kitchen sink in a tunneling protocol instead of having composable tools allowing for things the designers never imagined. But OK, this doesn't cover the second need, I'm guessing what you need is down one layer, and should be done in kernel if you really think it important, but how does wg prevent you from doing that? Build your tunnel obfuscator one layer down (I did some stateful, user-land driven, packet patching not long ago, with ebpf, it is not easy but the tooling is getting better. It seems the new way to do things nowadays anyway... And it runs in-kernel. Then lay wg above it. But having the wg codebase do what in fact the kernel should propose (pluggable transports, etc.) seems... asking the wrong team. The Linux kernel network stack is already plenty composable without ebpf...