Unitymedia TC7200 Switch Modus

[kikiriki2k]

hi,

hab gerade einen Blick auf das WebIF des TC7200 geworfen und siehe da eine Option "Switch Modus" zum Umschalten von Router auf den Bridge Modus ist da. Ist es ein Bug der SW? ;-)

http://www.bilder-hosting.info/viewer.php?id=bwy1391284567d.jpg

EDIT:
Zwar auf der WebIF sichtbar aber wenn ich Bridge Modus wähle tut sich nichts :-( Umsonst gefreut!

 

[DerJens]

Hallo kikiriki2k,

ich hatte gestern genau den gleichen Effekt. Ich habe gestern auch einen Blick auf das Web-Interface geworfen und bin über diese Einstellung gestolpert auf die ich dringend warte. Die Freude wich jedoch genau wie bei dir schnell der Ernüchterung. Die Einstellung lässt sich nicht speichern.

Ich habe daher gerade mal eine Mail an den Support geschrieben. Mal sehen, was diesmal die Ausrede ist. :traurig:

Aktuell habe ich einen Hack, der mir mit neighbor-proxy-Einträgen und dem radvd die globalen IPv6-Adressen ins lokale Netz durchschleift. Das Problem dabei ist, dass der TC7200 seine Route verliert, wenn er nicht regelmäßig an die Geräte im lokalen Netz erinnert wird. Außerdem muss ich per Cronjob ständig kontrollieren, ob sich das Präfix geändert hat (das passiert ja alle 14 Tage) und dann Firewall, radvd.conf und die neighbor-proxy-Einträge ändern. Nicht schön!

Grüße,
Jens

 

[SpaceRat]

Aktuell habe ich einen Hack, der mir mit neighbor-proxy-Einträgen und dem radvd die globalen IPv6-Adressen ins lokale Netz durchschleift. Das Problem dabei ist, dass der TC7200 seine Route verliert, wenn er nicht regelmäßig an die Geräte im lokalen Netz erinnert wird. Außerdem muss ich per Cronjob ständig kontrollieren, ob sich das Präfix geändert hat (das passiert ja alle 14 Tage) und dann Firewall, radvd.conf und die neighbor-proxy-Einträge ändern. Nicht schön!

Ich würde gerne mehr darüber wissen, was Du da wie bewerkstelligt hast.

Verstehe ich das richtig, daß Du einen eigenen Router kaskadiert hast und Dir für diesen einfach ein eigenes Prefix auf die linke Tour (Also ohne Unterstützung durch einen DHCPv6-Server auf dem DK7200 und damit ohne formale Prefix Delegation) abgreifst?

 

[DerJens]

Hallo SpaceRat,

nicht so ganz. Der TC7200 beherrscht keine DHCPv6-Extension - oder anders gesagt, er antwortet zumindest nicht auf entsprechende Anfragen. DHCP ist aber auch im ursprünglichen IPv6-Protokoll gar nicht mehr vorgesehen gewesen. Einen Großteil der notwendigen Konfiguration übernimmt ganz automatisch das Neighbor Discovery Protocol. Im Großen und Ganzen besteht das aus 4 verschiedenen ICMP-Paketen auf dem Link-Level. Damit kann der Client seine Nachbarn finden und unter diesen auch Router erkennen. Router können sich zudem selbst bekannt machen und Adressen vergeben. Das Problem ist, dass diese Mechanik eben nur auf Link-Level-Ebene funktioniert. Die NDP-Pakete werden nicht über eine Firewall, die man hinter den TC7200 hängt geroutete. Angenommen, du hast den TC7200 an eth0 und dein lokales Netz an eth1 angeschlossen, dann funktioniert NDP für eth0, so dass der TC7200 deiner Firewall an eth0 eine globale IPv6-Adresse zuweist. Deine Geräte im lokalen Netz, wie auch eth1 bekommen davon aber schon nichts mehr mit.

Die elegante Lösung wäre, wenn der TC7200 Prefix Delegation beherrschen würde. Der TC7200 bekommt nämlich (zumindest in meinem Fall) ein /57-Präfix zugewiesen, von dem er jedoch nur ein /64-Präfix nutzt. Er könnte also 126 weitere /64-Netze verteilen, von denen du eines für dein lokales Netz verwendest. Aber wie du wahrscheinlich schon erwartet hast, funktioniert das bei TC7200, wie auch der anfänglich in diesem Thread beschriebene Bridge-Modus des TC7200, ebenfalls nicht.

Damit sind alle eleganten Lösungen gestrichen.

Was ich jetzt mache ist ein Klimmzug, der die Funktionalität des Neighbor Discovery Protocols, zumindest in Teilen, doch in das lokale Netz spiegelt. Das funktioniert allerdings nur für feste globale IPv6-Adressen. Über einen Neighbor-Proxy-Eintrag auf eth0, dem ich für jedes der lokalen Geräte die jeweilige IPv6-Adresse aus dem lokalen Netz setze, kann ich dem TC7200 vorgaukeln, dass mein eth0 diese Adressen besitzt. Damit routet der TC7200 aus dem Internet kommende Pakete an meine Firewall, bei der ich die Pakete dann weiter ins lokale Netz leiten kann. Die Gegenrichtung ins Internet funktioniert automatisch über die Default-Routen. Der Krux an der ganzen Sache ist: es geht eben nur für statische IPs und der TC7200 bekommt alle 14 Tage ein neues Präfix zugewiesen. Ich habe also ein fettes Shell-Skript, das regelmäßig kontrolliert, ob sich das Präfix an eth0 geändert hat und in diesem Fall 1. die lokalen Adressen ändert, 2. alle Neighbor-Proxy-Einträge für alle lokalen Geräte von eth0 löscht und neu setzt, 3. die Konfiguration des RADVD auf das neue Präfix anpasst und 4. die Host-spezifischen Firewall-Regeln einmal ersetzt.

Das ist definitiv nichts, was man auf dauer so betreiben will.

Falls jemand eine bessere Lösung parat hat, immer her damit :zwinker:

Jens

 

[SpaceRat]

Falls jemand eine bessere Lösung parat hat, immer her damit :zwinker:

Mein Ansatz wäre näher an der Norm ...

Es fehlt ja eigentlich nur die Delegation eines Prefixes ...
Wenn wir nun einfach mal davon ausgehen, daß wir immer ein /57er Prefix kriegen, dann können wir uns das letzte Subnet oder auch das letzte /62er daraus auch selber ausrechnen:

2a02:908:1234:ff00::/57 ->
erstes /64er Subnet = 2a02:0908:1234:ff00::/64 (Vom elektronischen Mülleimer benutzt)
letztes /64er Subnet = 2a02:0908:1234:ff7f::/64
letztes /62er Subnet = 2a02:0908:1234:ff7c::/62

Dieses dann einfach in radvd oder dnsmasq übernehmen und advertisen, auch an den DK7200.

Ich habe das mal an meiner Fritz!Box 7390 indirekt ausprobiert:
1. Die Option "Auch IPv6-Präfixe zulassen, die andere IPv6-Router im Heimnetzwerk bekanntgeben" aktiv
2. Smartphone ins WLAN eingebucht und auf diesem den SixXS-Tunnel gestartet
3. Geräte im Netzwerk erhalten fortan zwei öffentliche IPv6-Adressen: Eine im Subnet der Fritte, eine im Subnet des Smartphones
4. ping6 <öffentliche IPv6 von PC1 aus dem Subnet der Fritz!Box> -I <öffentliche IPv6 von PC2 aus dem Subnet des Smartphones> ist erfolgreich

Ob das jetzt tatsächlich auch bei Euch in der Praxis funktioniert, hängt ganz wesentlich davon ab, ob das DK7200 ausgerechnet den Schutz vor rogue routers (Entspricht Punkt 1 des Tests) richtig macht. Da es sonst nix richtig macht, würde ich aber einfach mal hoffen, daß es auch den nicht hat ...

 

[Kiependraeger]

Hat das mal jemand ausprobiert? Ich bekomme nämlich keine Verbindung hin. Hab bisher immer ne Brücke zwischen WAN und LAN erstellt um mir die IPs zu holen + Firewalling mit iptables.

 

[DerJens]

Hallo zusammen,

@SpaceRat: ja, das habe ich auch schon probiert. Dabei gibt es zwei Probleme:

1. [...] einfach in radvd oder dnsmasq übernehmen und advertisen [...] bedeutet eine kontinuierliche Überwachung der Verbindung, da ich exakt alle 14 Tage ein neues Präfix zugewiesen bekomme. Mit dem neuen Präfix müssen dann die Konfigurationen von radvd und/oder dnsmasq angepasst und die Dienste neu gestartet werden.
2. Das K.O.-Kriterium: der TC7200 ignoriert das Router Advertisement und setzt keine IPv6-(Rück-)Routen. Die Pakete erreichen über die Default-Routen zwar ihr Ziel, die Antwortpakete bleiben jedoch am TC7200 hängen.

Möglicherweise habe ich ja was falsch gemacht, aber mir scheint, dass das nicht mein Problem ist :kratz:

DerJens

 

[SpaceRat]

@SpaceRat: ja, das habe ich auch schon probiert. Dabei gibt es zwei Probleme:

Naja, das war ja auch kein How-To, sondern ein einfach mal ins Unreine gedachter Ansatz.

Irgendwie hatte ich mir aber schon gedacht, daß das DK7200 auch dabei wieder Zicken macht.