voodu wire

voodu wire manages the WireGuard peers of a host — the other voodu hosts whose containers it can reach by name. Peers are stored by the controller, applied to wg0 at once with wg addconf (the tunnel never drops), and come back after a reboot. wg0.conf is written once by the installer and never edited.

The full picture — addresses, names, migration — is in Cross-VM networking.

Subcommands

Every verb runs against the controller of the host it targets, so -r does all of it from your own machine.

Wiring two hosts

show on one host, add on the other, then the same the other way round:

vd wire show -r vm-1
# → vd wire add --key <vm-1 key> --address 10.254.91.221 --endpoint VM_IP:51820
vd wire add -r vm-2 --key <vm-1 key> --address 10.254.91.221 --endpoint VM_IP:51820

vd wire show -r vm-2
# → vd wire add --key <vm-2 key> --address 10.254.167.105 --endpoint VM_IP:51820
vd wire add -r vm-1 --key <vm-2 key> --address 10.254.167.105 --endpoint VM_IP:51820

The three flags all describe the other host:

--address is enough for the routing: the peer's container subnet (10.167.105.0/24) is derived from it, so AllowedIPs covers both without a flag. A host behind NAT is added without --endpoint; it dials out, and the other side learns the endpoint from the handshake.

Open UDP 51820 on every host — that is the tunnel itself. The installer does it when ufw is active; see voodu wire ufw.

With three hosts, each pair needs its add on both sides: six commands, once.

voodu wire list

this host: 10.254.91.221  key LOCALKEY…

ADDRESS         ENDPOINT              HANDSHAKE    RX/TX        KEY
10.254.167.105  VM_IP:51820  12s ago      2.0KB/100B   PEERKEY2…
10.254.200.7    1.2.3.4:51820         never        0B/0B        PEERKEY3…

A peer that stops answering stays listed until you remove it. -o json on every verb.

voodu wire ufw

The mesh needs four things through a host firewall: the tunnel port, DNS from the other hosts (on wg0) and from this host's containers (on the voodu0 bridge), and forwarding from wg0 into the bridge. The installer applies them when ufw is active; this prints them at any time, with the bridge's real name:

vd wire ufw -r vm-1
# sudo ufw allow 51820/udp
# sudo ufw allow in on wg0 to any port 53
# sudo ufw allow in on br-21f70aa6d28e to any port 53
# sudo ufw route allow in on wg0 out on br-21f70aa6d28e

On the host itself, with root, it applies or removes them:

sudo vd wire ufw enable
sudo vd wire ufw disable

The controller only computes the rules — its sandbox cannot write the firewall — so enable and disable run ufw from the CLI process. Over -r that process is the SSH user, not root: the command prints the rules and says so. Any other firewall takes the same four rules in its own syntax.

What it changes

• add writes the peer to the controller's store and to /opt/voodu/wire/peers.conf, runs wg addconf wg0 on that file, and adds the kernel route to the peer's container subnet through wg0 (wg-quick only routes the peers in wg0.conf, at up). remove drops both.
• After a reboot the peers come back with wg0 (PostUp) and their routes with the controller, seconds later.
• The mesh DNS reads its peer list from wg0, so a new peer's names resolve within 30 seconds. Nothing to restart.
• add and remove land in the activity trail.

Errors