Damit wäre die Konfiguration in Aachen erst einmal fertig. Als nächstes kommt der Rechner in Bochum an die Reihe. Seine Dateien sehen fast genau so aus. Zunächst ist wieder die »tinc.conf
«
nötig:
Name = bochum Device = /dev/net/tun
Der Endpunkt heißt in diesem Fall »bochum
«
und nutzt auch hier wieder das Tun-Device. Dazu gehört eine weitere Datei »bochum
«
ins Unterverzeichnis »/tinc/hosts
«
mit dem Inhalt:
Adress = 50.1.2.3 Subnet = 192.168.2.0/24
Die zugehörige »tinc-up
«
sieht ebenfalls vertraut aus:
#!/bin/sh ifconfig $INTERFACE 192.168.2.222 netmask ↩ 255.255.0.0
Und auch hier erzeugt »sudo tincd -K
«
abschließend ein passendes Schlüsselpaar.
Damit stehen die Endpunkte auf beiden Rechnern, der Admin muss sie dem Gegenüber nur noch bekannt geben. Dazu kopiert er im ersten Schritt die Host-Datei »aachen
«
in das Verzeichnis »/etc/tinc/hosts
«
des Bochumer Computers und umgekehrt dessen »bochum
«
-Datei in den Ordner »/etc/tinc/hosts
«
des Aachener Rechners. Die Dateien darf er erst zu diesem Zeitpunkt tauschen, da erst jetzt in beiden der jeweilige, öffentliche Schlüssel steckt.
Werden anschließend die beiden Tinc-Daemons gestartet, warten Sie auf Verbindungsversuche eines bekannten Kollegen. Es gibt somit keine klare Trennung in Client und Server, wie es bei anderen VPNs der Fall ist. Um eine Verbindung herzustellen, ergänzen Sie in der »tinc.conf
«
die Zeile:
ConnectTo = <I>Endpunkt-Name<I>
Möchten Sie beispielsweise, dass sich der Bochumer Rechner mit dem in Aachen verbindet, ergänzen Sie in der Bochumer »/etc/tinc/tinc.conf
«
die Zeile
ConnectTo = aachen
Sollte ein Gegenüber nicht erreichbar sein, versucht es Tinc immer wieder erneut.
Startet man nun einen Tinc Daemon per »sudo tincd
«
laufen sämtliche Meldungen in die Syslog-Datei. Wer eine separate Log-Datei wünscht, hängt noch den Parameter »--logfile=dateiname
«
an. Der Befehl »sudo tincd -k
«
beendet den Daemon wieder.