Probably works

README.md

@@ -5,18 +5,17 @@ is one TCP port on one host per side.
 
 ```
 ansible/
-├── inventory.ini
 ├── wg-relay.yml           # the whole thing
-├── group_vars/all.yml     # defaults
-├── host_vars/site-a.yml   # Site A (Site B writes the mirror image)
+├── defaults.yml           # defaults
+├── vars/
+│   ├── site-a.yml         # Site A (Site B writes the mirror image)
+│   └── site-b.yml
 └── templates/
     ├── wg0.conf.j2
     ├── socat-relay.service.j2
     └── nftables-wgrelay.conf.j2
 ```
 
-Needs `ansible-core` and nothing else — no collections to install.
-
 ## How it works
 
 The relay VM never routes. `ip_forward` is pinned to 0 and the nftables
@@ -24,7 +23,7 @@ forward chain policy is `drop`, so there is no path from the tunnel to the
 LAN. The only things listening are socat processes you declared:
 
 - an **inbound** relay bound to the tunnel address, forwarding to one
-  `host:port` on the local LAN
+`host:port` on the local LAN
 - an **outbound** relay bound to the LAN address, forwarding down the tunnel
 
 Local clients point at the relay VM's LAN address and never learn a tunnel
@@ -43,20 +42,48 @@ Each side's restrictions live entirely on its own machine. There is no
 mechanism for one site to prove to the other how its half is configured — and
 none is needed, since the half that protects you is the half you control.
 
-## First run
+## Prerequisites
 
-1. Run it on each side with the peer key left as the placeholder. It
-   generates a keypair and prints the public key.
-2. Exchange public keys, fill in `wg_peers[].public_key`, run again.
-3. Point the local client at the relay VM's LAN address and port.
+You can use the ansible repositories or another installation method if desired, all that matters is you have ansible
 
-```bash
-ansible-playbook -i inventory.ini wg-relay.yml --check --diff
-ansible-playbook -i inventory.ini wg-relay.yml
+Needs `ansible-core`, no other packages or collections are needed. The playbook will install additional required packages
+
+```
+sudo apt update && sudo apt install ansible
 ```
 
-The playbook ends by asserting forwarding is off, waiting for each relay port
-to accept connections, and printing `wg show`.
+## Setup
+
+The playbook and `defaults.yml` are identical at both sites. Everything that
+differs lives in that site's vars file — copy `vars/site-a.yml` and edit:
+
+- `relay_host` / `relay_user` — which box to configure. Set it to the relay
+  VM to run over SSH, or leave it as `localhost` to configure the machine
+  you're sitting on.
+- `wg_address` — this side's tunnel address, as a `/32`.
+- `wg_peers` — the other site's public key, endpoint and `/32`.
+- `relays` — the inbound and outbound listeners.
+
+Values in the vars file override `defaults.yml`, because `-e` outranks
+everything else. Adding a site later means one more file in `vars/`; the
+playbook doesn't change.
+
+## Installation
+
+Run it at each site against that site's vars file. No inventory file needed.
+
+```
+ansible-playbook wg-relay.yml -e @vars/site-a.yml --check --diff
+ansible-playbook wg-relay.yml -e @vars/site-a.yml
+```
+
+Leave the peer's public key as the placeholder on the first run — it generates
+a keypair and prints this side's public key. Exchange public keys, fill in
+`wg_peers[].public_key` in each vars file, then run again. Finally, point the
+local client at the relay VM's LAN address and port.
+
+Each run ends by asserting forwarding is off, waiting for each relay port to
+accept connections, and printing `wg show`.
 
 ## Notes
 
@@ -65,8 +92,8 @@ to accept connections, and printing `wg show`.
 - Keys live in `/etc/wireguard/private.key` (0600, root-only). To manage them
   centrally instead, set `wg_private_key` from Ansible Vault and the playbook
   skips generation.
-- Removing a relay from `host_vars` stops and deletes its systemd unit on the
-  next run — no orphaned listeners.
+- Removing a relay from the vars file stops and deletes its systemd unit on
+  the next run — no orphaned listeners.
 - If either uplink is PPPoE or tunnelled, drop `wg_mtu` to 1380. Sustained
   bulk transfers are what find PMTU blackholes, and the symptom is a stall
   mid-transfer rather than a clean failure.