Verschüsselte IPv6-Verbindung zum Heim-Netzwerk

Beim Zugriff auf das heimische Netzwerk vom Internet aus ist es von Vorteil, wenn man eine verschlüsselte Verbindung aufbaut. Eine kleine Untersuchung der vorhandenen Möglichkeiten zeigt, dass die Verwendung des IPSec-Features des Kernels nicht unbedingt das Einfachste ist. Einige Arbeiten sind notwendig, und die sind nicht jedermanns Sache. Ein Ausflug in der Welt der VPN-Programme (openVPN, openswan und tinc) offenbart, dass tinc vielversprechend ist.

Die Einrichtung von tinc bedarf eigentlich wenig Arbeit, aber die Dokumentation, die ich gefunden habe, ging über den Umweg von IPv4 und dies ist für einen Zugriff auf mein internes Netz nicht möglich, ich kann kein Port Forwarding oder ähnliches einstellen. Zudem gefällt es mir nicht, jedes Gerät das ich auf Reisen mitnehme, extra mit einer IPv6-Adresse zu versehen.

Nach meiner Vorstellung sollte kein Mesh-Netz, wie bei tinc vorgesehen, vorhanden sein. Für die von tinc angebotenen Einrichtungsbeispiele werden immer die kürzesten Wege zwischen den verschiedenen mobilen Teilnehmern genommen, ohne den Umweg über den Heim-Router. Wenn eine Gruppe zusammenarbeitet, mag dies sinnvoll sein. Mit den aktuellen Übertragungsraten dürfte dieses Vorgehen nicht mehr so notwendig sein, außer wenn eine absolute Sicherheit gegenüber dem Ausfall einer der Komponenten des Netzes wichtig ist.

Außerdem sollten alle potentiellen Clients mit der gleichen Konfiguration versehen sein. Das Festlegen einer festen IPv6-Adresse und das Pflegen des Name-Servers auf dem Heim-Server sollten vermieden werden.

IPv6 bietet die Möglichgeit der »automatischen zustandslosen Adresskonfiguration«, und diese sollte verwendet werden. Die Vergabe der Adresse per DHCP dürfte nicht das Wahre sein. Dabei werden Software-Netzwerkschnittstellen verwendet, die beim Erzeugen eine neue Hardware-Adresse (MAC) erhalten. Dies würde dazu führen, dass die zugewiesene Adresse sich ständig ändert und die DHCP-Lease-Dateien sich aufblähen.

Wir gehen hier von folgenden Gegebenheiten aus:

• Externe IP-Adresse des Servers: 2001:db8:1::2
• Präfix unseres Netzwerks: 2001:db8:cafe::/48
• Lokales Subnetz:
  • 2001:db8:cafe:1::/64 Lokale IPv6-Geräte
  • 2001:db8:cafe:2::/64 Lokale IPv4-Geräte über tayga (NAT64)
  • 2001:db8:cafe:3::/64 Segment für externe IPv6-Geräte
• Privater Domänenname: localnet

Der Server ist bereits mit IPv6 eingerichtet, so dass nur die VPN-Verbindungsmöglichkeit zusätzlich hinzu kommt.

Netzwerk-Verbindungen werden mit tinc über einen frei vergebbaren Netzwerknamen angegeben. Da wir unser Heim-Netzwerk einbinden wollen, schlage ich »heimnetz« vor.

Als erstes muss das Verzeichnis /etc/tinc/heimnetz/hosts angelegt werden:

mkdir -p /etc/tinc/heimnetz/hosts

Wir können nun die Datei /etc/tinc/heimnetz/tinc.conf erstellen. Sie hat nachstehenden Inhalt:

Name = heimnetz
Mode = switch
Interface = vpn
forwarding = kernel

Als Name für die Netzwerk-Schnittstelle des VPN-Servers wurde »vpn« gewählt. Dieser Name wird in den Firewall-Regeln verwendet.

Die Zeile forwarding = 1 ist für tinc-Versionen kleiner 1.0.17 notwendig, für 1.0.17 kann stattdessen DecrementTTL = no eingetragen werden und ab Version 1.0.18 kann die Zeile entfallen.

Damit tinc die notwendigen Netzwerkschnittstellen-Parameter anlegen kann und den erforderlichen Dienst startet bzw. anhält, werden die Skripte tinc-up und tinc-down aufgerufen. Das Startskript tinc-up auf dem Server sieht wie folgt aus:

#!/bin/sh
# File tinc-up
ip link set dev $INTERFACE up
ip link set mtu 1280 dev $INTERFACE
ip ad ad 2001:db8:cafe:3::1/64 dev $INTERFACE 
ip ro ad default via 2001:db8:cafe:3::1 dev $INTERFACE

