* 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
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
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
Based on the conversation from #5 (comment) - this changes innernet's behavior on Linux from automatically falling back to the userspace, instead requiring --backend userspace to be specified.
This should help people avoid weird situations in environments like Docker.
The server now expects a UNIX timestamp after which the invitation will be expired. If a peer invite hasn't been redeemed after it expires, the server will clean up old entries and allow the IP to be re-allocated for a new invite.
Closes#24
This is a stop-gap CSRF protection mechanism from unsophisticated attacks. It's to be considered a temporary solution until a more complete one can be implemented, but it should be sufficient in most cases for the time being.
See https://github.com/tonarino/innernet/issues/38 for further discussion.
Jake McGinty