Seit 4 Tagen bin ich den lästigen reconnect der Telekom los. Keine Zwangstrennung mehr nach 24h. Yes !
Wie das geht ? Ziemlich simpel. Man wechselt den Tarif beim rosa Riesen. “Call & Surf Comfort IP” heisst das Ding. Einher mit dem Tarif geht ein SIP-Account, über den man von dort per VoIP erreichbar ist (Besonderheiten der Telekom inclusive – verfasse dazu noch einen Blogeintrag). Aufgrund dessen fällt dann nämlich die Zwangstrennung weg. Nun gut, genug Marketinggedönse. Zum eigentlichen: Wie ich ja schon gebloggt habe, bin ich zufriedener sixxs Kunde, was meine ipv6-Welt angeht. Schön statische Prefixe, soviel /56er subnetze (statisch!) wie man haben will. Eigentlich genau das, was man als Betreiber von ein paar unwichtigen Diensten im Netz so benötigt.
Ganz gegensätzlich ipv6 bei der Telekom. Man bekommt ein /64er /56er Prefix, und das ist zu allem übel auch noch dynamisch. Sprich bei jedem Reconnect (der zwar, s.o., nur noch alle Jubelmonate kommt) gibts wieder einen neuen Prefix. Ist jetzt nicht der ultimative Brüller, denn der Sinn von ipv6 war ja genau dieses Dilemma zu lösen. – Wir erinnern uns: in den 90ern gab es die dynamische Vergabe nur, weil die ganzen ISPs mehr Kunden als ipv4-Addressen hatten – also mit ipv6 eigentlich kein Grund mehr für sowas. Die Gründe mögen vielfältig sein. Paranoide Menschen sind der Meinung, dass man mit dyn.IP’s einen Datenschutzzugewinn hat (Bullshit !), die Telekom meint, dass man statische IPs besser hochpreisig vermarkten sollte, und so on.
Nun, was tun mit dem schwankenden ipv6-Prefix, bei dem man nichtmal ‘ne DNS-Reversedelegation setzen kann ? Folgende Dinge sind mir so eingefallen:
- Testen des sixxs.net oder HurricaneElectric-Tunnels von “aussen” 🙂
- Backup-Routing, falls sixxs/HE mal down sind (wobei das vermutlich tricky wird)
- Den “User” Kram aus dem Heimnetz über das
/64/56er routen. Alle Dienste über die statischen Netze
Naja, wie auch immer man sich entscheidet, das ganze unter linux auf einem “Selbstbaurouter” einzubinden bedarf ein wenig Bastelei. Was haben wir ?
- Ein Standard DSL-Modem (Speedport 221) / kein Router (an dieser Stelle sei erwähnt, dass, entgegen irgendwelchen Aussagen, ein Modem vollkommen ausreicht (sowohl für VoIP, als auch für Entertain, sowie für ipv6) – “pppoe-Passthrough” in einem Speedportrouter kann funktionieren, muss es aber nicht. Je puristischer, desto besser.
- Ein lauffähiges Linux, mit dem wir schon in der Vergangenheit pppoe gemacht haben und welches die öffentliche ipv4 bekommt. – Ich nehm’ hier Debian. Ein vorkonfektioniertes pfSense, ipcop, und wie die Distributionen so alle heissen, sollte auch gehen.
- pppoe über rp-pppoe wie gewohnt. Hier in die /etc/ppp/options ein “+ipv6” eintragen
Jetzt gibts beim Reconnect zusätzlich zur ipv4 eine ipv6-LinkLocal-Adresse. Mit der kann man noch nicht so viel anfangen, denn die ist ja linklocal und damit nicht gerouted. An dieser Stelle hab ich echt am längsten (im wahrsten Sinne des Wortes) gehangen. Wie kommt man nun an die ipv6-IP ? Im Normalfall über zwei Wege. Entweder Router-Advertising, oder DHCPv6 (wobei letzteres nur bedingt empfehlenswert ist). Die Telekom announced die Prefixe per RA. Und zwar in 10 Minuten Intervallen. Was zum debuggen recht schmerzhaft ist (immer 10min. warten). Um dem geneigten Leser die Wartezeit (und das debuggen) zu verkürzen hier die Einstellungen die man am ppp0 vornehmen sollte (am besten in irgendein /etc/ppp/ip-up.d/file zur Firewall packen):
echo 0 > /proc/sys/net/ipv6/conf/ppp0/forwarding
echo 1 > /proc/sys/net/ipv6/conf/ppp0/autoconf
Sodann wirds beim nächsten RA (wie gesagt: Nur alle 10 min. !) eine öffentliche IP geben, die dann über die, oben erwähnte, LinkLocal-Adresse raus/reingerouted wird. Routen sollten automatisch gesetzt werden.
ip6tables kann man dann nach gusto anpassen. Bei mir bekommt nur der “router” die Dynamische-V6, da dort der (Zwangs-)Proxy mit adblocker & Co. läuft – reicht dort also. Wer das v6 im LAN nutzen möchte, dem sei der radvd (Router Advertising Daemon) ans Herz gelegt.
Ein Grundsetup an ip6tables-Rules finden wir hier:
/sbin/ip6tables -P INPUT DROP
/sbin/ip6tables -A INPUT -i lo -j ACCEPT #allow everything out
/sbin/ip6tables -A INPUT -p icmpv6 -j ACCEPT
/sbin/ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/ip6tables -A INPUT -i $LAN -j ACCEPT # allow GRE
/sbin/ip6tables -A INPUT -i $WAN -j LOG --log-prefix "INP6:End "
/sbin/ip6tables -A INPUT -i $WAN -j DROP
### OUTPUT
### (connections with the router as source)
echo "BASE OUTPUT"
# base case
/sbin/ip6tables -A OUTPUT -o $WAN -j ACCEPT #allow everything out
/sbin/ip6tables -A OUTPUT -o $LAN -j ACCEPT #allow everything out
Happy v6ing !
[Update 26.02.2014] Es gibt ein /56er Prefix bei der Telekom, keine /64er – löst das Problem aber nicht. Danke an den Hinweisgeber.
man kann die 10min auch per manueller router discovery überspringen: rdisc6 pppoe-wan
ps: wo bleibt dein post übers voip?
Hi f4bs.
Die 10min. lassen sich nicht skippen, da das Router-Advertisment vom Provider kommmt. Mit anderen Worten: Das wird vom ISP “gepushed”. Da ist leider nix mit pullen wie bei DHCP. Mit rdisc6 hast Du halt nur einen anderen Daemon, der ebenso auf das RA wartet, wie der Kernel – nur halt im Userland statt im Kernelspace.
Zum Thema VoIP: Ja, wenn Zeit ist 😉
Nein, das stimmt nicht. Ich kann jederzeit mein /64 prefix auf dem wan-interface mit o.g. befehl abrufen bzw das RA von der Telekom pullen. Man(n) muss wie gesagt keine 10min warten. Siehe http://pastebin.com/raw.php?i=fJtdb8XZ
Spannend. Bei mir wartet der 10Min. Sollte es da ggf. noch Unterschiede geben ? Hast Du Entertain ?
Nein, ich habe kein Entertain. Läuft denn Entertain schon über ipv6? Afaik läuft das doch über ipv4.
Nee, Entertain laeuft via ipv4. Vermutung war, dass bei “aufgeschaltetem” Entertain (VLAN8) das RA-Pulling moeglich ist. Scheint aber nicht so. Ich werds mal testen, ob es per radisc6 schneller geht.
und wie siehts aus? sollte mich wundern, wenns bei Dir nicht geht.
Yap – tut mit rdisc6 – sogar asap, ohne 10min. wartezeit. Wie bekommt man das nun den “Standard”-Prozessen innerhalb des Kernels beigebracht ? Weil: rdisc6 ist ja nun eher so ein “Debugging-Tool”
also bei mir klappt das mit dd.wrt nicht so recht.
dhcp6c ziegt zwar ne öffentliche ip, aus der konsole geht auch der ping ins ipv6 land, aber die lan pc´s kommen alle nur bis zum router. ipv6 forwarding und co ist natuerlich aktiviert. provier ich jetz auch mal rdisc6 aus.
@Malle: Du musst die ipv6-Adressen auch per radvd ins LAN verteilen. Von alleine bekommen die LAN-Rechner kein v6, sondern nur LinkLocal.
Joerg: das ist alles eingerichtet, meine PC´s bekommen ja auch die 2003 der telekom. aber mitm routing ab dd-wrt hakts, aber so mega firm bin ich mit ipv6 auch nicht so dolle. der hop bis zu gateway klappt, auch die öffentliche ipv6 wird aufgelöst.
rdisc6 zieht bei mir leidr gar keine ip.
ah jetzt klappts. radvd braucht “prefix ::/64” . so orientiert es sich an eine nicht link lokalen adresse fuers RA. bloedes dynamisches telekom prefix 🙂
mh leider entschwindet die ip adresse nach ein paar std vom br0. da hildft dann nur ein reboot, denn eine “neue” kann ich nicht er”dhcp´en”.
strange.
In der tat suspekt. Das br0 ist Deine lokale Bridge ins LAN, oder?
Wenn ich ich ehrlich bin, habe ich das T-Offline-V6 nur an den Router gebunden. Die Workstations/etc. im LAN bekommen statische v6 aus dem sixxs-Netz. Das ist wenigstens statisch, sodass man den radvd drauf konfigurieren kann.
Scheint ein echtes Problem zu sein. Dynamisches v6 ist einfach Schrott. Hier ein paar Ideen, wie andere damit umgehen: http://debianforum.de/forum/viewtopic.php?f=30&t=139172#p905877
ja irgendwie scheint nach ein paar std der dhcp6c dann einen fail zu haben. der läuft zwar noch . .. aber in kill und restart bringt keine neue ip6 zustande. gerade mal ein wenig mit getestet. kille ihc den dhcp6c, verschwindet auch meine 2003:xxx vom br0. im log steht auch nix nennenswertes. vielleicht findet sich noch ne alternative zu dhcp6c. aber rdisc6 bringt leider gar nix. ansonsten läuft ipv6 echt topp und verteilt alles im lan. jetzt koennt eich natuerlich den router anweisen zu rebooten, wenn die ipv6 nicht mehr da ist, dass kann aber ja nicht sinn der sache sein. Aufjeden fall hat mir dein tipp mit +ipv6 fuer den pppoe schon mal ip6 nach hause gebracht 🙂
br0 ist in der tat die brücke von wlan, und lan. ppp0
So, es hat sich gezeigt, dass der dhcp6 client nur eine time to live für 14400 sekunden bekommt ( 4 std ) danach is denn feierabend. nu habe ich den mal mit kill -9 abgeschossen. schauen ob dann alles erhalten bleibt,lol. ansonsten verusch ich mal den dibblerclient
Also die verbidnung zut t-com wird trotzdem nach 14400 sekunden gecappt. die IP6 bleibt aber wenigsten nun aufm br0 erhalten. ein erneutes anstupsen des dhcp client lässt die verbindung wiederaufleben. so habe ich nun ein shell script implementiert, welches alle 10 sec ein ip6 host anpingt, schlägt das fehl, wird der dhcp6 client kurz angestubbt und danach wieder geikllt. das ganze im loop. na hoffentlich klappts. omg, was ne story und nerven hat das schon gekostet ^^
Jörg: übrigens: radvd kannste mit ::/64 auch autokonfigurieren. dann bekommen deine clients auch t-com ip´s. allerdings natuerlich dynamische. nix, wenn man dienste anbieten will . . .
Und wie machen das die “Standard-Speedport-User”? Ist da Ende mit v6 am Plasterouter, oder läuft da auch ein radvd? Würd mich echt mal interessieren. Die Zugriffe von 2003er-IP’s kann ich, im gegensatz zu den Tunnelusern, hier im Blog an einer Hand abzählen. Das ist nicht wirklich viel (3-4 IPs in 2 Monaten)
ich hab kein plan, ich hab auch mal danach googlen wollen. der w723v ist ja leider nicht von avm. ich hab mir zur sicherheit mal einen gemitet, falls es mit dd-wrt und IP anschluss nicht geklappt hätte. ich könnte Ihn mal anschliessen und mitm hub und wireshark was ablauschen.
zur zeit hantiere ich mit dibbler. das sucht seine config leider fest in /etc/dibbler. nur bloed , dass in dd-wrt /etc (ro) ist. nun durchwühl ich grad die dibbler source, um das zu ändern und es zu kompilieren.
zum radvd und dem w723v: in seinem pppoe client ist sicher ipv6 schon aktiviert. so. es erfolgt dann eine einwahl. mit awk koennte die ip6 dann vom interface gezogen werden und wird dynamisch in die radvd.conf geschrieben. danach startet radvd. fertig. beim dd-wrt isses ein wenig komplizierter, bzw bei allen (ro) oder temporären dateisystemen.
btw: allen durch mich müsste sich der 2003er erheblich erhöht haben 😀
schliesslich wird AAAA bevorzugt . . .