function startRadvd()
{
cat </tmp/radvd.conf >>!
interface heimnetz
{
   AdvSendAdvert on;
   MinRtrAdvInterval 300;
   MaxRtrAdvInterval 600;
   prefix 2001:db8:cafe:3::/64
   {
       AdvOnLink on;
       AdvAutonomous on;
       AdvRouterAddr on;
   };
   RDNSS 2001:db8:cafe:3::1 { };
   DNSSL localnet { };
};      
!
chmod 554 /tmp/radvd.conf
sleep 1
radvd -p /tmp/radvd.pid -C /tmp/radvd.conf -u radvd
sleep 1
ninsd -i $INTERFACE -p /tmp/ninsd.pid
}

startRadvd &

Die externen Rechner werden ihre Routing-Informationen sowie die Adresse des Name-Servers des Heimnetzes und die Domänen-Suchliste über das »Router Advertisement« erhalten. Die Konfigurationsdatei wird hier im Skript erstellt, könnte aber auch statisch vorliegen.

Mit dem Start des Daemons ninsd kann auch aus dem lokalen Netzwerk das externe System per Name aus dem Heimnetzwerk erreicht werden. Dies ist optional. Als Name-Server geben wir die Adresse des Tinc-Netzwerkgerätes an. Diese Adresse wird Client-seitig benötigt.

Mit ein wenig mehr Skripten können die Adressenteile usw. dynamisch bestimmt werden. Solch ein Skript wird später beschrieben.

Die Schnittstelle und die Dienste sollten nur so lange wie nötig vorhanden sein. Das Skript tinc-down sorgt für die Aufräumarbeiten:

#!/bin/sh
# File tinc-down

killme()
{
pid=`cat /tmp/$1.pid`
if [ "x$pid" != "x" ]
then 
    kill $pid
fi
}

ip set dev $INTERFACE down

killme radvd
killme ninsd

Eine verschlüsselte Verbindung setzt Schlüssel voraus, diese können nun erzeugt werden:

# tincd -K -n <span class="red">heimnetz</span>
Generating 2048 bits keys:
.......+++ p
............................................................+++ q
Done.
Please enter a file to save private RSA key to [/etc/tinc/heimnetz/rsa_key.priv]: 
Please enter a file to save public RSA key to [/etc/tinc/heimnetz/hosts/heimnetz]: 

Beide Fragen sollten mit [RETURN] bestätigt werden.

Im Verzeichnis hosts befindet sich der öffentliche Schlüssel des Servers. Er muss später auf jeden mobilen Rechner kopiert werden. Eine weitere wichtige Information über den Zielrechner ist seine Adresse oder sein Name. Diese Information muss jedem Client bekannt sein und wird daher in der Datei /etc/tinc/heimnetz/hosts/heimnetz eingetragen:

Address = 2001:db8:1::2
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEApzgk/MxBdWrCO9up+9ii146i76X+dsBsi+DhOyU2nT8xKJrSJq/P
4jv/OxmpC8NcmZPfuyOQxLMxczCBTLtM8rrPanBud7IpHg+tDS8wff5jox2iFK3R
AqNRubCnms3DD0PUDnC8OTHQsQ0Dl03EXjNxUhIExEi881Kbth2XMRIUW6yH/fr9
MP6DBG16w/Uf8pfReeuQyku1iITloVErvsSkFi7RTEY49BKkzrvehcHuVGltiRzy
SYe+IHnTTQarpq0MovaogEq4zPp/Ka4W6vb6ey5NVU/mjFtDenIZF1b+qrAelwPP
N5J5IhwRk49Zr7LF+5oHFsYyNRqDyFbB2QIDAQAB
-----END RSA PUBLIC KEY-----

Die hier aufgeführte Adresse ist die Adresse des Servers auf der Internet-Seite. Wenn ein Name vorhanden ist (z.B. mittels dynDNS.org), kann dieser Name anstelle der Adresse eingetragen werden. Dies ist vor allem bei einer dynamisch bezogenen »Haupt«-IPv6-Adresse unerlässlich.

Address = anna.dyndns.org

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

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.

Das Starten der VPN-Verbindung benötigt Root-Rechte. Bei manchen Distributionen ist es möglich, die Verbindung zur Bootzeit zu starten, dies ist aber nicht immer erwünscht. Mit nachstehendem Skript kann die Verbindung erstellt werden:

#!/bin/sh
# Please set the correct netname, see tinc documantation
NETNAME=heimnetzwerk

SU_COMMAND=
PROTECTED=yes

# no graphical tool, you must set one of
######################################
SU_COMMAND=su
#SU_COMMAND=sudo

# Graphical command will be detected
#####################################
# fedora example: beesu ls -l
# SU_COMMAND=beesu

# openSuse example_ gnomesu -c "ls -l"
# SU_COMMAND="gnomesu -c"

# ubuntu
# SU_COMMAND=gksu

