mirror of https://github.com/dswd/vpncloud.git
Add service for ws proxy
This commit is contained in:
parent
0cffea7017
commit
38c3ba1177
|
@ -27,6 +27,7 @@ mkdir -p %{buildroot}/lib/systemd/system
|
||||||
mkdir -p %{buildroot}/usr/share/man/man1
|
mkdir -p %{buildroot}/usr/share/man/man1
|
||||||
cp %{buildroot}/../../../../../assets/example.net.disabled %{buildroot}/etc/vpncloud/example.net.disabled
|
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@.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 %{buildroot}/../../../../../target/vpncloud.1.gz %{buildroot}/usr/share/man/man1/vpncloud.1.gz
|
||||||
cp -a * %{buildroot}
|
cp -a * %{buildroot}
|
||||||
|
|
||||||
|
@ -38,6 +39,7 @@ rm -rf %{buildroot}
|
||||||
/etc/vpncloud/example.net.disabled
|
/etc/vpncloud/example.net.disabled
|
||||||
/usr/bin/vpncloud
|
/usr/bin/vpncloud
|
||||||
/lib/systemd/system/vpncloud@.service
|
/lib/systemd/system/vpncloud@.service
|
||||||
|
/lib/systemd/system/vpncloud-wsproxy.service
|
||||||
/usr/share/man/man1/vpncloud.1.gz
|
/usr/share/man/man1/vpncloud.1.gz
|
||||||
|
|
||||||
%defattr(-,root,root,-)
|
%defattr(-,root,root,-)
|
||||||
|
|
|
@ -74,6 +74,7 @@ assets = [
|
||||||
["target/release/vpncloud", "/usr/bin/vpncloud", "755"],
|
["target/release/vpncloud", "/usr/bin/vpncloud", "755"],
|
||||||
["assets/example.net.disabled", "/etc/vpncloud/example.net.disabled", "600"],
|
["assets/example.net.disabled", "/etc/vpncloud/example.net.disabled", "600"],
|
||||||
["assets/vpncloud@.service", "/lib/systemd/system/vpncloud@.service", "644"],
|
["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"]
|
["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