mirror of https://github.com/dswd/vpncloud.git
Add service for ws proxy
This commit is contained in:
Dennis Schwerdel
parent
0cffea7017
commit
38c3ba1177
|
|
@ -27,6 +27,7 @@ mkdir -p %{buildroot}/lib/systemd/system
|
|||
mkdir -p %{buildroot}/usr/share/man/man1
|
||||
cp %{buildroot}/../../../../../assets/example.net.disabled %{buildroot}/etc/vpncloud/example.net.disabled
|
||||
cp %{buildroot}/../../../../../assets/vpncloud@.service %{buildroot}/lib/systemd/system/vpncloud@.service
|
||||
cp %{buildroot}/../../../../../assets/vpncloud-wsproxy.service %{buildroot}/lib/systemd/system/vpncloud-wsproxy.service
|
||||
cp %{buildroot}/../../../../../target/vpncloud.1.gz %{buildroot}/usr/share/man/man1/vpncloud.1.gz
|
||||
cp -a * %{buildroot}
|
||||
|
||||
|
|
@ -38,6 +39,7 @@ rm -rf %{buildroot}
|
|||
/etc/vpncloud/example.net.disabled
|
||||
/usr/bin/vpncloud
|
||||
/lib/systemd/system/vpncloud@.service
|
||||
/lib/systemd/system/vpncloud-wsproxy.service
|
||||
/usr/share/man/man1/vpncloud.1.gz
|
||||
|
||||
%defattr(-,root,root,-)
|
||||
|
|
|
|||
|
|
@ -74,6 +74,7 @@ assets = [
|
|||
["target/release/vpncloud", "/usr/bin/vpncloud", "755"],
|
||||
["assets/example.net.disabled", "/etc/vpncloud/example.net.disabled", "600"],
|
||||
["assets/vpncloud@.service", "/lib/systemd/system/vpncloud@.service", "644"],
|
||||
["assets/vpncloud-wsproxy.service", "/lib/systemd/system/vpncloud-wsproxy.service", "644"],
|
||||
["target/vpncloud.1.gz", "/usr/share/man/man1/vpncloud.1.gz", "644"]
|
||||
]
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
[Unit]
|
||||
Description=VpnCloud websocket proxy
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
Documentation=man:vpncloud(1)
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
ExecStart=/usr/bin/vpncloud ws-proxy -l 3210
|
||||
RestartSec=5s
|
||||
Restart=on-failure
|
||||
TasksMax=10
|
||||
MemoryMax=50M
|
||||
PrivateTmp=yes
|
||||
ProtectHome=yes
|
||||
ProtectSystem=strict
|
||||
ReadWritePaths=/var/log /run
|
||||
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT
|
||||
DeviceAllow=/dev/null rw
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
|
@ -1,860 +0,0 @@
|
|||
'\" t
|
||||
.\" Title: vpncloud
|
||||
.\" Author: [see the "AUTHORS" section]
|
||||
.\" Generator: Asciidoctor 1.5.5
|
||||
.\" Date: 2020-06-03
|
||||
.\" Manual: \ \&
|
||||
.\" Source: \ \&
|
||||
.\" Language: English
|
||||
.\"
|
||||
.TH "VPNCLOUD" "1" "2020-06-03" "\ \&" "\ \&"
|
||||
.ie \n(.g .ds Aq \(aq
|
||||
.el .ds Aq '
|
||||
.ss \n[.ss] 0
|
||||
.nh
|
||||
.ad l
|
||||
.de URL
|
||||
\\$2 \(laURL: \\$1 \(ra\\$3
|
||||
..
|
||||
.if \n[.g] .mso www.tmac
|
||||
.LINKSTYLE blue R < >
|
||||
.SH "NAME"
|
||||
vpncloud \- Peer\-to\-peer VPN
|
||||
.SH "SYNOPSIS"
|
||||
.sp
|
||||
\fBvpncloud [options] [\-\-config <file>] [\-t <type>] [\-d <name>] [\-l <addr>] [\-c <addr>...]\fP
|
||||
.SH "OPTIONS"
|
||||
.sp
|
||||
\fB\-\-config <file>\fP
|
||||
.RS 4
|
||||
Read configuration options from the specified file. Please see the section
|
||||
\fBCONFIG FILES\fP for documentation on the file format.
|
||||
If the same option is defined in the config file and as a parameter, the
|
||||
parameter overrides the config file.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-t <type>\fP, \fB\-\-type <type>\fP
|
||||
.RS 4
|
||||
Set the type of network. There are two options: \fBtap\fP devices process
|
||||
Ethernet frames \fBtun\fP devices process IP packets. [default: \fBtap\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-d <name>\fP, \fB\-\-device <name>\fP
|
||||
.RS 4
|
||||
Name of the virtual device. Any \fB%d\fP will be filled with a free number.
|
||||
[default: \fBvpncloud%d\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-device\-path <path>\fP
|
||||
.RS 4
|
||||
The path of the base device inode, e.g. /dev/net/run.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-m <mode>\fP, \fB\-\-mode <mode>\fP
|
||||
.RS 4
|
||||
The mode of the VPN. The VPN can like a router, a switch or a hub. A \fBhub\fP
|
||||
will send all data always to all peers. A \fBswitch\fP will learn addresses
|
||||
from incoming data and only send data to all peers when the address is
|
||||
unknown. A \fBrouter\fP will send data according to known subnets of the
|
||||
peers and ignore them otherwise. The \fBnormal\fP mode is switch for tap
|
||||
devices and router for tun devices. [default: \fBnormal\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-l <addr>\fP, \fB\-\-listen <addr>\fP
|
||||
.RS 4
|
||||
The address on which to listen for data. This can be simply a port number
|
||||
or a full address in form IP:PORT. If the IP is specified as \(aq\(rs*\(aq or only
|
||||
a port number is given, then the socket will listen on all IPs (v4 and v6),
|
||||
otherwise the socket will only listen on the given IP. [default: \fB3210\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-c <addr>\fP, \fB\-\-connect <addr>\fP
|
||||
.RS 4
|
||||
Address of a peer to connect to. The address should be in the form
|
||||
\fBaddr:port\fP. If the node is not started, the connection will be retried
|
||||
periodically. This parameter can be repeated to connect to multiple peers.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-s <subnet>\fP, \fB\-\-subnet <subnet>\fP:
|
||||
The local subnets to use. This parameter should be in the form
|
||||
\fBaddress/prefixlen\fP where address is an IPv4 address, an IPv6 address, or a
|
||||
MAC address. The prefix length is the number of significant front bits that
|
||||
distinguish the subnet from other subnets. Example: \fB10.1.1.0/24\fP.
|
||||
.sp
|
||||
\fB\-\-shared\-key <key>\fP
|
||||
.RS 4
|
||||
An optional shared key to encrypt the VPN data. If this option is not set,
|
||||
the traffic will be sent unencrypted.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-crypto <method>\fP
|
||||
.RS 4
|
||||
The encryption method to use ("aes256", or "chacha20"). Most current CPUs
|
||||
have special support for AES256 so this should be faster. For older
|
||||
computers lacking this support, only CHACHA20 is supported.
|
||||
[default: \fBchacha20\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-magic <id>\fP
|
||||
.RS 4
|
||||
Override the 4\-byte magic header of each packet. This header identifies the
|
||||
network and helps to distinguish it from other networks and other
|
||||
applications. The id can either be a 4 byte / 8 character hexadecimal
|
||||
string or an arbitrary string prefixed with "hash:" which will then be
|
||||
hashed into 4 bytes.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-peer\-timeout <secs>\fP
|
||||
.RS 4
|
||||
Peer timeout in seconds. The peers will exchange information periodically
|
||||
and drop peers that are silent for this period of time. [default: \fB600\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-keepalive <secs>\fP
|
||||
.RS 4
|
||||
Interval of peer exchange messages in seconds. The peers will exchange
|
||||
information periodically to keep connections alive. This setting overrides
|
||||
how often this will happen. [default: \fBpeer\-timeout/2\-60\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-dst\-timeout <secs>\fP
|
||||
.RS 4
|
||||
Switch table entry timeout in seconds. This parameter is only used in switch
|
||||
mode. Addresses that have not been seen for the given period of time will
|
||||
be forgotten. [default: \fB300\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-beacon\-store <path|command>\fP
|
||||
.RS 4
|
||||
Periodically store beacons containing the address of this node in the given
|
||||
file or via the given command. If the parameter value starts with a pipe
|
||||
character (\fB|\fP), the rest of the value is interpreted as a shell command.
|
||||
Otherwise the value is interpreted as a file to write the beacon to.
|
||||
If this parameter is not given, beacon storage is disabled.
|
||||
Please see the section \fBBEACONS\fP for more information.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-beacon\-load <path|command>\fP
|
||||
.RS 4
|
||||
Periodically load beacons containing the addresses of other nodes from the
|
||||
given file or via the given command. If the parameter value starts with a
|
||||
pipe character (\fB|\fP), the rest of the value is interpreted as a shell
|
||||
command. Otherwise the value is interpreted as a file to read the beacon
|
||||
from.
|
||||
If this parameter is not given, beacon loading is disabled.
|
||||
Please see the section \fBBEACONS\fP for more information.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-beacon\-interval <secs>\fP
|
||||
.RS 4
|
||||
Beacon storage/loading interval in seconds. If configured to do so via
|
||||
\fB\-\-beacon\-store\fP and \fB\-\-beacon\-load\fP, the node will periodically store its
|
||||
beacon and load beacons of other nodes. This parameter defines the interval
|
||||
in seconds. [default: \fB3600\fP]
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-ifup <command>\fP
|
||||
.RS 4
|
||||
A command to setup the network interface. The command will be run (as
|
||||
parameter to \fBsh \-c\fP) when the device has been created to configure it.
|
||||
The name of the allocated device will be available via the environment
|
||||
variable \fBIFNAME\fP.
|
||||
Please note that this command is executed with the full permissions of the
|
||||
caller.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-ifdown <command>\fP
|
||||
.RS 4
|
||||
A command to bring down the network interface. The command will be run (as
|
||||
parameter to \fBsh \-c\fP) to remove any configuration from the device.
|
||||
The name of the allocated device will be available via the environment
|
||||
variable \fBIFNAME\fP.
|
||||
Please note that this command is executed with the (limited) permissions of
|
||||
the user and group given as \fB\-\-user\fP and \fB\-\-group\fP.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-pid\-file <file>\fP
|
||||
.RS 4
|
||||
Store the process id in this file when running in the background. If set,
|
||||
the given file will be created containing the process id of the new
|
||||
background process. This option is only used when running in background.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-user <user>\fP, \fB\-\-group <group>\fP
|
||||
.RS 4
|
||||
Change the user and/or group of the process once all the setup has been
|
||||
done.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-log\-file <file>\fP
|
||||
.RS 4
|
||||
If set, print logs also to the given file. The file will be created and
|
||||
truncated if is exists.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-stats\-file <file>\fP
|
||||
.RS 4
|
||||
If set, periodically write statistics on peers and current traffic to the
|
||||
given file. The file will be periodically overwritten with new data.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-daemon\fP
|
||||
.RS 4
|
||||
Spawn a background process instead of running the process in the foreground.
|
||||
If this flag is set, the process will first carry out all the
|
||||
initialization, then drop permissions if \fB\-\-user\fP or \fB\-\-group\fP is used and
|
||||
then spawn a background process and write its process id to a file if
|
||||
\fB\-\-pid\-file\fP is set. Then, the main process will exit and the background
|
||||
process continues to provide the VPN. At the time, when the main process
|
||||
exits, the interface exists and is properly configured to be used.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-\-no\-port\-forwarding\fP
|
||||
.RS 4
|
||||
Disable automatic port forward. If this option is not set, VpnCloud tries to
|
||||
detect a NAT router and automatically add a port forwarding to it.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-v\fP, \fB\-\-verbose\fP
|
||||
.RS 4
|
||||
Print debug information, including information for data being received and
|
||||
sent.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-q\fP, \fB\-\-quiet\fP
|
||||
.RS 4
|
||||
Only print errors and warnings.
|
||||
.RE
|
||||
.sp
|
||||
\fB\-h\fP, \fB\-\-help\fP
|
||||
.RS 4
|
||||
Display the help.
|
||||
.RE
|
||||
.SH "DESCRIPTION"
|
||||
.sp
|
||||
\fBVpnCloud\fP is a simple VPN over UDP. It creates a virtual network interface on
|
||||
the host and forwards all received data via UDP to the destination. It can work
|
||||
in 3 different modes:
|
||||
.sp
|
||||
\fBSwitch mode\fP
|
||||
.RS 4
|
||||
In this mode, the VPN will dynamically learn addresses
|
||||
as they are used as source addresses and use them to forward data to its
|
||||
destination. Addresses that have not been seen for some time
|
||||
(option \fBswitch_timeout\fP) will be forgotten. Data for unknown addresses will be
|
||||
broadcast to all peers. This mode is the default mode for TAP devices that
|
||||
process Ethernet frames but it can also be used with TUN devices and IP
|
||||
packets.
|
||||
.RE
|
||||
.sp
|
||||
\fBHub mode\fP
|
||||
.RS 4
|
||||
In this mode, all data will always be broadcast to all peers.
|
||||
This mode uses lots of bandwidth and should only be used in special cases.
|
||||
.RE
|
||||
.sp
|
||||
\fBRouter mode\fP
|
||||
.RS 4
|
||||
In this mode, data will be forwarded based on preconfigured
|
||||
address ranges ("subnets"). Data for unknown nodes will be silently ignored.
|
||||
This mode is the default mode for TUN devices that work with IP packets but
|
||||
it can also be used with TAP devices and Ethernet frames.
|
||||
.RE
|
||||
.sp
|
||||
All connected VpnCloud nodes will form a peer\-to\-peer network and cross\-connect
|
||||
automatically until the network is fully connected. The nodes will periodically
|
||||
exchange information with the other nodes to signal that they are still active
|
||||
and to allow the automatic cross\-connect behavior. There are some important
|
||||
things to note:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 1.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 1." 4.2
|
||||
.\}
|
||||
To avoid that different networks that reuse each others addresses merge due
|
||||
to the cross\-connect behavior, the \fBmagic\fP option can be used and set
|
||||
to any unique string to identify the network. The \fBmagic\fP must be the
|
||||
same on all nodes of the same VPN network.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 2.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 2." 4.2
|
||||
.\}
|
||||
The cross\-connect behavior can be able to connect nodes that are behind
|
||||
firewalls or NATs as it can function as hole\-punching.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 3.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 3." 4.2
|
||||
.\}
|
||||
The management traffic will increase with the peer number quadratically.
|
||||
It should still be reasonably small for high node numbers (below 10 KiB/s
|
||||
for 10.000 nodes). A longer \fBpeer_timeout\fP can be used to reduce the traffic
|
||||
further. For high node numbers, router mode should be used as it never
|
||||
broadcasts data.
|
||||
.RE
|
||||
.sp
|
||||
VpnCloud does not implement any loop\-avoidance. Since data received on the UDP
|
||||
socket will only be sent to the local network interface and vice versa, VpnCloud
|
||||
cannot produce loops on its own. On the TAP device, however STP data can be
|
||||
transported to avoid loops caused by other network components.
|
||||
.sp
|
||||
For TAP devices, IEEE 802.1q frames (VLAN tagged) are detected and forwarded
|
||||
based on separate MAC tables. Any nested tags (Q\-in\-Q) will be ignored.
|
||||
.SH "EXAMPLES"
|
||||
.SS "Switched TAP scenario"
|
||||
.sp
|
||||
In the example scenario, a simple layer 2 network tunnel is established. Most
|
||||
likely those commands need to be run as \fBroot\fP using \fBsudo\fP.
|
||||
.sp
|
||||
First, VpnCloud need to be started on both nodes (the address after \fB\-c\fP is the
|
||||
address of the remote node and the the \fBX\fP in the interface address must be
|
||||
unique among all nodes, e.g. 0, 1, 2, ...):
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
vpncloud \-c REMOTE_HOST:PORT \-\-ifup \(aqifconfig $IFNAME 10.0.0.X/24 mtu 1400 up\(aq
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
Afterwards, the interface can be used to communicate.
|
||||
.SS "Routed TUN example"
|
||||
.sp
|
||||
In this example, 2 nodes and their subnets should communicate using IP.
|
||||
First, VpnCloud need to be started on both nodes:
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
vpncloud \-t tun \-c REMOTE_HOST:PORT \-\-subnet 10.0.X.0/24 \-\-ifup \(aqifconfig $IFNAME 10.0.X.1/16 mtu 1400 up\(aq
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.sp
|
||||
It is important to configure the interface in a way that all addresses on the
|
||||
VPN can be reached directly. E.g. if subnets 10.0.1.0/24, 10.0.2.0/24 and so on
|
||||
are used, the interface needs to be configured as 10.0.1.1/16.
|
||||
For TUN devices, this means that the prefix length of the subnets
|
||||
(/24 in this example) must be different than the prefix length that the
|
||||
interface is configured with (/16 in this example).
|
||||
.SS "Important notes"
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 1.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 1." 4.2
|
||||
.\}
|
||||
VpnCloud can be used to connect two separate networks. TAP networks can be
|
||||
bridged using \fBbrctl\fP and TUN networks must be routed. It is very important
|
||||
to be careful when setting up such a scenario in order to avoid network loops,
|
||||
security issues, DHCP issues and many more problems.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 2.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 2." 4.2
|
||||
.\}
|
||||
TAP devices will forward DHCP data. If done intentionally, this can be used
|
||||
to assign unique addresses to all participants. If this happens accidentally,
|
||||
it can conflict with DHCP servers of the local network and can have severe
|
||||
side effects.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04' 3.\h'+01'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP " 3." 4.2
|
||||
.\}
|
||||
VpnCloud is not designed for high security use cases. Although the used crypto
|
||||
primitives are expected to be very secure, their application has not been
|
||||
reviewed.
|
||||
The shared key is hashed using \fIScryptSalsa208Sha256\fP to derive a key,
|
||||
which is used to encrypt the payload of messages using \fIChaCha20Poly1305\fP or
|
||||
\fIAES256\-GCM\fP. The encryption includes an authentication that also protects the
|
||||
header.
|
||||
This method does only protect against attacks on single messages but not
|
||||
against attacks that manipulate the message series itself (i.e. suppress
|
||||
messages, reorder them, or duplicate them).
|
||||
.RE
|
||||
.SH "CONFIG FILES"
|
||||
.sp
|
||||
The config file is a YAML file that contains configuration values. All entries
|
||||
are optional and override the defaults. Please see the section \fBOPTIONS\fP for
|
||||
detailed descriptions of the options.
|
||||
.sp
|
||||
\fBdevice_type\fP
|
||||
.RS 4
|
||||
Set the type of network. Same as \fB\-\-type\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBdevice_name\fP
|
||||
.RS 4
|
||||
Name of the virtual device. Same as \fB\-\-device\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBdevice_path\fP
|
||||
.RS 4
|
||||
Set the path of the base device. Same as \fB\-\-device\-path\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBifup\fP
|
||||
.RS 4
|
||||
A command to setup the network interface. Same as \fB\-\-ifup\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBifdown\fP
|
||||
.RS 4
|
||||
A command to bring down the network interface. Same as \fB\-\-ifdown\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBcrypto\fP
|
||||
.RS 4
|
||||
The encryption method to use. Same as \fB\-\-crypto\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBshared_key\fP
|
||||
.RS 4
|
||||
The shared key to encrypt all traffic. Same as \fB\-\-shared\-key\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBmagic\fP
|
||||
.RS 4
|
||||
Override the 4\-byte magic header of each packet. Same as \fB\-\-magic\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBport\fP
|
||||
.RS 4
|
||||
A port number to listen on. This option is DEPRECATED.
|
||||
.RE
|
||||
.sp
|
||||
\fBlisten\fP
|
||||
.RS 4
|
||||
The address on which to listen for data. Same as \fB\-\-listen\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBpeers\fP
|
||||
.RS 4
|
||||
A list of addresses to connect to. See \fB\-\-connect\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBpeer_timeout\fP
|
||||
.RS 4
|
||||
Peer timeout in seconds. Same as\fB\-\-peer\-timeout\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBbeacon_store\fP
|
||||
.RS 4
|
||||
Path or command to store beacons. Same as \fB\-\-beacon\-store\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBbeacon_load\fP
|
||||
.RS 4
|
||||
Path or command to load beacons. Same as \fB\-\-beacon\-load\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBbeacon_interval\fP
|
||||
.RS 4
|
||||
Interval for loading and storing beacons in seconds. Same as \fB\-\-beacon\-interval\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBmode\fP
|
||||
.RS 4
|
||||
The mode of the VPN. Same as \fB\-\-mode\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBswitch_timeout\fP
|
||||
.RS 4
|
||||
Switch table entry timeout in seconds. Same as \fB\-\-dst\-timeout\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBsubnets\fP
|
||||
.RS 4
|
||||
A list of local subnets to use. See \fB\-\-subnet\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBport_forwarding\fP
|
||||
.RS 4
|
||||
Whether to activate port forwardig. See \fB\-\-no\-port\-forwarding\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBuser\fP
|
||||
.RS 4
|
||||
The name of a user to run the background process under. See \fB\-\-user\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBgroup\fP
|
||||
.RS 4
|
||||
The name of a group to run the background process under. See \fB\-\-group\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBpid_file\fP
|
||||
.RS 4
|
||||
The path of the pid file to create. See \fB\-\-pid\-file\fP
|
||||
.RE
|
||||
.sp
|
||||
\fBstats_file\fP
|
||||
.RS 4
|
||||
The path of the statistics file. See \fB\-\-stats\-file\fP
|
||||
.RE
|
||||
.SS "Example"
|
||||
.sp
|
||||
.if n \{\
|
||||
.RS 4
|
||||
.\}
|
||||
.nf
|
||||
device_type: tun
|
||||
device_name: vpncloud%d
|
||||
ifup: ifconfig $IFNAME 10.0.1.1/16 mtu 1400 up
|
||||
crypto: aes256
|
||||
shared_key: mysecret
|
||||
listen: 3210
|
||||
peers:
|
||||
\- remote.machine.foo:3210
|
||||
\- remote.machine.bar:3210
|
||||
peer_timeout: 600
|
||||
mode: normal
|
||||
subnets:
|
||||
\- 10.0.1.0/24
|
||||
port_forwarding: true
|
||||
user: nobody
|
||||
group: nogroup
|
||||
pid_file: /run/vpncloud.pid
|
||||
.fi
|
||||
.if n \{\
|
||||
.RE
|
||||
.\}
|
||||
.SH "BEACONS"
|
||||
.sp
|
||||
Beacons are short character sequences that contain a timestamp and a list of
|
||||
addresses. They can be published and retrieved by other nodes to find peers
|
||||
without the need for static addresses.
|
||||
.sp
|
||||
The beacons are short (less than 100 characters), encrypted and encoded with
|
||||
printable characters to allow publishing them in various places on the
|
||||
internet, e.g.:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
On shared drives or synchronized folders (e.g. on Dropbox)
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Via a dedicated database
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Via a general purpose message board of message service (e.g. Twitter)
|
||||
.RE
|
||||
.sp
|
||||
The beacons are very robust. They only consist of alphanumeric characters
|
||||
and can be interleaved with non\-alphanumeric characters (e.g. whitespace).
|
||||
Also the beacons contain a prefix and suffix that depends on the configured
|
||||
network magic and secret key (if set) so that all nodes can find beacons in
|
||||
a long text.
|
||||
.sp
|
||||
When beacons are stored or loaded via a command (using the pipe character \fB|\fP),
|
||||
the command is interpreted using the configured shell \fBsh\fP. This command has
|
||||
access to the following environment variables:
|
||||
.sp
|
||||
\fB$begin\fP
|
||||
.RS 4
|
||||
The prefix of the beacon.
|
||||
.RE
|
||||
.sp
|
||||
\fB$end\fP
|
||||
.RS 4
|
||||
The suffix of the beacon.
|
||||
.RE
|
||||
.sp
|
||||
\fB$data\fP (only on store)
|
||||
.RS 4
|
||||
The middle part of the beacon. Do not use this
|
||||
without prefix and suffix!
|
||||
.RE
|
||||
.sp
|
||||
\fB$beacon\fP (only on store)
|
||||
.RS 4
|
||||
The full beacon consisting of prefix, data and
|
||||
suffix.
|
||||
The commands are called in separate threads, so even longer running commands
|
||||
will not block the node.
|
||||
.RE
|
||||
.SH "NETWORK PROTOCOL"
|
||||
.sp
|
||||
The protocol of VpnCloud is kept as simple as possible to allow other
|
||||
implementations and to maximize the performance.
|
||||
.sp
|
||||
Every packet sent over UDP contains the following header (in order):
|
||||
.sp
|
||||
4 bytes \fBmagic\fP
|
||||
.RS 4
|
||||
This field is used to identify the packet and to sort out packets that do
|
||||
not belong. The default is \fB[0x76, 0x70, 0x6e, 0x01]\fP ("vpn\(rsx01").
|
||||
This field can be used to identify VpnCloud packets and might be set to
|
||||
something different to hide the protocol.
|
||||
.RE
|
||||
.sp
|
||||
1 byte \fBcrypto method\fP
|
||||
.RS 4
|
||||
This field specifies the method that must be used to decrypt the rest of the
|
||||
data. The currently supported methods are:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Method \fB0\fP, \fBNo encryption\fP: Rest of the data can be read without
|
||||
decrypting it.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Method \fB1\fP, \fBChaCha20\fP: The header is followed by a 12 byte
|
||||
\fInonce\fP. The rest of the data is encrypted with the
|
||||
\fBlibsodium::crypto_aead_chacha20poly1305_ietf\fP method, using the 8 byte
|
||||
header as additional data.
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Method \fB2\fP, \fBAES256\fP: The header is followed by a 12 byte \fInonce\fP.
|
||||
The rest of the data is encrypted with the
|
||||
\fBlibsodium::crypto_aead_aes256gcm\fP method, using the 8 byte header
|
||||
as additional data.
|
||||
.RE
|
||||
.RE
|
||||
.sp
|
||||
2 \fBreserved bytes\fP
|
||||
.RS 4
|
||||
that are currently unused and set to 0
|
||||
.RE
|
||||
.sp
|
||||
1 byte for the \fBmessage type\fP
|
||||
.RS 4
|
||||
This byte specifies the type of message that follows. Currently the
|
||||
following message types are supported:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Type 0: Data packet
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Type 1: Peer list
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Type 2: Initial message
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
Type 3: Closing message
|
||||
.RE
|
||||
.RE
|
||||
.sp
|
||||
After this 8 byte header, the rest of the message follows. It is encrypted using
|
||||
the method specified in the header.
|
||||
.sp
|
||||
In the decrypted data, the message as specified in the \fBmessage type\fP field
|
||||
will follow:
|
||||
.sp
|
||||
\fBData packet\fP (message type 0)
|
||||
.RS 4
|
||||
This packet contains payload. The format of the data depends on the device
|
||||
type. For TUN devices, this data contains an IP packet. For TAP devices it
|
||||
contains an Ethernet frame. The data starts right after the header and ends
|
||||
at the end of the packet.
|
||||
If it is an Ethernet frame, it will start with the destination MAC and end
|
||||
with the payload. It does not contain the preamble, SFD, padding, and CRC
|
||||
fields.
|
||||
.RE
|
||||
.sp
|
||||
\fBPeer list\fP (message type 1)
|
||||
.RS 4
|
||||
This packet contains the peer list of the sender. The first byte after the
|
||||
switch byte contains the number of IPv4 addresses that follow.
|
||||
After that, the specified number of addresses follow, where each address
|
||||
is encoded in 6 bytes. The first 4 bytes are the IPv4 address and the later
|
||||
2 bytes are port number (both in network byte order).
|
||||
After those addresses, the next byte contains the number of IPv6 addresses
|
||||
that follow. After that, the specified number of addresses follow, where
|
||||
each address is encoded in 18 bytes. The first 16 bytes are the IPv6 address
|
||||
and the later 2 bytes are port number (both in network byte order).
|
||||
.RE
|
||||
.sp
|
||||
\fBInitial message\fP (message type 2)
|
||||
.RS 4
|
||||
This packet contains the following information:
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
The stage of the initialization process
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
A random node id to distinguish different nodes
|
||||
.RE
|
||||
.sp
|
||||
.RS 4
|
||||
.ie n \{\
|
||||
\h'-04'\(bu\h'+03'\c
|
||||
.\}
|
||||
.el \{\
|
||||
.sp -1
|
||||
.IP \(bu 2.3
|
||||
.\}
|
||||
All the local subnets claimed by the nodes
|
||||
.RE
|
||||
.sp
|
||||
Its first byte marks the stage of the initial handshake process.
|
||||
The next 16 bytes contain the unique node id. After that,
|
||||
the list of local subnets follows.
|
||||
The subnet list is encoded in the following way: Its first byte of data
|
||||
contains the number of encoded subnets that follow. After that, the given
|
||||
number of encoded subnets follow.
|
||||
For each subnet, the first byte is the length of bytes in the base address
|
||||
and is followed by the given number of base address bytes and one additional
|
||||
byte that is the prefix length of the subnet.
|
||||
The addresses for the subnet will be encoded like they are encoded in their
|
||||
native protocol (4 bytes for IPv4, 16 bytes for IPv6, and 6 bytes for a MAC
|
||||
address) with the exception of MAC addresses in a VLan which will be encoded
|
||||
in 8 bytes where the first 2 bytes are the VLan number in network byte order
|
||||
and the later 6 bytes are the MAC address.
|
||||
.RE
|
||||
.sp
|
||||
\fBClosing message\fP (message type 3)
|
||||
.RS 4
|
||||
This packet does not contain any more data.
|
||||
.RE
|
||||
.sp
|
||||
Nodes are expected to send an \fBinitial message\fP with stage 0 whenever they
|
||||
connect to a node they were not connected to before. As a reply to this message,
|
||||
another initial should be sent with stage 1. Also a \fBpeer list\fP message should
|
||||
be sent as a reply.
|
||||
.sp
|
||||
When connected, nodes should periodically send their \fBpeer list\fP to all
|
||||
of their peers to spread this information and to avoid peer timeouts.
|
||||
To avoid the cubic growth of management traffic, nodes should at a certain
|
||||
network size start sending partial peer lists instead of the full list. A
|
||||
reasonable number would be about 20 peers. The subsets should be selected
|
||||
randomly.
|
||||
.sp
|
||||
Nodes should remove peers from their peer list after a certain period of
|
||||
inactivity or when receiving a \fBclosing message\fP. Before shutting down, nodes
|
||||
should send the closing message to all of their peers in order to avoid
|
||||
receiving further data until the timeout is reached.
|
||||
.sp
|
||||
Nodes should only add nodes to their peer list after receiving an initial
|
||||
message from them instead of adding them right from the peer list of another
|
||||
peer. This is necessary to avoid the case of a large network keeping dead nodes
|
||||
alive.
|
||||
.SH "COPYRIGHT"
|
||||
.sp
|
||||
Copyright \(co 2015\-2020 Dennis Schwerdel
|
||||
This software is licensed under GPL\-3 or newer (see LICENSE.md)
|
||||
Loading…
Reference in New Issue