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.
This tunneling 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.
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, noone 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 do not interfere with each other. 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.
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.
tinc uses normal IP datagrams to encapsulate data that goes over the VPN network link. In this case it's also clear that the network is virtual, because no direct network link has to exist between to participants.
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.
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.
A lot can--and will be--changed. I have a few things that I'd 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.
This chapter contains information on how a Linux system is configured for the use of tinc.
Since this particular implementation only runs on 2.1 or higher Linux kernels, you should grab one (2.2 is current at this time). A 2.0 port is not really possible, unless someone tells me someone ported the ethertap and netlink devices back to 2.0.
If you are unfamiliar with the process of configuring and compiling a new kernel, you should read the Kernel HOWTO first. Do that now!
Here are the options you have to turn on/off when configuring a new kernel.
Code maturity level options [*] Prompt for development and/or incomplete code/drivers Networking options [*] Kernel/User netlink socket <*> Netlink device emulation Network device support <*> Ethertap network tap
Any other options not mentioned here are not relevant to tinc. 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 tap0 ethertap alias char-major-36 netlink_dev
Finally, after having set up other options, build the kernel and boot it. Unfortunately it's not possible to insert these modules in a running kernel.
First, you'll need the special device file(s) that form the interface between the kernel and the daemon.
mknod -m 600 /dev/tap0 c 36 16 chown 0.0 /dev/tap0
The permissions now will 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 want to, you may also create more device files, which would be numbered 0...15, with minor device numbers 16...31. They all should be owned by root and have permission 600.
You may add a line to `/etc/networks' so that your VPN will get a symbolic name. For example:
myvpn 10.0.0.0
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>
Before you can start transmitting data over the tinc tunnel, you must set up the ethertap network devices.
First, decide which IP addresses you want to have associated with these devices, and what network mask they must have. You also need these numbers when you are going to configure tinc itself. See section Configuring tinc.
It doesn't matter much which part you do first, setting up the network devices or configure tinc. But they both have to be done before you try to start a tincd.
The actual setup of the ethertap device is quite simple, just repeat after me:
ifconfig tapn hw ether fe:fd:xx:xx:xx:xx
The n here is the number of the ethertap device you want to use. It should be the same n as the one you use for `/dev/tapn'. The xxs are four hexadecimal numbers (0--ff). With previous versions of tincd, it didn't matter what they were. But newer kernels require properly set up ethernet addresses. In fact, the old behavior was wrong. It is required that the xxs match MyOwnVPNIP.
ifconfig tapn IP netmask mask
This will activate the device with an IP address IP with network mask mask.
First download it. This is the download page, which has the checksums of these files listed; you may wish to check these with md5sum before continuing.
tinc comes in a handy 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.
It is perfectly OK for you to run more than one tinc daemon. However, in its default form, you will soon notice that you can't use two different configuration files without the -c option.
We have thought of another way of dealing with this: network names. This means that you call tincd with the -n argument, which will assign a name to this daemon.
The effect of this is that the daemon will set its configuration "root" to /etc/tinc/nn/, where nn is your argument to the -n option. You'll notice that it appears in syslog as "tinc.nn".
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/nn/; the configuration file should be /etc/tinc/tinc.conf, and the passphrases are now expected to be in /etc/tinc/passphrases/.
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.
Before going on, first a bit on how tinc sees connections.
When tinc starts up, it reads in the configuration file and parses the command-line options. If it sees a `ConnectTo' value in the file, it will try to connect to it, on the given port. If this fails, tinc exits.
The actual configuration of the daemon is done in the file `/etc/tinc/nn/tinc.conf'.
This 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.
Here are all valid variables, listed in alphabetical order:
Imagine the following situation. An A-based 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 LAN of the office. This could be the same as the interface that leads to the internet.
A would be configured like this:
ifconfig tap0 hw ether fe:fd:0a:01:36:01 ifconfig tap0 10.1.54.1 netmask 255.0.0.0 ifconfig eth0 10.1.54.1 netmask 255.255.0.0 broadcast 10.1.255.255
and in /etc/tinc/tinc.conf:
TapDevice = /dev/tap0 MyVirtualIP = 10.1.54.1/16 VpnMask = 255.0.0.0
ifconfig tap0 hw ether fe:fd:0a:02:01:0c ifconfig tap0 10.2.1.12 netmask 255.0.0.0 ifconfig eth0 10.2.43.8 netmask 255.255.0.0 broadcast 10.2.255.255
and in /etc/tinc/tinc.conf:
TapDevice = /dev/tap0 MyVirtualIP = 10.2.1.12/16 ConnectTo = 1.2.3.4 VpnMask = 255.0.0.0
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.
ifconfig tap0 hw ether fe:fd:0a:03:45:fe ifconfig tap0 10.3.69.254 netmask 255.0.0.0 ifconfig eth0 10.3.69.254 netmask 255.255.0.0 broadcast 10.3.255.255
and in /etc/tinc/A/tinc.conf:
MyVirtualIP = 10.3.69.254/16 ConnectTo = 1.2.3.4 ListenPort = 2000 VpnMask = 255.0.0.0
C already has another daemon that runs on port 655, so they have to reserve another port for tinc. They also use the netname to distinguish between the two. tinc is started with `tincd -n A'.
ifconfig tap0 hw ether fe:fd:0a:04:03:20 ifconfig tap0 10.4.3.32 netmask 255.0.0.0 ifconfig tap0 10.4.3.32 netmask 255.255.0.0 broadcast 10.4.255.255
and in /etc/tinc/tinc.conf:
MyVirtualIP = 10.4.3.32/16 ConnectTo = 3.4.5.6 ConnectPort = 2000 VpnMask=255.0.0.0
D will be connecting to C, which has a tincd running for this network on port 2000. Hence they need to put in a ConnectPort.
A, B, C and D all generate a passphrase with genauth 2048, the output is stored in /etc/tinc/passphrases/local, except for C, where it should be /etc/tinc/A/passphrases/local.
A stores a copy of B's passphrase in /etc/tinc/passphrases/10.2.0.0
A stores a copy of C's passphrase in /etc/tinc/passphrases/10.3.0.0
B stores a copy of A's passphrase in /etc/tinc/passphrases/10.1.0.0
C stores a copy of A's passphrase in /etc/tinc/A/passphrases/10.1.0.0
C stores a copy of D's passphrase in /etc/tinc/A/passphrases/10.4.0.0
D stores a copy of C's passphrase in /etc/tinc/passphrases/10.3.0.0
A has to start their tincd first. Then come B and C, where C has to provide the option `-n A', because they have more than one tinc network. Finally, D's tincd is started.
Running tinc isn't just as easy as typing `tincd' and hoping everything will just work out the way you wanted. Instead, the use of tinc is a project that involves trust relations and more than one computer.
Before attempting to start tinc, you have to create passphrases. When tinc tries to make a connection, it exchanges some sensitive data. Before doing so, it likes to know if the other end is trustworthy.
To do this, both ends must have some knowledge about the other. In the case of tinc this is the authentication passphrase.
This passphrase is a number, which is chosen at random. This number is then sent to the other computers which want to talk to us directly. To avoid breaking security, this should be done over a known secure channel (such as ssh or similar).
All passphrases are stored in the passphrases directory, which is normally /etc/tinc/nn/passphrases/, but it may be changed using the `Passphrases' option in the config file.
To generate a passphrase, run `genauth'. genauth takes one argument, which is the length of the passphrase in bits. The length of the passphrase should be in the range 1024--2048 for a key length of 128 bits. genauth creates a random number of the specified length, and puts it to stdout.
Every computer that wants to participate in the VPN should do this, and store the output in the passphrases directory, in the file `local'.
When every computer has his own local key, it should copy it to the computer that it wants to talk to directly. (i.e. the one it connects to during startup.) This should be done via a secure channel, because it is sensitive information. If this is not done securely, someone might break in on you later on.
Those non-local passphrase files must have the name of the VPN IP address that they will advertise to you. For instance, if a computer tells us it likes to be 10.1.1.3 with netmask 255.255.0.0, the file should still be called 10.1.1.3, and not 10.1.0.0.
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.
tinc is a daemon that takes VPN data and transmit that to another host computer over the existing Internet infrastructure.
The data itself is read from a character device file, the so-called ethertap device. This device is associated with a network interface. Any data sent to this interface can be read from the device, and any data written to the device gets sent from the interface. Data to and from the device is formatted as if it were a normal ethernet card, so a frame is preceded by two MAC addresses and a frame type field.
So when tinc reads an ethernet frame from the device, it determines its type. Right now, tinc can only handle Internet Protocol version 4 (IPv4) frames. Plans to support other protocols are being made. When tinc knows which type of frame it has read, it can also read the source and destination address from it.
Now it is time that the frame gets encrypted. Currently the only encryption algorithm available is blowfish.
When the encryption is ready, time has come to actually transport the packet to the destination computer. We do this by sending the packet over an UDP connection to the destination host. This is called encapsulating, the VPN packet (though now encrypted) is encapsulated in another IP datagram.
When the destination receives this packet, the same thing happens, only in reverse. So it does a decrypt on the contents of the UDP datagram, and it writes the decrypted information to its own ethertap device.
Having only an UDP connection available is not enough. Though suitable for transmitting data, we want to be able to reliably send other information, such as routing and encryption information to somebody.
TCP is a better alternative, because it already contains protection against information being lost, unlike UDP.
So we establish two connections. One for the encrypted VPN data, and one for other information, the meta-data. Hence, we call the second connection the meta-connection. We can now be sure that the meta-information doesn't get lost on the way to another computer.
Like with any communication, we must have a protocol, so that everybody knows what everything stands for, an how he should react. Because we have two connections, we also have two protocols. The protocol used for the UDP data is the "data-protocol," the other one is the "meta-protocol."
The reason we don't use TCP for both protocols is that UDP is much better for encapsulation, even while it is less reliable. The real problem is that when TCP would be used to encapsulate a TCP stream that's on the private network, for every packet sent there would be three ACK's sent instead of just one. Furthermore, if there would be a timeout, both TCP streams would sense the timeout, and both would start resending packets.
tinc got its name from "TINC," short for There Is No Cabal; the alleged Cabal was/is an organization that was said to keep an eye on the entire Internet. As this is exactly what you don't want, we named the tinc project after TINC.
But in order to be "immune" to eavesdropping, you'll have to encrypt your data. Because tinc is a Secure VPN (SVPN) daemon, it does exactly that: encrypt.
This chapter is a mixture of ideas, reasoning and explanation, please don't take it too serious.
You can't just send a private encryption key to your peer, because somebody else might already be listening to you. So you'll have to negotiate over a shared but secret key. One way to do this is by using the "Diffie-Hellman key exchange" protocol (http://www.rsa.com/rsalabs/faq/html/3-6-1.html). The idea is as follows.
You have two participants A and B that want to agree over a shared secret encryption key. Both parties have some large prime number p and a generator g. These numbers may be known to the outside world, and hence may be included in the source distribution.
Both parties then generate a secret key. A generates a, and computes g^a mod p. This is then sent to B; while B computes g^b mod p, and transmits this to A, b being generated by B. Both a and b must be smaller than p-1.
These private keys are generated upon startup, and they are not changed while the connection exists. A possible feature in the future is to dynamically change the keys, every hour for example.
Both parties then calculate g^ab mod p = k. k is the new, shared, but still secret key.
To obtain a key k of a sufficient length (128 bits in our vpnd), p should be 2^129-1 or more.
Because the Diffie-Hellman protocol is in itself vulnerable to the "man-in-the-middle attack," we should introduce an authentication system.
We will let A transmit a passphrase that is also known to B encrypted with g^a, before A sends this to B. This way, B can check whether A is really A or just someone else.
This passphrase should be 2304 bits for a symmetric encryption system. But since an asymmetric system is more secure, we could do with 2048 bits. This only holds if the passphrase is very random.
These passphrases could be stored in a file that is non-readable by anyone else but root; e.g. `/etc/vpn/passphrases'.
The only thing that needs to be taken care of is how A announces its passphrase to B.
Now we have securely hidden our data. But a malicious cracker may still bother you by randomly altering the encrypted data he intercepts.
tinc's main page is at http://tinc.nl.linux.org/, this server is located in the Netherlands.
We have an IRC channel on the Open Projects IRC network. Connect to irc.openprojects.net, and join channel #tinc.
Thank you's to: Dekan, Emphyrio, vDong
Greetings to: braque, Fluor, giggles, macro, smoke, tribbel
Jump to: c - d - e - f - m - p - s - t - v
This document was generated on 31 May 2000 using texi2html 1.56k.