[Problem] Eigener IPv6 Tunnelbroker für FRITZ!Box

[padowa76]

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

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

In der sysctl.conf ist folgendes schon aktiv:

[COLOR=#333333]net.ipv6.conf.all.forwarding=1[/COLOR]
[COLOR=#333333]net.ipv6.conf.default.forwarding=1[/COLOR]

Hier meine Interfaces:

[COLOR=#333333]auto lo[/COLOR]
[COLOR=#333333]iface lo inet loopback[/COLOR]
[/FONT][/SIZE][SIZE=2][FONT=arial][COLOR=#333333]auto eth0[/COLOR]
[COLOR=#333333]iface eth0 inet static[/COLOR]
[COLOR=#333333]address 84.XXX.YYY.166[/COLOR]
[COLOR=#333333]netmask 255.255.255.0[/COLOR]
[COLOR=#333333]network 84.XXX.YYY.0[/COLOR]
[COLOR=#333333]broadcast 84.XXX.YYY.255[/COLOR]
[COLOR=#333333]gateway 84.XXX.YYY.1[/COLOR]
[COLOR=#333333]dns-nameservers 8.8.8.8 8.8.4.4[/COLOR]
[COLOR=#333333]dns-search doern.zone[/COLOR]

[COLOR=#333333]iface eth0 inet6 static[/COLOR]
[COLOR=#333333]address 2001:1608:10:12:84:XXX.YYY:166[/COLOR]
[COLOR=#333333]netmask 64[/COLOR]
[COLOR=#333333]gateway 2001:1608:10::1[/COLOR]
[/FONT][/SIZE]

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

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

[COLOR=#333333]C:\Users\patri>tracert -6 www.heise.de[/COLOR]

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

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

Jemand eine Idee woran es noch liegen kann, dass nicht weiter geroutet wird?
IP-Tables ist auf dem Server aktuell deaktiviert, um das direkt 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

Hier noch die Einstellungen der Fritz!Box




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

Gruß Patrick

 

[PeterPawn]

Ist denn sicher, daß für das "frische" Präfix auch die Daten aus Richtung Internet wirklich auf dem Server vorbeikommen, sprich: Kommt denn bei einem Ping aus dem Internet für eine Adresse aus 2001:1608:10:264/64 überhaupt ein Echo-Request auf dem Server an? Ohne dieses, kann man schlecht etwas in den Tunnel stecken ... und das ausbleibende Reply-Paket auf das Ping von der FRITZ!Box (oder dem Windows-PC dahinter) kann ja theoretisch auch daran liegen, daß es ganz woanders landet, nur nicht auf Deinem Server mit dem SIT-Tunnel.

 

[padowa76]

Das könnte natürlich sein, ein Ping auf die normale IPv6-Adresse kann ich mit Wireshark mitverfolgen, ein Ping auf eine Adresse aus dem "neuen" /64 taucht nicht auf. Ich werde morgen früh mal im RZ anfragen, ob das /64 überhaupt schon aktiv ist. Am Samstagmorgen war die aussage das in max. 24 Stunden aktiv ist, vielleicht dann doch nicht !?!?!

- - - Aktualisiert - - -

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

 

[PeterPawn]

Ist denn ein ausgehendes (getunneltes) IPv6-Paket am Ziel des "ping" zu sehen? Kommt eine Antwort aus dem Internet auf diesen "echo request" zurück?

Man muß wohl erst einmal am Server feststellen, ob der Tunnel (für den Rückweg zur FRITZ!Box) nicht funktioniert (hin sollte ja gehen, wenn der Server im RZ selbst antworten kann) oder ob die Antworten nicht richtig verstanden werden oder ob die über den Tunnel ankommenden Pakete mit falschen Angaben weiter ins Internet gesendet werden. Das geht alles mit einem Packet-Dump auf dem Server selbst ... aber man muß eben den Weg der Pakete von Station zu Station verfolgen und der erste "hop" auf dem Server ist der Tunnel als eingehendes Interface, von wo es dann auf eth0 weitergehen sollte. Ist bis dahin ausgehend alles in Ordnung, steht die Frage der Antwort (eingehend am WAN-Interface des Servers im RZ) im Raum und wenn auch da noch alles richtig aussieht, kann das Paket ja nur noch falsch oder gar nicht in den Tunnel gesteckt werden.

Da der SIT-Tunnel ja offen (also Klartext) ist, kann man das normalerweise sehr gut verfolgen ... ohne Idee, wo es bei diesem Weg so eines Roundtrips für "echo request" und "echo reply" nun klemmt, ist das Raten auch schwer.

 

[frank_m24]

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

Das heißt ja noch nichts, je nachdem wie das System konfiguriert war. Bist du sicher, dass für den Ping die richtige Quell-IP benutzt wurde? Ist sichergestellt, dass die Pakete aus dem Internet für das Subnetz 2001:1608:10:264::/64 auf 2001:1608:10:12:84:XXX.YYY:166 geroutet werden? Denn das muss ja des Gateway für dieses Subnetz sein.

Was mir noch auffällt: Die IPv6 Adresse, die du auf dem Server den Devices eth0 und fritztun zuweist, ist identisch ("2001:1608:10:12:84:XXX.YYY:166"). Das halte ich für keine gute Idee. Das Howto geht nicht explizit darauf ein, aber ich bin mir relativ sicher, dass die Adressen auf den beiden Interfaces nicht identisch sind.

 

[padowa76]

Hab leider erst nächstes Wochenende Zeit zum basteln. Das mit den gleichen IP's auf eth0 und fritztun kann eigentlich wirklich nicht sein.

 

[PeterPawn]

Ich hielt das für einen Fehler beim Maskieren der tatsächlichen Angaben mit dem "XXX" und "YYY".

Aber eigentlich dürfte diese IP-Adresse auch keine Rolle spielen - die korrekte Absenderadresse der Pakete aus dem Tunnel steht bereits in diesen Paketen drin (im Payload der IPv4-Pakete mit Protokoll 41, also in den IPv6-Paketen des Clients hinter der FRITZ!Box) und wenn diese zweite Adresse über irgendeine automatisch eingetragene link-lokale Route das System durcheinanderbringen sollte, dürfte ja der gesamte Server nicht mehr erreichbar sein unter der IPv6-Adresse.

Beim Empfang von Paketen für den Tunnel aus dem Internet spielt diese Adresse ja auch keine Rolle ... denn die Zieladresse der IPv6-Pakete ist ja eine aus dem delegierten Präfix und da wird über das Hinzufügen der Route ja der Verkehr zum Interface "fritztun" durchgereicht, wo er dann in IPv4 verpackt wird. Da kommt die IPv6-Adresse des Interfaces auch nicht vor ... höchstens bei irgendwelchen ICMP-Paketen, wenn das Tunnel-Interface nicht nur Daten hin und her transportiert und dabei ein- und auspackt, sondern wenn es ein Problem feststellt und selbst eine Control-Message an den Absender eines Paketes senden will oder muß. Theoretisch käme so ein SIT-Interface sogar ohne eigene IPv6-Adresse aus - zumindest ohne öffentliche, denn der Tunnel selbst ist an der IPv6-Kommunikation ja nicht wirklich beteiligt, weil er für die beiden Teilnehmer im IPv6-Paket (Quelle und Ziel) eigentlich vollkommen transparent - vulgo unsichtbar - ist.

Die Konsequenz dürfte nur sein, daß die Antwort von dieser Adresse auf das "echo request"-Paket beim "ping" in #1 dann nicht erst vom "eth0"-Interface kommt, sondern schon von "fritztun" ... das also kein Transit ist, sondern Inbound (Zieladresse == Interface-IP), wobei ich mir nicht einmal sicher bin, daß das Paket nach dem Entfernen der IPv4-Hülle wieder am eingehenden Interface "eingespeist" wird (auch wenn das eigentlich theoretisch so sein müßte, damit da ggf. noch "iptables" o.ä. eingreifen kann).

Mich würde aber mal interessieren, ob der Server event. mehr als eine einzelne aktivierte Netzwerk-Karte hat ... manchmal haben gerade gemietete Server identische Netzwerk-Karten (bzw. Onboard-Interfaces) und - je nachdem, wo das Kabel gerade steckt - benutzen das mit dem aktiven Link für das Senden/Empfangen. Dann wäre es aber denkbar, daß der Automatismus im Kernel hinter der "netlink"-Schnittstelle bei der Auswahl des Interfaces, an das der Tunnel gebunden wird, daneben greift ... die in #1 gezeigten Kommandos legen ja das physische Interface nicht explizit fest (und ein Zusatz "dev eth0" würde sicherlich auch nicht schaden beim "ip tunnel add").

Nachsehen könnte man (wenn der Server wirklich mehr als ein Interface hat) mit den diversen Optionen des "ip"-Kommandos (aus dem "iproute2"-Paket), wobei das auch bei einem einzelnen Interface sicherlich keine schlechte Idee wäre (von den Interfaces mit ihren Adressen über den Tunnel bis hin zur Routing-Tabelle jeweils für IPv4 und IPv6), denn in #1 steht eigentlich nur, wie es aussehen sollte, wenn alles richtig konfiguriert werden konnte und (mit Ausnahme des "pings") keinerlei Ausgabe eines Kommandos zur Kontrolle, ob die Einstellungen denn auch alle so gesetzt werden konnten. Mag sein, daß das alles kontrolliert wurde ... aber manchmal sehen mehr Augen auch eher etwas, was einem Einzelnen schon mal entgeht.