names in wireguard.conf & bringing interface up

names in wireguard.conf & bringing interface up

[Michael Tokarev]

Hello.

We're having fun issue with wireguard at boot.

The thing is that there are a few "Endpoint" settings
in wg.conf which are names, not IP addresses - names
which are being resolved over DNS.

The problem is that DNS startup is scheduled AFTER the
interfaces are up, but in order to bring interfaces up,
we're waiting for DNS.

For the wg interface to be up there's no need to resolve
names. Yet `wg setconf' insists on resovling everything.

As the result, system waits (deadwaits) for quite some
time and does not bring wg interfaces up, resulting in
network being !up.

Like this:
...
ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 7.43 seconds...
ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 8.92 seconds...
ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 10.70 seconds...
ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 12.84 seconds...
ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'
ifup[952]: Configuration parsing error
ifup[530]: ifup: failed to bring up wgtls

We used tinc before trying out wireguard. In tinc, we had
an asyncronous DNS resolution which continued as long as
the daemon is running (and since the daemon must run all
the time the tunnel is up, it were always running - unlike
wg). So the DNS resolution has always worked.

Now I wonder how I can solve this.  Maybe I can configure
the basic interface parameters (local IP address/netmask,
routes, etc), and try to actually set all the info about
remotes in the background somehow?

But this still looks quite fragile - we should not fail to
bring whole thing up even if we can't connect to just one
endpoint, - this way we also can't connect TO the server to
fix things if the tunnel is the only way to log in.  All
local config does not require any DNS or other remote info,
only the few "connect to this remote" require it.

Please note that we can't connect TO this server from the outside
even if I put process of configuring the peer into background,
until everything is working.

I also tried to split configuration into two parts, one which
require some network access and one which doesn't, but this
way commands like syncconf does not work anymore, obviously -
we can't change configuration at runtime and reload it.

Comments?

Thanks,

/mjt