# KDE Desktop
# SU_COMMAND="kdesu -c"

start()
{
# get interface name
iface=`grep -i interface /etc/tinc/$1/tinc.conf| tr '=' ' '`
if [ ! -n $iface ]
then
  iface=$1
else
  iface=`echo $iface | awk '{ print $NF }'`
fi

# create a persistent tap device
if ! ip link sh dev $iface >/dev/null 2>/dev/null
then
  ip tuntap add mode tap dev $iface
fi

# start vpn
tincd -n $1
}

stop()
{
tincd -k -n $1
}

case $1 in
start)start  $NETNAME; exit;;
stop) stop $NETNAME; exit;;
esac

ans=`zenity  --list  --text "Start / Stop $NETNAME VPN" \
--radiolist  --column "Choose" --column "" TRUE Start FALSE Stop`


# Search graphical command
for cmd in beesu gnomesu gksu
do
tmp=`which $cmd`
if [ $? -eq 0 ]
then
    command=`basename $tmp`
    break;
fi
done

# if not found set the default
if [ ! -n $command ]
then
command=$SU_COMMAND
fi

# set args if required and for sudo tell that the
# args may not be protected
case $command in
beesu)   SU_COMMAND=beesu ;;
gksu)    SU_COMMAND=gksu ;;
gnomesu) SU_COMMAND="gnomesu -c" ;;
kdesu)   SU_COMMAND="kdesu -c" ;;
su)      SU_COMMAND="su root -c" ;;
sudo)    SU_COMMAND="sudo -u root"; PROTECTED=no ;;
esac

# call us again with arguments via the root password utility
case $PROTECTED in
no)
case $ans in
Start)  $SU_COMMAND $0 start home ;;
Stop)   $SU_COMMAND $0 stop home ;;
esac
;;
yes)
case $ans in
Start)  $SU_COMMAND "$0 start home" ;;
Stop)   $SU_COMMAND "$0 stop home" ;;
esac
;;
esac

Wenn zur Passwort-Abfrage kein GUI-Programm vorhanden ist, können su oder sudo Verwendung finden.

Dieses Skript kann irgendwo auf dem Rechner installiert werden und muss als ausführbar markiert sein:

chmod +x heimnetzVPN.sh

Danach kann ein Starter installiert werden, entweder auf dem Desktop oder in der Task-Leiste. Diese Anwendung muss innerhalb eines Terminals laufen. Falls su oder sudo zum Einsatz kommen, ist das Passwort im Terminal einzugeben.

Da die IPv6-Adressen auf der Internet-Seite öffentlich sind, kann auf jedes IPv6-Gerät des Heimnetzes zugegriffen werden. Ein Schutz durch den Router ist nicht gegeben, außer wenn ein Firewall Router-seitig installiert ist. Wenn ein Tunnel zur Verbindung mit dem IPv6-Netz verwendet wird, ist der Rechner auf jeden Fall exponiert. Eine Firewall ist daher ein Muss.

Je nach Distribution stehen unterschiedliche graphische Oberflächen zu Verfügung. In der Regel sind diese zu sehr auf IPv4 getrimmt und für bestimmte Aufgaben nicht gerade leicht handhabbar.

Da Firewalling immer auf iptables bzw. dem IPv6-Pendant ip6tables basiert, kann eine kleine Datei erstellt und später von Hand ergänzt werden. Das Einspielen und Starten der Firewall erfolgt dann über ip6tables-restore < Datei. Dies sollte auf allen Systemen funktionieren.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i nat64 -j ACCEPT
-A INPUT -i vpn -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 5353 -d ff02::fb -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 655 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 655 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i nat64 -j ACCEPT
-A FORWARD -i vpn -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT

Als erstes nach der Filter-Deklaration und den folgenden drei Zeilen werden angeforderte Nachrichten von externen Diensten zugelassen.

Danach werden alle eingehende ICMPv6-Verbindungen erlaubt, dies ist für den IPv6-Betrieb wichtig.

Der Verkehr von den angegebenen Schnittstellen lo, eth0, eth1 nat64 und vpn wird grundsätzlich erlaubt.

