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

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.

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.

Snuff schrieb:

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

Zum Vergrößern anklicken....

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.

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.