Included release tonarino/innernet@1.4.1.
github-actions[bot]
parent
05092efae1
commit
d0a795b25c
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1,4 @@
|
|||
5.3.0
|
||||
3.3.0
|
||||
bdb5.3.28
|
||||
bdb5.3.0
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Origin: Unofficial Innernet Debian repository
|
||||
Label: innernet-debian
|
||||
Suite: unstable
|
||||
Codename: bullseye
|
||||
Date: Sat, 11 Sep 2021 09:52:21 UTC
|
||||
Architectures: amd64
|
||||
Components: contrib
|
||||
Description: APT repository for https://github.com/tonarino/innernet/.
|
||||
MD5Sum:
|
||||
a0f7834a69495dfafadef1bef68ac156 11129 contrib/binary-amd64/Packages
|
||||
fad31ef85a5bda42271fcf663dbd3fb4 4499 contrib/binary-amd64/Packages.gz
|
||||
054c9a1e8a25809201dc62d407f4e83e 197 contrib/binary-amd64/Release
|
||||
SHA1:
|
||||
5d0bc00e1374cc23225de1d5e05da469087eced3 11129 contrib/binary-amd64/Packages
|
||||
7f15fde5972a28d092d04a651f6f678670ae5633 4499 contrib/binary-amd64/Packages.gz
|
||||
27df8ea870558476a122fd03363988c0ff791151 197 contrib/binary-amd64/Release
|
||||
SHA256:
|
||||
01c15437c1030c91cc54081f483d287a5184c5f22b73db72b3ce672a1f74d286 11129 contrib/binary-amd64/Packages
|
||||
809770fa7f07d896ba2cb86c0c226e3e20d43c3ea269b57297aefbd26abed641 4499 contrib/binary-amd64/Packages.gz
|
||||
852d73d87a0a610605e16f05c4b773ed6fda9a47be68fb4809171988c79f96ed 197 contrib/binary-amd64/Release
|
||||
|
|
@ -0,0 +1,357 @@
|
|||
Package: innernet
|
||||
Version: 1.4.1
|
||||
Architecture: amd64
|
||||
Vcs-Browser: https://github.com/tonarino/innernet
|
||||
Vcs-Git: https://github.com/tonarino/innernet
|
||||
Homepage: https://github.com/tonarino/innernet
|
||||
Maintainer: tonari <hey@tonari.no>
|
||||
Installed-Size: 7560
|
||||
Depends: libc6, libgcc1, systemd
|
||||
Priority: optional
|
||||
Section: net
|
||||
Filename: pool/contrib/i/innernet/innernet_1.4.1_amd64.deb
|
||||
Size: 1069196
|
||||
SHA256: d002ebdd6845744a6931b9b586b5a8e2b3ef60403c0e5a9fb74bc74c51f5e564
|
||||
SHA1: f914c4f8104052c48cc9174431cc7e1b78c4808e
|
||||
MD5sum: 2c94a01ab32e70a6c8b22f8dc94a530c
|
||||
Description: A client to manage innernet network interfaces.
|
||||
innernet client binary for fetching peer information and conducting admin tasks
|
||||
such as adding a new peer.
|
||||
|
||||
Package: innernet-server
|
||||
Version: 1.4.1
|
||||
Architecture: amd64
|
||||
Maintainer: tonari <hey@tonari.no>
|
||||
Installed-Size: 4135
|
||||
Depends: libsqlite3-0, zlib1g, libgcc1, systemd, libc6
|
||||
Source: innernet
|
||||
Priority: optional
|
||||
Section: net
|
||||
Filename: pool/contrib/i/innernet-server/innernet-server_1.4.1_amd64.deb
|
||||
Size: 1173208
|
||||
SHA256: 278ebba60d59f0970375fdc002e5ee7fd73e050181fb2e45b4850f79ae0d83a7
|
||||
SHA1: 2a2a735d5f3dec7f5963f5e0498715c6b277f5c9
|
||||
MD5sum: f2ba3bbd3eccb5e459187fc4d6030f0b
|
||||
Description: A server to coordinate innernet networks.
|
||||
# innernet
|
||||
.
|
||||
A private network system that uses [WireGuard](https://wireguard.com) under the
|
||||
hood. See the [announcement blog
|
||||
post](https://blog.tonari.no/introducing-innernet) for a longer-winded
|
||||
explanation.
|
||||
.
|
||||
<img
|
||||
src="https://user-images.githubusercontent.com/373823/118917068-09ae7700-b96b-11eb-80f4-6860072d504d.gif"
|
||||
width="600" height="370">
|
||||
.
|
||||
`innernet` is similar in its goals to Slack's
|
||||
[nebula](https://github.com/slackhq/nebula) or
|
||||
[Tailscale](https://tailscale.com/), but takes a bit of a different approach.
|
||||
It aims to take advantage of existing networking concepts like CIDRs and the
|
||||
security properties of WireGuard to turn your computer's basic IP networking
|
||||
into more powerful ACL primitives.
|
||||
.
|
||||
`innernet` is not an official WireGuard project, and WireGuard is a registered
|
||||
trademark of Jason A. Donenfeld.
|
||||
.
|
||||
This has not received an independent security audit, and should be considered
|
||||
experimental software at this early point in its lifetime.
|
||||
.
|
||||
## Usage
|
||||
.
|
||||
### Server Creation
|
||||
.
|
||||
Every `innernet` network needs a coordination server to manage peers and
|
||||
provide endpoint information so peers can directly connect to each other.
|
||||
Create a new one with
|
||||
.
|
||||
```sh
|
||||
sudo innernet-server new
|
||||
```
|
||||
.
|
||||
The init wizard will ask you questions about your network and give you some
|
||||
reasonable defaults. It's good to familiarize yourself with [network
|
||||
CIDRs](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) as a lot
|
||||
of innernet's access control is based upon them. As an example, let's say the
|
||||
root CIDR for this network is `10.60.0.0/16`. Server initialization creates a
|
||||
special "infra" CIDR which contains the `innernet` server itself and is
|
||||
reachable from all CIDRs on the network.
|
||||
.
|
||||
Next we'll also create a `humans` CIDR where we can start adding some peers.
|
||||
.
|
||||
```sh
|
||||
sudo innernet-server add-cidr <interface>
|
||||
```
|
||||
.
|
||||
For the parent CIDR, you can simply choose your network's root CIDR. The name
|
||||
will be `humans`, and the CIDR will be `10.60.64.0/24` (not a great example
|
||||
unless you only want to support 256 humans, but it works for now...).
|
||||
.
|
||||
By default, peers which exist in this new CIDR will only be able to contact
|
||||
peers in the same CIDR, and the special "infra" CIDR which was created when the
|
||||
server was initialized.
|
||||
.
|
||||
A typical workflow for creating a new network is to create an admin peer from
|
||||
the `innernet-server` CLI, and then continue using that admin peer via the
|
||||
`innernet` client CLI to add any further peers or network CIDRs.
|
||||
.
|
||||
```sh
|
||||
sudo innernet-server add-peer <interface>
|
||||
```
|
||||
.
|
||||
Select the `humans` CIDR, and the CLI will automatically suggest the next
|
||||
available IP address. Any name is fine, just answer "yes" when asked if you
|
||||
would like to make the peer an admin. The process of adding a peer results in
|
||||
an invitation file. This file contains just enough information for the new peer
|
||||
to contact the `innernet` server and redeem its invitation. It should be
|
||||
transferred securely to the new peer, and it can only be used once to
|
||||
initialize the peer.
|
||||
.
|
||||
You can run the server with `innernet-server serve <interface>`, or if you're
|
||||
on Linux and want to run it via `systemctl`, run `systemctl enable --now
|
||||
innernet-server@<interface>`. If you're on a home network, don't forget to
|
||||
configure port forwarding to the `Listen Port` you specified when creating the
|
||||
`innernet` server.
|
||||
.
|
||||
### Peer Initialization
|
||||
.
|
||||
Let's assume the invitation file generated in the steps above have been
|
||||
transferred to the machine a network admin will be using.
|
||||
.
|
||||
You can initialize the client with
|
||||
.
|
||||
```sh
|
||||
sudo inn install /path/to/invitation.toml
|
||||
```
|
||||
.
|
||||
You can customize the network name if you want to, or leave it at the default.
|
||||
`innernet` will then connect to the `innernet` server via WireGuard, generate a
|
||||
new key pair, and register that pair with the server. The private key in the
|
||||
invitation file can no longer be used.
|
||||
.
|
||||
If everything was successful, the new peer is on the network. You can run
|
||||
things like
|
||||
.
|
||||
```sh
|
||||
sudo inn list
|
||||
```
|
||||
.
|
||||
or
|
||||
.
|
||||
```sh
|
||||
sudo inn list --tree
|
||||
```
|
||||
.
|
||||
to view the current network and all CIDRs visible to this peer.
|
||||
.
|
||||
Since we created an admin peer, we can also add new peers and CIDRs from this
|
||||
peer via `innernet` instead of having to always run commands on the server.
|
||||
.
|
||||
### Adding Associations between CIDRs
|
||||
.
|
||||
In order for peers from one CIDR to be able to contact peers in another CIDR,
|
||||
those two CIDRs must be "associated" with each other.
|
||||
.
|
||||
With the admin peer we created above, let's add a new CIDR for some theoretical
|
||||
CI servers we have.
|
||||
.
|
||||
```sh
|
||||
sudo inn add-cidr <interface>
|
||||
```
|
||||
.
|
||||
The name is `ci-servers` and the CIDR is `10.60.64.0/24`, but for this example
|
||||
it can be anything.
|
||||
.
|
||||
For now, we want peers in the `humans` CIDR to be able to access peers in the
|
||||
`ci-servers` CIDR.
|
||||
.
|
||||
```sh
|
||||
sudo inn add-association <interface>
|
||||
```
|
||||
.
|
||||
The CLI will ask you to select the two CIDRs you want to associate. That's all
|
||||
it takes to allow peers in two different CIDRs to communicate!
|
||||
.
|
||||
You can verify the association with
|
||||
.
|
||||
```sh
|
||||
sudo inn list-associations <interface>
|
||||
```
|
||||
.
|
||||
and associations can be deleted with
|
||||
.
|
||||
```sh
|
||||
sudo inn delete-associations <interface>
|
||||
```
|
||||
.
|
||||
### Enabling/Disabling Peers
|
||||
.
|
||||
For security reasons, IP addresses cannot be re-used by new peers, and
|
||||
therefore peers cannot be deleted. However, they can be disabled. Disabled
|
||||
peers will not show up in the list of peers when fetching the config for an
|
||||
interface.
|
||||
.
|
||||
Disable a peer with
|
||||
.
|
||||
```su
|
||||
sudo inn disable-peer <interface>
|
||||
```
|
||||
.
|
||||
Or re-enable a peer with
|
||||
.
|
||||
```su
|
||||
sudo inn enable-peer <interface>
|
||||
```
|
||||
.
|
||||
### Specifying a Manual Endpoint
|
||||
.
|
||||
The `innernet` server will try to use the internet endpoint it sees from a peer
|
||||
so other peers can connect to that peer as well. This doesn't always work and
|
||||
you may want to set an endpoint explicitly. To set an endpoint, use
|
||||
.
|
||||
```sh
|
||||
sudo inn override-endpoint <interface>
|
||||
```
|
||||
.
|
||||
You can go back to automatic endpoint discovery with
|
||||
.
|
||||
```sh
|
||||
sudo inn override-endpoint -u <interface>
|
||||
```
|
||||
.
|
||||
### Setting the Local WireGuard Listen Port
|
||||
.
|
||||
If you want to change the port which WireGuard listens on, use
|
||||
.
|
||||
```sh
|
||||
sudo inn set-listen-port <interface>
|
||||
```
|
||||
.
|
||||
or unset the port and use a randomized port with
|
||||
.
|
||||
```sh
|
||||
sudo innernet set-listen-port -u <interface>
|
||||
```
|
||||
.
|
||||
## Security recommendations
|
||||
.
|
||||
If you're running a service on innernet, there are some important security
|
||||
considerations.
|
||||
.
|
||||
### Enable strict Reverse Path Filtering ([RFC
|
||||
3704](https://tools.ietf.org/html/rfc3704))
|
||||
.
|
||||
Strict RPF prevents packets from _other_ interfaces from having internal source
|
||||
IP addresses. This is _not_ the default on Linux, even though it is the right
|
||||
choice for 99.99% of situations. You can enable it by adding the following to a
|
||||
`/etc/sysctl.d/60-network-security.conf`:
|
||||
.
|
||||
```
|
||||
net.ipv4.conf.all.rp_filter=1
|
||||
net.ipv4.conf.default.rp_filter=1
|
||||
```
|
||||
.
|
||||
### Bind to the WireGuard device
|
||||
.
|
||||
If possible, to _ensure_ that packets are only ever transmitted over the
|
||||
WireGuard interface, it's recommended that you use `SO_BINDTODEVICE` on Linux
|
||||
or `IP_BOUND_IF` on macOS/BSDs. If you have strict reverse path filtering,
|
||||
though, this is less of a concern.
|
||||
.
|
||||
### IP addresses alone often aren't enough authentication
|
||||
.
|
||||
Even following all the above precautions, rogue applications on a peer's
|
||||
machines could be able to make requests on their behalf unless you add extra
|
||||
layers of authentication to mitigate this CSRF-type vector.
|
||||
.
|
||||
It's recommended that you carefully consider this possibility before deciding
|
||||
that the source IP is sufficient for your authentication needs on a service.
|
||||
.
|
||||
## Installation
|
||||
.
|
||||
innernet has only officially been tested on Linux and MacOS, but we hope to
|
||||
support as many platforms as is feasible!
|
||||
.
|
||||
### Runtime Dependencies
|
||||
.
|
||||
It's assumed that WireGuard is installed on your system, either via the kernel
|
||||
module in Linux 5.6 and later, or via the
|
||||
[`wireguard-go`](https://git.zx2c4.com/wireguard-go/about/) userspace
|
||||
implementation.
|
||||
.
|
||||
[WireGuard Installation Instructions](https://www.wireguard.com/install/)
|
||||
.
|
||||
### Arch Linux
|
||||
.
|
||||
```sh
|
||||
pacman -S innernet
|
||||
```
|
||||
.
|
||||
### Ubuntu
|
||||
.
|
||||
Fetch the appropriate `.deb` packages from
|
||||
https://github.com/tonarino/innernet/releases and install with
|
||||
.
|
||||
```sh
|
||||
sudo apt install ./innernet*.deb
|
||||
```
|
||||
.
|
||||
### macOS
|
||||
.
|
||||
```sh
|
||||
brew install tonarino/innernet/innernet
|
||||
```
|
||||
.
|
||||
### Cargo
|
||||
.
|
||||
```sh
|
||||
# to install innernet:
|
||||
cargo install --git https://github.com/tonarino/innernet --tag v1.4.1 client
|
||||
.
|
||||
# to install innernet-server:
|
||||
cargo install --git https://github.com/tonarino/innernet --tag v1.4.1 server
|
||||
```
|
||||
.
|
||||
Note that you'll be responsible for updating manually.
|
||||
.
|
||||
## Development
|
||||
.
|
||||
### `innernet-server` Build dependencies
|
||||
.
|
||||
- `rustc` / `cargo` (version 1.50.0 or higher)
|
||||
- `libclang` (see more info at
|
||||
[https://crates.io/crates/clang-sys](https://crates.io/crates/clang-sys))
|
||||
- `libsqlite3`
|
||||
.
|
||||
Build:
|
||||
.
|
||||
```sh
|
||||
cargo build --release --bin innernet-server
|
||||
```
|
||||
.
|
||||
The resulting binary will be located at `./target/release/innernet-server`
|
||||
.
|
||||
### `innernet` Client CLI Build dependencies
|
||||
.
|
||||
- `rustc` / `cargo` (version 1.50.0 or higher)
|
||||
- `libclang` (see more info at
|
||||
[https://crates.io/crates/clang-sys](https://crates.io/crates/clang-sys))
|
||||
.
|
||||
Build:
|
||||
.
|
||||
```sh
|
||||
cargo build --release --bin innernet
|
||||
```
|
||||
.
|
||||
The resulting binary will be located at `./target/release/innernet`
|
||||
.
|
||||
### Releases
|
||||
.
|
||||
1. Run `cargo release [--dry-run] [minor|major|patch|...]` to automatically
|
||||
bump the crates appropriately.
|
||||
2. Create a new git tag (ex. `v0.6.0`).
|
||||
3. Push (with tags) to the repo.
|
||||
.
|
||||
innernet uses GitHub Actions to automatically produce a debian package for the
|
||||
[releases page](https://github.com/tonarino/innernet/releases).
|
||||
|
||||
Binary file not shown.
|
|
@ -0,0 +1,6 @@
|
|||
Archive: unstable
|
||||
Component: contrib
|
||||
Origin: Unofficial Innernet Debian repository
|
||||
Label: innernet-debian
|
||||
Architecture: amd64
|
||||
Description: APT repository for https://github.com/tonarino/innernet/.
|
||||
Binary file not shown.
Binary file not shown.
Loading…
Reference in New Issue