Anschließend werden einige Dienste für eingehende Verbindungen freigegeben (mdns, ipp, ssh, http/https und schließlich tinc (655).

Die Forwarding-Regeln gelten für das interne Netz, deswegen wird für die angegebenen Schnittstellen alles akzeptiert.

Die letzten Regeln senden eine ICMPv6-Fehlernachricht an den Absender zurück.

Die Zulassung weiterer Dienste kann leicht erreicht werden, indem Zeilen

-A INPUT -m state --state NEW -m udp -p udp --dport # -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport # -j ACCEPT

hinzugefügt werden. # steht für die Portnummer des Dienstes. Falls UDP bzw. TCP für den Dienst nicht notwendig ist, sollte die entsprechende Zeile ausgelassen werden.

Die Einträge mit IP-Adressen und Namen müssen an die eigenen Gegebenheiten angepasst werden.

Das Tap-Gerät, das mittels des Kommandos ip tuntap ... angelegt wurde, ist persistent. Dies erlaubt es, immer die gleiche IP-Adresse zu erhalten. Dies ist wichtig für den Fall, dass eine volle Einbindung des Clients ins Heim-Netzwerk erwünscht ist. Ohne dieses persistente Tap-Gerät würde tincd ein neues Gerät (mit einer anderen Mac-Adresse und demzufolge einer anderen IPv6-Adresse) anlegen. Dies könnte das DNS stören, wenn die Verbindung gestoppt und kurze Zeit danach neu gestartet wird.

Wenn ein Progamm sehr lange Zeit benötigt, bis eine Verbindung zu irgendeinem Dienst aufgebaut wurde, kann dies durch eine Multicast-Abfrage (Avahi mdns) bedingt sein. In diesem Fall sollte die Datei /etc/nsswitch.conf kontrolliert werden. Wenn in der Zeile hosts ein Eintrag mit mdns... vorhanden ist, sollte das mdns entfernt werden.

Eine IPv6 Verbindung ist trotzdem über einen IPv6 über IPv4-Tunnel möglich. Als Alternative bestehen verschiedene Verfahren. Als bestes hat sich der Zugriff über gogoNET herausgestellt. Das Paket gogoc kann aus dem Ubuntu- oder Debian-Repositorium installiert werden, für Fedora kann auf die Fedora-gogoc-Sourcen zurückgegriffen werden. Von gogo6.net können auch die Quellen von gogoc heruntergeladen werden.

Beim Kompilieren ist leider ein kleines Problem vorhanden. Dies kann dadurch gelöst werden, dass in der Datei gogoc-1_2-RELEASE/gogoc-messaging/gogocmessaging/message.h vor der Zeile #include <pal.h> ein #include <stddef.h> eingefügt wird. Danach sollte sich gogoc kompilieren lassen.

Mit dem Teredo-Protokoll (Miredo) kann auch der heimische Server erreicht werden. Für Ubuntu existiert das entsprechende Paket miredo, bei Fedora ist miredo-client zu installieren. Das Teredo-Protokol bietet aber nicht die Stabilität von gogoc.

Wenn die IP-Adressen und das delegierte Netz-Präfix dynamisch vergeben werden, können die Server-Adresse und das Subnetz für VPN-verbindungen dynamisch ermittelt werden. Eine mögliche Implementierung des Server-Skripts tinc-up könnte wie nachstehend ausehen:

#!/bin/sh
# File tinc-up

# Set the following according to your needs
MN_IF=eth0                 # the main interface to the LAN
VPN_SUBNET_NR=3            # the subnet forseen for VPN
VPN_SERVER_SUFFIX=1        # The adresse of the VPN tap is the <prefix>::$VPN_SERVER_SUFFIX
SEARCH_LIST=localnet       # The domain name for your LAN

# calc dynamic value
server_ip=`ip -6 ro sh dev $MN_IF | grep '::/64 via' | awk '{ print $3 }'`
vpn_subnet=`ip -6 ro sh dev $MN_IF | grep '::/64 via' | sed 's/:[0-9a-fA-F][0-9a-fA-F]*::.*/:'$VPN_SUBNET_NR'::\/64/'`
vpn_server_ip=`echo $vpn_subnet | sed "s@/64@$VPN_SERVER_SUFFIX@"`

ip link set dev $INTERFACE up 
ip link set mtu 1280 dev $INTERFACE

ip ad ad $vpn_server_ip/64 dev $INTERFACE
ip ro ad $vpn_subnet via $vpn_server_ip dev $INTERFACE

function startRadvd()
{
   cat < /tmp/radvd.conf >>!
interface $INTERFACE
{
    AdvSendAdvert on;
    MinRtrAdvInterval 300;
    MaxRtrAdvInterval 600;
    prefix $vpn_subnet
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
    };
    RDNSS $server_ip { };
    DNSSL $SEARCH_LIST { };
};
!
    chmod 554 /tmp/radvd.conf
    sleep 1
    radvd -p /tmp/radvd.pid -C /tmp/radvd.conf -u radvd
    sleep 1
    ninsd -i $INTERFACE -p /tmp/ninsd.pid
}

startRadvd $vpn_subnet &

MN_IF ist die Netzwerkschnittstelle an, der die internen lokalen Geräte angeschlossen sind.
VPN_SUBNET_NR wird zur Bildung des Subnet Präfix für VPN Systeme verwendet.
VPN_SERVER_SUFFIX dient zur Festlegung der Adresse der VPN Netzwerkschnittstelle.