Tag Archive: 6to4

6to4 Tunnel mit dynamischer IPv4-Adresse

IPv6 (c) crazyengineers.com

Vorwort

Hinweis: Der Artikel ist an vielen Stellen sehr detailliert. Das Wissen dient dem allgemeinen Verständnis, was mir in vielen Artikeln im Internet leider fehlte.

6to4 ist eine einfache Möglichkeit, auch ohne „echte“ Adresse vom ISP IPv6 via IPv4-Tunnel zu verwenden.
Eine 6to4 IPv6-Adresse ist einmalig. Jeder Benutzer mit IPv4-Adresse, besitzt grundsätzlich auch eine IPv6-Adresse/ein Netz.
Das Netz setzt sich folgendermaßen zusammen:
2002:AABB:CCDD::/48
„AABB:CCDD“ habe ich symbolisch für den IPv4-Adressanteil gewählt. Hierzu später mehr.

Im Folgenden werde ich folgende IPv6-Adressen bzw. -Netze konfigurieren. Alles auf Basis von Debian, Ubuntu und weiteren Derivaten:
2002:AABB:CCDD:1::1/64 für den Router
2002:AABB:CCDD:2::/64 als Netz für die Clients

Für die Konfiguration der Clients wähle ich keinen DHCP(v6)-Server, sondern bediene mich an einer Besonderheit des IPv6: Das „Stateless Address Autoconfiguration“ (SLAAC).
SLAAC ist Bestandteil von IPv6 und konfiguriert die Clients in einem Netzwerk automatisch.
Natürlich besteht mit IPv6 weiterhin die Möglichkeit, einen DHCP-Server zu verwenden. Das empfiehlt sich besonders dann, wenn IPv6 DNS-Serveradressen verteilt werden sollen, da SLAAC dies nicht tut!
Warum keine DNS-Server mehr? Mit IPv6/SLAAC wendet man sich immer mehr von der aufwendigen (manuellen) Konfiguration komplexer Netzwerke ab. Garantiert nicht neu, aber im Kommen, ist mDNS. Anfragen zur Namensauflösung werden direkt via Multicast in das Netzwerk gesendet.
Hierauf werde ich nicht weiter eingehen, das ist ein Thema für sich, jedoch möchte ich es im Zusammenhang mit SLAAC nicht unerwähnt lassen.

Die Umrechnung

Eine IPv4-Adresse:
A.B.C.D -> 10.10.10.10
Darstellung in Bit. Ich habe nach jedem 4. Bit ein „|“ gesetzt, um die Umrechnung in Hex genauer aufzuzeigen:
0000|1010 0000|1010 0000|1010 0000|1010
Nun wird jeder 4-Bit Block in Hex umgerechnet:
0|a 0|a 0|a 0|a
Ein Block im IPv6 ist 16 Bit lang, daher fasse ich zusammen:
0a0a:0a0a
IPv6 hat einen 128 Bit großen Adressraum. Das Resultat mit vorangehender „2002“ für den Tunnel mit /48 Subnetz lautet also:
2002:0a0a:0a0a:0000:0000:0000:0000:0000
FFFF:FFFF:FFFF:0000:0000:0000:0000:0000

Die vereinfachte Darstellung unter Auslassung der angereihten 0000er Blocks sowie vorangehenden 0en:
2002:a0a:a0a::/48

Natürlich wird keiner gezwungen, das Netz des Tunnels manuell auszurechnen.
Ohne zusätzliche Tools, lässt sich das Netz für den Tunnel via IP 10.10.10.10 in der Bash errechnen und anzeigen:

printf "2002:%02x%02x:%02x%02x::\n" 10 10 10 10

Ausgabe:
2002:0a0a:0a0a::

Konfiguration des Tunnels

Da mein ISP (Unitymedia) mir eine öffentliche IPv4 via DHCP zuteilt, die sich über die Zeit ändern kann, erstelle ich ein Script, welches die 6to4-Adresse unter Angabe des Interface ausgibt:

