Add file handle attachment support#759
Conversation
Adds BridgedNetworkInterface, which uses VZBridgedNetworkDeviceAttachment to place a container on the host's physical network. The IP address is assigned by the upstream DHCP server rather than our allocation pool, so ipv4Address is always nil for this type. Makes Interface.ipv4Address optional (CIDRv4?) to accommodate interfaces whose address is not known at configuration time. Updates all existing conformers (NATInterface, NATNetworkInterface, VmnetNetwork.Interface) and guards the static address/route setup in LinuxContainer and LinuxPod behind an ipv4Address nil-check. Fixes apple#457
When configureDns is called with an empty nameservers list or no domain, read /proc/net/pnp (written by the kernel IP_PNP DHCP client) and use any nameserver and domain lines found there. The two are filled in independently, so an explicit nameserver does not prevent the domain from being read from pnp. This provides automatic DNS configuration for bridge-mode containers without a new RPC or proto change.
FileHandleNetworkInterface uses VZFileHandleNetworkDeviceAttachment to attach the container to a file handle where another service can provide an arbitrary network. This might be an entirely simulated network, a virtual network like a VPN, e.g. using Wireguard, but it could be also a bridged physical network from the host where the service will then take over the responsibility of bridging the traffic between the container and host. We do not make any assumption about IP addresses for now, but instead also assume that the IP address can get assigned via DHCP.
|
@curdbecker sounds like cool feature! but with VZFileHandleNetworkDeviceAttachment it will not be easy to configure port forwarding and other options that are much easier with the native vmnet support introduced in macOS 26. |
|
@nirs thanks a lot :) Yes, the native bridging support is likely the go-to-alternative in any case, but if you maybe want to take a look at the linked PR in container from torarnv and the discussion as well as mine, then unfortunately the entitlement blocks using the integrated bridging support as far as I understand. I also took a look at your new project and it seems to be missing there as well, right? Without the entitlement one can only choose between SIP and bridging. Then I would always choose SIP in a heartbeat. The goal here from me is also that I do not want to have classical container features like port forwarding etc., but I would like to have containers where I do have a great deal of control about the underlying VM, e.g. kernel, init ad command line, as well as still benefiting from everything great the container eco system has brought us. The worse performance (although you seem to have put a great deal of work into optimization - that is something that would be as well also possible here) and the overhead of having a bridge would be okay for me when I need it :) Btw, I used your vmnet-helper with this little tool when creating a drop-in of Docker Desktop's VM runner to achieve the goals above... That's how I learned of it. Very nice! :) |
4 participants
Based on @torarnv's existing PR this PR adds also exposes a
VZFileHandleNetworkDeviceAttachmentvia aFileHandleNetworkInterfaceto allow connection a container to an arbitrary file handle provided by another service.This attachment is used by tools like nirs/vmnet-helper to bridge the container to an existing host interface. It opens also up the possibility to add a similar service directly into container to circumvent the need for without having the binary signed with the
com.apple.vm.networkingentitlement, e.g. during container development.