Verschüsselte IPv6-Verbindung zum Heim-Netzwerk

Vorbereitung der mobilen Geräte

Die Einrichtung der Clients unterscheidet sich nur geringfügig von der Einrichtung des Servers. Einige Hürden müssen aber seitens der Netzwerkschnittstelle übersprungen werden.

mkdir -p /etc/tinc/heimnetz/hosts

Die Konfigurationsdatei /etc/tinc/heimnetz/tinc.conf sieht wie folgt aus:

Name = bernd
Mode = switch
Interface = vpn
ConnectTo = heimnetz

Hauptunterschied zur Konfigurationsdatei der Server ist der Eintrag ConnectTo = heimnetz. Damit kann der Client gezielt in dem passenden Verzeichnis (/etc/tinc/heimnetz) die notwendigen Informationen finden.

Das Generieren der Schlüsseldateien ist identisch zur Generierung auf dem Server:

tincd -K -n heimnetz
...

Die öffentliche Schlüsseldatei bedarf keiner weiteren Änderungen. Die Dateien /etc/tinc/heimnetz/tinc-up und /etc/tinc/heimnetz/tinc-down unterscheiden sich aber von denen des Servers.

Nachdem die Schnittstelle in den Zustand up gesetzt wurde, ist sie noch lange nicht initialisiert. Sofort nach dem Hochfahren werden interne Prüfungen vorgenommen. Erst nachdem diese erste Phase der Initialisierung abgeschlossen und eine Adresse vergeben wurde, können Routen festgelegt werden. Bis zum Vorhandensein der Adresse dauert es auch ein wenig. In der Testumgebung, alles im lokalen Netz, wird eine Adresse nach ca. 2 s zugewiesen. Der Versuch, das Routing nach 2 oder 3 Sekunden zu setzen, scheitert.

Die Überwachung der Schnittstelle auf das Vorhandensein der globalen IPv6-Addresse, um nach deren Erkennung die Route zu setzen, ist der richtige Weg. Da die Adresse sich unter Umständen im Präfix ändern könnte, wurde das kleine Programm set_route geschrieben.

Damit der Client namentlich auf Systeme des privates Netzes zugreifen kann, muss der Name-Sserver des heimischen Netzes und nicht irgendein anderer Name-Server abgefragt werden. Die Lösung hierfür ist es, die Datei /etc/resolv.conf neu zu erzeugen, wobei der alte Stand aufbewahrt wird. Somit kann beim Stoppen der VPN-Verbindung die ursprüngliche Konfiguration wieder hergestellt werden. Diese Aufgabe wird vom Programm radvc wahrgenommen.

#!/bin/sh
# File tinc-up
ip link set dev $INTERFACE up
ip link set mtu 1280 dev $INTERFACE
radvc -d /etc/tinc/$NETNAME/$INTERFACE -p /etc/tinc/$NETNAME/radvc.pid
set_route -i $INTERFACE &
echo $! > /etc/tinc/$NETNAME/$INTERFACE -p /etc/tinc/$NETNAME/set_route.pid

Nach dem Hochfahren der Schnittstelle wird der Daemon radvc aufgerufen. Radvc wertet die Router-Advertisement-Nachrichten aus und erkennt die IP-Adresse des Name-Servers und die passende Suchliste, z.B. example.org oder localnet. Damit kann eine neue Datei /etc/resov.conf erzeugt werden.

Damit die SLAAC (Zustandslose Adressen-Autokonfiguration) möglich wird, aber dennoch eine statische Route für den Bereich 2001:db8:cafe::/48 (das ganze lokale Netz), muss ein wenig getrickst werden. set_route überprüft zyklisch, ob die Tinc-Schnittstelle mit einer globalen Adresse versehen ist. Sobald dieser Zustand erkannt wird, wird die Schnittstelle auf Forwarding gestellt und die errechnete statische Route gesetzt. Letzeres geschieht im Skript tinc-slaac.

Wenn radvc auf allen Clients installiert ist und alle Netzwerkschnittstellen überwacht sind, sollte radvc nicht erneut aufgerufen werden. In diesem Fall sollte dem Daemon radvc eine zusätzliche Startoption gegeben werden (-i vpn). Dies bewirkt, dass die Tinc-VPN-Netwerkschnittstelle (vpn) als solche behandelt wird und dass die Datei /etc/resolv.conf entsprechend dem Vorhandensein oder Nichtvorhandensein der VPN-Verbindung verwaltet wird.

#!/bin/sh
# File: tinc-slaac

sysctl -w net.ipv6.conf.$INTERFACE.forwarding=1;

ip route add $PREFIX_NET/$MASK_NET via $PREFIX_SUBNET$SUFFIX dev $INTERFACE

Dieses Skript wird im Verzeichnis /etc/tinc/home erwartet.

Wenn tinc beendet wird, werden mit dem Skript tinc-down die notwendigen Aufräumaktionen erledigt:

#!/bin/sh
# File tinc-down
if [ -f /etc/tinc/$NETNAME/set_route.pid ]
then
kill `cat /etc/tinc/$NETNAME/set_route.pid`
rm -f /etc/tinc/$NETNAME/set_route.pid
fi
sysctl -w net.ipv6.conf.$INTERFACE.forwarding=0

ip link set dev $INTERFACE down

if [ -f /etc/tinc/$NETNAME/radvc.pid ]
then
kill `cat /etc/tinc/$NETNAME/radvc.pid`
fi

Falls eine Verbindung nicht zustande kam, existiert noch der Prozess set_route und wird hier beendet. Danach wird die Netzwerkschnittstelle heruntergefahren und radvc beendet.

Alternativ kann der Client eine feste IP-Addresse erhalten, In diesem Fall könnten die Skripte tinc-up und tinc-down so aussehen:

#!/bin/sh
# File tinc-up
ip link set dev $INTERFACE up
radvc -d /etc/tinc/$NETNAME/$INTERFACE
sysctl -w net.ipv6.conf.$INTERFACE.forwarding=1
ip -6 ad ad 2001:db8:cafe:3::24 dev $INTERFACE
ip -6 ro ad 2001:db8:cafe::/48 via 2001:db8:cafe:3::1 dev $INTERFACE

#!/bin/sh
# File: tinc-down
sysctl -w net.ipv6.conf.$INTERFACE.forwarding=0

ip link set dev $INTERFACE down

if [ -f /etc/tinc/$NETNAME/radvc.pid ]
then
kill `cat /etc/tinc/$NETNAME/radvc.pid`
fi

Schlüsseldateien des Servers und der Clients

Damit die Protagonisten sich verständigen können, müssen die privaten Schlüssel bekannt sein. Diese befinden sich im Verzeichnis /etc/tinc/heimnetz/hosts. Die Datei des Servers, in unseren Fall heimnetz, muss in den oben genannten Ordner jedes Clients kopiert werden. Da diese Schlüssel nur dann funktionieren, wenn die Gegenstelle ihre passende private Version besitzt, spricht nichts gegen das Austauschen der Schlüsseldatei per Mail oder einem anderen Medium.

Die öffentlichen Schlüsseldateien der Clients sind auf den Server, ebenfalls ins Verzeichnis /etc/tinc/heimnetz/hosts zu kopieren.