Outbound works out of the box: guests are NAT'd through their host and reach the internet like any process on it. That NIC is unconditional—the guest's egress, its way to the other guests on that host, and where the SSH jump gate meets it.
Inbound has two answers. The gate works from anywhere: it authenticates every
connection against your tenant's CA and tunnels you in. The other is to put the
VM on your own network—declare a bridge on a Linux host, name it to the agent
(--host-network lan=br0), pick that name at create. Your own DHCP server
addresses the guest's second NIC, and it is then a machine on the network:
every port, every device, nothing of eitri's in front of that NIC. The
networking has the recipe.
For reach beyond that LAN it is still a normal Linux machine, so install Tailscale (or WireGuard) inside it. A public gateway is on the roadmap.
No. The SSH jump gate authenticates every connection against your tenant's CA. A published port has nothing in front of it: whoever can reach the host on that port reaches the service, exactly as if the service were running on the host itself.
That is the LAN trust posture, deliberately. The socket binds every interface on the host, IPv4 only. Publish what you are content to serve to everything that can reach it; put anything else behind the gate, or behind the service's own authentication.
A published UDP port is the same posture carried one step further. Nothing in UDP proves where a datagram came from, so the host answers the address the datagram claimed—someone else's, if that is what it said. A UDP exposure can therefore be pointed at a third party, and a guest service that answers larger than it is asked makes that worse. Publish UDP the way you would publish anything else here: onto a network you are content to serve.
Docker. Installing (or starting) Docker on a host sets the kernel's iptables
FORWARD policy to drop, which silently discards the guests' NAT'd traffic —
the agent's own forwarding and masquerade rules are still in place, and a
drop in any chain wins. The symptoms are exactly this shape: the guest pings
its gateway, the jump gate still works (that path is tunnelled, not
forwarded), but DNS and everything outbound time out.
Docker reserves the DOCKER-USER chain for the host admin. Allow the eitri
bridge through it:
sudo iptables -I DOCKER-USER -i eitri0 -j ACCEPT
sudo iptables -I DOCKER-USER -o eitri0 -j ACCEPT
Docker re-creates its rules on every daemon start, so persist these (e.g.
iptables-persistent, or a systemd unit ordered after docker.service) —
a plain one-off insert is gone after the next reboot.