sudo nano /usr/local/bin/6to4

Mit Inhalt:

#!/bin/bash
/sbin/ip addr list $1 |grep "inet " |cut -d' ' -f6|cut -d/ -f1

Nun noch als ausführbar markieren:

sudo chmod +x /usr/local/bin/6to4

Mein Netzwerk konfiguriere ich folgendermaßen, das Script ist direkt mit eingebunden:

auto lo eth0 eth1

iface lo inet loopback
iface eth0 inet dhcp
        post-up sleep 5
        post-up /sbin/ifup tun6to4
iface eth1 inet static
        address 192.168.1.254
        netmask 255.255.255.0
        broadcast 192.168.1.255
        network 192.168.1.0
iface tun6to4 inet6 v4tunnel
        address `printf "2002:%02x%02x:%02x%02x:1::1" \`6to4 eth0 | tr . " "\``
        netmask 64
        gateway ::192.88.99.1
        endpoint any
        local `6to4 eth0`
        up ip route add `printf "2002:%02x%02x:%02x%02x:2::/64" \`6to4 eth0 | tr . " "\`` dev eth1
        down ip route del `printf "2002:%02x%02x:%02x%02x:2::/64" \`6to4 eth0 | tr . " "\`` dev eth1

IPv4:
eth0: via DHCP vom ISP; Interface startet automatisch
eth1: 192.168.1.254/24, intern; Interface startet automatisch

IPv6:
tun6to4 (Host, Netz), wie im Vorwort erwähnt:
2002:XXXX:XXXX:0001:0000:0000:0000:0001
FFFF:FFFF:FFFF:FFFF:0000:0000:0000:0000

Also 2002:XXXX:XXXX:1::1/64, wobei XXXX:XXXX der IPv4-Anteil des Interfaces eth0 ist; Interface startet 5 Sekunden nachdem eth0 gestartet wurde, um eth0 Zeit zu geben, eine IPv4 via DHCP zu requesten.

Route:
Zu sehen ist, dass nachdem Interface tun6to4 gestartet wurde, die Route für die Clients in das IPv6-Internet gesetzt wird. Selbstverständlich ist diese Option Pflicht, schließlich befinden sich die Clients in einem anderen Subnetz als der Router.

Was ist ::192.88.99.1?

::192.88.99.1 bzw. 2002:c058:6301:: ist eine Anycast-Adresse, die uns das nächste/am schnellsten antwortende 6to4 Relay mitteilt.
Klingt ungewöhnlich, wenn man vorher noch nie mit IPv6 gearbeitet hat. Hat aber alles seine Richtigkeit.
Um herauszufinden, welcher Relay gerade der nächste ist, kann ich diesen tracen:

traceroute 192.88.99.1

Mir antwortet as6939.dus.ecix.net. Da Unitymedia für Neukunden (so mein letzter Stand) auch nativ IPv6 im Dual-Stack Verfahren anbietet, gibt es dort wohl keine eigenen Relays.

Konfiguration der SLAAC

Zuerst wird der Server zum IPv6-Router promoviert:

sudo nano /etc/sysctl.conf

Folgende Zeile hinzufügen/auf „1“ setzen:

net.ipv6.conf.all.forwarding=1

„Scharf schalten“:

sudo sysctl -p

Fortan ignoriert der Server SLAAC für sich selbst, konfiguriert sich also nicht selber automatisch. Logisch.

Damit an die Clients die Konfiguration ausgegeben werden kann, muss der Server sich im Netzwerk als IPv6-Router ausgeben. Das kann durch „radvd“ eingestellt werden:

sudo apt-get install radvd

Der Router Advertisement Daemon (radvd) startet nach der Installation durch die fehlende Konfiguration nicht automatisch, daher erstelle ich diese:

sudo nano /etc/radvd.conf

