naggie / dsnet

FAST command to manage a centralised wireguard VPN. Think wg-quick but quicker: key generation + address allocation.
https://calbryant.uk/blog/how-to-set-up-a-wireguard-vpn-in-minutes-with-dsnet/
MIT License
673 stars 33 forks source link

dsnet up does nothing #71

Closed xxxserxxx closed 2 years ago

xxxserxxx commented 2 years ago

Everything from the tutorial seems to have run without hickup, but dsnet up doesn't appear to do anything. The WG config generated for a peer was good, and the resulting wg-quick up <config> command looks good on the peer. However, on node 0 -- where all of the commands to generate the json config, and the peer WG config was created -- no routing is established:

# dsnet up
# echo $?
0
# dsnet sync
# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         m.n.o.p   0.0.0.0         UG        0 0          0 eth0
m.n.o.0   0.0.0.0         255.255.224.0   U         0 0          0 eth0
m.n.o.0   m.n.o.1   255.255.224.0   UG        0 0          0 eth0
# wg
interface: dsnet
  public key: censored
  private key: (hidden)
  listening port: 51820

peer: censored
  preshared key: (hidden)
  allowed ips: 10.79.56.2/32, censored

peer: censored
  preshared key: (hidden)
  allowed ips: 10.79.56.3/32, censored
# cat /proc/sys/net/ipv4/ip_forward
1

No error, but no network and no information for the wg interface, as if it was never set up. I tried dsnet down and up a few times -- always exit code 0, but no change to the routing that I could detect. The wireguard data toggles in and out. I've made sure the 51820 port is open in the firewall (both TCP and UDP).

As I said, the WG config for the peer imported into wg-quick beautifully and set up the routing correctly.

Node 0 is

botto commented 2 years ago

I will take a look, I just bumped all the deps so there might have been something in the old api that was silently broken

botto commented 2 years ago

Can you try with sudo @xxxserxxx

botto commented 2 years ago

@naggie I don't see any errors when trying to do up or down without sudo I'm not sure which direction would make most sense here, just simply check if we have root or check each permission required to perform a command.

xxxserxxx commented 2 years ago

@botto Sorry if it wasn't clear, but I was su'd to root (sudo su -), so all commands in my example were run as root.

xxxserxxx commented 2 years ago

Which branch should we be building from? I just did a go install github.com/naggie/dsnet@latest and it looks like what got installed was version v0.2.2. From the project latest releases, it looks like the most recent release is v0.6. The last change to go.mod on the master branch was 7 months ago -- are you releasing from a different branch than master?

EDIT: I don't know why go install seems to grab v0.2.2, but it doesn't matter. I cloned the repo, made sure I was on a commit post v0.6 tag (last commit on the master branch), built it, and get the same result. dsnet returns no errors, but also doesn't set up routing:

$ git log -1
commit f08433b23c87de70eb60dbb352b8ded00da61a9f (HEAD, origin/master, origin/HEAD)
Merge: 226c61a 4ea3809
Author: Cal Bryant <callan.bryant@gmail.com>
Date:   Fri Aug 5 09:40:47 2022 +0100

    Merge pull request #73 from naggie/remove_vendor

    Removed vendor
$ go build -o ./dsnet ./cmd
$ sudo ./dsnet up && echo Success
Success
$ sudo ./dsnet sync && echo Success
Success
$ sudo wg
interface: dsnet
  public key: censored
  private key: (hidden)
  listening port: 51820

peer: censored
  preshared key: (hidden)
  allowed ips: 10.79.56.2/32, fd00:1547:dac6:c500:4efb:bed6:3b62:474e/128

peer: censored
  preshared key: (hidden)
  allowed ips: 10.79.56.3/32, fd00:1547:dac6:c500:62bc:7655:8eb2:a784/128
$ netstat -rn
Kernel IP routing table
Destination Gateway     Genmask     Flags   MSS Window  irtt Iface
0.0.0.0     censored.1  0.0.0.0     UG    0 0          0 eth0
censored.0  0.0.0.0     255.255.224.0   U     0 0          0 eth0
censored.0  censored.1  255.255.224.0   UG    0 0          0 eth0
$ exit
xxxserxxx commented 2 years ago

Ok, a little more info: I ran the dsnet server portion on a different computer, and it worked as expected, so you can rule out any recent commit bug. It is specific to this server (I have some other servers at this cloud provider I'm going to test -- maybe it's their VMs). That said, I've set up other networking on this machine, so there's nothing specifically preventing routing commands from working

While it may be not working as expected because of some external system thing, there's no information useful for debugging. It'd be nice if it logged an error if it was unable to set up the routing -- right now, it looks like every command is successful.

UPDATE Ran the machine as a client, and wg-quick returned RTNETLINK answers: Permission denied. So definitely not an issue with dsnet. From other research, it looks like systems that aren't able to use ipV6 have this issue. The fix may then be #36; I haven't yet tested what happens if I remove all ipV6 entries from the config, but if it prevents dsnet from trying to set up ipV6 routes, it may solve the issue.

The fact that dsnet is swallowing this error is something I believe could be improved. Documenting the fix for non-ipV6 systems would also be helpful. I'm closing this ticket in any case, but hopefully someone else who runs into this issue will find it helpful.

botto commented 2 years ago

Yes, the errors being swallowed I've noticed as well. It's something I'm going to look at improving.

xxxserxxx commented 2 years ago

Quick update: deleting all ipv6 references made everything work.