Algo: dnscrypt-proxy doesn't restart after a reboot

[Stanpol]

OS / Environment (where do you run Algo on)

Linux Paris 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Cloud Provider (where do you deploy Algo to)

Scaleway

Summary of the problem

After installing the latest algo version via 8. Install to existing Ubuntu 16.04 server (Advanced) to a fresh VM everything works fine. However, after a reboot dnscrypt-proxy doesn't start.

root@Paris:~# sudo systemctl status dnscrypt-proxy
● dnscrypt-proxy.service - DNSCrypt-proxy client
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2018-05-21 20:08:03 UTC; 2s ago
     Docs: https://github.com/jedisct1/dnscrypt-proxy/wiki
  Process: 1589 ExecStart=/usr/bin/dnscrypt-proxy --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml (code=exited, status=255)
 Main PID: 1589 (code=exited, status=255)

May 21 20:08:03 Paris systemd[1]: Started DNSCrypt-proxy client.
May 21 20:08:03 Paris dnscrypt-proxy[1589]: TLS handshake failure - Try changing or deleting the tls_cipher_suite value in the configuration file
May 21 20:08:03 Paris dnscrypt-proxy[1589]: Source [public-resolvers.md] loaded
May 21 20:08:03 Paris dnscrypt-proxy[1589]: dnscrypt-proxy 2.0.14
May 21 20:08:03 Paris dnscrypt-proxy[1589]: listen udp 172.16.0.1:53: bind: cannot assign requested address
May 21 20:08:03 Paris systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=255/n/a
May 21 20:08:03 Paris systemd[1]: dnscrypt-proxy.service: Unit entered failed state.
May 21 20:08:03 Paris systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.

In dnscrypt-proxy.toml it's written:

## Note: When using systemd socket activation, choose an empty set (i.e. [] ).
listen_addresses  = ['172.16.0.1:53']

So that's the problem. To start dnscrypt-proxy via systemd listen_addresses should be empty = []. And it works - after changing it to the empty set [] dnscrypt-proxy restarts without problems. However, then without specifying the listen_addresses dnscrypt-proxy doesn't work with the strongSwan and there is no dns through the vpn.

Steps to reproduce the behavior

1. Install algo to a new server via advanced version
2. sudo reboot
3. sudo systemctl status dnscrypt-proxy

Any ideas how to start dnscrypt-proxy without getting listen udp 172.16.0.1:53: bind: cannot assign requested address?

[adamluk]

This may not be as straight forward as it appears as I am running Ubuntu 16.04 in a KVM with the 4.4.0-127-generic kernel. I also installed Algo via 8. Install to existing Ubuntu 16.04 server (Advanced).

I have no issues with reboots of the server, so this could be specific to Scaleway.

● dnscrypt-proxy.service - DNSCrypt-proxy client
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.service; enabled; vendor p
   Active: active (running) since Tue 2018-05-22 10:52:43 UTC; 10h ago
     Docs: https://github.com/jedisct1/dnscrypt-proxy/wiki
 Main PID: 1083 (dnscrypt-proxy)
   Memory: 19.5M
   CGroup: /system.slice/dnscrypt-proxy.service
           └─1083 /usr/bin/dnscrypt-proxy --config /etc/dnscrypt-proxy/dnscrypt-

May 22 10:52:45 vpn dnscrypt-proxy[1083]: Now listening to 172.16.0.1:53 [UDP]
May 22 10:52:45 vpn dnscrypt-proxy[1083]: Now listening to 172.16.0.1:53 [TCP]
May 22 10:52:45 vpn dnscrypt-proxy[1083]: Wiring systemd TCP socket #0
May 22 10:52:45 vpn dnscrypt-proxy[1083]: Wiring systemd UDP socket #1
May 22 10:52:48 vpn dnscrypt-proxy[1083]: [cloudflare-ipv6] OK (DoH) - rtt: 32ms
May 22 10:52:48 vpn dnscrypt-proxy[1083]: Server with the lowest initial latency
May 22 10:52:48 vpn dnscrypt-proxy[1083]: dnscrypt-proxy is ready - live servers
May 22 14:52:48 vpn dnscrypt-proxy[1083]: [cloudflare] OK (DoH) - rtt: 2ms
May 22 14:52:48 vpn dnscrypt-proxy[1083]: Server with the lowest initial latency
May 22 18:52:48 vpn dnscrypt-proxy[1083]: Server with the lowest initial latency

[Stanpol]

I confirm, installation on Vultr.com via 8. Install to existing Ubuntu 16.04 server (Advanced) doesn't have problems after rebooting. So it looks like this is indeed Scaleway system problem.

[jackivanov]

For some reason scaleway scripts clean up /etc/network/interfaces.d/ every reboot

[jackivanov]

The fix is coming in https://github.com/trailofbits/algo/pull/925