1318 lines
48 KiB
Text
1318 lines
48 KiB
Text
|
This is tinc.info, produced by makeinfo version 4.1 from tinc.texi.
|
|||
|
|
|||
|
INFO-DIR-SECTION Networking tools
|
|||
|
START-INFO-DIR-ENTRY
|
|||
|
* tinc: (tinc). The tinc Manual.
|
|||
|
END-INFO-DIR-ENTRY
|
|||
|
|
|||
|
This is the info manual for tinc, a Virtual Private Network daemon.
|
|||
|
|
|||
|
Copyright (C) 1998-2002 Ivo Timmermans <itimmermans@bigfoot.com>,
|
|||
|
Guus Sliepen <guus@sliepen.warande.net> and Wessel Dankers
|
|||
|
<wsl@nl.linux.org>.
|
|||
|
|
|||
|
$Id: tinc.texi,v 1.8.4.28 2002/04/09 11:43:29 guus Exp $
|
|||
|
|
|||
|
Permission is granted to make and distribute verbatim copies of this
|
|||
|
manual provided the copyright notice and this permission notice are
|
|||
|
preserved on all copies.
|
|||
|
|
|||
|
Permission is granted to copy and distribute modified versions of
|
|||
|
this manual under the conditions for verbatim copying, provided that the
|
|||
|
entire resulting derived work is distributed under the terms of a
|
|||
|
permission notice identical to this one.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir)
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Introduction:: Introduction
|
|||
|
* Preparations::
|
|||
|
* Installation::
|
|||
|
* Configuration::
|
|||
|
* Running tinc::
|
|||
|
* Technical information::
|
|||
|
* About us::
|
|||
|
* Concept Index:: All used terms explained
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Introduction, Next: Preparations, Prev: Top, Up: Top
|
|||
|
|
|||
|
Introduction
|
|||
|
************
|
|||
|
|
|||
|
tinc is a Virtual Private Network (VPN) daemon that uses tunneling
|
|||
|
and encryption to create a secure private network between hosts on the
|
|||
|
Internet.
|
|||
|
|
|||
|
Because the tunnel appears to the IP level network code as a normal
|
|||
|
network device, there is no need to adapt any existing software. The
|
|||
|
encrypted tunnels allows VPN sites to share information with each other
|
|||
|
over the Internet without exposing any information to others.
|
|||
|
|
|||
|
This document is the manual for tinc. Included are chapters on how
|
|||
|
to configure your computer to use tinc, as well as the configuration
|
|||
|
process of tinc itself.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* VPNs:: Virtual Private Networks in general
|
|||
|
* tinc:: about tinc
|
|||
|
* Supported platforms::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: VPNs, Next: tinc, Prev: Introduction, Up: Introduction
|
|||
|
|
|||
|
Virtual Private Networks
|
|||
|
========================
|
|||
|
|
|||
|
A Virtual Private Network or VPN is a network that can only be
|
|||
|
accessed by a few elected computers that participate. This goal is
|
|||
|
achievable in more than just one way.
|
|||
|
|
|||
|
Private networks can consist of a single stand-alone Ethernet LAN.
|
|||
|
Or even two computers hooked up using a null-modem cable. In these
|
|||
|
cases, it is obvious that the network is _private_, no one can access
|
|||
|
it from the outside. But if your computers are linked to the Internet,
|
|||
|
the network is not private anymore, unless one uses firewalls to block
|
|||
|
all private traffic. But then, there is no way to send private data to
|
|||
|
trusted computers on the other end of the Internet.
|
|||
|
|
|||
|
This problem can be solved by using _virtual_ networks. Virtual
|
|||
|
networks can live on top of other networks, but they use encapsulation
|
|||
|
to keep using their private address space so they do not interfere with
|
|||
|
the Internet. Mostly, virtual networks appear like a singe LAN, even
|
|||
|
though they can span the entire world. But virtual networks can't be
|
|||
|
secured by using firewalls, because the traffic that flows through it
|
|||
|
has to go through the Internet, where other people can look at it.
|
|||
|
|
|||
|
As is the case with either type of VPN, anybody could eavesdrop. Or
|
|||
|
worse, alter data. Hence it's probably advisable to encrypt the data
|
|||
|
that flows over the network.
|
|||
|
|
|||
|
When one introduces encryption, we can form a true VPN. Other
|
|||
|
people may see encrypted traffic, but if they don't know how to
|
|||
|
decipher it (they need to know the key for that), they cannot read the
|
|||
|
information that flows through the VPN. This is what tinc was made for.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: tinc, Next: Supported platforms, Prev: VPNs, Up: Introduction
|
|||
|
|
|||
|
tinc
|
|||
|
====
|
|||
|
|
|||
|
I really don't quite remember what got us started, but it must have
|
|||
|
been Guus' idea. He wrote a simple implementation (about 50 lines of
|
|||
|
C) that used the ethertap device that Linux knows of since somewhere
|
|||
|
about kernel 2.1.60. It didn't work immediately and he improved it a
|
|||
|
bit. At this stage, the project was still simply called `vpnd'.
|
|||
|
|
|||
|
Since then, a lot has changed--to say the least.
|
|||
|
|
|||
|
tinc now supports encryption, it consists of a single daemon (tincd)
|
|||
|
for both the receiving and sending end, it has become largely
|
|||
|
runtime-configurable--in short, it has become a full-fledged
|
|||
|
professional package.
|
|||
|
|
|||
|
tinc also allows more than two sites to connect to eachother and
|
|||
|
form a single VPN. Traditionally VPNs are created by making tunnels,
|
|||
|
which only have two endpoints. Larger VPNs with more sites are created
|
|||
|
by adding more tunnels. tinc takes another approach: only endpoints
|
|||
|
are specified, the software itself will take care of creating the
|
|||
|
tunnels. This allows for easier configuration and improved scalability.
|
|||
|
|
|||
|
A lot can--and will be--changed. We have a number of things that we
|
|||
|
would like to see in the future releases of tinc. Not everything will
|
|||
|
be available in the near future. Our first objective is to make tinc
|
|||
|
work perfectly as it stands, and then add more advanced features.
|
|||
|
|
|||
|
Meanwhile, we're always open-minded towards new ideas. And we're
|
|||
|
available too.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Supported platforms, Prev: tinc, Up: Introduction
|
|||
|
|
|||
|
Supported platforms
|
|||
|
===================
|
|||
|
|
|||
|
tinc has been verified to work under Linux, FreeBSD, OpenBSD and
|
|||
|
Solaris, with various hardware architectures. These are some of the
|
|||
|
platforms that are supported by the universal tun/tap device driver or
|
|||
|
other virtual network device drivers. Without such a driver, tinc will
|
|||
|
most likely compile and run, but it will not be able to send or receive
|
|||
|
data packets.
|
|||
|
|
|||
|
For an up to date list of supported platforms, please check the list
|
|||
|
on our website: `http://tinc.nl.linux.org/platforms.html'.
|
|||
|
|
|||
|
Linux
|
|||
|
-----
|
|||
|
|
|||
|
tinc was first written for Linux running on an intel x86 processor,
|
|||
|
so this is the best supported platform. The protocol however, and
|
|||
|
actually anything about tinc, has been rewritten to support random byte
|
|||
|
ordering and arbitrary word length. So in theory it should run on other
|
|||
|
processors that Linux runs on. It has already been verified to run on
|
|||
|
alpha and sparc processors as well.
|
|||
|
|
|||
|
tinc uses the ethertap device or the universal tun/tap driver. The
|
|||
|
former is provided in the standard kernel from version 2.1.60 up to
|
|||
|
2.3.x, but has been replaced in favour of the tun/tap driver in kernel
|
|||
|
versions 2.4.0 and later.
|
|||
|
|
|||
|
FreeBSD
|
|||
|
-------
|
|||
|
|
|||
|
tinc on FreeBSD relies on the universal tun/tap driver for its data
|
|||
|
acquisition from the kernel. Therefore, tinc will work on the same
|
|||
|
platforms as this driver. These are: FreeBSD 3.x, 4.x, 5.x.
|
|||
|
|
|||
|
OpenBSD
|
|||
|
-------
|
|||
|
|
|||
|
tinc on OpenBSD relies on the tun driver for its data acquisition
|
|||
|
from the kernel. It has been verified to work under at least OpenBSD
|
|||
|
2.9.
|
|||
|
|
|||
|
Tunneling IPv6 packets may not work on OpenBSD.
|
|||
|
|
|||
|
Solaris
|
|||
|
-------
|
|||
|
|
|||
|
tinc on Solaris relies on the universal tun/tap driver for its data
|
|||
|
acquisition from the kernel. Therefore, tinc will work on the same
|
|||
|
platforms as this driver. These are: Solaris 8 (SunOS 5.8).
|
|||
|
|
|||
|
IPv6 packets cannot be tunneled on Solaris.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Preparations, Next: Installation, Prev: Introduction, Up: Top
|
|||
|
|
|||
|
Preparations
|
|||
|
************
|
|||
|
|
|||
|
This chapter contains information on how to prepare your system to
|
|||
|
support tinc.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Configuring the kernel::
|
|||
|
* Libraries::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuring the kernel, Next: Libraries, Prev: Preparations, Up: Preparations
|
|||
|
|
|||
|
Configuring the kernel
|
|||
|
======================
|
|||
|
|
|||
|
If you are running Linux, chances are good that your kernel already
|
|||
|
supports all the devices that tinc needs for proper operation. For
|
|||
|
example, the standard kernel from Redhat Linux already has support for
|
|||
|
ethertap and netlink compiled in. Debian users can use the modconf
|
|||
|
utility to select the modules. If your Linux distribution supports
|
|||
|
this method of selecting devices, look out for something called
|
|||
|
`ethertap', and `netlink_dev' if it is using a kernel version prior to
|
|||
|
2.4.0. In that case you will need both these devices. If you are using
|
|||
|
kernel 2.4.0 or later, you need to select `tun'.
|
|||
|
|
|||
|
If you can install these devices in a similar manner, you may skip
|
|||
|
this section. Otherwise, you will have to recompile the kernel in
|
|||
|
order to turn on the required features. If you are unfamiliar with the
|
|||
|
process of configuring and compiling a new kernel, you should read the
|
|||
|
Kernel HOWTO (http://howto.linuxberg.com/LDP/HOWTO/Kernel-HOWTO.html)
|
|||
|
first.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Configuration of Linux kernels 2.1.60 up to 2.4.0::
|
|||
|
* Configuration of Linux kernels 2.4.0 and higher::
|
|||
|
* Configuration of FreeBSD kernels::
|
|||
|
* Configuration of OpenBSD kernels::
|
|||
|
* Configuration of Solaris kernels::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration of Linux kernels 2.1.60 up to 2.4.0, Next: Configuration of Linux kernels 2.4.0 and higher, Prev: Configuring the kernel, Up: Configuring the kernel
|
|||
|
|
|||
|
Configuration of Linux kernels 2.1.60 up to 2.4.0
|
|||
|
-------------------------------------------------
|
|||
|
|
|||
|
Here are the options you have to turn on when configuring a new
|
|||
|
kernel:
|
|||
|
|
|||
|
Code maturity level options
|
|||
|
[*] Prompt for development and/or incomplete code/drivers
|
|||
|
Networking options
|
|||
|
[*] Kernel/User netlink socket
|
|||
|
<M> Netlink device emulation
|
|||
|
Network device support
|
|||
|
<M> Ethertap network tap
|
|||
|
|
|||
|
If you want to run more than one instance of tinc or other programs
|
|||
|
that use the ethertap, you have to compile the ethertap driver as a
|
|||
|
module, otherwise you can also choose to compile it directly into the
|
|||
|
kernel.
|
|||
|
|
|||
|
If you decide to build any of these as dynamic kernel modules, it's
|
|||
|
a good idea to add these lines to `/etc/modules.conf':
|
|||
|
|
|||
|
alias char-major-36 netlink_dev
|
|||
|
alias tap0 ethertap
|
|||
|
options tap0 -o tap0 unit=0
|
|||
|
alias tap1 ethertap
|
|||
|
options tap1 -o tap1 unit=1
|
|||
|
...
|
|||
|
alias tap_N_ ethertap
|
|||
|
options tap_N_ -o tap_N_ unit=_N_
|
|||
|
|
|||
|
Add as much alias/options lines as necessary.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration of Linux kernels 2.4.0 and higher, Next: Configuration of FreeBSD kernels, Prev: Configuration of Linux kernels 2.1.60 up to 2.4.0, Up: Configuring the kernel
|
|||
|
|
|||
|
Configuration of Linux kernels 2.4.0 and higher
|
|||
|
-----------------------------------------------
|
|||
|
|
|||
|
Here are the options you have to turn on when configuring a new
|
|||
|
kernel:
|
|||
|
|
|||
|
Code maturity level options
|
|||
|
[*] Prompt for development and/or incomplete code/drivers
|
|||
|
Network device support
|
|||
|
<M> Universal tun/tap device driver support
|
|||
|
|
|||
|
It's not necessary to compile this driver as a module, even if you
|
|||
|
are going to run more than one instance of tinc.
|
|||
|
|
|||
|
If you have an early 2.4 kernel, you can choose both the tun/tap
|
|||
|
driver and the `Ethertap network tap' device. This latter is marked
|
|||
|
obsolete, and chances are that it won't even function correctly
|
|||
|
anymore. Make sure you select the universal tun/tap driver.
|
|||
|
|
|||
|
If you decide to build the tun/tap driver as a kernel module, add
|
|||
|
these lines to `/etc/modules.conf':
|
|||
|
|
|||
|
alias char-major-10-200 tun
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration of FreeBSD kernels, Next: Configuration of OpenBSD kernels, Prev: Configuration of Linux kernels 2.4.0 and higher, Up: Configuring the kernel
|
|||
|
|
|||
|
Configuration of FreeBSD kernels
|
|||
|
--------------------------------
|
|||
|
|
|||
|
This section will contain information on how to configure your
|
|||
|
FreeBSD kernel to support the universal tun/tap device. For 4.1 and
|
|||
|
higher versions, this is included in the default kernel configuration,
|
|||
|
for earlier systems (4.0 and earlier), you need to install the
|
|||
|
universal tun/tap driver yourself.
|
|||
|
|
|||
|
Unfortunately somebody still has to write the text.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration of OpenBSD kernels, Next: Configuration of Solaris kernels, Prev: Configuration of FreeBSD kernels, Up: Configuring the kernel
|
|||
|
|
|||
|
Configuration of OpenBSD kernels
|
|||
|
--------------------------------
|
|||
|
|
|||
|
This section will contain information on how to configure your
|
|||
|
OpenBSD kernel to support the tun device. For 2.9 and 3.0 systems,
|
|||
|
this is included in the default kernel configuration.
|
|||
|
|
|||
|
Unfortunately somebody still has to write the text.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration of Solaris kernels, Prev: Configuration of OpenBSD kernels, Up: Configuring the kernel
|
|||
|
|
|||
|
Configuration of Solaris kernels
|
|||
|
--------------------------------
|
|||
|
|
|||
|
This section will contain information on how to configure your
|
|||
|
Solaris kernel to support the universal tun/tap device. For Solaris 8
|
|||
|
(SunOS 5.8), this is included in the default kernel configuration.
|
|||
|
|
|||
|
Unfortunately somebody still has to write the text.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Libraries, Prev: Configuring the kernel, Up: Preparations
|
|||
|
|
|||
|
Libraries
|
|||
|
=========
|
|||
|
|
|||
|
Before you can configure or build tinc, you need to have the OpenSSL
|
|||
|
library installed on your system. If you try to configure tinc without
|
|||
|
having installed it, configure will give you an error message, and stop.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* OpenSSL::
|
|||
|
* zlib::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: OpenSSL, Next: zlib, Prev: Libraries, Up: Libraries
|
|||
|
|
|||
|
OpenSSL
|
|||
|
-------
|
|||
|
|
|||
|
For all cryptography-related functions, tinc uses the functions
|
|||
|
provided by the OpenSSL library.
|
|||
|
|
|||
|
If this library is not installed, you wil get an error when
|
|||
|
configuring tinc for build. Support for running tinc without having
|
|||
|
OpenSSL installed _may_ be added in the future.
|
|||
|
|
|||
|
You can use your operating system's package manager to install this
|
|||
|
if available. Make sure you install the development AND runtime
|
|||
|
versions of this package.
|
|||
|
|
|||
|
If you have to install OpenSSL manually, you can get the source code
|
|||
|
from <http://www.openssl.org/>. Instructions on how to configure,
|
|||
|
build and install this package are included within the package. Please
|
|||
|
make sure you build development and runtime libraries (which is the
|
|||
|
default).
|
|||
|
|
|||
|
If you installed the OpenSSL libraries from source, it may be
|
|||
|
necessary to let configure know where they are, by passing configure
|
|||
|
one of the -with-openssl-* parameters.
|
|||
|
|
|||
|
--with-openssl=DIR OpenSSL library and headers prefix
|
|||
|
--with-openssl-include=DIR OpenSSL headers directory
|
|||
|
(Default is OPENSSL_DIR/include)
|
|||
|
--with-openssl-lib=DIR OpenSSL library directory
|
|||
|
(Default is OPENSSL_DIR/lib)
|
|||
|
|
|||
|
License
|
|||
|
.......
|
|||
|
|
|||
|
Since the license under which OpenSSL is distributed is not directly
|
|||
|
compatible with the terms of the GNU GPL
|
|||
|
`http://www.openssl.org/support/faq.html#LEGAL2', therefore we include
|
|||
|
an addition to the GPL (see also the file COPYING.README):
|
|||
|
|
|||
|
This program is released under the GPL with the additional
|
|||
|
exemption that compiling, linking, and/or using OpenSSL is
|
|||
|
allowed. You may provide binary packages linked to the OpenSSL
|
|||
|
libraries, provided that all other requirements of the GPL are met.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: zlib, Prev: OpenSSL, Up: Libraries
|
|||
|
|
|||
|
zlib
|
|||
|
----
|
|||
|
|
|||
|
For the optional compression of UDP packets, tinc uses the functions
|
|||
|
provided by the zlib library.
|
|||
|
|
|||
|
If this library is not installed, you wil get an error when
|
|||
|
configuring tinc for build. Support for running tinc without having
|
|||
|
zlib installed _may_ be added in the future.
|
|||
|
|
|||
|
You can use your operating system's package manager to install this
|
|||
|
if available. Make sure you install the development AND runtime
|
|||
|
versions of this package.
|
|||
|
|
|||
|
If you have to install zlib manually, you can get the source code
|
|||
|
from <http://www.gzip.org/zlib/>. Instructions on how to configure,
|
|||
|
build and install this package are included within the package. Please
|
|||
|
make sure you build development and runtime libraries (which is the
|
|||
|
default).
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Installation, Next: Configuration, Prev: Preparations, Up: Top
|
|||
|
|
|||
|
Installation
|
|||
|
************
|
|||
|
|
|||
|
If you use Debian, you may want to install one of the precompiled
|
|||
|
packages for your system. These packages are equipped with system
|
|||
|
startup scripts and sample configurations.
|
|||
|
|
|||
|
If you cannot use one of the precompiled packages, or you want to
|
|||
|
compile tinc for yourself, you can use the source. The source is
|
|||
|
distributed under the GNU General Public License (GPL). Download the
|
|||
|
source from the download page (http://tinc.nl.linux.org/download.html),
|
|||
|
which has the checksums of these files listed; you may wish to check
|
|||
|
these with md5sum before continuing.
|
|||
|
|
|||
|
tinc comes in a convenient autoconf/automake package, which you can
|
|||
|
just treat the same as any other package. Which is just untar it, type
|
|||
|
`configure' and then `make'. More detailed instructions are in the
|
|||
|
file `INSTALL', which is included in the source distribution.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Building and installing tinc::
|
|||
|
* System files::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Building and installing tinc, Next: System files, Prev: Installation, Up: Installation
|
|||
|
|
|||
|
Building and installing tinc
|
|||
|
============================
|
|||
|
|
|||
|
Detailed instructions on configuring the source, building tinc and
|
|||
|
installing tinc can be found in the file called `INSTALL'.
|
|||
|
|
|||
|
If you happen to have a binary package for tinc for your
|
|||
|
distribution, you can use the package management tools of that
|
|||
|
distribution to install tinc. The documentation that comes along with
|
|||
|
your distribution will tell you how to do that.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: System files, Prev: Building and installing tinc, Up: Installation
|
|||
|
|
|||
|
System files
|
|||
|
============
|
|||
|
|
|||
|
Before you can run tinc, you must make sure you have all the needed
|
|||
|
files on your system.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Device files::
|
|||
|
* Other files::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Device files, Next: Other files, Prev: System files, Up: System files
|
|||
|
|
|||
|
Device files
|
|||
|
------------
|
|||
|
|
|||
|
First, you'll need the special device file(s) that form the interface
|
|||
|
between the kernel and the daemon.
|
|||
|
|
|||
|
The permissions for these files have to be such that only the super
|
|||
|
user may read/write to this file. You'd want this, because otherwise
|
|||
|
eavesdropping would become a bit too easy. This does, however, imply
|
|||
|
that you'd have to run tincd as root.
|
|||
|
|
|||
|
If you use Linux and have a kernel version prior to 2.4.0, you have
|
|||
|
to make the ethertap devices:
|
|||
|
|
|||
|
mknod -m 600 /dev/tap0 c 36 16
|
|||
|
chown 0.0 /dev/tap0
|
|||
|
mknod -m 600 /dev/tap1 c 36 17
|
|||
|
chown 0.0 /dev/tap0
|
|||
|
...
|
|||
|
mknod -m 600 /dev/tap_N_ c 36 _N+16_
|
|||
|
chown 0.0 /dev/tap_N_
|
|||
|
|
|||
|
There is a maximum of 16 ethertap devices.
|
|||
|
|
|||
|
If you use the universal tun/tap driver, you have to create the
|
|||
|
following device file (unless it already exist):
|
|||
|
|
|||
|
mknod -m 600 /dev/tun c 10 200
|
|||
|
chown 0.0 /dev/tun
|
|||
|
|
|||
|
If you use Linux, and you run the new 2.4 kernel using the devfs
|
|||
|
filesystem, then the tun/tap device will probably be automatically
|
|||
|
generated as `/dev/misc/net/tun'.
|
|||
|
|
|||
|
Unlike the ethertap device, you do not need multiple device files if
|
|||
|
you are planning to run multiple tinc daemons.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Other files, Prev: Device files, Up: System files
|
|||
|
|
|||
|
Other files
|
|||
|
-----------
|
|||
|
|
|||
|
`/etc/networks'
|
|||
|
...............
|
|||
|
|
|||
|
You may add a line to `/etc/networks' so that your VPN will get a
|
|||
|
symbolic name. For example:
|
|||
|
|
|||
|
myvpn 10.0.0.0
|
|||
|
|
|||
|
`/etc/services'
|
|||
|
...............
|
|||
|
|
|||
|
You may add this line to `/etc/services'. The effect is that you
|
|||
|
may supply a `tinc' as a valid port number to some programs. The
|
|||
|
number 655 is registered with the IANA.
|
|||
|
|
|||
|
tinc 655/tcp TINC
|
|||
|
tinc 655/udp TINC
|
|||
|
# Ivo Timmermans <itimmermans@bigfoot.com>
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration, Next: Running tinc, Prev: Installation, Up: Top
|
|||
|
|
|||
|
Configuration
|
|||
|
*************
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Configuration introduction::
|
|||
|
* Multiple networks::
|
|||
|
* How connections work::
|
|||
|
* Configuration files::
|
|||
|
* Generating keypairs::
|
|||
|
* Network interfaces::
|
|||
|
* Example configuration::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration introduction, Next: Multiple networks, Prev: Configuration, Up: Configuration
|
|||
|
|
|||
|
Configuration introduction
|
|||
|
==========================
|
|||
|
|
|||
|
Before actually starting to configure tinc and editing files, make
|
|||
|
sure you have read this entire section so you know what to expect.
|
|||
|
Then, make it clear to yourself how you want to organize your VPN: What
|
|||
|
are the nodes (computers running tinc)? What IP addresses/subnets do
|
|||
|
they have? What is the network mask of the entire VPN? Do you need
|
|||
|
special firewall rules? Do you have to set up masquerading or
|
|||
|
forwarding rules? These questions can only be answered by yourself,
|
|||
|
you will not find the answers in this documentation. Make sure you
|
|||
|
have an adequate understanding of networks in general. A good resource
|
|||
|
on networking is the Linux Network Administrators Guide
|
|||
|
(http://www.linuxdoc.org/LDP/nag2/).
|
|||
|
|
|||
|
If you have everything clearly pictured in your mind, proceed in the
|
|||
|
following order: First, generate the configuration files (`tinc.conf',
|
|||
|
your host configuration file, `tinc-up' and perhaps `tinc-down'). Then
|
|||
|
generate the keypairs. Finally, distribute the host configuration
|
|||
|
files. These steps are described in the subsections below.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Multiple networks, Next: How connections work, Prev: Configuration introduction, Up: Configuration
|
|||
|
|
|||
|
Multiple networks
|
|||
|
=================
|
|||
|
|
|||
|
In order to allow you to run more than one tinc daemon on one
|
|||
|
computer, for instance if your computer is part of more than one VPN,
|
|||
|
you can assign a "netname" to your VPN. It is not required if you only
|
|||
|
run one tinc daemon, it doesn't even have to be the same on all the
|
|||
|
sites of your VPN, but it is recommended that you choose one anyway.
|
|||
|
|
|||
|
We will asume you use a netname throughout this document. This
|
|||
|
means that you call tincd with the -n argument, which will assign a
|
|||
|
netname to this daemon.
|
|||
|
|
|||
|
The effect of this is that the daemon will set its configuration
|
|||
|
"root" to /etc/tinc/netname/, where netname is your argument to the -n
|
|||
|
option. You'll notice that it appears in syslog as "tinc.netname".
|
|||
|
|
|||
|
However, it is not strictly necessary that you call tinc with the -n
|
|||
|
option. In this case, the network name would just be empty, and it will
|
|||
|
be used as such. tinc now looks for files in /etc/tinc/, instead of
|
|||
|
/etc/tinc/netname/; the configuration file should be
|
|||
|
/etc/tinc/tinc.conf, and the host configuration files are now expected
|
|||
|
to be in /etc/tinc/hosts/.
|
|||
|
|
|||
|
But it is highly recommended that you use this feature of tinc,
|
|||
|
because it will be so much clearer whom your daemon talks to. Hence,
|
|||
|
we will assume that you use it.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: How connections work, Next: Configuration files, Prev: Multiple networks, Up: Configuration
|
|||
|
|
|||
|
How connections work
|
|||
|
====================
|
|||
|
|
|||
|
When tinc starts up, it parses the command-line options and then
|
|||
|
reads in the configuration file. If it sees a `ConnectTo' value
|
|||
|
pointing to another tinc daemon in the file, it will try to connect to
|
|||
|
that other one. Whether this succeeds or not and whether `ConnectTo'
|
|||
|
is specified or not, tinc will listen for incoming connection from
|
|||
|
other deamons. If you did specify a `ConnectTo' value and the other
|
|||
|
side is not responding, tinc will keep retrying. This means that once
|
|||
|
started, tinc will stay running until you tell it to stop, and failures
|
|||
|
to connect to other tinc daemons will not stop your tinc daemon for
|
|||
|
trying again later. This means you don't have to intervene if there
|
|||
|
are any network problems.
|
|||
|
|
|||
|
There is no real distinction between a server and a client in tinc.
|
|||
|
If you wish, you can view a tinc daemon without a `ConnectTo' value as
|
|||
|
a server, and one which does specify such a value as a client. It does
|
|||
|
not matter if two tinc daemons have a `ConnectTo' value pointing to
|
|||
|
eachother however.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Configuration files, Next: Generating keypairs, Prev: How connections work, Up: Configuration
|
|||
|
|
|||
|
Configuration files
|
|||
|
===================
|
|||
|
|
|||
|
The actual configuration of the daemon is done in the file
|
|||
|
`/etc/tinc/netname/tinc.conf' and at least one other file in the
|
|||
|
directory `/etc/tinc/netname/hosts/'.
|
|||
|
|
|||
|
These file consists of comments (lines started with a #) or
|
|||
|
assignments in the form of
|
|||
|
|
|||
|
Variable = Value.
|
|||
|
|
|||
|
The variable names are case insensitive, and any spaces, tabs,
|
|||
|
newlines and carriage returns are ignored. Note: it is not required
|
|||
|
that you put in the `=' sign, but doing so improves readability. If
|
|||
|
you leave it out, remember to replace it with at least one space
|
|||
|
character.
|
|||
|
|
|||
|
In this section all valid variables are listed in alphabetical order.
|
|||
|
The default value is given between parentheses, other comments are
|
|||
|
between square brackets and required directives are given in *bold*.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Main configuration variables::
|
|||
|
* Host configuration variables::
|
|||
|
* How to configure::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Main configuration variables, Next: Host configuration variables, Prev: Configuration files, Up: Configuration files
|
|||
|
|
|||
|
Main configuration variables
|
|||
|
----------------------------
|
|||
|
|
|||
|
AddressFamily = <ipv4|ipv6|any> (ipv4) [experimental]
|
|||
|
This option affects the address family of listening and outgoing
|
|||
|
sockets. If "any" is selected, then depending on the operating
|
|||
|
system both IPv4 and IPv6 or just IPv6 listening sockets will be
|
|||
|
created.
|
|||
|
|
|||
|
BindToInterface = <interface> [experimental]
|
|||
|
If you have more than one network interface in your computer, tinc
|
|||
|
will by default listen on all of them for incoming connections.
|
|||
|
It is possible to bind tinc to a single interface like eth0 or
|
|||
|
ppp0 with this variable.
|
|||
|
|
|||
|
This option may not work on all platforms.
|
|||
|
|
|||
|
*ConnectTo = <name>*
|
|||
|
Specifies which host to connect to on startup. Multiple ConnectTo
|
|||
|
variables may be specified, if connecting to the first one fails
|
|||
|
then tinc will try the next one, and so on. It is possible to
|
|||
|
specify hostnames for dynamic IP addresses (like those given on
|
|||
|
dyndns.org), tinc will not cache the resolved IP address.
|
|||
|
|
|||
|
If you don't specify a host with ConnectTo, regardless of whether a
|
|||
|
value for ConnectPort is given, tinc won't connect at all, and will
|
|||
|
instead just listen for incoming connections.
|
|||
|
|
|||
|
*Device = <device>* (/dev/tap0 or /dev/misc/net/tun)
|
|||
|
The virtual network device to use. Note that you can only use one
|
|||
|
device per daemon. See also *Note Device files::.
|
|||
|
|
|||
|
Hostnames = <yes|no> (no)
|
|||
|
This option selects whether IP addresses (both real and on the VPN)
|
|||
|
should be resolved. Since DNS lookups are blocking, it might
|
|||
|
affect tinc's efficiency, even stopping the daemon for a few
|
|||
|
seconds everytime it does a lookup if your DNS server is not
|
|||
|
responding.
|
|||
|
|
|||
|
This does not affect resolving hostnames to IP addresses from the
|
|||
|
configuration file.
|
|||
|
|
|||
|
Interface = <interface>
|
|||
|
Defines the name of the interface corresponding to the virtual
|
|||
|
network device. Depending on the operating system and the type of
|
|||
|
device this may or may not actually set the name. Currently this
|
|||
|
option only affects the Linux tun/tap device.
|
|||
|
|
|||
|
Mode = <router|switch|hub> (router)
|
|||
|
This option selects the way packets are routed to other daemons.
|
|||
|
|
|||
|
router
|
|||
|
In this mode Subnet variables in the host configuration files
|
|||
|
will be used to form a routing table. Only unicast packets
|
|||
|
of routable protocols (IPv4 and IPv6) are supported in this
|
|||
|
mode.
|
|||
|
|
|||
|
switch
|
|||
|
In this mode the MAC addresses of the packets on the VPN will
|
|||
|
be used to dynamically create a routing table just like an
|
|||
|
Ethernet switch does. Unicast, multicast and broadcast
|
|||
|
packets of every protocol that runs over Ethernet are
|
|||
|
supported in this mode at the cost of frequent broadcast ARP
|
|||
|
requests and routing table updates.
|
|||
|
|
|||
|
hub
|
|||
|
This mode is almost the same as the switch mode, but instead
|
|||
|
every packet will be broadcast to the other daemons while no
|
|||
|
routing table is managed.
|
|||
|
|
|||
|
KeyExpire = <seconds> (3600)
|
|||
|
This option controls the time the encryption keys used to encrypt
|
|||
|
the data are valid. It is common practice to change keys at
|
|||
|
regular intervals to make it even harder for crackers, even though
|
|||
|
it is thought to be nearly impossible to crack a single key.
|
|||
|
|
|||
|
MACExpire = <seconds> (600)
|
|||
|
This option controls the amount of time MAC addresses are kept
|
|||
|
before they are removed. This only has effect when Mode is set to
|
|||
|
"switch".
|
|||
|
|
|||
|
*Name = <name>*
|
|||
|
This is a symbolic name for this connection. It can be anything
|
|||
|
|
|||
|
PingTimeout = <seconds> (60)
|
|||
|
The number of seconds of inactivity that tinc will wait before
|
|||
|
sending a probe to the other end. If that other end doesn't
|
|||
|
answer within that same amount of seconds, the connection is
|
|||
|
terminated, and the others will be notified of this.
|
|||
|
|
|||
|
PriorityInheritance = <yes|no> (no) [experimental]
|
|||
|
When this option is enabled the value of the TOS field of tunneled
|
|||
|
IPv4 packets will be inherited by the UDP packets that are sent
|
|||
|
out.
|
|||
|
|
|||
|
PrivateKey = <key> [obsolete]
|
|||
|
This is the RSA private key for tinc. However, for safety reasons
|
|||
|
it is advised to store private keys of any kind in separate files.
|
|||
|
This prevents accidental eavesdropping if you are editting the
|
|||
|
configuration file.
|
|||
|
|
|||
|
*PrivateKeyFile = <path>* [recommended]
|
|||
|
This is the full path name of the RSA private key file that was
|
|||
|
generated by "tincd -generate-keys". It must be a full path, not a
|
|||
|
relative directory.
|
|||
|
|
|||
|
Note that there must be exactly one of PrivateKey or PrivateKeyFile
|
|||
|
specified in the configuration file.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Host configuration variables, Next: How to configure, Prev: Main configuration variables, Up: Configuration files
|
|||
|
|
|||
|
Host configuration variables
|
|||
|
----------------------------
|
|||
|
|
|||
|
*Address = <IP address|hostname>* [recommended]
|
|||
|
This variable is only required if you want to connect to this
|
|||
|
host. It must resolve to the external IP address where the host
|
|||
|
can be reached, not the one that is internal to the VPN.
|
|||
|
|
|||
|
Cipher = <cipher> (blowfish)
|
|||
|
The symmetric cipher algorithm used to encrypt UDP packets. Any
|
|||
|
cipher supported by OpenSSL is recognized.
|
|||
|
|
|||
|
Compression = <level> (0)
|
|||
|
This option sets the level of compression used for UDP packets.
|
|||
|
Possible values are 0 (off), 1 (fast) and any integer up to 9
|
|||
|
(best).
|
|||
|
|
|||
|
Digest = <digest> (sha1)
|
|||
|
The digest algorithm used to authenticate UDP packets. Any digest
|
|||
|
supported by OpenSSL is recognized. Furthermore, specifying
|
|||
|
"none" will turn off packet authentication.
|
|||
|
|
|||
|
IndirectData = <yes|no> (no)
|
|||
|
This option specifies whether other tinc daemons besides the one
|
|||
|
you specified with ConnectTo can make a direct connection to you.
|
|||
|
This is especially useful if you are behind a firewall and it is
|
|||
|
impossible to make a connection from the outside to your tinc
|
|||
|
daemon. Otherwise, it is best to leave this option out or set it
|
|||
|
to no.
|
|||
|
|
|||
|
MACLength = <length> (4)
|
|||
|
The length of the message authentication code used to authenticate
|
|||
|
UDP packets. Can be anything from 0 up to the length of the
|
|||
|
digest produced by the digest algorithm.
|
|||
|
|
|||
|
Port = <port> (655)
|
|||
|
Connect to the upstream host (given with the ConnectTo directive)
|
|||
|
on port port. port may be given in decimal (default), octal (when
|
|||
|
preceded by a single zero) o hexadecimal (prefixed with 0x). port
|
|||
|
is the port number for both the UDP and the TCP (meta) connections.
|
|||
|
|
|||
|
PublicKey = <key> [obsolete]
|
|||
|
This is the RSA public key for this host.
|
|||
|
|
|||
|
PublicKeyFile = <path> [obsolete]
|
|||
|
This is the full path name of the RSA public key file that was
|
|||
|
generated by "tincd -generate-keys". It must be a full path, not
|
|||
|
a relative directory.
|
|||
|
|
|||
|
From version 1.0pre4 on tinc will store the public key directly
|
|||
|
into the host configuration file in PEM format, the above two
|
|||
|
options then are not necessary. Either the PEM format is used, or
|
|||
|
exactly *one of the above two options* must be specified in each
|
|||
|
host configuration file, if you want to be able to establish a
|
|||
|
connection with that host.
|
|||
|
|
|||
|
Subnet = <address[/prefixlength]>
|
|||
|
The subnet which this tinc daemon will serve. tinc tries to look
|
|||
|
up which other daemon it should send a packet to by searching the
|
|||
|
appropiate subnet. If the packet matches a subnet, it will be
|
|||
|
sent to the daemon who has this subnet in his host configuration
|
|||
|
file. Multiple subnet lines can be specified for each daemon.
|
|||
|
|
|||
|
Subnets can either be single MAC, IPv4 or IPv6 addresses, in which
|
|||
|
case a subnet consisting of only that single address is assumed,
|
|||
|
or they can be a IPv4 or IPv6 network address with a prefixlength.
|
|||
|
Shorthand notations are not supported. For example, IPv4 subnets
|
|||
|
must be in a form like 192.168.1.0/24, where 192.168.1.0 is the
|
|||
|
network address and 24 is the number of bits set in the netmask.
|
|||
|
Note that subnets like 192.168.1.1/24 are invalid! Read a
|
|||
|
networking HOWTO/FAQ/guide if you don't understand this. IPv6
|
|||
|
subnets are notated like fec0:0:0:1:0:0:0:0/64. MAC addresses are
|
|||
|
notated like 0:1a:2b:3c:4d:5e.
|
|||
|
|
|||
|
prefixlength is the number of bits set to 1 in the netmask part;
|
|||
|
for example: netmask 255.255.255.0 would become /24, 255.255.252.0
|
|||
|
becomes /22. This conforms to standard CIDR notation as described
|
|||
|
in RFC1519 (ftp://ftp.isi.edu/in-notes/rfc1519.txt)
|
|||
|
|
|||
|
TCPonly = <yes|no> (no) [experimental]
|
|||
|
If this variable is set to yes, then the packets are tunnelled
|
|||
|
over a TCP connection instead of a UDP connection. This is
|
|||
|
especially useful for those who want to run a tinc daemon from
|
|||
|
behind a masquerading firewall, or if UDP packet routing is
|
|||
|
disabled somehow. Setting this options also implicitly sets
|
|||
|
IndirectData.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: How to configure, Prev: Host configuration variables, Up: Configuration files
|
|||
|
|
|||
|
How to configure
|
|||
|
----------------
|
|||
|
|
|||
|
Step 1. Creating the main configuration file
|
|||
|
.............................................
|
|||
|
|
|||
|
The main configuration file will be called
|
|||
|
`/etc/tinc/netname/tinc.conf'. Adapt the following example to create a
|
|||
|
basic configuration file:
|
|||
|
|
|||
|
Name = _yourname_
|
|||
|
Device = _/dev/tap0_
|
|||
|
PrivateKeyFile = /etc/tinc/_netname_/rsa_key.priv
|
|||
|
|
|||
|
Then, if you know to which other tinc daemon(s) yours is going to
|
|||
|
connect, add `ConnectTo' values.
|
|||
|
|
|||
|
Step 2. Creating your host configuration file
|
|||
|
..............................................
|
|||
|
|
|||
|
If you added a line containing `Name = yourname' in the main
|
|||
|
configuarion file, you will need to create a host configuration file
|
|||
|
`/etc/tinc/netname/hosts/yourname'. Adapt the following example to
|
|||
|
create a host configuration file:
|
|||
|
|
|||
|
Address = _your.real.hostname.org_
|
|||
|
Subnet = _192.168.1.0/24_
|
|||
|
|
|||
|
You can also use an IP address instead of a hostname. The `Subnet'
|
|||
|
specifies the address range that is local for _your part of the VPN
|
|||
|
only_. If you have multiple address ranges you can specify more than
|
|||
|
one `Subnet'. You might also need to add a `Port' if you want your
|
|||
|
tinc daemon to run on a different port number than the default (655).
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Generating keypairs, Next: Network interfaces, Prev: Configuration files, Up: Configuration
|
|||
|
|
|||
|
Generating keypairs
|
|||
|
===================
|
|||
|
|
|||
|
Now that you have already created the main configuration file and
|
|||
|
your host configuration file, you can easily create a public/private
|
|||
|
keypair by entering the following command:
|
|||
|
|
|||
|
tincd -n _netname_ -K
|
|||
|
|
|||
|
tinc will generate a public and a private key and ask you where to
|
|||
|
put them. Just press enter to accept the defaults.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Network interfaces, Next: Example configuration, Prev: Generating keypairs, Up: Configuration
|
|||
|
|
|||
|
Network interfaces
|
|||
|
==================
|
|||
|
|
|||
|
Before tinc can start transmitting data over the tunnel, it must set
|
|||
|
up the virtual network interface.
|
|||
|
|
|||
|
First, decide which IP addresses you want to have associated with
|
|||
|
these devices, and what network mask they must have.
|
|||
|
|
|||
|
tinc will open a virtual network device (`/dev/tun', `/dev/tap0' or
|
|||
|
similar), which will also create a network interface called something
|
|||
|
like `tun0', `tap0', or, if you are using the Linux tun/tap driver, the
|
|||
|
network interface will by default have the same name as the netname.
|
|||
|
|
|||
|
You can configure the network interface by putting ordinary
|
|||
|
ifconfig, route, and other commands to a script named
|
|||
|
`/etc/tinc/netname/tinc-up'. When tinc starts, this script will be
|
|||
|
executed. When tinc exits, it will execute the script named
|
|||
|
`/etc/tinc/netname/tinc-down', but normally you don't need to create
|
|||
|
that script.
|
|||
|
|
|||
|
An example `tinc-up' script:
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
ifconfig $INTERFACE hw ether fe:fd:0:0:0:0
|
|||
|
ifconfig $INTERFACE 192.168.1.1 netmask 255.255.0.0
|
|||
|
ifconfig $INTERFACE -arp
|
|||
|
|
|||
|
The first line sets up the MAC address of the network interface.
|
|||
|
Due to the nature of how Ethernet and tinc work, it has to be set to
|
|||
|
fe:fd:0:0:0:0 for tinc to work in it's normal mode. If you configured
|
|||
|
tinc to work in `switch' or `hub' mode, the hardware address should
|
|||
|
instead be set to a unique address instead of fe:fd:0:0:0:0.
|
|||
|
|
|||
|
You can use the environment variable $INTERFACE to get the name of
|
|||
|
the interface. However, this might not be reliable. If in doubt, use
|
|||
|
the name of the interface explicitly.
|
|||
|
|
|||
|
The next line gives the interface an IP address and a netmask. The
|
|||
|
kernel will also automatically add a route to this interface, so
|
|||
|
normally you don't need to add route commands to the `tinc-up' script.
|
|||
|
The kernel will also bring the interface up after this command. The
|
|||
|
netmask is the mask of the _entire_ VPN network, not just your own
|
|||
|
subnet.
|
|||
|
|
|||
|
The last line tells the kernel not to use ARP on that interface.
|
|||
|
Again this has to do with how Ethernet and tinc work. Use this option
|
|||
|
only if you are running tinc under Linux and are using tinc's normal
|
|||
|
routing mode.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Example configuration, Prev: Network interfaces, Up: Configuration
|
|||
|
|
|||
|
Example configuration
|
|||
|
=====================
|
|||
|
|
|||
|
Imagine the following situation. Branch A of our example `company'
|
|||
|
wants to connect three branch offices in B, C and D using the Internet.
|
|||
|
All four offices have a 24/7 connection to the Internet.
|
|||
|
|
|||
|
A is going to serve as the center of the network. B and C will
|
|||
|
connect to A, and D will connect to C. Each office will be assigned
|
|||
|
their own IP network, 10.x.0.0.
|
|||
|
|
|||
|
A: net 10.1.0.0 mask 255.255.0.0 gateway 10.1.54.1 internet IP 1.2.3.4
|
|||
|
B: net 10.2.0.0 mask 255.255.0.0 gateway 10.2.1.12 internet IP 2.3.4.5
|
|||
|
C: net 10.3.0.0 mask 255.255.0.0 gateway 10.3.69.254 internet IP 3.4.5.6
|
|||
|
D: net 10.4.0.0 mask 255.255.0.0 gateway 10.4.3.32 internet IP 4.5.6.7
|
|||
|
|
|||
|
"gateway" is the VPN IP address of the machine that is running the
|
|||
|
tincd. "internet IP" is the IP address of the firewall, which does not
|
|||
|
need to run tincd, but it must do a port forwarding of TCP&UDP on port
|
|||
|
655 (unless otherwise configured).
|
|||
|
|
|||
|
In this example, it is assumed that eth0 is the interface that
|
|||
|
points to the inner (physical) LAN of the office, although this could
|
|||
|
also be the same as the interface that leads to the Internet. The
|
|||
|
configuration of the real interface is also shown as a comment, to give
|
|||
|
you an idea of how these example host is set up. All branches use the
|
|||
|
netname `company' for this particular VPN.
|
|||
|
|
|||
|
For Branch A
|
|||
|
............
|
|||
|
|
|||
|
_BranchA_ would be configured like this:
|
|||
|
|
|||
|
In `/etc/tinc/company/tinc-up':
|
|||
|
|
|||
|
# Real interface of internal network:
|
|||
|
# ifconfig eth0 10.1.54.1 netmask 255.255.0.0 broadcast 10.1.255.255
|
|||
|
|
|||
|
ifconfig tap0 hw ether fe:fd:0:0:0:0
|
|||
|
ifconfig tap0 10.1.54.1 netmask 255.0.0.0
|
|||
|
ifconfig tap0 -arp
|
|||
|
|
|||
|
and in `/etc/tinc/company/tinc.conf':
|
|||
|
|
|||
|
Name = BranchA
|
|||
|
PrivateKey = /etc/tinc/company/rsa_key.priv
|
|||
|
Device = /dev/tap0
|
|||
|
|
|||
|
On all hosts, /etc/tinc/company/hosts/BranchA contains:
|
|||
|
|
|||
|
Subnet = 10.1.0.0/16
|
|||
|
Address = 1.2.3.4
|
|||
|
|
|||
|
Note that the IP addresses of eth0 and tap0 are the same.
|
|||
|
This is quite possible, if you make sure that the netmasks of the interfaces are different.
|
|||
|
It is in fact recommended to give give both real internal network interfaces and tap interfaces the same IP address,
|
|||
|
since that will make things a lot easier to remember and set up.
|
|||
|
|
|||
|
-----BEGIN RSA PUBLIC KEY-----
|
|||
|
...
|
|||
|
-----END RSA PUBLIC KEY-----
|
|||
|
|
|||
|
For Branch B
|
|||
|
............
|
|||
|
|
|||
|
In `/etc/tinc/company/tinc-up':
|
|||
|
|
|||
|
# Real interface of internal network:
|
|||
|
# ifconfig eth0 10.2.43.8 netmask 255.255.0.0 broadcast 10.2.255.255
|
|||
|
|
|||
|
ifconfig tap0 hw ether fe:fd:0:0:0:0
|
|||
|
ifconfig tap0 10.2.1.12 netmask 255.0.0.0
|
|||
|
ifconfig tap0 -arp
|
|||
|
|
|||
|
and in `/etc/tinc/company/tinc.conf':
|
|||
|
|
|||
|
Name = BranchB
|
|||
|
ConnectTo = BranchA
|
|||
|
PrivateKey = /etc/tinc/company/rsa_key.priv
|
|||
|
|
|||
|
Note here that the internal address (on eth0) doesn't have to be the
|
|||
|
same as on the tap0 device. Also, ConnectTo is given so that no-one can
|
|||
|
connect to this node.
|
|||
|
|
|||
|
On all hosts, in `/etc/tinc/company/hosts/BranchB':
|
|||
|
|
|||
|
Subnet = 10.2.0.0/16
|
|||
|
Address = 2.3.4.5
|
|||
|
|
|||
|
-----BEGIN RSA PUBLIC KEY-----
|
|||
|
...
|
|||
|
-----END RSA PUBLIC KEY-----
|
|||
|
|
|||
|
For Branch C
|
|||
|
............
|
|||
|
|
|||
|
In `/etc/tinc/company/tinc-up':
|
|||
|
|
|||
|
# Real interface of internal network:
|
|||
|
# ifconfig eth0 10.3.69.254 netmask 255.255.0.0 broadcast 10.3.255.255
|
|||
|
|
|||
|
ifconfig tap1 hw ether fe:fd:0:0:0:0
|
|||
|
ifconfig tap1 10.3.69.254 netmask 255.0.0.0
|
|||
|
ifconfig tap1 -arp
|
|||
|
|
|||
|
and in `/etc/tinc/company/tinc.conf':
|
|||
|
|
|||
|
Name = BranchC
|
|||
|
ConnectTo = BranchA
|
|||
|
Device = /dev/tap1
|
|||
|
|
|||
|
C already has another daemon that runs on port 655, so they have to
|
|||
|
reserve another port for tinc. It knows the portnumber it has to listen
|
|||
|
on from it's own host configuration file.
|
|||
|
|
|||
|
On all hosts, in `/etc/tinc/company/hosts/BranchC':
|
|||
|
|
|||
|
Address = 3.4.5.6
|
|||
|
Subnet = 10.3.0.0/16
|
|||
|
Port = 2000
|
|||
|
|
|||
|
-----BEGIN RSA PUBLIC KEY-----
|
|||
|
...
|
|||
|
-----END RSA PUBLIC KEY-----
|
|||
|
|
|||
|
For Branch D
|
|||
|
............
|
|||
|
|
|||
|
In `/etc/tinc/company/tinc-up':
|
|||
|
|
|||
|
# Real interface of internal network:
|
|||
|
# ifconfig eth0 10.4.3.32 netmask 255.255.0.0 broadcast 10.4.255.255
|
|||
|
|
|||
|
ifconfig company hw ether fe:fd:0:0:0:0
|
|||
|
ifconfig company 10.4.3.32 netmask 255.0.0.0
|
|||
|
ifconfig company -arp
|
|||
|
|
|||
|
and in `/etc/tinc/company/tinc.conf':
|
|||
|
|
|||
|
Name = BranchD
|
|||
|
ConnectTo = BranchC
|
|||
|
Device = /dev/misc/net/tun
|
|||
|
PrivateKeyFile = /etc/tinc/company/rsa_key.priv
|
|||
|
|
|||
|
D will be connecting to C, which has a tincd running for this
|
|||
|
network on port 2000. It knows the port number from the host
|
|||
|
configuration file. Also note that since D uses the tun/tap driver,
|
|||
|
the network interface will not be called `tun' or `tap0' or something
|
|||
|
like that, but will have the same name as netname.
|
|||
|
|
|||
|
On all hosts, in `/etc/tinc/company/hosts/BranchD':
|
|||
|
|
|||
|
Subnet = 10.4.0.0/16
|
|||
|
Address = 4.5.6.7
|
|||
|
|
|||
|
-----BEGIN RSA PUBLIC KEY-----
|
|||
|
...
|
|||
|
-----END RSA PUBLIC KEY-----
|
|||
|
|
|||
|
Key files
|
|||
|
.........
|
|||
|
|
|||
|
A, B, C and D all have generated a public/private keypair with the
|
|||
|
following command:
|
|||
|
|
|||
|
tincd -n company -K
|
|||
|
|
|||
|
The private key is stored in `/etc/tinc/company/rsa_key.priv', the
|
|||
|
public key is put into the host configuration file in the
|
|||
|
`/etc/tinc/company/hosts/' directory. During key generation, tinc
|
|||
|
automatically guesses the right filenames based on the -n option and
|
|||
|
the Name directive in the `tinc.conf' file (if it is available).
|
|||
|
|
|||
|
Starting
|
|||
|
........
|
|||
|
|
|||
|
After each branch has finished configuration and they have
|
|||
|
distributed the host configuration files amongst them, they can start
|
|||
|
their tinc daemons. They don't necessarily have to wait for the other
|
|||
|
branches to have started their daemons, tinc will try connecting until
|
|||
|
they are available.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Running tinc, Next: Technical information, Prev: Configuration, Up: Top
|
|||
|
|
|||
|
Running tinc
|
|||
|
************
|
|||
|
|
|||
|
If everything else is done, you can start tinc by typing the
|
|||
|
following command:
|
|||
|
|
|||
|
tincd -n _netname_
|
|||
|
|
|||
|
tinc will detach from the terminal and continue to run in the
|
|||
|
background like a good daemon. If there are any problems however you
|
|||
|
can try to increase the debug level and look in the syslog to find out
|
|||
|
what the problems are.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Runtime options::
|
|||
|
* Error messages::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Runtime options, Next: Error messages, Up: Running tinc
|
|||
|
|
|||
|
Runtime options
|
|||
|
===============
|
|||
|
|
|||
|
Besides the settings in the configuration file, tinc also accepts
|
|||
|
some command line options.
|
|||
|
|
|||
|
This list is a longer version of that in the manpage. The latter is
|
|||
|
generated automatically, so may be more up-to-date.
|
|||
|
|
|||
|
`--bypass-security'
|
|||
|
Disables encryption and authentication. Only useful for debugging.
|
|||
|
|
|||
|
`-c, --config=PATH'
|
|||
|
Read configuration options from the directory PATH. The default is
|
|||
|
`/etc/tinc/netname/'.
|
|||
|
|
|||
|
`-d, --debug=LEVEL'
|
|||
|
Set debug level to LEVEL. The higher the debug level, the more
|
|||
|
gets logged. Everything goes via syslog.
|
|||
|
|
|||
|
`-K, --generate-keys[=BITS]'
|
|||
|
Generate public/private keypair of BITS length. If BITS is not
|
|||
|
specified, 1024 is the default. tinc will ask where you want to
|
|||
|
store the files, but will default to the configuration directory
|
|||
|
(you can use the -c or -n option in combination with -K). After
|
|||
|
that, tinc will quit.
|
|||
|
|
|||
|
`--help'
|
|||
|
Display a short reminder of these runtime options and terminate.
|
|||
|
|
|||
|
`-k, --kill[=SIGNAL]'
|
|||
|
Attempt to kill a running tincd (optionally with the specified
|
|||
|
SIGNAL instead of SIGTERM) and exit. Use it in conjunction with
|
|||
|
the -n option to make sure you kill the right tinc daemon.
|
|||
|
|
|||
|
`-n, --net=NETNAME'
|
|||
|
Connect to net NETNAME. *Note Multiple networks::.
|
|||
|
|
|||
|
`-D, --no-detach'
|
|||
|
Don't fork and detach. This will also disable the automatic
|
|||
|
restart mechanism for fatal errors.
|
|||
|
|
|||
|
`--version'
|
|||
|
Output version information and exit.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Error messages, Prev: Runtime options, Up: Running tinc
|
|||
|
|
|||
|
Error messages
|
|||
|
==============
|
|||
|
|
|||
|
What follows is a list of the most common error messages you can see
|
|||
|
when configuring tinc. Most of these messages are visible in the syslog
|
|||
|
only, so keep an eye on it!
|
|||
|
|
|||
|
*Could not open /dev/tap0: No such device*
|
|||
|
* You forgot to `modprobe netlink_dev' or `modprobe ethertap'.
|
|||
|
|
|||
|
* You forgot to compile `Netlink device emulation' in the
|
|||
|
kernel.
|
|||
|
|
|||
|
*Can't write to /dev/misc/net/tun: No such device*
|
|||
|
* You forgot to `modprobe tun'.
|
|||
|
|
|||
|
* You forgot to compile `Universal TUN/TAP driver' in the
|
|||
|
kernel.
|
|||
|
|
|||
|
*Packet with destination 1.2.3.4 is looping back to us!*
|
|||
|
* Something is not configured right. Packets are being sent out
|
|||
|
to the virtual network device, but according to the Subnet
|
|||
|
directives in your host configuration file, those packets
|
|||
|
should go to your own host. Most common mistake is that you
|
|||
|
have a Subnet line in your host configuration file with a
|
|||
|
prefix length which is just as large as the prefix of the
|
|||
|
virtual network interface. The latter should in almost all
|
|||
|
cases be larger. Rethink your configuration. Note that you
|
|||
|
will only see this message if you specified a debug level of
|
|||
|
5 or higher!
|
|||
|
|
|||
|
* Chances are that a `Subnet = ...' line in the host
|
|||
|
configuration file of this tinc daemon is wrong. Change it
|
|||
|
to a subnet that is accepted locally by another interface, or
|
|||
|
if that is not the case, try changing the prefix length into
|
|||
|
/32.
|
|||
|
|
|||
|
*Network doesn't work, syslog shows only packets of length 46*
|
|||
|
Jan 1 12:00:00 host tinc.net[1234]: Read packet of length 46 from tap device
|
|||
|
Jan 1 12:00:00 host tinc.net[1234]: Trying to look up 0.0.192.168 in connection list failed!
|
|||
|
|
|||
|
* Add the `ifconfig $INTERFACE -arp' to tinc-up.
|
|||
|
|
|||
|
*Network address and prefix length do not match!*
|
|||
|
* The Subnet field must contain a _network_ address.
|
|||
|
|
|||
|
* If you only want to use one IP address, set the netmask to
|
|||
|
/32.
|
|||
|
|
|||
|
*This is a bug: net.c:253: 24: Some error*
|
|||
|
* This is something that should not have happened. Please
|
|||
|
report this, and tell us exactly what went wrong before you
|
|||
|
got this message. In normal operation, these errors should
|
|||
|
not occur.
|
|||
|
|
|||
|
*Error reading RSA key file `rsa_key.priv': No such file or directory*
|
|||
|
* You must specify the complete pathname. Specifying a
|
|||
|
relative path does not make sense here. tinc changes its
|
|||
|
directory to / when starting (to avoid keeping a mount point
|
|||
|
busy); and even if we built in a default directory to look
|
|||
|
for these files, the key files are bound to be in a different
|
|||
|
directory.
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: Technical information, Next: About us, Prev: Running tinc, Up: Top
|
|||
|
|
|||
|
Technical information
|
|||
|
*********************
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* The connection::
|
|||
|
* The meta-protocol::
|
|||
|
* Security::
|
|||
|
|
|||
|
|
|||
|
File: tinc.info, Node: The connection, Next: The meta-protocol, Prev: Technical information, Up: Technical information
|
|||
|
|
|||
|
The connection
|
|||
|
==============
|
|||
|
|
|||
|
tinc is a daemon that takes VPN data and transmit that to another
|
|||
|
host computer over the existing Internet infrastructure.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* The UDP tunnel::
|
|||
|
* The meta-connection::
|
|||
|
|