Cannot redeem invite on same machine as server

[russkel]

Hello,

I am trying to redeem an invite on the same machine as the server but I am getting a HTTP 401 error.

I had someone else redeem an invite on the server and it worked. Any ideas what's happening?

↳ inn --version
innernet 1.4.1

$ russ @ devmachine in ~ [18:26:31]
↳ sudo innernet-server add-peer testinnernet
✔ Eligible CIDRs for peer · devnet (10.42.1.0/24)
✔ IP · 10.42.1.4
✔ Name · test
✔ Make test an admin? · no
✔ Invite expires after · 14d
✔ Save peer invitation file to · test.toml
✔ Create peer test? · yes
adding to WireGuard interface: test (xxxxxx)

Peer "test" added
Peer invitation file written to test.toml
Please send it to them securely (eg. via magic-wormhole) to bootstrap them onto the network.

$ russ @ devmachine in ~ [18:29:59]
↳ sudo inn install test.toml             
[!] /etc/innernet is world-accessible (mode is 0o755). This is probably not what you want.
✔ Interface name · testinnernettest
[*] bringing up the interface.
[*] Generating new keypair.
[*] Registering keypair with server (at 10.42.0.1:51820).
[E] failed to start the interface: http://10.42.0.1:51820/v1/user/redeem: status code 401.
[*] bringing down the interface.
[E] Failed to redeem invite. Now's a good time to make sure the server is started and accessible!

[E] http://10.42.0.1:51820/v1/user/redeem: status code 401

Also thank you for this project! Rust, wireguard, peer to peer, it has everything!

[mcginty]

Hey @russkel and sorry for the late reply! One can't run a client and server on the same machine (or, more specifically, the same network namespace) since you'll have conflicting routes (ip route), as both interfaces will be trying to route 10.42.0.0/16.

While you could probably do some fancy stuff with ip-netns, my general recommendation would be to have the innernet-server on a separate host.

[russkel]

Thanks @mcginty. I see. Thanks for the reply. If I were to run the server in a docker container that will solve the namespace issues?

[tommie]

The routes are already set up, right?

Isn't it enough to

1. let innernet-server also update the local /etc/hosts
2. change SERVER_NAME in innernet-server new to be customizable and default to the hostname?

[mcginty]

@russkel running it in a docker container should also solve the namespace issue since it also has a similar network namespace concept :).

[mcginty]

@tommie makes sense to have innernet-server also update its /etc/hosts! I'll add that. As for renaming the server peer, that also makes sense just to have one less hard-coded thing. I just want it to remain clear that there's a difference between the server and regular peers.

[tommie]

Thanks for the confirmation, and work on this project!

Showing a difference between clients and servers sounds nice. Are there other user-visible differences, aside from it having access to every sub-CIDR?

Maybe a boolean option to allow the server to participate? Would provide a natural spot for documentation.

[agausmann]

+1 for an option for adding the server as a network participant.

In particular, I would like it to populate its own /etc/hosts and also be reachable using its own hostname instead of just innernet-server. If there's interest in those features, I may be able to contribute them

[strohel]

In particular, I would like it to populate its own /etc/hosts and also be reachable using its own hostname instead of just innernet-server. If there's interest in those features, I may be able to contribute them

Contributions welcome! It makes most sense to me add support for writing /etc/hosts also on the server and allow to specify its innernet name. (as opposed to joining as a peer).

[strohel]

This actually looks like a duplicate of #45?

I'm not sure about supporting joining as a peer from the server machine, but we can surely make the server name configurable and allow writing the /etc/hosts file from the server.

[agausmann]

As a workaround, I just got a network up and running by containerizing innernet-server, and running innernet on the host machine.

There was one quirk, I had to hand-edit the same-machine invite to point to 127.0.0.1:51820 instead of <public-ip>:51820. (Not sure why that doesn't work, I think I was able to use a machine's public IP on the machine itself for other services)

Here is my Dockerfile and compose file