passt: Relicense to GPL 2.0, or any later version
In practical terms, passt doesn't benefit from the additional
protection offered by the AGPL over the GPL, because it's not
suitable to be executed over a computer network.
Further, restricting the distribution under the version 3 of the GPL
wouldn't provide any practical advantage either, as long as the passt
codebase is concerned, and might cause unnecessary compatibility
dilemmas.
Change licensing terms to the GNU General Public License Version 2,
or any later version, with written permission from all current and
past contributors, namely: myself, David Gibson, Laine Stump, Andrea
Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian
Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-05 20:11:44 +02:00
|
|
|
.\" SPDX-License-Identifier: GPL-2.0-or-later
|
2022-02-19 04:39:47 +01:00
|
|
|
.\" Copyright (c) 2020-2022 Red Hat GmbH
|
2021-10-19 12:43:28 +02:00
|
|
|
.\" Author: Stefano Brivio <sbrivio@redhat.com>
|
2021-08-19 20:22:40 +02:00
|
|
|
.TH passt 1
|
|
|
|
|
|
|
|
|
|
.SH NAME
|
|
|
|
|
.B passt
|
|
|
|
|
\- Unprivileged user-mode network connectivity for virtual machines
|
|
|
|
|
.br
|
|
|
|
|
.B pasta
|
|
|
|
|
\- Unprivileged user-mode network connectivity for network namespaces
|
|
|
|
|
|
|
|
|
|
.SH SYNOPSIS
|
|
|
|
|
.B passt
|
|
|
|
|
[\fIOPTION\fR]...
|
|
|
|
|
.br
|
|
|
|
|
.B pasta
|
2022-08-26 06:58:39 +02:00
|
|
|
[\fIOPTION\fR]... [\fICOMMAND\fR [\fIARG\fR]...]
|
|
|
|
|
.br
|
|
|
|
|
.B pasta
|
|
|
|
|
[\fIOPTION\fR]... \fIPID\fR
|
2022-08-26 06:58:38 +02:00
|
|
|
.br
|
|
|
|
|
.B pasta
|
|
|
|
|
[\fIOPTION\fR]... \fB--netns\fR [\fIPATH\fR|\fINAME\fR]
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SH DESCRIPTION
|
|
|
|
|
|
|
|
|
|
.SS passt
|
|
|
|
|
|
|
|
|
|
.B passt
|
|
|
|
|
(\fIP\fRlug \fIA\fR \fIS\fRimple \fIS\fRocket \fIT\fRransport) provides full,
|
|
|
|
|
quasi-native network connectivity to virtual machines in user-mode without
|
|
|
|
|
requiring any capabilities or privileges.
|
|
|
|
|
|
|
|
|
|
The data plane implements a translation layer between a Layer-2 virtual network
|
|
|
|
|
interface and native Layer-4 (TCP, UDP, ping) sockets on the host, giving the
|
|
|
|
|
illusion that application processes residing on the guest are running on the
|
|
|
|
|
local host, from a networking perspective.
|
|
|
|
|
|
|
|
|
|
Built-in ARP, DHCP, NDP, and DHCPv6 implementations are designed to provide the
|
|
|
|
|
guest with a network configuration that tightly resembles the host native
|
|
|
|
|
configuration. With the default options, guest and host share IP addresses,
|
|
|
|
|
routes, and port bindings.
|
|
|
|
|
|
|
|
|
|
Port forwarding and translation allow networking services running in the guest
|
|
|
|
|
to be reachable from both local and remote hosts.
|
|
|
|
|
|
|
|
|
|
Unlike \fBslirp4netns\fR(1), \fBpasst\fR doesn't implement a full TCP stack: the
|
|
|
|
|
TCP translation layer has no stateful data buffering and operates by reflecting
|
|
|
|
|
one peer's observed parameters (congestion window size, acknowledged data, etc.)
|
|
|
|
|
to the corresponding peer.
|
|
|
|
|
|
|
|
|
|
Currently, the only supported hypervisor is \fBqemu\fR(1), connecting to
|
2022-11-04 02:38:31 +01:00
|
|
|
\fBpasst\fR by means of a UNIX domain socket. This is supported starting from
|
|
|
|
|
qemu 7.2. For older qemu versions, see the \fBqrap\fR(1) wrapper.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SS pasta
|
|
|
|
|
|
|
|
|
|
.B pasta
|
|
|
|
|
(\fIP\fRack \fIA\fR \fIS\fRubtle \fIT\fRap \fIA\fRbstraction) provides
|
|
|
|
|
equivalent functionality to network namespaces, as the one offered by
|
|
|
|
|
\fBpasst\fR for virtual machines.
|
|
|
|
|
|
2022-08-26 06:58:39 +02:00
|
|
|
If PID or --netns are given, \fBpasta\fR associates to an existing
|
|
|
|
|
user and network namespace. Otherwise, \fBpasta\fR creates a new user
|
|
|
|
|
and network namespace, and spawns the given command or a default shell
|
|
|
|
|
within this context. A \fItap\fR device within the network namespace
|
|
|
|
|
is created to provide network connectivity.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
For local TCP and UDP traffic only, \fBpasta\fR also implements a bypass path
|
|
|
|
|
directly mapping Layer-4 sockets between \fIinit\fR and target namespaces,
|
|
|
|
|
for performance reasons.
|
|
|
|
|
|
|
|
|
|
.SH OPTIONS
|
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
Unless otherwise noted below, \fBif conflicting or multiple options are given,
|
|
|
|
|
the last one takes effect.\fR
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-d ", " \-\-debug
|
2022-10-26 16:48:42 +02:00
|
|
|
Be verbose, don't log to the system logger.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
2022-03-15 00:59:09 +01:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-trace
|
2022-10-26 16:48:42 +02:00
|
|
|
Be extra verbose, show single packets. Implies \fB--debug\fR.
|
2022-03-15 00:59:09 +01:00
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-q ", " \-\-quiet
|
|
|
|
|
Don't print informational messages.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-f ", " \-\-foreground
|
passt, pasta: Namespace-based sandboxing, defer seccomp policy application
To reach (at least) a conceptually equivalent security level as
implemented by --enable-sandbox in slirp4netns, we need to create a
new mount namespace and pivot_root() into a new (empty) mountpoint, so
that passt and pasta can't access any filesystem resource after
initialisation.
While at it, also detach IPC, PID (only for passt, to prevent
vulnerabilities based on the knowledge of a target PID), and UTS
namespaces.
With this approach, if we apply the seccomp filters right after the
configuration step, the number of allowed syscalls grows further. To
prevent this, defer the application of seccomp policies after the
initialisation phase, before the main loop, that's where we expect bad
things to happen, potentially. This way, we get back to 22 allowed
syscalls for passt and 34 for pasta, on x86_64.
While at it, move #syscalls notes to specific code paths wherever it
conceptually makes sense.
We have to open all the file handles we'll ever need before
sandboxing:
- the packet capture file can only be opened once, drop instance
numbers from the default path and use the (pre-sandbox) PID instead
- /proc/net/tcp{,v6} and /proc/net/udp{,v6}, for automatic detection
of bound ports in pasta mode, are now opened only once, before
sandboxing, and their handles are stored in the execution context
- the UNIX domain socket for passt is also bound only once, before
sandboxing: to reject clients after the first one, instead of
closing the listening socket, keep it open, accept and immediately
discard new connection if we already have a valid one
Clarify the (unchanged) behaviour for --netns-only in the man page.
To actually make passt and pasta processes run in a separate PID
namespace, we need to unshare(CLONE_NEWPID) before forking to
background (if configured to do so). Introduce a small daemon()
implementation, __daemon(), that additionally saves the PID file
before forking. While running in foreground, the process itself can't
move to a new PID namespace (a process can't change the notion of its
own PID): mention that in the man page.
For some reason, fork() in a detached PID namespace causes SIGTERM
and SIGQUIT to be ignored, even if the handler is still reported as
SIG_DFL: add a signal handler that just exits.
We can now drop most of the pasta_child_handler() implementation,
that took care of terminating all processes running in the same
namespace, if pasta started a shell: the shell itself is now the
init process in that namespace, and all children will terminate
once the init process exits.
Issuing 'echo $$' in a detached PID namespace won't return the
actual namespace PID as seen from the init namespace: adapt
demo and test setup scripts to reflect that.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-07 21:11:37 +01:00
|
|
|
Don't run in background. This implies that the process is not moved to a
|
|
|
|
|
detached PID namespace after starting, because the PID itself cannot change.
|
2021-10-21 20:13:18 +02:00
|
|
|
Default is to fork into background.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-e ", " \-\-stderr
|
conf, passt: Make --stderr do nothing, and deprecate it
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-06-19 20:10:10 +02:00
|
|
|
This option has no effect, and is maintained for compatibility purposes only.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
conf, passt: Make --stderr do nothing, and deprecate it
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-06-19 20:10:10 +02:00
|
|
|
Note that this configuration option is \fBdeprecated\fR and will be removed in a
|
|
|
|
|
future version.
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
|
2022-10-06 14:51:04 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-l ", " \-\-log-file " " \fIPATH\fR
|
conf, passt: Make --stderr do nothing, and deprecate it
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-06-19 20:10:10 +02:00
|
|
|
Log to file \fIPATH\fR, and not to the system logger.
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
|
|
|
|
|
Specifying this option multiple times does \fInot\fR lead to multiple log files:
|
|
|
|
|
the last given option takes effect.
|
|
|
|
|
|
2022-10-06 14:51:04 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-log-size " " \fISIZE\fR
|
|
|
|
|
Limit log file size to \fISIZE\fR bytes. When the log file is full, make room
|
|
|
|
|
for new entries by removing old ones at the beginning. This limit is mandatory.
|
|
|
|
|
Default is 1048576 (1 MiB).
|
|
|
|
|
|
2022-05-18 19:10:45 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-runas " " \fIUID\fR|\fIUID:GID\fR|\fILOGIN\fR|\fILOGIN:GROUP\fR
|
2022-09-12 14:24:00 +02:00
|
|
|
Attempt to change to given UID and corresponding group if UID is given,
|
2022-05-18 19:10:45 +02:00
|
|
|
or to given UID and given GID if both are given. Alternatively, login name, or
|
2022-09-12 14:24:00 +02:00
|
|
|
login name and group name can be passed. This requires privileges (either
|
|
|
|
|
initial effective UID 0 or CAP_SETUID capability) to work.
|
2022-05-18 19:10:45 +02:00
|
|
|
Default is to change to user \fInobody\fR if started as root.
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-h ", " \-\-help
|
|
|
|
|
Display a help message and exit.
|
|
|
|
|
|
2022-10-10 10:35:47 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-version
|
|
|
|
|
Show version and exit.
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-p ", " \-\-pcap " " \fIfile
|
|
|
|
|
Capture tap-facing (that is, guest-side or namespace-side) network packets to
|
|
|
|
|
\fIfile\fR in \fBpcap\fR format.
|
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
Specifying this option multiple times does \fInot\fR lead to multiple capture
|
|
|
|
|
files: the last given option takes effect.
|
|
|
|
|
|
2021-10-14 12:17:47 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-P ", " \-\-pid " " \fIfile
|
|
|
|
|
Write own PID to \fIfile\fR once initialisation is done, before forking to
|
|
|
|
|
background (if configured to do so).
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-m ", " \-\-mtu " " \fImtu
|
2023-03-15 10:06:50 +01:00
|
|
|
Assign \fImtu\fR via DHCP (option 26) and NDP (option type 5). A zero value
|
|
|
|
|
disables assignment.
|
|
|
|
|
By default, the advertised MTU is 65520 bytes, that is, the maximum 802.3 MTU
|
|
|
|
|
minus the length of a 802.3 header, rounded to 32 bits (IPv4 words).
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-a ", " \-\-address " " \fIaddr
|
|
|
|
|
Assign IPv4 \fIaddr\fR via DHCP (\fByiaddr\fR), or \fIaddr\fR via DHCPv6 (option
|
|
|
|
|
5) and an \fIaddr\fR-based prefix via NDP Router Advertisement (option type 3)
|
|
|
|
|
for an IPv6 \fIaddr\fR.
|
|
|
|
|
This option can be specified zero (for defaults) to two times (once for IPv4,
|
|
|
|
|
once for IPv6).
|
2022-07-30 22:17:07 +02:00
|
|
|
By default, assigned IPv4 and IPv6 addresses are taken from the host interfaces
|
2024-03-15 13:25:44 +01:00
|
|
|
with the first default route, if any, for the corresponding IP version. If no
|
netlink: With no default route, pick the first interface with a route
While commit f919dc7a4b1c ("conf, netlink: Don't require a default
route to start") sounded reasonable in the assumption that, if we
don't find default routes for a given address family, we can still
proceed by selecting an interface with any route *iff it's the only
one for that protocol family*, Jelle reported a further issue in a
similar setup.
There, multiple interfaces are present, and while remote container
connectivity doesn't matter for the container, local connectivity is
desired. There are no default routes, but those multiple interfaces
all have non-default routes, so we should just pick one and start.
Pick the first interface reported by the kernel with any route, if
there are no default routes. There should be no harm in doing so.
Reported-by: Jelle van der Waa <jvanderwaa@redhat.com>
Reported-by: Martin Pitt <mpitt@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2277954
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:55:43 +02:00
|
|
|
default routes are available and there is any interface with any route for a
|
|
|
|
|
given IP version, the first of these interfaces will be chosen instead.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-n ", " \-\-netmask " " \fImask
|
|
|
|
|
Assign IPv4 netmask \fImask\fR, expressed as dot-decimal or number of bits, via
|
|
|
|
|
DHCP (option 1).
|
|
|
|
|
By default, the netmask associated to the host address matching the assigned one
|
|
|
|
|
is used. If there's no matching address on the host, the netmask is determined
|
|
|
|
|
according to the CIDR block of the assigned address (RFC 4632).
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-M ", " \-\-mac-addr " " \fIaddr
|
|
|
|
|
Use source MAC address \fIaddr\fR when communicating to the guest or to the
|
|
|
|
|
target namespace.
|
2022-07-30 22:17:07 +02:00
|
|
|
Default is to use the MAC address of the interface with the first IPv4 default
|
|
|
|
|
route on the host.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-g ", " \-\-gateway " " \fIaddr
|
|
|
|
|
Assign IPv4 \fIaddr\fR as default gateway via DHCP (option 3), or IPv6
|
|
|
|
|
\fIaddr\fR as source for NDP Router Advertisement and DHCPv6 messages.
|
|
|
|
|
This option can be specified zero (for defaults) to two times (once for IPv4,
|
|
|
|
|
once for IPv6).
|
2024-02-02 00:09:37 +01:00
|
|
|
By default, IPv4 and IPv6 gateways are taken from the host interface with the
|
2024-03-15 13:25:44 +01:00
|
|
|
first default route, if any, for the corresponding IP version. If the default
|
|
|
|
|
route is a multipath one, the gateway is the first nexthop router returned by
|
|
|
|
|
the kernel which has the highest weight in the set of paths. If no default
|
|
|
|
|
routes are available and there is just one interface with any route, that
|
|
|
|
|
interface will be chosen instead.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Note: these addresses are also used as source address for packets directed to
|
|
|
|
|
the guest or to the target namespace having a loopback or local source address,
|
|
|
|
|
to allow mapping of local traffic to guest and target namespace. See the
|
|
|
|
|
\fBNOTES\fR below for more details about this mechanism.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-i ", " \-\-interface " " \fIname
|
|
|
|
|
Use host interface \fIname\fR to derive addresses and routes.
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
Default is to use the interfaces specified by \fB--outbound-if4\fR and
|
2024-03-15 13:25:44 +01:00
|
|
|
\fB--outbound-if6\fR, for IPv4 and IPv6 addresses and routes, respectively.
|
|
|
|
|
|
|
|
|
|
If no interfaces are given, the interface with the first default routes for each
|
|
|
|
|
IP version is selected. If no default routes are available and there is just one
|
|
|
|
|
interface with any route, that interface will be chosen instead.
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-o ", " \-\-outbound " " \fIaddr
|
|
|
|
|
Use an IPv4 \fIaddr\fR as source address for IPv4 outbound TCP connections, UDP
|
|
|
|
|
flows, ICMP requests, or an IPv6 \fIaddr\fR for IPv6 ones, by binding outbound
|
|
|
|
|
sockets to it.
|
|
|
|
|
This option can be specified zero (for defaults) to two times (once for IPv4,
|
|
|
|
|
once for IPv6).
|
|
|
|
|
By default, the source address is selected by the routing tables.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-outbound-if4 " " \fIname
|
|
|
|
|
Bind IPv4 outbound sockets to host interface \fIname\fR, and, unless another
|
|
|
|
|
interface is specified via \fB-i\fR, \fB--interface\fR, use this interface to
|
|
|
|
|
derive IPv4 addresses and routes.
|
2024-03-15 13:25:44 +01:00
|
|
|
|
|
|
|
|
By default, the interface given by the default route is selected. If no default
|
|
|
|
|
routes are available and there is just one interface with any route, that
|
|
|
|
|
interface will be chosen instead.
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-outbound-if6 " " \fIname
|
|
|
|
|
Bind IPv6 outbound sockets to host interface \fIname\fR, and, unless another
|
|
|
|
|
interface is specified via \fB-i\fR, \fB--interface\fR, use this interface to
|
|
|
|
|
derive IPv6 addresses and routes.
|
2024-03-15 13:25:44 +01:00
|
|
|
|
|
|
|
|
By default, the interface given by the default route is selected. If no default
|
|
|
|
|
routes are available and there is just one interface with any route, that
|
|
|
|
|
interface will be chosen instead.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-D ", " \-\-dns " " \fIaddr
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
Use \fIaddr\fR (IPv4 or IPv6) for DHCP, DHCPv6, NDP or DNS forwarding, as
|
|
|
|
|
configured (see options \fB--no-dhcp-dns\fR, \fB--dhcp-dns\fR,
|
|
|
|
|
\fB--dns-forward\fR) instead of reading addresses from \fI/etc/resolv.conf\fR.
|
2022-08-26 06:58:33 +02:00
|
|
|
This option can be specified multiple times. Specifying \fB-D none\fR disables
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
usage of DNS addresses altogether.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-dns-forward " " \fIaddr
|
2024-07-24 09:51:12 +02:00
|
|
|
Map \fIaddr\fR (IPv4 or IPv6) as seen from guest or namespace to the
|
|
|
|
|
first configured DNS resolver (with corresponding IP version). Maps
|
|
|
|
|
only UDP and TCP traffic to port 53 or port 853. Replies are
|
|
|
|
|
translated back with a reverse mapping. This option can be specified
|
|
|
|
|
zero to two times (once for IPv4, once for IPv6).
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-S ", " \-\-search " " \fIlist
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
Use space-separated \fIlist\fR for DHCP, DHCPv6, and NDP purposes, instead of
|
|
|
|
|
reading entries from \fI/etc/resolv.conf\fR. See options \fB--no-dhcp-search\fR
|
2022-08-26 06:58:33 +02:00
|
|
|
and \fB--dhcp-search\fR. \fB--search none\fR disables the DNS domain search
|
|
|
|
|
list altogether (if you need to search a domain called "none" you can use
|
|
|
|
|
\fB--search none.\fR).
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
|
|
|
|
|
.TP
|
2024-03-12 19:17:50 +01:00
|
|
|
.BR \-\-no-dhcp-dns
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
In \fIpasst\fR mode, do not assign IPv4 addresses via DHCP (option 23) or IPv6
|
|
|
|
|
addresses via NDP Router Advertisement (option type 25) and DHCPv6 (option 23)
|
|
|
|
|
as DNS resolvers.
|
|
|
|
|
By default, all the configured addresses are passed.
|
|
|
|
|
|
|
|
|
|
.TP
|
2024-03-12 19:17:50 +01:00
|
|
|
.BR \-\-dhcp-dns
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
In \fIpasta\fR mode, assign IPv4 addresses via DHCP (option 23) or IPv6
|
|
|
|
|
addresses via NDP Router Advertisement (option type 25) and DHCPv6 (option 23)
|
|
|
|
|
as DNS resolvers.
|
|
|
|
|
By default, configured addresses, if any, are not passed.
|
|
|
|
|
|
|
|
|
|
.TP
|
2024-03-12 19:17:50 +01:00
|
|
|
.BR \-\-no-dhcp-search
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
In \fIpasst\fR mode, do not send the DNS domain search list addresses via DHCP
|
|
|
|
|
(option 119), via NDP Router Advertisement (option type 31) and DHCPv6 (option
|
|
|
|
|
24).
|
|
|
|
|
By default, the DNS domain search list resulting from configuration is passed.
|
|
|
|
|
|
|
|
|
|
.TP
|
2024-03-12 19:17:50 +01:00
|
|
|
.BR \-\-dhcp-search
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
In \fIpasta\fR mode, send the DNS domain search list addresses via DHCP (option
|
|
|
|
|
119), via NDP Router Advertisement (option type 31) and DHCPv6 (option 24).
|
|
|
|
|
By default, the DNS domain search list resulting from configuration is not
|
|
|
|
|
passed.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-tcp
|
|
|
|
|
Disable the TCP protocol handler. No TCP connections will be accepted host-side,
|
|
|
|
|
and TCP packets coming from guest or target namespace will be silently dropped.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-udp
|
|
|
|
|
Disable the UDP protocol handler. No UDP traffic coming from the host side will
|
|
|
|
|
be forwarded, and UDP packets coming from guest or target namespace will be
|
|
|
|
|
silently dropped.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-icmp
|
|
|
|
|
Disable the ICMP/ICMPv6 echo handler. ICMP and ICMPv6 echo requests coming from
|
|
|
|
|
guest or target namespace will be silently dropped.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-dhcp
|
|
|
|
|
Disable the DHCP server. DHCP client requests coming from guest or target
|
conf: Don't exit if sourced default route has no gateway
If we use a template interface without a gateway on the default
route, we can still offer almost complete functionality, except that,
of course, we can't map the gateway address to the outer namespace or
host, and that we have no obvious server address or identifier for
use in DHCP's siaddr and option 54 (Server identifier, mandatory).
Continue, if we have a default route but no default gateway, and
imply --no-map-gw and --no-dhcp in that case. NDP responder and
DHCPv6 should be able to work as usual because we require a
link-local address to be present, and we'll fall back to that.
Together with the previous commits implementing an actual copy of
routes from the outer namespace, this should finally fix the
operation of 'pasta --config-net' for cases where we have a default
route on the host, but no default gateway, as it's the case for
tap-style routes, including typical Wireguard endpoints.
Reported-by: me@yawnt.com
Link: https://bugs.passt.top/show_bug.cgi?id=49
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-05-14 16:24:11 +02:00
|
|
|
namespace will be silently dropped. Implied if there is no gateway on the
|
|
|
|
|
selected IPv4 default route.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-ndp
|
|
|
|
|
Disable NDP responses. NDP messages coming from guest or target namespace will
|
|
|
|
|
be ignored.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-dhcpv6
|
|
|
|
|
Disable the DHCPv6 server. DHCPv6 client requests coming from guest or target
|
|
|
|
|
namespace will be silently dropped.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-ra
|
|
|
|
|
Disable Router Advertisements. Router Solicitations coming from guest or target
|
|
|
|
|
namespace will be ignored.
|
|
|
|
|
|
2021-10-14 05:26:37 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-map-gw
|
|
|
|
|
Don't remap TCP connections and untracked UDP traffic, with the gateway address
|
conf: Don't exit if sourced default route has no gateway
If we use a template interface without a gateway on the default
route, we can still offer almost complete functionality, except that,
of course, we can't map the gateway address to the outer namespace or
host, and that we have no obvious server address or identifier for
use in DHCP's siaddr and option 54 (Server identifier, mandatory).
Continue, if we have a default route but no default gateway, and
imply --no-map-gw and --no-dhcp in that case. NDP responder and
DHCPv6 should be able to work as usual because we require a
link-local address to be present, and we'll fall back to that.
Together with the previous commits implementing an actual copy of
routes from the outer namespace, this should finally fix the
operation of 'pasta --config-net' for cases where we have a default
route on the host, but no default gateway, as it's the case for
tap-style routes, including typical Wireguard endpoints.
Reported-by: me@yawnt.com
Link: https://bugs.passt.top/show_bug.cgi?id=49
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-05-14 16:24:11 +02:00
|
|
|
as destination, to the host. Implied if there is no gateway on the selected
|
2024-03-15 13:25:44 +01:00
|
|
|
default route, or if there is no default route, for any of the enabled address
|
|
|
|
|
families.
|
2021-10-14 05:26:37 +02:00
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-4 ", " \-\-ipv4-only
|
|
|
|
|
Enable IPv4-only operation. IPv6 traffic will be ignored.
|
2024-03-15 13:25:44 +01:00
|
|
|
By default, IPv6 operation is enabled as long as at least an IPv6 route and an
|
|
|
|
|
interface address are configured on a given host interface.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
2023-05-08 18:05:01 +02:00
|
|
|
.BR \-6 ", " \-\-ipv6-only
|
2021-08-19 20:22:40 +02:00
|
|
|
Enable IPv6-only operation. IPv4 traffic will be ignored.
|
2024-03-15 13:25:44 +01:00
|
|
|
By default, IPv4 operation is enabled as long as at least an IPv4 route and an
|
|
|
|
|
interface address are configured on a given host interface.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SS \fBpasst\fR-only options
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-s ", " \-\-socket " " \fIpath
|
|
|
|
|
Path for UNIX domain socket used by \fBqemu\fR(1) or \fBqrap\fR(1) to connect to
|
|
|
|
|
\fBpasst\fR.
|
|
|
|
|
Default is to probe a free socket, not accepting connections, starting from
|
|
|
|
|
\fI/tmp/passt_1.socket\fR to \fI/tmp/passt_64.socket\fR.
|
|
|
|
|
|
2022-11-17 19:49:34 +01:00
|
|
|
.TP
|
|
|
|
|
.BR \-F ", " \-\-fd " " \fIFD
|
|
|
|
|
Pass a pre-opened, connected socket to \fBpasst\fR. Usually the socket is opened
|
|
|
|
|
in the parent process and \fBpasst\fR inherits it when run as a child. This
|
|
|
|
|
allows the parent process to open sockets using another address family or
|
|
|
|
|
requiring special privileges.
|
|
|
|
|
|
|
|
|
|
This option implies the behaviour described for \-\-one-off, once this socket
|
|
|
|
|
is closed.
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
2022-10-07 04:01:56 +02:00
|
|
|
.BR \-1 ", " \-\-one-off
|
|
|
|
|
Quit after handling a single client connection, that is, once the client closes
|
|
|
|
|
the socket, or once we get a socket error.
|
|
|
|
|
|
|
|
|
|
.TP
|
2021-08-19 20:22:40 +02:00
|
|
|
.BR \-t ", " \-\-tcp-ports " " \fIspec
|
|
|
|
|
Configure TCP port forwarding to guest. \fIspec\fR can be one of:
|
|
|
|
|
.RS
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR none
|
|
|
|
|
Don't forward any ports
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR all
|
|
|
|
|
Forward all unbound, non-ephemeral ports, as permitted by current capabilities.
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
For low (< 1024) ports, see \fBNOTES\fR. No failures are reported for
|
|
|
|
|
unavailable ports, unless no ports could be forwarded at all.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR ports
|
|
|
|
|
A comma-separated list of ports, optionally ranged with \fI-\fR, and,
|
2022-05-01 06:36:34 +02:00
|
|
|
optionally, with target ports after \fI:\fR, if they differ. Specific addresses
|
2022-10-07 04:53:40 +02:00
|
|
|
can be bound as well, separated by \fI/\fR, and also, since Linux 5.7, limited
|
|
|
|
|
to specific interfaces, prefixed by \fI%\fR. Within given ranges, selected ports
|
2022-07-13 08:05:01 +02:00
|
|
|
and ranges can be excluded by an additional specification prefixed by \fI~\fR.
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
|
|
|
|
|
Specifying excluded ranges only implies that all other ports are forwarded. In
|
|
|
|
|
this case, no failures are reported for unavailable ports, unless no ports could
|
|
|
|
|
be forwarded at all.
|
|
|
|
|
|
2022-07-13 08:05:01 +02:00
|
|
|
Examples:
|
2021-08-19 20:22:40 +02:00
|
|
|
.RS
|
|
|
|
|
.TP
|
|
|
|
|
-t 22
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward local port 22 to port 22 on the guest
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
|
|
|
|
-t 22:23
|
|
|
|
|
Forward local port 22 to port 23 on the guest
|
|
|
|
|
.TP
|
|
|
|
|
-t 22,25
|
|
|
|
|
Forward local ports 22 and 25 to ports 22 and 25 on the guest
|
|
|
|
|
.TP
|
|
|
|
|
-t 22-80
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward local ports between 22 and 80 to corresponding ports on the guest
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
2023-02-16 02:00:47 +01:00
|
|
|
-t 22-80:32-90
|
|
|
|
|
Forward local ports between 22 and 80 to ports between 32 and 90 on the guest
|
2022-05-01 06:36:34 +02:00
|
|
|
.TP
|
|
|
|
|
-t 192.0.2.1/22
|
|
|
|
|
Forward local port 22, bound to 192.0.2.1, to port 22 on the guest
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
2022-10-07 04:53:40 +02:00
|
|
|
-t 192.0.2.1%eth0/22
|
|
|
|
|
Forward local port 22, bound to 192.0.2.1 and interface eth0, to port 22
|
|
|
|
|
.TP
|
2023-03-27 19:35:26 +02:00
|
|
|
-t %eth0/22
|
|
|
|
|
Forward local port 22, bound to any address on interface eth0, to port 22
|
|
|
|
|
.TP
|
2022-07-13 08:05:01 +02:00
|
|
|
-t 2000-5000,~3000-3010
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward local ports between 2000 and 5000, except for those between 3000 and
|
|
|
|
|
3010
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
|
|
|
|
-t 192.0.2.1/20-30,~25
|
2023-02-16 02:00:47 +01:00
|
|
|
For the local address 192.0.2.1, forward ports between 20 and 24 and between 26
|
|
|
|
|
and 30
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
|
|
|
|
-t ~20000-20010
|
|
|
|
|
Forward all ports to the guest, except for the range from 20000 to 20010
|
2021-08-19 20:22:40 +02:00
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
Default is \fBnone\fR.
|
|
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-u ", " \-\-udp-ports " " \fIspec
|
|
|
|
|
Configure UDP port forwarding to guest. \fIspec\fR is as described for TCP
|
|
|
|
|
above.
|
|
|
|
|
|
|
|
|
|
Note: unless overridden, UDP ports with numbers corresponding to forwarded TCP
|
|
|
|
|
port numbers are forwarded too, without, however, any port translation. IPv6
|
|
|
|
|
bound ports are also forwarded for IPv4.
|
|
|
|
|
|
|
|
|
|
Default is \fBnone\fR.
|
|
|
|
|
|
|
|
|
|
.SS \fBpasta\fR-only options
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-I ", " \-\-ns-ifname " " \fIname
|
|
|
|
|
Name of tap interface to be created in target namespace.
|
|
|
|
|
By default, the same interface name as the external, routable interface is used.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-t ", " \-\-tcp-ports " " \fIspec
|
|
|
|
|
Configure TCP port forwarding to namespace. \fIspec\fR can be one of:
|
|
|
|
|
.RS
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR none
|
|
|
|
|
Don't forward any ports
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR auto
|
2021-09-27 05:24:30 +02:00
|
|
|
Dynamically forward ports bound in the namespace. The list of ports is
|
|
|
|
|
periodically derived (every second) from listening sockets reported by
|
|
|
|
|
\fI/proc/net/tcp\fR and \fI/proc/net/tcp6\fR, see \fBproc\fR(5).
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR ports
|
|
|
|
|
A comma-separated list of ports, optionally ranged with \fI-\fR, and,
|
2022-05-01 06:36:34 +02:00
|
|
|
optionally, with target ports after \fI:\fR, if they differ. Specific addresses
|
2022-10-07 04:53:40 +02:00
|
|
|
can be bound as well, separated by \fI/\fR, and also, since Linux 5.7, limited
|
|
|
|
|
to specific interfaces, prefixed by \fI%\fR. Within given ranges, selected ports
|
2022-07-13 08:05:01 +02:00
|
|
|
and ranges can be excluded by an additional specification prefixed by \fI~\fR.
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
|
|
|
|
|
Specifying excluded ranges only implies that all other ports are forwarded. In
|
|
|
|
|
this case, no failures are reported for unavailable ports, unless no ports could
|
|
|
|
|
be forwarded at all.
|
|
|
|
|
|
2022-07-13 08:05:01 +02:00
|
|
|
Examples:
|
2021-08-19 20:22:40 +02:00
|
|
|
.RS
|
|
|
|
|
.TP
|
|
|
|
|
-t 22
|
|
|
|
|
Forward local port 22 to 22 in the target namespace
|
|
|
|
|
.TP
|
|
|
|
|
-t 22:23
|
|
|
|
|
Forward local port 22 to port 23 in the target namespace
|
|
|
|
|
.TP
|
|
|
|
|
-t 22,25
|
|
|
|
|
Forward local ports 22 and 25 to ports 22 and 25 in the target namespace
|
|
|
|
|
.TP
|
|
|
|
|
-t 22-80
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward local ports between 22 and 80 to corresponding ports in the target
|
|
|
|
|
namespace
|
2021-08-19 20:22:40 +02:00
|
|
|
.TP
|
2023-02-16 02:00:47 +01:00
|
|
|
-t 22-80:32-90
|
|
|
|
|
Forward local ports between 22 and 80 to ports between 32 and 90 in the target
|
2021-08-19 20:22:40 +02:00
|
|
|
namespace
|
2022-05-01 06:36:34 +02:00
|
|
|
.TP
|
|
|
|
|
-t 192.0.2.1/22
|
|
|
|
|
Forward local port 22, bound to 192.0.2.1, to port 22 in the target namespace
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
2022-10-07 04:53:40 +02:00
|
|
|
-t 192.0.2.1%eth0/22
|
|
|
|
|
Forward local port 22, bound to 192.0.2.1 and interface eth0, to port 22
|
|
|
|
|
.TP
|
2023-03-27 19:35:26 +02:00
|
|
|
-t %eth0/22
|
|
|
|
|
Forward local port 22, bound to any address on interface eth0, to port 22
|
|
|
|
|
.TP
|
2022-07-13 08:05:01 +02:00
|
|
|
-t 2000-5000,~3000-3010
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward local ports between 2000 and 5000, except for those between 3000 and
|
|
|
|
|
3010
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
|
|
|
|
-t 192.0.2.1/20-30,~25
|
2023-02-16 02:00:47 +01:00
|
|
|
For the local address 192.0.2.1, forward ports between 20 and 24 and between 26
|
|
|
|
|
and 30
|
2022-07-13 08:05:01 +02:00
|
|
|
.TP
|
|
|
|
|
-t ~20000-20010
|
2023-02-16 02:00:47 +01:00
|
|
|
Forward all ports to the namespace, except for those between 20000 and 20010
|
2021-08-19 20:22:40 +02:00
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
IPv6 bound ports are also forwarded for IPv4.
|
|
|
|
|
|
|
|
|
|
Default is \fBauto\fR.
|
|
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-u ", " \-\-udp-ports " " \fIspec
|
2021-09-27 05:24:30 +02:00
|
|
|
Configure UDP port forwarding to namespace. \fIspec\fR is as described for TCP
|
2021-08-19 20:22:40 +02:00
|
|
|
above, and the list of ports is derived from listening sockets reported by
|
2023-11-15 06:25:34 +01:00
|
|
|
\fI/proc/net/udp\fR and \fI/proc/net/udp6\fR, see \fBproc\fR(5).
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Note: unless overridden, UDP ports with numbers corresponding to forwarded TCP
|
|
|
|
|
port numbers are forwarded too, without, however, any port translation.
|
|
|
|
|
|
|
|
|
|
IPv6 bound ports are also forwarded for IPv4.
|
|
|
|
|
|
|
|
|
|
Default is \fBauto\fR.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-T ", " \-\-tcp-ns " " \fIspec
|
|
|
|
|
Configure TCP port forwarding from target namespace to init namespace.
|
2021-09-27 05:24:30 +02:00
|
|
|
\fIspec\fR is as described above for TCP.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Default is \fBauto\fR.
|
|
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-U ", " \-\-udp-ns " " \fIspec
|
|
|
|
|
Configure UDP port forwarding from target namespace to init namespace.
|
2021-09-27 05:24:30 +02:00
|
|
|
\fIspec\fR is as described above for UDP.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Default is \fBauto\fR.
|
|
|
|
|
|
2021-09-29 16:11:06 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-userns " " \fIspec
|
2022-08-26 06:58:34 +02:00
|
|
|
Target user namespace to join, as a path. If PID is given, without this option,
|
|
|
|
|
the user namespace will be the one of the corresponding process.
|
2021-09-29 16:11:06 +02:00
|
|
|
|
2022-08-26 06:58:38 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-netns " " \fIspec
|
|
|
|
|
Target network namespace to join, as a path or a name. A name is treated as
|
|
|
|
|
with \fBip-netns(8)\fR as equivalent to a path in \fI/run/netns\fR.
|
|
|
|
|
|
|
|
|
|
This option can't be specified with a PID.
|
2021-09-29 16:11:06 +02:00
|
|
|
|
|
|
|
|
.TP
|
|
|
|
|
.BR \-\-netns-only
|
passt, pasta: Namespace-based sandboxing, defer seccomp policy application
To reach (at least) a conceptually equivalent security level as
implemented by --enable-sandbox in slirp4netns, we need to create a
new mount namespace and pivot_root() into a new (empty) mountpoint, so
that passt and pasta can't access any filesystem resource after
initialisation.
While at it, also detach IPC, PID (only for passt, to prevent
vulnerabilities based on the knowledge of a target PID), and UTS
namespaces.
With this approach, if we apply the seccomp filters right after the
configuration step, the number of allowed syscalls grows further. To
prevent this, defer the application of seccomp policies after the
initialisation phase, before the main loop, that's where we expect bad
things to happen, potentially. This way, we get back to 22 allowed
syscalls for passt and 34 for pasta, on x86_64.
While at it, move #syscalls notes to specific code paths wherever it
conceptually makes sense.
We have to open all the file handles we'll ever need before
sandboxing:
- the packet capture file can only be opened once, drop instance
numbers from the default path and use the (pre-sandbox) PID instead
- /proc/net/tcp{,v6} and /proc/net/udp{,v6}, for automatic detection
of bound ports in pasta mode, are now opened only once, before
sandboxing, and their handles are stored in the execution context
- the UNIX domain socket for passt is also bound only once, before
sandboxing: to reject clients after the first one, instead of
closing the listening socket, keep it open, accept and immediately
discard new connection if we already have a valid one
Clarify the (unchanged) behaviour for --netns-only in the man page.
To actually make passt and pasta processes run in a separate PID
namespace, we need to unshare(CLONE_NEWPID) before forking to
background (if configured to do so). Introduce a small daemon()
implementation, __daemon(), that additionally saves the PID file
before forking. While running in foreground, the process itself can't
move to a new PID namespace (a process can't change the notion of its
own PID): mention that in the man page.
For some reason, fork() in a detached PID namespace causes SIGTERM
and SIGQUIT to be ignored, even if the handler is still reported as
SIG_DFL: add a signal handler that just exits.
We can now drop most of the pasta_child_handler() implementation,
that took care of terminating all processes running in the same
namespace, if pasta started a shell: the shell itself is now the
init process in that namespace, and all children will terminate
once the init process exits.
Issuing 'echo $$' in a detached PID namespace won't return the
actual namespace PID as seen from the init namespace: adapt
demo and test setup scripts to reflect that.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-07 21:11:37 +01:00
|
|
|
Join only a target network namespace, not a user namespace, and don't create one
|
|
|
|
|
for sandboxing purposes either. This is implied if PATH or NAME are given
|
|
|
|
|
without \-\-userns.
|
2021-09-29 16:11:06 +02:00
|
|
|
|
2022-02-18 16:12:11 +01:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-netns-quit
|
pasta: Don't try to watch namespaces in procfs with inotify, use timer instead
We watch network namespace entries to detect when we should quit
(unless --no-netns-quit is passed), and these might stored in a tmpfs
typically mounted at /run/user/UID or /var/run/user/UID, or found in
procfs at /proc/PID/ns/.
Currently, we try to use inotify for any possible location of those
entries, but inotify, of course, doesn't work on pseudo-filesystems
(see inotify(7)).
The man page reflects this: the description of --no-netns-quit
implies that we won't quit anyway if the namespace is not "bound to
the filesystem".
Well, we won't quit, but, since commit 9e0dbc894813 ("More
deterministic detection of whether argument is a PID, PATH or NAME"),
we try. And, indeed, this is harmless, as the caveat from that
commit message states.
Now, it turns out that Buildah, a tool to create container images,
sharing its codebase with Podman, passes a procfs entry to pasta, and
expects pasta to exit once the network namespace is not needed
anymore, that is, once the original container process, also spawned
by Buildah, terminates.
Get this to work by using the timer fallback mechanism if the
namespace name is passed as a path belonging to a pseudo-filesystem.
This is expected to be procfs, but I covered sysfs and devpts
pseudo-filesystems as well, because nothing actually prevents
creating this kind of directory structure and links there.
Note that fstatfs(), according to some versions of man pages, was
apparently "deprecated" by the LSB. My reasoning for using it is
essentially this:
https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u
...that is, there was no such thing as an LSB deprecation, and
anyway there's no other way to get the filesystem type.
Also note that, while it might sound more obvious to detect the
filesystem type using fstatfs() on the file descriptor itself
(c->pasta_netns_fd), the reported filesystem type for it is nsfs, no
matter what path was given to pasta. If we use the parent directory,
we'll typically have either tmpfs or procfs reported.
If the target namespace is given as a PID, or as a PID-based procfs
entry, we don't risk races if this PID is recycled: our handle on
/proc/PID/ns will always refer to the original namespace associated
with that PID, and we don't re-open this entry from procfs to check
it.
There's, however, a remaining race possibility if the parent process
is not the one associated to the network namespace we operate on: in
that case, the parent might pass a procfs entry associated to a PID
that was recycled by the time we parse it. This can't happen if the
namespace PID matches the one of the parent, because we detach from
the controlling terminal after parsing the namespace reference.
To avoid this type of race, if desired, we could add the option for
the parent to pass a PID file descriptor, that the parent obtained
via pidfd_open(). This is beyond the scope of this change.
Update the man page to reflect that, even if the target network
namespace is passed as a procfs path or a PID, we'll now quit when
the procfs entry is gone.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1948200214
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-02-17 13:41:39 +01:00
|
|
|
Do not exit once the target namespace reference is removed.
|
|
|
|
|
|
|
|
|
|
Without this option, \fBpasta\fR will terminate if the target network namespace
|
|
|
|
|
is bound to the filesystem, and the given path is deleted, or if the target
|
|
|
|
|
network namespace is represented by a procfs entry, and that entry is deleted,
|
|
|
|
|
representing the fact that a process with the given PID terminated.
|
2022-02-18 16:12:11 +01:00
|
|
|
|
2021-10-11 12:01:31 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-config-net
|
|
|
|
|
Configure networking in the namespace: set up addresses and routes as configured
|
2022-02-23 13:22:08 +01:00
|
|
|
or sourced from the host, and bring up the tap interface.
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2023-05-14 15:04:38 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-copy-routes " " (DEPRECATED)
|
|
|
|
|
With \-\-config-net, do not copy all the routes associated to the interface we
|
|
|
|
|
derive addresses and routes from: set up only the default gateway. Implied by
|
|
|
|
|
-g, \-\-gateway.
|
|
|
|
|
|
|
|
|
|
Default is to copy all the routing entries from the interface in the outer
|
|
|
|
|
namespace to the target namespace, translating the output interface attribute to
|
|
|
|
|
the outbound interface in the namespace.
|
|
|
|
|
|
|
|
|
|
Note that this configuration option is \fBdeprecated\fR and will be removed in a
|
|
|
|
|
future version. It is not expected to be of any use, and it simply reflects a
|
|
|
|
|
legacy behaviour. If you have any use for this, refer to \fBREPORTING BUGS\fR
|
|
|
|
|
below.
|
|
|
|
|
|
2023-05-14 19:12:09 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-no-copy-addrs " " (DEPRECATED)
|
|
|
|
|
With \-\-config-net, do not copy all the addresses associated to the interface
|
|
|
|
|
we derive addresses and routes from: set up a single one. Implied by \-a,
|
|
|
|
|
\-\-address.
|
|
|
|
|
|
|
|
|
|
Default is to copy all the addresses, except for link-local ones, from the
|
|
|
|
|
interface from the outer namespace to the target namespace.
|
|
|
|
|
|
|
|
|
|
Note that this configuration option is \fBdeprecated\fR and will be removed in a
|
|
|
|
|
future version. It is not expected to be of any use, and it simply reflects a
|
|
|
|
|
legacy behaviour. If you have any use for this, refer to \fBREPORTING BUGS\fR
|
|
|
|
|
below.
|
|
|
|
|
|
2021-10-11 12:01:31 +02:00
|
|
|
.TP
|
|
|
|
|
.BR \-\-ns-mac-addr " " \fIaddr
|
|
|
|
|
Configure MAC address \fIaddr\fR on the tap interface in the namespace.
|
|
|
|
|
|
|
|
|
|
Default is to let the tap driver build a pseudorandom hardware address.
|
|
|
|
|
|
2021-08-19 20:22:40 +02:00
|
|
|
.SH EXAMPLES
|
|
|
|
|
|
|
|
|
|
.SS \fBpasta
|
|
|
|
|
.BR "Create and use a new, connected, user and network namespace"
|
|
|
|
|
.RS
|
|
|
|
|
.nf
|
|
|
|
|
$ iperf3 -s -D
|
|
|
|
|
$ ./pasta
|
|
|
|
|
Outbound interface: eth0, namespace interface: eth0
|
|
|
|
|
ARP:
|
|
|
|
|
address: 28:16:ad:39:a9:ea
|
|
|
|
|
DHCP:
|
|
|
|
|
assign: 192.168.1.118
|
|
|
|
|
mask: 255.255.255.0
|
|
|
|
|
router: 192.168.1.1
|
|
|
|
|
NDP/DHCPv6:
|
|
|
|
|
assign: 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17
|
|
|
|
|
router: fe80::62e3:27ff:fe33:2b01
|
|
|
|
|
#
|
2022-06-10 04:32:44 +02:00
|
|
|
# dhclient -4 --no-pid
|
2022-06-10 04:32:43 +02:00
|
|
|
# dhclient -6 --no-pid
|
2021-08-19 20:22:40 +02:00
|
|
|
# ip address show
|
|
|
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
|
|
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
|
|
|
|
inet 127.0.0.1/8 scope host lo
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 ::1/128 scope host
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN group default qlen 1000
|
|
|
|
|
link/ether 5e:90:02:eb:b0:2a brd ff:ff:ff:ff:ff:ff
|
|
|
|
|
inet 192.168.1.118/24 brd 192.168.1.255 scope global eth0
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17/128 scope global
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:5c90:2ff:feeb:b02a/64 scope global dynamic mngtmpaddr
|
|
|
|
|
valid_lft 3591sec preferred_lft 3591sec
|
|
|
|
|
inet6 fe80::5c90:2ff:feeb:b02a/64 scope link
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
# ip route show
|
|
|
|
|
default via 192.168.1.1 dev eth0
|
|
|
|
|
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.118
|
|
|
|
|
# ip -6 route show
|
|
|
|
|
2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17 dev eth0 proto kernel metric 256 pref medium
|
|
|
|
|
2a02:6d40:3ca5:2001::/64 dev eth0 proto kernel metric 256 expires 3584sec pref medium
|
|
|
|
|
fe80::/64 dev eth0 proto kernel metric 256 pref medium
|
|
|
|
|
default via fe80::62e3:27ff:fe33:2b01 dev eth0 proto ra metric 1024 expires 3584sec pref medium
|
|
|
|
|
# iperf3 -c 127.0.0.1 -t1
|
|
|
|
|
Connecting to host 127.0.0.1, port 5201
|
|
|
|
|
[ 5] local 127.0.0.1 port 51938 connected to 127.0.0.1 port 5201
|
|
|
|
|
[ ID] Interval Transfer Bitrate Retr Cwnd
|
|
|
|
|
[ 5] 0.00-1.00 sec 4.46 GBytes 38.3 Gbits/sec 0 3.93 MBytes
|
|
|
|
|
- - - - - - - - - - - - - - - - - - - - - - - - -
|
|
|
|
|
[ ID] Interval Transfer Bitrate Retr
|
|
|
|
|
[ 5] 0.00-1.00 sec 4.46 GBytes 38.3 Gbits/sec 0 sender
|
|
|
|
|
[ 5] 0.00-1.41 sec 4.45 GBytes 27.1 Gbits/sec receiver
|
|
|
|
|
|
|
|
|
|
iperf Done.
|
|
|
|
|
# iperf3 -c ::1 -t1
|
|
|
|
|
Connecting to host ::1, port 5201
|
|
|
|
|
[ 5] local ::1 port 50108 connected to ::1 port 5201
|
|
|
|
|
[ ID] Interval Transfer Bitrate Retr Cwnd
|
|
|
|
|
[ 5] 0.00-1.00 sec 4.35 GBytes 37.4 Gbits/sec 0 4.99 MBytes
|
|
|
|
|
- - - - - - - - - - - - - - - - - - - - - - - - -
|
|
|
|
|
[ ID] Interval Transfer Bitrate Retr
|
|
|
|
|
[ 5] 0.00-1.00 sec 4.35 GBytes 37.4 Gbits/sec 0 sender
|
|
|
|
|
[ 5] 0.00-1.41 sec 4.35 GBytes 26.4 Gbits/sec receiver
|
|
|
|
|
|
|
|
|
|
iperf Done.
|
|
|
|
|
# ping -c1 -4 spaghetti.pizza
|
|
|
|
|
PING spaghetti.pizza (172.67.192.217) 56(84) bytes of data.
|
|
|
|
|
64 bytes from 172.67.192.217: icmp_seq=1 ttl=255 time=37.3 ms
|
|
|
|
|
|
|
|
|
|
--- spaghetti.pizza ping statistics ---
|
|
|
|
|
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
|
|
|
|
# ping -c1 -6 spaghetti.pizza
|
|
|
|
|
PING spaghetti.pizza(2606:4700:3034::6815:147a (2606:4700:3034::6815:147a)) 56 data bytes
|
|
|
|
|
64 bytes from 2606:4700:3034::6815:147a: icmp_seq=1 ttl=255 time=35.6 ms
|
|
|
|
|
|
|
|
|
|
--- spaghetti.pizza ping statistics ---
|
|
|
|
|
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
|
|
|
|
rtt min/avg/max/mdev = 35.605/35.605/35.605/0.000 ms
|
|
|
|
|
# logout
|
|
|
|
|
$
|
|
|
|
|
|
|
|
|
|
.RE
|
|
|
|
|
.fi
|
|
|
|
|
|
|
|
|
|
.BR "Connect an existing user and network namespace"
|
|
|
|
|
.RS
|
|
|
|
|
.nf
|
|
|
|
|
$ unshare -rUn
|
|
|
|
|
# echo $$
|
|
|
|
|
2446678
|
|
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [From another terminal]"
|
|
|
|
|
.nf
|
|
|
|
|
$ ./pasta 2446678
|
|
|
|
|
Outbound interface: eth0, namespace interface: eth0
|
|
|
|
|
ARP:
|
|
|
|
|
address: 28:16:ad:39:a9:ea
|
|
|
|
|
DHCP:
|
|
|
|
|
assign: 192.168.1.118
|
|
|
|
|
mask: 255.255.255.0
|
|
|
|
|
router: 192.168.1.1
|
|
|
|
|
NDP/DHCPv6:
|
|
|
|
|
assign: 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17
|
|
|
|
|
router: fe80::62e3:27ff:fe33:2b01
|
|
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [Back to the original terminal]"
|
|
|
|
|
.nf
|
2022-06-10 04:32:44 +02:00
|
|
|
# dhclient -4 --no-pid
|
2022-06-10 04:32:43 +02:00
|
|
|
# dhclient -6 --no-pid
|
2021-08-19 20:22:40 +02:00
|
|
|
# ip address show
|
|
|
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
|
|
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
|
|
|
|
inet 127.0.0.1/8 scope host lo
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 ::1/128 scope host
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN group default qlen 1000
|
|
|
|
|
link/ether fa:c1:2a:27:92:a9 brd ff:ff:ff:ff:ff:ff
|
|
|
|
|
inet 192.168.1.118/24 brd 192.168.1.255 scope global eth0
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17/128 scope global
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:f8c1:2aff:fe27:92a9/64 scope global dynamic mngtmpaddr
|
|
|
|
|
valid_lft 3594sec preferred_lft 3594sec
|
|
|
|
|
inet6 fe80::f8c1:2aff:fe27:92a9/64 scope link
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
.fi
|
|
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
.SS \fBpasst
|
|
|
|
|
.BR "Start and connect a guest with basic port forwarding"
|
|
|
|
|
.RS
|
|
|
|
|
.nf
|
|
|
|
|
$ ./passt -f -t 2222:22
|
|
|
|
|
Outbound interface: eth0
|
|
|
|
|
ARP:
|
|
|
|
|
address: 28:16:ad:39:a9:ea
|
|
|
|
|
DHCP:
|
|
|
|
|
assign: 192.168.1.118
|
|
|
|
|
mask: 255.255.255.0
|
|
|
|
|
router: 192.168.1.1
|
|
|
|
|
search:
|
|
|
|
|
redhat.com
|
|
|
|
|
NDP/DHCPv6:
|
|
|
|
|
assign: 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17
|
|
|
|
|
router: fe80::62e3:27ff:fe33:2b01
|
|
|
|
|
search:
|
|
|
|
|
redhat.com
|
|
|
|
|
UNIX domain socket bound at /tmp/passt_1.socket
|
|
|
|
|
|
|
|
|
|
You can now start qrap:
|
2022-07-06 09:28:58 +02:00
|
|
|
./qrap 5 qemu-system-x86_64 ... -net socket,fd=5 -net nic,model=virtio
|
2021-08-19 20:22:40 +02:00
|
|
|
or directly qemu, patched with:
|
|
|
|
|
qemu/0001-net-Allow-also-UNIX-domain-sockets-to-be-used-as-net.patch
|
|
|
|
|
as follows:
|
2022-07-06 09:28:58 +02:00
|
|
|
qemu-system-x86_64 ... -net socket,connect=/tmp/passt_1.socket -net nic,model=virtio
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [From another terminal]"
|
|
|
|
|
.nf
|
2022-07-06 09:28:58 +02:00
|
|
|
$ ./qrap 5 qemu-system-x86_64 test.qcow2 -m 1024 -display none -nodefaults -nographic -net socket,fd=5 -net nic,model=virtio
|
2021-08-19 20:22:40 +02:00
|
|
|
Connected to /tmp/passt_1.socket
|
|
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [Back to the original terminal]"
|
|
|
|
|
.nf
|
|
|
|
|
passt: DHCP: ack to request
|
|
|
|
|
passt: from 52:54:00:12:34:56
|
|
|
|
|
passt: NDP: received NS, sending NA
|
|
|
|
|
passt: NDP: received RS, sending RA
|
|
|
|
|
passt: DHCPv6: received SOLICIT, sending ADVERTISE
|
|
|
|
|
passt: NDP: received NS, sending NA
|
|
|
|
|
passt: DHCPv6: received REQUEST/RENEW/CONFIRM, sending REPLY
|
|
|
|
|
passt: NDP: received NS, sending NA
|
|
|
|
|
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [From yet another terminal]"
|
|
|
|
|
.nf
|
|
|
|
|
$ ssh -p 2222 root@localhost
|
|
|
|
|
root@localhost's password:
|
|
|
|
|
.fi
|
|
|
|
|
.BR " [...]"
|
|
|
|
|
.nf
|
|
|
|
|
# ip address show
|
|
|
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
|
|
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
|
|
|
|
inet 127.0.0.1/8 scope host lo
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 ::1/128 scope host
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UP group default qlen 1000
|
|
|
|
|
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
|
|
|
|
|
inet 192.168.1.118/24 brd 192.168.1.255 scope global noprefixroute ens2
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:b81d:fa4a:8cdd:cf17/128 scope global noprefixroute
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
inet6 2a02:6d40:3ca5:2001:b019:9ae2:a2fe:e6b4/64 scope global dynamic noprefixroute
|
|
|
|
|
valid_lft 3588sec preferred_lft 3588sec
|
|
|
|
|
inet6 fe80::1f98:d09f:9309:9e77/64 scope link noprefixroute
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
.fi
|
|
|
|
|
.RE
|
|
|
|
|
|
|
|
|
|
.SH NOTES
|
|
|
|
|
|
2022-10-27 14:28:00 +02:00
|
|
|
.SS Handling of traffic with local destination and source addresses
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Both \fBpasst\fR and \fBpasta\fR can bind on ports with a local address,
|
|
|
|
|
depending on the configuration. Local destination or source addresses need to be
|
|
|
|
|
changed before packets are delivered to the guest or target namespace: most
|
|
|
|
|
operating systems would drop packets received from non-loopback interfaces with
|
|
|
|
|
local addresses, and it would also be impossible for guest or target namespace
|
|
|
|
|
to route answers back.
|
|
|
|
|
|
|
|
|
|
For convenience, and somewhat arbitrarily, the source address on these packets
|
2024-03-15 13:25:44 +01:00
|
|
|
is translated to the address of the default IPv4 or IPv6 gateway (if any) --
|
|
|
|
|
this is known to be an existing, valid address on the same subnet.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
Loopback destination addresses are instead translated to the observed external
|
|
|
|
|
address of the guest or target namespace. For IPv6 packets, if usage of a
|
|
|
|
|
link-local address by guest or namespace has ever been observed, and the
|
|
|
|
|
original destination address is also a link-local address, the observed
|
|
|
|
|
link-local address is used. Otherwise, the observed global address is used. For
|
|
|
|
|
both IPv4 and IPv6, if no addresses have been seen yet, the configured addresses
|
|
|
|
|
will be used instead.
|
|
|
|
|
|
|
|
|
|
For example, if \fBpasst\fR or \fBpasta\fR receive a connection from 127.0.0.1,
|
|
|
|
|
with destination 127.0.0.10, and the default IPv4 gateway is 192.0.2.1, while
|
|
|
|
|
the last observed source address from guest or namespace is 192.0.2.2, this will
|
|
|
|
|
be translated to a connection from 192.0.2.1 to 192.0.2.2.
|
|
|
|
|
|
|
|
|
|
Similarly, for traffic coming from guest or namespace, packets with destination
|
|
|
|
|
address corresponding to the default gateway will have their destination address
|
|
|
|
|
translated to a loopback address, if and only if a packet, in the opposite
|
|
|
|
|
direction, with a loopback destination or source address, port-wise matching for
|
|
|
|
|
UDP, or connection-wise for TCP, has been recently forwarded to guest or
|
2021-10-14 05:26:37 +02:00
|
|
|
namespace. This behaviour can be disabled with \-\-no\-map\-gw.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SS Handling of local traffic in pasta
|
|
|
|
|
|
|
|
|
|
Depending on the configuration, \fBpasta\fR can bind to local ports in the init
|
|
|
|
|
namespace, in the target namespace, or both, and forward connections and packets
|
|
|
|
|
to corresponding ports in the other namespace.
|
|
|
|
|
|
|
|
|
|
To avoid unnecessary overhead, these connections and packets are not forwarded
|
|
|
|
|
through the tap device connecting the namespaces: \fBpasta\fR creates a socket
|
|
|
|
|
in the destination namespace, with matching Layer-4 protocol, and uses it to
|
|
|
|
|
forward local data. For TCP, data is forwarded between the originating socket
|
|
|
|
|
and the new socket using the \fBsplice\fR(2) system call, and for UDP, a pair
|
|
|
|
|
of \fBrecvmmsg\fR(2) and \fBsendmmsg\fR(2) system calls deals with packet
|
|
|
|
|
transfers.
|
|
|
|
|
|
|
|
|
|
This bypass only applies to local connections and traffic, because it's not
|
|
|
|
|
possible to bind sockets to foreign addresses.
|
|
|
|
|
|
|
|
|
|
.SS Binding to low numbered ports (well-known or system ports, up to 1023)
|
|
|
|
|
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
If the port forwarding configuration requires binding to ports with numbers
|
|
|
|
|
lower than 1024, \fBpasst\fR and \fBpasta\fR will try to bind to them, but will
|
|
|
|
|
fail, unless, either:
|
|
|
|
|
|
|
|
|
|
.IP \(bu 2
|
|
|
|
|
the \fIsys.net.ipv4.ip_unprivileged_port_start\fR sysctl is set to the number
|
|
|
|
|
of the lowest port \fBpasst\fR and \fBpasta\fR need. For example, as root:
|
|
|
|
|
|
|
|
|
|
.nf
|
|
|
|
|
sysctl -w net.ipv4.ip_unprivileged_port_start=443
|
|
|
|
|
.fi
|
|
|
|
|
|
|
|
|
|
\fBNote\fR: this is the recommended way of enabling \fBpasst\fR and \fBpasta\fR
|
|
|
|
|
to bind to ports with numbers below 1024.
|
|
|
|
|
|
|
|
|
|
.IP \(bu
|
|
|
|
|
or the \fICAP_NET_BIND_SERVICE\fR Linux capability is granted, see
|
|
|
|
|
\fBservices\fR(5) and \fBcapabilities\fR(7).
|
|
|
|
|
|
|
|
|
|
This is, in general, \fBnot the recommended way\fR, because \fBpasst\fR and
|
|
|
|
|
\fBpasta\fR might be used as vector to effectively use this capability from
|
|
|
|
|
another process.
|
|
|
|
|
|
|
|
|
|
However, if your environment is sufficiently controlled by an LSM (Linux
|
|
|
|
|
Security Module) such as \fIAppArmor\fR, \fISELinux\fR, \fISmack\fR or
|
|
|
|
|
\fITOMOYO\fR, and no other processes can interact in such a way in virtue of
|
|
|
|
|
this, granting this capability to \fBpasst\fR and \fBpasta\fR only can
|
|
|
|
|
effectively prevent other processes from utilising it.
|
|
|
|
|
|
|
|
|
|
Note that this will not work for automatic detection and forwarding of ports
|
|
|
|
|
with \fBpasta\fR, because \fBpasta\fR will relinquish this capability at
|
|
|
|
|
runtime.
|
|
|
|
|
|
|
|
|
|
To grant this capability, you can issue, as root:
|
|
|
|
|
|
|
|
|
|
.nf
|
|
|
|
|
for p in $(which passt passt.avx2); do
|
|
|
|
|
setcap 'cap_net_bind_service=+ep' "${p}"
|
|
|
|
|
done
|
|
|
|
|
.fi
|
2021-10-12 23:03:01 +02:00
|
|
|
|
|
|
|
|
.RE
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SS ICMP/ICMPv6 Echo sockets
|
|
|
|
|
|
|
|
|
|
ICMP and ICMPv6 Echo requests coming from guest or target namespace are handled
|
|
|
|
|
using so-called "ping" sockets, introduced in Linux 2.6.30. To preserve the
|
|
|
|
|
original identifier (see RFC 792, page 14, for ICMP, and RFC 4443, section 4.1,
|
|
|
|
|
for ICMPv6), \fBpasst\fR and \fBpasta\fR try to bind these sockets using the
|
|
|
|
|
observed source identifier as "port" -- that corresponds to Echo identifiers
|
|
|
|
|
for "ping" sockets.
|
|
|
|
|
|
|
|
|
|
As \fBbind\fR(2) failures were seen with particularly restrictive SELinux
|
|
|
|
|
policies, a fall-back mechanism maps different identifiers to different sockets,
|
|
|
|
|
and identifiers in replies will be mapped back to the original identifier of the
|
|
|
|
|
request. However, if \fBbind\fR(2) fails and the fall-back mechanism is used,
|
|
|
|
|
echo requests will be forwarded with different, albeit unique, identifiers.
|
|
|
|
|
|
|
|
|
|
For ICMP and ICMPv6 Echo requests to work, the \fIping_group_range\fR parameter
|
|
|
|
|
needs to include the PID of \fBpasst\fR or \fBpasta\fR, see \fBicmp\fR(7).
|
|
|
|
|
|
|
|
|
|
.SS pasta and loopback interface
|
|
|
|
|
|
|
|
|
|
As \fBpasta\fR connects to an existing namespace, or once it creates a new
|
|
|
|
|
namespace, it will also ensure that the loopback interface, \fIlo\fR, is brought
|
|
|
|
|
up. This is needed to bind ports using the loopback address in the namespace.
|
|
|
|
|
|
|
|
|
|
.SS TCP sending window and \fITCP_INFO\fB before Linux 5.3
|
|
|
|
|
|
|
|
|
|
To synchronise the TCP sending window from host Layer-4 sockets to the TCP
|
|
|
|
|
parameters announced in TCP segments sent over the Layer-2 interface,
|
|
|
|
|
\fBpasst\fR and \fBpasta\fR routinely query the size of the sending window seen
|
|
|
|
|
by the kernel on the corresponding socket using the \fITCP_INFO\fR socket
|
|
|
|
|
option, see \fBtcp\fR(7). Before Linux 5.3, i.e. before Linux kernel commit
|
|
|
|
|
8f7baad7f035 ("tcp: Add snd_wnd to TCP_INFO"), the sending window
|
|
|
|
|
(\fIsnd_wnd\fR field) is not available.
|
|
|
|
|
|
2021-10-12 22:56:36 +02:00
|
|
|
If the sending window cannot be queried, it will always be announced as the
|
|
|
|
|
current sending buffer size to guest or target namespace. This might affect
|
|
|
|
|
throughput of TCP connections.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SH LIMITATIONS
|
|
|
|
|
|
|
|
|
|
Currently, IGMP/MLD proxying (RFC 4605) and support for SCTP (RFC 4960) are not
|
|
|
|
|
implemented.
|
|
|
|
|
|
|
|
|
|
TCP Selective Acknowledgment (RFC 2018), as well as Protection Against Wrapped
|
|
|
|
|
Sequences (PAWS) and Round-Trip Time Measurement (RTTM), both described by RFC
|
|
|
|
|
7232, are currently not implemented.
|
|
|
|
|
|
2022-10-13 21:58:13 +02:00
|
|
|
.SH AUTHORS
|
2021-08-19 20:22:40 +02:00
|
|
|
|
2022-10-13 21:58:13 +02:00
|
|
|
Stefano Brivio <sbrivio@redhat.com>, David Gibson <david@gibson.dropbear.id.au>.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SH REPORTING BUGS
|
|
|
|
|
|
2022-02-19 04:39:47 +01:00
|
|
|
Please report issues on the bug tracker at https://passt.top/passt/bugs, or
|
|
|
|
|
send a message to the passt-user@passt.top mailing list, see
|
|
|
|
|
https://passt.top/passt/lists.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
.SH COPYRIGHT
|
|
|
|
|
|
2022-02-19 04:39:47 +01:00
|
|
|
Copyright (c) 2020-2022 Red Hat GmbH.
|
2021-08-19 20:22:40 +02:00
|
|
|
|
|
|
|
|
\fBpasst\fR and \fBpasta\fR are free software: you can redistribute them and/or
|
2024-06-19 11:40:55 +02:00
|
|
|
modify them under the terms of the GNU General Public License as
|
|
|
|
|
published by the Free Software Foundation, either version 2 of the License, or
|
2021-08-19 20:22:40 +02:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
.SH SEE ALSO
|
|
|
|
|
|
|
|
|
|
\fBnamespaces\fR(7), \fBqemu\fR(1), \fBqrap\fR(1), \fBslirp4netns\fR(1).
|
|
|
|
|
|
|
|
|
|
High-level documentation is available at https://passt.top/passt/about/.
|