extern/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2024-11-25 09:33:24 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: readme formatting

Browse Source
This commit is contained in:
braginini 2021-05-06 14:40:51 +02:00
parent d08b61b31d
commit 8c1cf88e07
1 changed files with 16 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
README.md
View File

@ -4,34 +4,30 @@ A WireGuard®-based mesh network that connects your devices into a single privat
### Why using Wiretrustee? ### Why using Wiretrustee?
* Connect multiple devices at home, office or anywhere else to each other via a secure peer-to-peer Wireguard VPN tunnel. * Connect multiple devices to each other via a secure peer-to-peer Wireguard VPN tunnel. At home, the office, or anywhere else.
* No need to open ports and expose public IPs on the device. * No need to open ports and expose public IPs on the device.
* Automatic reconnects in case of network failures or switches. * Automatically reconnects in case of network failures or switches.
* Automatic NAT traversal. * Automatic NAT traversal.
* Relay server fallback in case of an unsuccessful peer-to-peer connection. * Relay server fallback in case of an unsuccessful peer-to-peer connection.
* Private key never leaves your device. * Private key never leaves your device.
* Works on ARM devices (e.g. Raspberry Pi). * Works on ARM devices (e.g. Raspberry Pi).
### A bit on Wiretrustee internals ### A bit on Wiretrustee internals
* Wiretrustee uses WebRTC ICE implemented in [pion/ice library](https://github.com/pion/ice) to discover connection candidates * Wiretrustee uses WebRTC ICE implemented in [pion/ice library](https://github.com/pion/ice) to discover connection candidates when establishing a peer-to-peer connection between devices.
when establishing a peer-to-peer connection between devices. * A connection session negotiation between peers is achieved with the Wiretrustee Signalling server [signal](signal/)
* A connection session negotiation between peers is achieved with Wiretrustee Signalling server [signal](signal/) * Contents of the messages sent between peers through the signalling server are encrypted with Wireguard keys, making it impossible to inspect them.
* Contents of the messages sent between peers through the signalling server are encrypted with Wireguard keys making it impossible
to inspect them.
The routing of the messages on a Signalling server is based on public Wireguard keys. The routing of the messages on a Signalling server is based on public Wireguard keys.
* Sometimes NAT-traversal is unsuccessful due to strict NATs (e.g. mobile carrier grade NAT). * Occasionally, the NAT-traversal is unsuccessful due to strict NATs (e.g. mobile carrier grade NAT).
For that matter there is a support for a relay server fallback (TURN). In this case a secure Wireguard tunnel is established via a TURN server. For that matter, there is support for a relay server fallback (TURN). So in case, the (NAT-traversal is unsuccessful???), a secure Wireguard tunnel is established via TURN server.
[Coturn](https://github.com/coturn/coturn) is the one that has been successfully used for STUN and TURN in Wiretrustee setups. [Coturn](https://github.com/coturn/coturn) is the one that has been successfully used for STUN and TURN in Wiretrustee setups.
### What Wiretrustee is not doing (yet): ### What Wiretrustee is not doing (yet):
* Wireguard key management. For that reason you need to generate peer keys and specify them on Wiretrustee initialization step. * Wireguard key management. In consequence, you need to generate peer keys and specify them on Wiretrustee initialization step. However, the support for the key management feature is on our roadmap.
However, the support for the key management feature is in our roadmap. * Peer address management. You have to specify a unique peer local address (e.g. 10.30.30.1/24) when configuring Wiretrustee
* Peer address assignment. You have to specify a unique peer local address (e.g. 10.30.30.1/24) when configuring Wiretrustee The peer management assignment is on our roadmap too.
Same as for the key management it is in our roadmap.
### Installation ### Installation
1. Checkout Wiretrustee releases 1. Checkout Wiretrustee [releases](https://github.com/wiretrustee/wiretrustee/releases)
https://github.com/wiretrustee/wiretrustee/releases
2. Download the latest release: 2. Download the latest release:
```shell ```shell
wget https://github.com/wiretrustee/wiretrustee/releases/download/v0.0.4/wiretrustee_0.0.4_linux_amd64.rpm wget https://github.com/wiretrustee/wiretrustee/releases/download/v0.0.4/wiretrustee_0.0.4_linux_amd64.rpm
@ -49,12 +45,11 @@ sudo wiretrustee init \
--wgLocalAddr 10.30.30.1/24 \ --wgLocalAddr 10.30.30.1/24 \
--log-level info --log-level info
``` ```
It is important to mention that ```wgLocalAddr``` parameter has to be unique across your network It is important to mention that the ```wgLocalAddr``` parameter has to be unique across your network.
E.g. if you have a Peer A with wgLocalAddr=10.30.30.1/24 then another Peer B can have a wgLocalAddr=10.30.30.2/24 E.g. if you have Peer A with ```wgLocalAddr=10.30.30.1/24``` then another Peer B can have ```wgLocalAddr=10.30.30.2/24```
If for some reason you already have a generated Wireguard key you can specify it with ```--wgKey``` parameter.
If not specified then a new one will be generated, and it's corresponding public key will be output in the log.
If for some reason, you already have a generated Wireguard key, you can specify it with the ```--wgKey``` parameter.
If not specified, then a new one will be generated, and its corresponding public key will be output to the log.
A new config will be generated and stored under ```/etc/wiretrustee/config.json``` A new config will be generated and stored under ```/etc/wiretrustee/config.json```
5. Add a peer to connect to. 5. Add a peer to connect to.