Mirror of https://passt.top/passt/ . Pull requests are not accepted here.
passt implements a translation layer between a Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't require any capabilities or privileges, and it can be used as a simple replacement for Slirp.
canvas.width = rect.right - rect.left;
canvas.height = rect.bottom - rect.top;
canvas.style.left = rect.left + 'px';
canvas.style.top = rect.top + 'px';
}
function map_hover() { var coords = this.coords.split(','); var canvas = document.getElementById('map_highlight'); var ctx = canvas.getContext('2d');
canvas_position(this);
ctx.fillStyle = 'rgba(255, 255, 255, .3)';
ctx.lineWidth = 1.5;
ctx.strokeStyle = 'rgba(255, 255, 100, 1)';
ctx.beginPath();
ctx.setLineDash([15, 15]);
if (this.shape == "poly") {
ctx.moveTo(coords[0], coords[1]);
for (item = 2; item < coords.length - 1; item += 2) {
ctx.lineTo(coords[item], coords[item + 1])
}
} else if (this.shape == "rect") {
ctx.rect(coords[0], coords[1],
coords[2] - coords[0], coords[3] - coords[1]);
}
ctx.closePath();
ctx.stroke();
ctx.fill();
}
function map_out() { var canvas = document.getElementById('map_highlight'); var ctx = canvas.getContext('2d');
ctx.clearRect(0, 0, canvas.width, canvas.height);
}
var map_areas = document.getElementsByClassName("map_area");
for (var i = 0; i < map_areas.length; i++) { map_areas[i].onmouseover = map_hover; map_areas[i].onmouseout = map_out; }
pasta (same binary as passt, different command) offers equivalent functionality, for network namespaces: traffic is forwarded using a tap interface inside the namespace, without the need to create further interfaces on the host, hence not requiring any capabilities or privileges.
It also implements a tap bypass path for local connections: packets with a local destination address are moved directly between Layer-4 sockets, avoiding Layer-2 translations, using the splice(2) and recvmmsg(2)/sendmmsg(2) system calls for TCP and UDP, respectively.
See also the man page.
When container workloads are moved to virtual machines, the network traffic is typically forwarded by interfaces operating at data link level. Some components in the containers ecosystem (such as service meshes), however, expect applications to run locally, with visible sockets and processes, for the purposes of socket redirection, monitoring, port mapping.
To solve this issue, user mode networking, as provided e.g. by libslirp, can be used. Existing solutions implement a full TCP/IP stack, replaying traffic on sockets that are local to the pod of the service mesh. This creates the illusion of application processes running on the same host, eventually separated by user namespaces.
While being almost transparent to the service mesh infrastructure, that kind of solution comes with a number of downsides:
passt implements a thinner layer between guest and host, that only implements
what's strictly needed to pretend processes are running locally. The TCP
adaptation doesn't keep per-connection packet buffers, and reflects observed
sending windows and acknowledgements between the two sides. This TCP adaptation
is needed as passt runs without the CAP_NET_RAW
capability: it can't create
raw IP sockets on the pod, and therefore needs to map packets at Layer-2 to
Layer-4 sockets offered by the host kernel.
See also a detailed illustration of the problem and what lead to this approach.
On Linux, regular users can create network namespaces and run application
services inside them. However, connecting namespaces to other namespaces and to
external hosts requires the creation of network interfaces, such as veth
pairs, which needs in turn elevated privileges or the CAP_NET_ADMIN
capability. pasta, similarly to slirp4netns, solves this problem by creating
a tap interface available to processes in the namespace, and mapping network
traffic outside the namespace using native Layer-4 sockets.
Existing approaches typically implement a full, generic TCP/IP stack for this translation between data and transport layers, without the possibility of speeding up local connections, and usually requiring NAT. pasta:
✅: done/supported, ❌: out of scope, 🛠: in progress/being considered ⌚: nice-to-have, eventually
sbrk
(2), brk
(2), mmap
(2) blocked viaseccomp
)CAP_NET_BIND_SERVICE
(if granted)CAP_NET_RAW
is grantedpasst exchanges packets with qemu via UNIX domain socket, using the socket
back-end in qemu. This is supported since qemu 7.2.
For older versions, the qrap wrapper can be used to connect to a UNIX domain socket and to start qemu, which can now use the file descriptor that's already opened.
This approach, compared to using a tap device, doesn't require any security capabilities, as we don't need to create any interface.
pasta runs out of the box with any recent (post-3.8) Linux kernel.
passt and pasta provide some minimalistic implementations of networking services:
For IPv4, the guest or namespace is assigned, via DHCP, the same address as the upstream interface of the host, and the same default gateway as the default gateway of the host. Addresses are translated in case the guest is seen using a different address from the assigned one.
For IPv6, the guest or namespace is assigned, via SLAAC, a prefix derived from the address of the upstream interface of the host, the same default route as the default route of the host, and, if a DHCPv6 client is running in the guest or namespace, also the same address as the upstream address of the host. This means that, with a DHCPv6 client in the guest or namespace, addresses don't need to be translated. Should the client use a different address, the destination address is translated for packets going to the guest or to the namespace.
For UDP and TCP, for both IPv4 and IPv6, packets from the host addressed to a loopback address are forwarded to the guest with their source address changed to the address of the gateway or first hop of the default route. This mapping is reversed on the other way.
Packets addressed to a loopback address in either namespace are directly forwarded to the corresponding (or configured) port in the other namespace. Similarly as passt, packets from the non-init namespace addressed to the default gateway, which are therefore sent via the tap device, will have their destination address translated to the loopback address.
passt and pasta support TCP, UDP and ICMP/ICMPv6 echo (requests and replies). More details about the TCP implementation are described in the theory of operation, and similarly for UDP.
An IGMP/MLD proxy is currently work in progress.
To avoid the need for explicit port mapping configuration, passt can bind to all unbound non-ephemeral (0-49152) TCP and UDP ports. Binding to low ports (0-1023) will fail without additional capabilities, and ports already bound (service proxies, etc.) will also not be used. Smaller subsets of ports, with port translations, are also configurable.
UDP ephemeral ports are bound dynamically, as the guest uses them.
If all ports are forwarded, service proxies and other services running in the container need to be started before passt starts.
With default options, pasta scans for bound ports on init and non-init namespaces, and automatically forwards them from the other side. Port forwarding is fully configurable with command line options.
demo_podman_player = AsciinemaPlayer.create('/builds/latest/web/demo_podman.cast',
document.getElementById('demo_podman'),
{ cols: 130, rows: 41,
preload: true, poster: 'npt:0:4'
});
}
See also the test logs.
build from source:
git clone https://passt.top/passt
cd passt
make
alternatively, install one of the available packages
Static binaries and packages are simply built with:
make pkgs
have a look at the man page for synopsis and options:
man ./passt.1
run the demo script, that detaches user and network namespaces, configures the
new network namespace using pasta
, starts passt
and, optionally, qemu
:
doc/demo.sh
alternatively, you can use libvirt to start QEMU
and that's it, you should now have TCP connections, UDP, and ICMP/ICMPv6 echo working from/to the guest for IPv4 and IPv6
to connect to a service on the VM, just connect to the same port directly with the address of the current network namespace
build from source:
git clone https://passt.top/passt
cd passt
make
alternatively, install one of the available packages
Static binaries and packages are simply built with:
make pkgs
have a look at the man page for synopsis and options:
man ./pasta.1
start pasta with:
./pasta
alternatively, use it directly with Podman (since Podman 4.3.2, or with
commit aa47e05ae4a0
):
podman run --net=pasta ...
you're now inside a new user and network namespace. For IPv6, SLAAC happens right away as pasta sets up the interface, but DHCPv6 support is available as well. For IPv4, configure the interface with a DHCP client:
dhclient
and, optionally:
dhclient -6
alternatively, start pasta as:
./pasta --config-net
to let pasta configure networking in the namespace by itself, using
netlink
...or run the demo script:
doc/demo.sh
and that's it, you should now have TCP connections, UDP, and ICMP/ICMPv6 echo working from/to the namespace for IPv4 and IPv6
to connect to a service inside the namespace, just connect to the same port using the loopback address.
Submit, review patches, and discuss development ideas on
passt-dev
Ask your questions and discuss usage needs on
passt-user
#passt
at