opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-10-29 00:38:34 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
podman/docs/source/markdown/options/network.md
Stefano Brivio aa47e05ae4 libpod: Add pasta networking mode 
Conceptually equivalent to networking by means of slirp4netns(1),
with a few practical differences:

- pasta(1) forks to background once networking is configured in the
  namespace and quits on its own once the namespace is deleted:
  file descriptor synchronisation and PID tracking are not needed

- port forwarding is configured via command line options at start-up,
  instead of an API socket: this is taken care of right away as we're
  about to start pasta

- there's no need for further selection of port forwarding modes:
  pasta behaves similarly to containers-rootlessport for local binds
  (splice() instead of read()/write() pairs, without L2-L4
  translation), and keeps the original source address for non-local
  connections like slirp4netns does

- IPv6 is not an experimental feature, and enabled by default. IPv6
  port forwarding is supported

- by default, addresses and routes are copied from the host, that is,
  container users will see the same IP address and routes as if they
  were in the init namespace context. The interface name is also
  sourced from the host upstream interface with the first default
  route in the routing table. This is also configurable as documented

- sandboxing and seccomp(2) policies cannot be disabled

- only rootless mode is supported.

See https://passt.top for more details about pasta.

Also add a link to the maintained build of pasta(1) manual as valid
in the man page cross-reference checks: that's where the man page
for the latest build actually is -- it's not on Github and it doesn't
match any existing pattern, so add it explicitly.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-11-08 00:16:35 +01:00

6.1 KiB
Raw Blame History

####> This option file is used in: ####> podman create, kube play, pod create, run ####> If you edit this file, make sure your changes ####> are applicable to all of those.

--network=mode, --net

Set the network mode for the <<container|pod>>.

Valid mode values are:

  • bridge[:OPTIONS,...]: Create a network stack on the default bridge. This is the default for rootful containers. It is possible to specify these additional options:

    • alias=name: Add network-scoped alias for the container.

    • ip=IPv4: Specify a static ipv4 address for this container.

    • ip=IPv6: Specify a static ipv6 address for this container.

    • mac=MAC: Specify a static mac address for this container.

    • interface_name: Specify a name for the created network interface inside the container.

      For example to set a static ipv4 address and a static mac address, use --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99.

  • <network name or ID>[:OPTIONS,...]: Connect to a user-defined network; this is the network name or ID from a network created by podman network create. Using the network name implies the bridge network mode. It is possible to specify the same options described under the bridge mode above. You can use the --network option multiple times to specify additional networks.

  • none: Create a network namespace for the container but do not configure network interfaces for it, thus the container has no network connectivity.

  • container:id: Reuse another container's network stack.

  • host: Do not create a network namespace, the container will use the host's network. Note: The host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.

  • ns:path: Path to a network namespace to join.

  • private: Create a new namespace for the container. This will use the bridge mode for rootful containers and slirp4netns for rootless ones.

  • slirp4netns[:OPTIONS,...]: use slirp4netns(1) to create a user network stack. This is the default for rootless containers. It is possible to specify these additional options, they can also be set with network_cmd_options in containers.conf:

    • allow_host_loopback=true|false: Allow slirp4netns to reach the host loopback IP (default is 10.0.2.2 or the second IP from slirp4netns cidr subnet when changed, see the cidr option below). The default is false.
    • mtu=MTU: Specify the MTU to use for this network. (Default is 65520).
    • cidr=CIDR: Specify ip range to use for this network. (Default is 10.0.2.0/24).
    • enable_ipv6=true|false: Enable IPv6. Default is true. (Required for outbound_addr6).
    • outbound_addr=INTERFACE: Specify the outbound interface slirp should bind to (ipv4 traffic only).
    • outbound_addr=IPv4: Specify the outbound ipv4 address slirp should bind to.
    • outbound_addr6=INTERFACE: Specify the outbound interface slirp should bind to (ipv6 traffic only).
    • outbound_addr6=IPv6: Specify the outbound ipv6 address slirp should bind to.
    • port_handler=rootlesskit: Use rootlesskit for port forwarding. Default. Note: Rootlesskit changes the source IP address of incoming packets to an IP address in the container network namespace, usually 10.0.2.100. If your application requires the real source IP address, e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for rootless containers when connected to user-defined networks.
    • port_handler=slirp4netns: Use the slirp4netns port forwarding, it is slower than rootlesskit but preserves the correct source IP address. This port handler cannot be used for user-defined networks.

  • pasta[:OPTIONS,...]: use pasta(1) to create a user-mode networking stack.
    This is only supported in rootless mode.
    By default, IPv4 and IPv6 addresses and routes, as well as the pod interface name, are copied from the host. If port forwarding isn't configured, ports will be forwarded dynamically as services are bound on either side (init namespace or container namespace). Port forwarding preserves the original source IP address. Options described in pasta(1) can be specified as comma-separated arguments.
    In terms of pasta(1) options, --config-net is given by default, in order to configure networking when the container is started, and --no-map-gw is also assumed by default, to avoid direct access from container to host using the gateway address. The latter can be overridden by passing --map-gw in the pasta-specific options (despite not being an actual pasta(1) option).
    Also, -t none and -u none are passed if, respectively, no TCP or UDP port forwarding from host to container is configured, to disable automatic port forwarding based on bound ports. Similarly, -T none and -U none are given to disable the same functionality from container to host.
    Some examples:

    • pasta:--map-gw: Allow the container to directly reach the host using the gateway address.
    • pasta:--mtu,1500: Specify a 1500 bytes MTU for the tap interface in the container.
    • pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options: disable IPv6, assign 10.0.2.0/24 to the tap0 interface in the container, with gateway 10.0.2.3, enable DNS forwarder reachable at 10.0.2.3, set MTU to 1500 bytes, disable NDP, DHCPv6 and DHCP support.
    • pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options with Podman overrides: same as above, but leave the MTU to 65520 bytes
    • pasta:-t,auto,-u,auto,-T,auto,-U,auto: enable automatic port forwarding based on observed bound ports from both host and container sides
    • pasta:-T,5201: enable forwarding of TCP port 5201 from container to host, using the loopback interface instead of the tap interface for improved performance