sbrivio
Joined 4 years ago
Karma
61
Submissions
8
Member since
Feb 23
Recent submissions
Comment · 7 months ago
Comment · 4 years ago
There are two port forwarding modes allowed with slirp4netns. One uses slirp4netns itself: data is passed across a tap device, libslirp translates the destination address and preserves the source address.
The second one uses rootlesskitport (while slirp4netns still takes care of outbound connections): it opens sockets directly in the detached network namespace and passes data between sockets without going through the tap device. It's faster, because you avoid 1. the tap device 2. Layer-4/Layer-2 translations. But those sockets are local to the namespace, so destination and source address become loopback addresses. That might be unexpected in some cases, see also https://nvd.nist.gov/vuln/detail/CVE-2021-20199.
pasta implements both modes (it's the "tap bypass" in https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...), and selects the appropriate one based on the original source address, so that you don't need to choose one. Local connections skip the tap device, non-local ones go through it (you can have non-loopback source addresses only for traffic coming through a a non-loopback interface).
Comment · 4 years ago
See podman-network-create(1), I think the description of the --driver option should clarify this. You can use macvlan there, but in rootless operation you don't have access to the network interface of the hosts -- unless you set that up networking separately beforehand (as root), that is.
So yes, it supports rootless, but by (kernel) design, there's no magic way to bridge (no pun intended) that gap (even with macvlan).
Comment · 4 years ago
I have specifically not added that out of respect for what Slirp represented to dialup shell users in the late 1990s and for what it did for the ecosystem in the past 15 years. I used it for more than a decade myself, and if you consider that it's now used for containers and virtual machines, given the original purpose, it's really an impressive piece of software. Feature comparisons can be risky at times.
It's mostly in the direction of IPv6 support, performance, security. Those topics are covered in slides: https://static.sched.com/hosted_files/kvmforum2022/01/passt_... or recording: https://www.youtube.com/watch?v=U89bWP1HNgU of a recent talk from KVM Forum 2022.
Comment · 4 years ago
You might be right, but I hope you're not. :)
I had a look at Winsock documentation a while ago, that doesn't look so bad in terms of what we need. See also: https://lore.kernel.org/qemu-devel/20220919232441.661eda8d@e.... Replacing epoll might be messy, though.
Comment · 4 years ago
On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).
See https://medium.com/nttlabs/dont-use-host-network-namespace-f... for just an example of what can go wrong otherwise.
We're finally adding multithreading (https://bugs.passt.top/show_bug.cgi?id=13) these days.