Surprisingly, Restart=always may not _always_ restart the unit if it restarts too fast.
Set a combination of options which should make systemd truly restart innernet always.
See https://unix.stackexchange.com/q/289629/352972.
The `RestartSec=60` is the main and important one which would prevent systemd from ever failing
to restart innernet in the default settings (because with it it would never exceed the default
limit of 5 restarts in 10 seconds).
`StartLimitIntervalSec=0` option is a complementary one for explicitly disabling the logic, and
may be removed from this PR if deemed unnecessary.
* client: allow config/data dirs to be changed
* server: allow config/data dirs to be changed
* meta: cargo clippy & cargo fmt
* shared: use const for Duration instead of lazy_static
added to `innernet {up,fetch,install}`:
--no-nat-traversal: Doesn't attempt NAT traversal
(prevents long time delays in execution of command)
--exclude-nat-candidates: Exclude a list of CIDRs from being
considered candidates
--no-nat-candidates: Don't report NAT candidates.
(shorthand for '--exclude-nat-candidates 0.0.0.0/0')
Closes#160
Before, only clients would report local addresses for NAT traversal. Servers should too! This will be helpful in common situations when the server is run inside the same LAN as other peers, and there's no NAT hairpinning enabled (or possible) on the router.
closes#146
It's very likely a user will want at least wireguard-dkms, and having
the userspace tools might be useful in an emergency. This metapackage
draws in both.
For automated installations in e.g. containers, use
apt install --no-install-recommends
to avoid installing recommended packages.
Previously, we treated all IPv6 addresses as assignable, but that causes
problems with setups that expect the first address in a subnet to be the
router anycast address.
Note that this does not fix existing innernet networks, and those
experiencing this problem are advised to revised to recreate their
network after this fix has been merged. Sorry for the annoyance.
Fixes#131
This change adds the ability for peers to report additional candidate endpoints for other peers to attempt connections with outside of the endpoint reported by the coordinating server.
While not a complete solution to the full spectrum of NAT traversal issues (TURN-esque proxying is still notably missing), it allows peers within the same NAT to connect to each other via their LAN addresses, which is a win nonetheless. In the future, more advanced candidate discovery could be used to punch through additional types of NAT cone types as well.
Co-authored-by: Matěj Laitl <matej@laitl.cz>
* Tidy code a bit thanks to clippy
Clippy 1.54 newly detects some redundant constructs, that's nice.
sort_unstable() should yield exact same results as sort() for `Vec<&str>`
and could be faster, clippy says.
* Add clippy to CI
Jake McGinty