Der Inhalt: eth1 ist das Interface, das die physische Verbindung zu den Clients hat, eth0 (weiter unten) mein getunneltes Interface mit der öffentlichen IPv4-Adresse.
prefix 0:0:0:2::/64 bezeichnet das IPv6-Subnetz meiner Clients. Wie beschrieben wähle ich hier die „2“ im vierten Block. Im Subnetz 0:0:0:1::/64 („1“ im vierten Block) befindet sich der Router, das spielt hier keine Rolle.

interface eth1
{
  AdvSendAdvert on;
  MaxRtrAdvInterval 30;
  prefix 0:0:0:2::/64
  {
    Base6to4Interface eth0;
    AdvValidLifetime 300; 
    AdvPreferredLifetime 120;
  };
};

Wichtig: „AdvSendAdvert on“ sagt dem Netz, dass der Server ein Router ist.
Eine Beschreibung der Optionen und weitere Einstellungen finden sich hier: http://linux.die.net/man/5/radvd.conf

Der Dienst kann gestartet werden, nachdem der Tunnel eingeschaltet wurde:

sudo ifup tun6to4
sudo service radvd start

Clients prüfen

Ich wähle als Client einen PC mit Windows 7. IPv6 ist installiert und aktiviert.
Die Verbindung hat sich sofort automatisch konfiguriert:

Windows 7 mit IPv6
Windows 7 mit IPv6

Zu sehen ist, dass die Local Link Adress als mein IPv6 Gateway eingetragen ist, was korrekt ist.
Diese Adresse ist weniger eine IP. Eher vergleichbar ist sie mit einer MAC-Adresse. Sie setzt sich auch aus dieser zusammen.

Hier ein Beispiel:
– MAC-Adresse 00:11:22:33:44:55
Jetzt der mathematische Teil. Ich nehme den ersten Block („00“), schreibe ihn binär nieder und invertiere den siebten Bit:
Hex „00“ ergibt binär „0000 0000“. Der siebte Bit wird invertiert: „0000 0010“. Zurück zu Hex ergibt das „02“.
Die veränderte MAC-Adresse lautet also: 02:11:22:33:44:55. Dem wird nun das Prefix FE80::/64 vorangestellt, was zu diesem (lokalen!) Zweck definiert ist. In der Mitte füge ich FFEF ein:
FE80:0000:0000:0000:0211:22FF:FE33:4455

Wer sich schon mal die Frage stellte, wofür die „Privacy Extension“ des IPv6 da ist, hat die Antwort nun gefunden. In einem nativen IPv6-Netzwerk möchte (fast) keiner seine MAC-Adresse verteilen.
Das spielt in diesem Artikel aber keine Rolle und ist hier nur sehr schwach und oberflächlich zum Verständnis beschrieben. :)

Getestet werden kann im Anschluss noch mit einem Ping auf „ping ipv6.google.com“.
Einen besonderen IPv6 DNS-Server brauche ich hierfür nicht.

Ping ipv6.google.com
Ping ipv6.google.com

Sicherheit!

IPv6 verzichtet im Gegensatz zu IPv4 auf NAT.
Rufe ich die Seite ipv6.whatismyv6.com auf, wird meine vom Router vergebene Adresse angezeigt. Nicht die von dem Router selber.
Grund ist das von IPv6 verwendete Peer-To-Peer Verfahren.
Der Router leitet die Pakete natürlich trotzdem an die Clients weiter, daher findet das altbekannte „iptables“ weiterhin Verwendung. Allerdings in Form von „ip6tables“.
Waren die Clients des klassischen NAT-Routers schon durch die Maskierung relativ sicher vor Angriffen aus dem Internet, darf mit IPv6 auf keinen Fall die Konfiguration/Absicherung via ip6tables vergessen werden.
Das Vorgehen lässt sich beinahe 1:1 übertragen. Ich werde bei Zeit entsprechende Beispiel nachliefern.