Host routes – ARP on wireguard interfaces?
toke at toke.dk
Mon Dec 3 20:39:53 CET 2018
Matthias Urlichs <matthias at urlichs.de> writes:
> On 03.12.18 14:14, Toke Høiland-Jørgensen wrote:
>> I'm not sure I quite understand what it is you are trying to achieve;
>> why can't just you reconfigure the wireguard interface to route the IP
>> to the right peer?
> Because that (a) requires a new mechanism and (b) requires locking,
> because currently you can't atomically remove/add an address from/to a peer.
> For a "normal" interface I'd change the host route to whatever the
> nexthop to the real destination address is, and I'm *done*. That's one
> atomic "ip route replace" command (or its netlink equivalent). I've
> found a couple of HA management programs which can do that.
> For a wireguard interface I need to find the correct peer (by matching
> the real destination against all Allowed-IP entries), lock the peer
> against changes, read the Allowed-IP list, add the multihomed address,
> and write the list back. Before/after I do all of this I have to remove
> the multihomed address from whatever peer it was previously set to, so
> there's an indeterminate time during which the destination is either
> unreachable or random. The aforementioned HA managers have no idea what
> wireguard is, and their authors may or may not be interested in
> special-casing a still-somewhat-obscure network interface type.
I'm pretty sure you don't have to go through that whole dance. You can
just add the AllowedIP to the new peer, which Wireguard will interpret
as a 'move'.
That still leaves the 'new mechanism' complaint, of course. I'm not sure
it's quite trivial to have the kernel-side do what you want, though, so
it may not be something that is likely to show up. I have a similar
problem because I want to run routing protocols over wireguard; my plan
is to teach the Bird routing daemon about wg peers to resolve this...
More information about the WireGuard