Eine Tinc-Instanz aufsetzen

Doku zu Tinc

Bestandteile einer Tinc-Instanz

Eindeutige Bezeichner und Adressen

Konkrete Nummern und Adressen siehe Adressen. Dort bitte die eigenen Routernummern, Adressen etc. eintragen, bevor Du sie auf Deinem Gerät konfigurierst!-)

Im Folgenden benutzte Variablen

Bei der folgenden Beschreibung werden einige Variablen benutzt:

  • X = Nummer des eigenen Routers (1, 2, 3, …)
  • TN = Nummer der Tinc-Instanz (1, 2, 3, …)
  • TA = Buchstabe der Tinc-Instanz (a, b, c, …)
  • IPext = externe IP Adresse, an die dieser tincd Prozess sich bindet (Adresse im transport layer)
  • IPint = IP Adresse des tap interfaces dieses tincd Prozesses (Adresse im VPN)
  • IPintmask = Präfixlänge des tap interfaces dieses tincd Prozesses
  • Y, Z = Nummern von Routern mit fester externer IP, zu denen im Rahmen dieser Tinc-Instanz eine (Meta-)Verbindung aufgebaut werden sollen

Die Variablen müssen natürlich durch die konkreten Werte für den jeweiligen Router und die jeweilige Tinc-Instanz ersetzt werden.

Tinc package

Die üblichen freien Betriebssysteme sollten ein package für die stable version von Tinc (1.0) haben (20160215: 1.0.26). Die config Verzeichnisse für die Tinc-Instanzen liegen dann zB bei FreeBSD unter /usr/local/etc/tinc, bei Linux vmtl. unter /etc/tinc.

Tinc Konfiguration

Im Unterordner …/tinc/ findest Du Musterdateien für Tinc-Instanzen des Labornetzes. Es folgt hier eine Version mit den obigen Variablenkonventionen:

tinc.conf

Name = ffdorX
Device = /dev/tap9+TN
Mode = switch
BindToAddress =IPext
Port =10009+TN
MaxTimeout = 60
PingTimeout = 10
GraphDumpFile = /var/run/tinc.ffdotTA.dot
ConnectTo = ffdorY
ConnectTo = ffdorZ

tinc-up

#!/bin/sh
IP=IPint
NETLEN=IPintmask
ifconfig $INTERFACE $IP/$NETLEN

Unter OpenWRT hat das tinc-up Skript von Johannes leider nicht funktioniert. Deshalb habe ich eine andere Variante erstellt…aus meiner Sicht sollte diese Variante auch auf anderen Systemen funktionieren.

#!/bin/sh
ip addr add IPint/IPintmask dev $INTERFACE
ip link set $INTERFACE up

Nicht vergessen:

chmod +x .../tinc/ffdotTA/tinc-up

Und schließlich chmod 700 .../tinc.

Kryptographische Schlüssel

Jeder Router generiert sich für jede Tinc-Instanz, an der er teilnimmt, ein Schlüsselpaar:

mkdir .../tinc/ffdotTA/hosts
tincd -n ffdotTA--generate-keys=4096

Dabei TA durch den Buchstaben der Instanz ersetzen: a, b, c, …

Anschließend befindet sich der private key in rsa_key.priv, der public key in hosts/ffdorX.

hosts Dateien

Ins Unterverzeichnis …/tinc/ffdotTA/hosts kommen die public keys der Router, mit denen dieser Router eine Meta-Verbindung einzugehen bereit ist. Für jeden Router Y, zu dem aktiv eine Verbindung aufgebaut werden soll, muss die Datei hosts/ffdorY vor dem public key von Router Y folgende Zeilen enthalten:

Address =IPextY
Port =10009+TN

Also die externe IP Adresse von Router Y eintragen und die Portnummer dieser Tinc-Instanz. Außerdem für den aktiven Verbindungsaufbau die entsprechende Anweisung “ConnectTo = ffdorY” in der tinc.conf nicht vergessen.

Router hinter NAT

Bei geNATeten Routern kann man die BindToAddress in der tinc.conf Zeile weglassen. Solche Router können nicht als Einstiegspunkt für’s VPN dienen, d.h. sie dürfen nicht in einer ConnectTo Anweisung auftauchen. Wenn irgendwie möglich sollte man ein port forwarding auf dem NAT-Router einrichten, der Pakete für den port dieser Tinc-Instanz zu dem hinter ihm liegenden Tinc-Router (ffdorX) weiterleitet. Dadurch wird ffdorX wieder zu einem vollwertigen Tinc-Router.

Separate FIB für den tincd Prozess

Der tincd sollte auf einem Router nicht mit der default forwarding table des kernels laufen. (Grund dafür ist, dass man schließlich über das tap interface des tincd, also das (interne) VPN, routen will. Die externen Adressen, die ein tincd zum Aufbau des VPN benutzt, gehören vom VPN aus gesehen zu einem lower (transport) layer. Diese dürfen nie durch das VPN geroutet werden! Deshalb verschiende FIBs für transport layer und VPN.)

Wie man den tincd in eine separate FIB sperrt, hängt vom OS ab, und sollte für die in der AG benutzten Routerplattformen separat dokumentiert werden (TBD). Das sieht dann üblicherweise einfach so aus, dass man eine separate FIB für den tincd anlegt, die nur eine default route enthält, über die der tincd die externen Adressen seiner peers erreichen kann. (Im Falle einer Tinc-Instanz, die als lower layer einen (bzw. den FF-DO-B.A.T.M.A.N.-) switch benutzt, braucht man nicht mal diese default route, da sich alle peers schon per interface route erreichen können).

Unter Linux verwendet man Policy Routing, das in “Session 6: Policy Based Routing” der FFRL-RoutingDays-Folien beschrieben wird. Ein weiteres Beispiel ist für die OpenWRT-basierte MeshKit-Firmware dokumentiert.

Das Thema wird erst akut, wenn wir über die VPNs routen. D.h. für erste Tests, ob tincd funktioniert, kann man die FIB 0 benutzen. Aber nicht vergessen, sich anschließend um die FIBs für die tincd Prozesse zu kümmern - denn sonst fällt einem das später durch rekursives Routing übel auf die Füße, weil sich das VPN dabei permanent auf- und wieder abbaut => VPN unbenutzbar:-(