Eigener IPv6 Tunnelbroker für FRITZ!Box

Hallo zusammen,

da man als Unitymedia-Business NUR (okay andere wären froh drum) eine IPv4-Adresse erhält, habe ich bisher Hurricane Electric (tunnelbroker.net) für die IPv6-Anbindung genutzt. Allerdings hat Netflix und Co. mittlerweile eine Überprüfung drin, so dass man mit Standort DE und US-IP keine Inhalte mehr sehen kann.

Habe nun einen kleinen Server (Debian 8.2) aufgesetzt der selbst eine IPv6-Anbindung hat und ein freies /64 für die Fritz!Box bereitstellt. Das funktioniert soweit, die FRITZ!Box und auch die Endgeräte bekommen eine passende IP aus dem freien /64 Netz. Allerdings erreiche ich nur die IPv6-Adresse des Servers. Weiter ins Internet geht momentan nicht

In der sysctl.conf ist folgendes schon aktiv:
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1

Hier meine Interfaces:

auto lo
iface lo inet loopback

The primary network interface

auto eth0
iface eth0 inet static
address 84.XXX.YYY.166
netmask 255.255.255.0
network 84.XXX.YYY.0
broadcast 84.XXX.YYY.255
gateway 84.XXX.YYY.1
dns-nameservers 8.8.8.8 8.8.4.4
dns-search doern.zone

iface eth0 inet6 static
address 2001:1608:10:12:84:XXX.YYY:166
netmask 64
gateway 2001:1608:10::1

Und hier mein Script das den Tunnel für die Fritz!Box erzeugt:

ip_alt=$(cat letzteip)
ip_neu=$(dig +short meinefritzbox.myfritz.net)
echo $ip_alt > letzteip
if [ "$ip_alt" = "$ip_neu" ]; then
echo "IP hat sich nicht geaendert"
else
echo "Tunnelkonfiguration wird aktualisiert"
ip tunnel del fritztun
ip tunnel add fritztun mode sit remote $ip_neu local 84.XXX.YYY.166 ttl 255
ip link set fritztun up
ip addr add 2001:1608:10:12:84:XXX.YYY:166/64 dev fritztun
ip route add 2001:1608:10:264::/64 dev fritztun
ip -f inet6 addr
fi
exit

Ping und Tracert geht bis zum Server 2001:1608:10:12:84:XXX.YYY:166

Jemand eine Idee woran es noch liegen kann, dass nicht weiter geroutet wird?

Die Idee hatte ich übrigens von https://klenzel.de/524

Gruß Patrick

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 306303

Url: https://administrator.de/contentid/306303

Ausgedruckt am: 21.11.2024 um 21:11 Uhr

11 Kommentare

Neuester Kommentar

Ist das ein geroutetes Präfix, was du da auf dem Server hast oder befindet sich der Server selbst im selben Präfix?

Das 2001:1608:10:264:: wurde mir gestern frisch für meine Versuche zugeordnet. Der Server selbst hat das Präfix 2001:1608:10:12

Nach Traceroutes zu urteilen, wird das Präfix nicht auf deine Server-IP geroutet sondern einfach im Netzwerk zur Verfügung gestellt - sonst würde dein Server bei Traceroutes auf z.B. 2001:1608:10:264::aaa als Hop im Traceroute auftauchen.
In diesem Fall müsstest du mal schauen, ob du per NDP-Proxy (über sysctl einschalten) weiterkommst.

Im Tracert taucht der Server ja mit seiner eigenen Adresse auf ...

C:\Users\patri>tracert -6 www.heise.de

Routenverfolgung zu www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms fritz.box [2001:1608:10:264:3631:c4ff:fe69:762c]
2 13 ms 10 ms 11 ms 2001:1608:10:12:84:XXX:YYY:166
3 * *

Wie sieht's mit der Firewall aus (Stichwort: ip6tables)? Stehen die Default-Rules der FORWARD- und Input- Chain auf Accept oder Drop? Und wie sehen die Regeln aus?

Ebenso die herkömmliche IPv4 Firewall muss passen und das Protokoll "ipv6" durchlassen, siehe dazu
http://madduck.net/docs/ipv6/

