book on tinc

[Guus Sliepen]

On Fri, Jun 22, 2001 at 08:35:31PM -0000, Oleg Kolesnikov wrote:

> We are writing a book on building VPNs for Linux and a part of it describes 
> tinc. I wanted to make sure that your opinion, as tinc authors and 
> developers, is reflected.

Ok :).

> First, let me ask a couple of technical questions.

(Also wait for Ivo's response, I'm answering for myself here.)

> If there are two hosts, foo and bar, that are to be connected via tinc, and 
> each host should only have _one_ IP address (i.e. nmask is /32), would the 
> following configuration work (in the context of the recent routing problems 
> pointed out by users) ?

No it wouldn't work, there is a slight mistake in the tinc-up scripts. It
should be:

> /etc/tinc/vpn1/tinc-up --
> 
> #!/bin/sh
> ifconfig tap0 down
> ifconfig tap0 hw ether fe:fd:00:00:00:00
ifconfig tap0 192.168.1.1 netmask 255.255.255.0
> ifconfig tap0 -arp

> /etc/tinc/vpn1/tinc-up --
> 
> #!/bin/sh
> ifconfig tap0 down
> ifconfig tap0 hw ether fe:fd:00:00:00:00
ifconfig tap0 192.168.1.2 netmask 255.255.255.0
> ifconfig tap0 -arp

If you ifconfig with a netmask of 255.255.255.255, the only routing table entry
that is generated will look like this:

192.168.1.1	255.255.255.255		tap0

Packets for 192.168.1.2 are not matched against that entry, so it will probably
go to your default gateway instead. Change the netmask so that it encompasses
both addresses and you'll be fine.

> What is the right way of modifying the configuration above to switch to the 
> universal TUN/TAP driver? Would it be ok if I just change tap0 to tun
> (assuming that all other changes, such as adding kernel modules, 
> recompiling, creating devices etc. have been made)

Change "TapDevice = /dev/tap0" to "TapDevice = /dev/net/tun" (or whereever your
tun device is), but change "ifconfig tap0" to "ifconfig <netname>", where
<netname> is the same thing as when you start tinc by typing "tincd -n
<netname>". You can also use the environment variable $NETNAME in the tinc-up
scripts, which will be set accordingly.

> I would also like to ask you a couple of questions about your vision of tinc 
> future and current direction tinc development is going in. Can you elaborate 
> on that? What do you see as the drawbacks of the current version of tinc? 
> How do you plan to improve it?

- In 1.0pre4 you still have to ifconfig hw ether fe:fd:0:0:0:0 and ifconfig
  -arp, which is kind of annoying. The current CVS version has some code to do
  proxy-arp, so this will not be necessary anymore in 1.0.
- Currently tinc will only route IPv4 packets, and broadcast protocols (for
  example Windows Network Neighbourhood) won't work over the VPN. This
  limitation comes from the fact that tinc allows more than two hosts to be
  connected to a single VPN, unlike most other tunneling software. Tinc has the
  characteristics of a network router. We are working on making tinc act like a
  network hub or switch as well, which will allow any protocol to be
  transported, including broadcast protocols. This is already available in the
  CVS version.
- You still need to add multiple ConnectTo lines and the corresponding host
  configuration files to get true redundancy. It would be nice if tinc could
  somehow exchange the host configuration files it knows with other tinc
  daemons.
- Tinc only really works on Linux and FreeBSD platforms. We are working on a
  Solaris port (but we don't have root access on a Solaris box, so we cannot
  try it out). I think we will add more platforms in the future, we might even
  consider Windows (if the VTun developpers are kind enough to port the TUN/TAP
  driver to it).
- Also see http://tinc.nl.linux.org/goals.html

> From your experience, what category of people use tinc?

Mostly network managers of small companies, people wanting to work at home and
students I guess, but I think that the fact that most tinc users also use Linux
plays an important role.

> Are you planning on adding other symmetric ciphers?

Well since we are using OpenSSL's EVP functions, it is a matter of changing 6
characters in the source code and tinc will use a different cipher :). We will
make it a configuration option somewhere in the future. The only problem I see
is people wanting to mix different kinds of ciphers in the same VPN, that would
complicate things a lot.

> Certificates?

We have been thinking about that. This too would complicate things a lot (think
about setting up a CA, setting up a trust relationship between each tinc daemon
and that CA, but more importantly we would also have to be dealing with
revocation and other issues), but since it offers many possibilities we will
certainly try to do things with certificates in the future.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <guus at sliepen.warande.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20010623/ce59eadb/attachment.pgp