Re: gutd — WireGuard traffic obfuscator via TC/XDP eBPF (no kernel patches)

sh0rch <[email protected]> writes:

> Hi Toke,
>
> Thanks a lot for taking a look, really appreciate it!
>
> I actually started with Aya, but ended up losing some hair fighting
> the verifier :) libbpf_rs just worked for me in the end.

Yeah, writing the BPF code in Rust is hard, still, but you could still
use Aya to load, and avoid the extra dependency on libbpf? Not sure how
much of a difference that makes in practice (I just noted you were
chasing small binaries, so maybe that would help?)

> About the veth. I=E2=80=99m trying to keep things compatible with stock
> WireGuard and also need proper routing through a relay/gateway. Inside
> my perimeter I can use plain WG, but to get traffic out I rely on a
> gateway, so I need packets to go through the normal networking stack.
> If everything happens in eBPF, it won=E2=80=99t even reach netfilter. Tha=
t=E2=80=99s
> why I went with veth, also gives a bit more flexibility than tun/tap.

Hmm, not sure I undestrand what you mean by "rely on a gateway"? What
breaks if it's run only on TC, exactly?

In any case, if you need the extra step you could still have the BPF
programs run on the other side of the veth device, but still just as a
pair of TC ingress/egress programs? That would still simplify the BPF
side of things, and make the usage of veth devices optional.

> Ideally this would all live in AF_XDP + userspace, but that=E2=80=99s har=
d to
> rely on in VPS environments where AF_XDP support is still limited.

Don't think you'd get very good performance doing that, AF_XDP has a
pretty severe performance penalty if you want to re-inject packets into
the kernel. So unless you're actually creating an obfuscating middlebox,
going with BPF like you did here seems like a better solution :)

-Toke