Bedenke der Tunnel endet an deinem Server, dieser Packt die Pakete aus und sendet sie für die Fritte, umgekehrt kommen die Pakete bei Ihm an, er verpackt sie wieder und schickt sie zurück an die Fritte.

Und bei sowas hilft dir zu 99% wie immer Wireshark, das zeigt dir wo die Pakete hängen bleiben, und ob und wie und über welches Interface die Pakete den Server überhaupt verlassen

Gruß skybird

iptables sind auf dem System aktuell komplett deaktiviert um das erstmal als Ursache auszuschließen

Ich hab jetzt mal kurz WireShark bei einem PING an www.heise.de laufen lassen

Man sieht das der Ping von Source 2001:1608:10:264:76d4:35ff:feb6:89ae (Fritzbox) an 2a02:2e0:3fe:1001:7777:772e:2:85 (www.heise.de) und als Ergebnis Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 1496

Zitat von @Snuffchen:

Im Tracert taucht der Server ja mit seiner eigenen Adresse auf ...

C:\Users\patri>tracert -6 www.heise.de

Routenverfolgung zu www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms fritz.box [2001:1608:10:264:3631:c4ff:fe69:762c]
2 13 ms 10 ms 11 ms 2001:1608:10:12:84:XXX:YYY:166
3 * *

Von innen ja, aber nicht vom Internet aus:

~# traceroute -6 -I -q 1 2001:1608:10:264::aaa
traceroute to 2001:1608:10:264::aaa (2001:1608:10:264::aaa), 30 hops max, 80 byte packets
2003:0:590c:202::1 (2003:0:590c:202::1)  18.505 ms
2003:0:590c:220::2 (2003:0:590c:220::2)  19.135 ms
2003:0:130c:8000::1 (2003:0:130c:8000::1)  23.854 ms
2003:0:130b:4::2 (2003:0:130b:4::2)  24.063 ms
2001:1608:0:13::1 (2001:1608:0:13::1)  24.545 ms
2001:1608:0:13::1 (2001:1608:0:13::1)  230.287 ms !H

Da versucht ganz offenbar der Router 2001:1608:0:13::1 vor deinem Server NDP-Lookup zu machen - sonst könnte er kein "Host unreachable" schicken.
Das zusätzliche Präfix wird also ganz offenbar nicht geroutet und damit relativ einfach geforwarded werden, sondern du musst den NDP-Proxy benutzen:

sysctl net.ipv6.conf.eth0.proxy_ndp=1

Zitat von @Snuffchen:

Das 2001:1608:10:264:: wurde mir gestern frisch für meine Versuche zugeordnet. Der Server selbst hat das Präfix 2001:1608:10:12

--- 05.06.2016 21:31:53
--- Connection: WIFI

Trace to 2001:1608:10:264::1

1 ...
2 ...
3 - 2a01:1e8:e000::2
      19   27   76   (ms)
      Avg: 40 ms     Loss: 0/3 (0 %)
4 - 2a01:1e8:e000::1
      16   70   35   (ms)
      Avg: 40 ms     Loss: 0/3 (0 %)
5 - 2003:0:130b:c006::6
      19   34   38   (ms)
      Avg: 30 ms     Loss: 0/3 (0 %)
6 - 2001:7f8::7aa8:0:1
      decix.accelerated.de
      19   40   33   (ms)
      Avg: 30 ms     Loss: 0/3 (0 %)
7 - 2001:1608:10:264::1
      2001:1608:10:264::1
      23   36   32   (ms)
      Avg: 30 ms     Loss: 0/3 (0 %)

Wie man sieht, wird "Dein" Netz "falsch" geroutet. Da kommen keine Pakete zu Deinem Server zurück. Sprich mit Deinem Hoster/Provider.

lks

Am Routing liegt es nicht. Wenn ich eine IP aus dem neuen /64 Netz auf einem Server im RZ konfiguriere, dann kann ich damit Problemlos ins Netz

Hast du es denn mal mit dem NDP-Proxy versucht?
Bitte mache das einmal und gib Rückmeldung - dann kann ich gerne auch auf den Unterschied zwischen "Routing des Präfixes mit deinem Server als Next-Hop" und "Routing via Provider-Router in der Broadcast-Domain" eingehen