ipv6 bei hetzner

Tuesday, December 30. 2014

 schon schräg. IPv6 humpelt immer noch.

Neuen root server bei hetzner bestellt (EX40 im RZ 21), Debian-77-wheezy-64-minimal drauf. Erste Aktion die neuen IPs auf dns.he.net eingetragen, host erkennt sie sofort, also als naechstes ein ssh auf den neuen Vogel. Dauert, und dauert, und .. Ok, ssh -4 neuerVogel.domain.tld: zap ist er da.

Gleich ein ping6 heise.de und 

PING heise.de(redirector.heise.de) 56 data bytes
From Debian-77-wheezy-64-minimal icmp_seq=1 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=2 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=3 Destination unreachable: Address unreachable
^C
--- heise.de ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5030ms
 
Na fein, Tante Google findet mir serverfault.com/questions/477471/ipv6-only-works-after-pinging-the-default-gateway mit einer Problembeschreibung, die ich voll nachvollziehen kann. Nur die dort beschriebene Lösung bleibt hier wirkungslos.
Zahllose google/test/reboot - Zyklen später bleibt als Ergebnis meiner Recherche:
- verblüffend wenige Fundstellen. IPv6 scheint wirklich kaum jemanden zu interessieren.
- der einzige auf meinem Rechner funktionierende Weg ist, den im obigen Link beschriebenen Workaround
  ping6 -I eth0 -c3  fe80::1
mit etwas sleep davor und danach in /etc/rc.local zu packen. slep 1 war zu wenig, sleep 10 tuts scheinbar.
 
Das ist doch kaum zu glauben, dass das Hetzner/debian - Image IPv6 nicht auf Anhieb klaglos hinbekommt sondern ich eine solche Krücke einsetzen muss! 
Vor gefühlt 10+ Jahren habe ich mir IPv6-Tunnel von sixxs und später he.net auf Hetzner-Server gelegt und die waren schneller benutzbar konfiguriert als das 'native' heute ...
 
 

 Vor bald schon drei Jahren habe ich das Verhalten der ISP zu IPv6 albern genannt. Das war in der Zeit der Counter auf das Auslaufen verfügbarer IPv4 - Adressen bei der IANA. Das ist nun schon graue Vergangenheit, IANA steht seit dem 3.2. 2011 auf 0 und inzwischen stehen APNIC (Asien/Pacific) und RIPE (Europa) mit 17, 18 Mio restlicher legacy IPs am dichtesten an der Kante. Oder noch weniger, Ripe hat jedenfalls am 14.9.2012 die letzte Schnitte ausgerufen.
Da rast der Zug also mit relativ vorhersehbarem Tempo auf's Gleisende zu.

Und bei den ISPs? Fast alles wie gehabt, mein Anruf bei der Alice-Hotline erwischt den Mitarbeiter dort auf dem falschen Fuss, weil er mit dem Begriff IPv6 grade nichts zu verbinden weiss. Gelegentlich findet man in Foren einen Beitrag von ISP-Mitarbeitern, die versichern, das Kundeninteresse im Auge IPv6 zeitnah einführen zu wollen, beharrliches Quengeln stösst auf nichts als Ausreden.
Kabel-anbieter (Kabel Deutschland, Kabel BW) geben IPv6, aber selbst wo es technisch möglich sein sollte, kann man sie nicht unbedingt bekommen. Ich zum Beispiel; auf der anderen Strassenseite ist Kabel Deutschland verfügbar aber ich wohne in einem Block, der bei irgendeiner undurchsichtigen Aufteilung von Interessensgebieten der seinerzeitigen Fernsehkabelanbieter einem anderen Oligopolisten zugeschlagen wurde.  

Aber jetzt gibt es wirklich mal Bewegung: angeblich seit September richtet die Telekom für Neukunden-anschlüsse Dual Stack ein. Neukunden heisst: das gibt es nur für sg. NG-Anschlüsse (bei denen die Telefonie letztlich via VOIP umgesetzt ist.)

Altkunden und Leute, die gern ihren ISDN-Anschluss (der auch bei Stromausfall noch funktioniert und mit Fax keine Probleme macht) behalten wollen, kriegen es aber nicht.  

Einen Überblick über den (Still)Stand bei den ISPs gibt Lutz Donnerhackes Artikel auf 
http://lutz.donnerhacke.de/Blog/IPv6-Wo-stehen-wir-im-Plan

Und, ergänzt aus Thomas Schäfers Kommentar (unten) noch eine interaktive Browser-Statistik. 
http://www.vyncke.org/ipv6status/compare.php?metric=p&countries=us,fr,jp,de,kr

Letztere sieht die Lage vom anderen Ende her an und zählt eben auch Tunnelanten (wie Thomas und mich) mit, aber es ist tatsächlich seit Oktober ein leiser Aufwärtstrend erkennbar. Frankreich weit voraus und Südkorea als Gegenbeispiel.

Update:
Slashdot, selbst immer noch ohne ipv6, hat einen post zum Thema. Gefühltes Resumee: in Amiland kommt langsam Bewegung in die Sache, ein großer Provider, comcast, bietet native IPv6 und andere Anbieter scheinen in Vorbereitung zu sein. Wie üblich nimmt das aesthetische Argument (die neuen IPs sind so lang / schlecht durchs Telefon zu sagen / iih, Buchstaben und Doppelpunkte) und die folgende Diskussion zu dhcpv6 erheblichen Raum ein.
Interessant ist vllt, dass der Vorreiter comcast mit einem Schwerpunkt seines Geschäfts Kabelanbieter ist. Hat das etwas mit der an die Endkunden verteilten Hardware zu tun oder warum sind Kabelanbieter in dieser Hinsicht anscheinend wendiger / innovationsfreundlicher?

Ts, ich entsinne mich an Zeiten, als die technointeressierte Crowd, die sich im Internet organisierte / begegnete, scharf war auf Neuerungen, neue Versionen, erweiterte Protokolle, was nicht. Bunte Vergangenheit!

Update 2:
Telekom - IPv6-user gibt es wirklich - dieses kleine Blog hatte den ersten Besucher aus 2003:: am 15.9.2012
 

update 3:
Ich habe da ein kleines plugin fuer Piwik entdeckt, dass IPv4 vs IP6 traffic mitzaehlt. Vllt gibt es dazu bald einen eigenen Eintrag,  erste Tageswerte liegen bei 5-6% IPv6. Vorne dran scheint KabelBW, Tunneln (HE, Sixxs) und dann mal Unitymedia, mal M-Net, mal Telekom.

update 4:
Seit Mitte Januar zählt mir Piwik nun die beiden Protokolle aus und, mal den Februar im ganzen genommen, erreichen mich tatsächlich 5% der Besucher via IPv6. Auch von der Verteilung bestaetigt sich das Bild (gefühlt! ich mache immer mal einen whois auf v6er, aber ohne jeden methodischen Anspruch): Vorne dran die Kabelnetze, dicht gefolgt von den Tunnelanten und dann der Rest als Streufeld: Google, Dassault-systems, Telekom, das chin. Universitätsnetz und quasi ein Cluster von Klein- und Kleinstanbietern aus Bayern. 
Gemessen an den repräsentativen Statistiken sind 5% natürlich ungewöhnlich viel. 
 
update 5:
Die Schweiz, Rumänien, Frankreich und Letzeburg liegen inzwischen mit 10 - 5% IPV6-Nutzung vorne in der Statistik, Deutschland nähert sich sachte den 3%, mit einer auffällig stetigen Kurve. Fast möchte man sagen, verdächtig stetig - Sprünge nach oben wären bei Ereignissen wie "weiterer ISP schaltet IPV6 frei" zu erwarten, Sprünge nach unten bei Ausfällen. Beides scheint in DE nicht vorzukommen. 
Die Zahlen sind nur ca. zutreffend, denn angesichts der anhaltenden Blockade seitens der ISP haben Tunnelanten einiges Gewicht. Und da zieht Sixx Traffik-anteile nach Kerneuropa, während meine Nutzung (via HE) andererseits die Statistik der US auspolstert.
 

Serendipity und IPv6

Saturday, October 6. 2012

Serendipity ist die Software, die dieses Blog liefert, und wegen eines IPv6-bezogenen bug dieser Software war dies blog mehr als einen Tag offline. 
Serendipity hat ein plugin Spamschutz mit einer Reihe von Möglichkeiten, Kommentarspam zu bekämpfen, und eine davon ist, erkannte Spammer per IP vom Zugang zum Blog auszuschliessen. Das hat sich hier gegen bestimmte Serienspammer erstaunlich gut bewährt. 

Bis der erste Spammer mit einer IPv6-Adresse gelogt wurde, danach war mein blog weg.

Das Problem ist: 

serendipity_event_spamblock.php patzt bei der Behandlung von IPv6-Adressen. IPv4 sind kürzer als IPv6 Adressen.
(IPv4: 4 Teile x 3 Stellen + 3 Trenner = 15 Zeichen  IPv6: 8 x 4 + 7 = 39). Darauf ist das plugin nicht eingerichtet.
Wenn man in der config des Plugin "SPAM IP Adressen via HTaccess blocken? " 'Ja' ankreuzt und eine IPv6-IP als Spam erkannt worden ist, dann schreibt das Plugin in die .htaccess etwas ähnliches wie:
 
#SPAMDENY
Deny From 205.189.73.46 205.189.73.64 208.89.211.173 217.157.179.122 24.62.10.133 
2607:5300:10:60 31.135.196.229 37.10.106.185 37.10.112.228 37.10.116.107 37.10.116.35 
#/SPAMDENY
 
Problematisch ist der Eintrag '2607:5300:10:60' Das ist keine gültige IP sondern nur die vordere Hälfte einer IPv6. Und so bekommt man nun bei jedem Versuch, das Blog zu laden, eine wunderschöne 500er-Fehlermeldung mit dem Hinweis auf 'invalid IP'
 
Das Hackstück aus der .htaccess zu löschen hilft auch nicht, denn mit dem naechsten Spammer wird der ganze deny from... - Block neu aus der Datenbank gelesen und eingeschrieben, incl. des fehlerhaften Eintrags. Die zuständige Tabelle heisst serendipity_spamblock_htaccess und ist wohl auch gleich die Schuldige an dem Bug. 
 
Diese Tabelle hat zwei Felder, timestamp vom Typ varchar(19) unsigned und ip vom Typ varchar(15). Eine Breite von 15 ist fuer legacy IPs grad recht, für IPv6 ist das ein Fehler. Benötigt wird eine Feldbreite von varchar(39). 
 
Massnahmen:
- Breite des Feldes ip auf 39 hochsetzen
- alle (in meinem Fall nur 1) defekte IPv6 löschen
o shell öffnen, 
o mysql -u (username) -p (und passwort)
o use (datenbankName)
o delete from `serendipity_spamblock_htaccess` where (`ip` like "%:%");
- auf den nächsten Spammer mit IPv6 warten...

fonera, openwrt und IPv6

Friday, July 20. 2012

Kann man mit einem Passwort einen WLAN-Router hinrichten? Kommt drauf an, was man als nächstes macht, so die nahe liegende Antwort - aber ich habe doch gar nichts gemacht.... - wie aus dem Support-Bilderbuch.
Das Opfer war mein altgedienter Linksys WRT54GS, mit openwrt White Russian an Bord seit Jahren stabil. Für einen Flachmann, der es nicht anders konnte, lief das Funknetz immer noch mit WEP. Jetzt umgestellt auf WPA, ein richtig schön langes Passwort vergeben - und drei Tage später stirbt das WLAN im laufenden Betrieb, der Linksys lässt sich auch nicht mehr über das Webinterface ansprechen und macht seltsame Spratzeltöne. Alles neu booten und resetten hilft nichts: das Ding ist hin.

In der Tüte kramend taucht ein alter fonera (fonera 2100A, wirklich alt) auf, der sich, eingestöpselt, gleich ein firmware-update zieht. Passwörter und alles sind verschollen, eine Büroklammer auf den winzigen Resetknopf an der Unterseite, langes Halten, Strom aus, an und mit weiter gedrücktem Reset booten lassen: jetzt ist die firmware wieder Version 0.7.0 r4, die Passwörter sind fonera-default admin/admin bzw. root/admin und ich kann mich ans rooten machen.

Zunächst mal auf einem WLAN-Client ein passendes subnet fuer den Zugriff auf's webinterface:  
ifconfig eth1:1 192.168.10.20

Dann ssh aufmachen, hier funzt es mühelos mit BingoBommels step1.html/step2.html - Lösung:
zwei kleine HTML-docs auf dem Rechner anlegen, step1.html: 

<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/adv_wifi.sh" enctype="multipart/form-data">
<input name="wifimode" value="/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='&quot;;' + this.form.wifimode.value +';&quot;'}" />
</form>
</body>
</html>
 
und step2.html:
 
<html>
<head>
</head>
<body>
<center>
<form method="post" action="http://192.168.10.1/cgi-bin/webif/adv_wifi.sh" enctype="multipart/form-data">
<input name="wifimode" value="/etc/init.d/dropbear" size="68" >
<input type="submit" name="submit" value="Submit" onClick="{this.form.wifimode.value='&quot;;' + this.form.wifimode.value +';&quot;'}" />
</form>
</body>
</html>
erst das eine, dann das andere doc im Browser oeffnen, je auf den submit-Button klicken und fertig.
Jetzt geht ssh root@192.168.10.1, user root, Passwort admin.

Und um das permanent zu machen, jetzt in der ssh-shell:

mv /etc/init.d/dropbear /etc/init.d/S50dropbear
vi /etc/firewall.user

da gibt es, unter der Überschrift ### Open port to WAN zwei auskommentierte Zeilen, da je die Kommentar-Hashes löschen. ("i" aktiviert den edit-Modus, ESC :wq speichert und beendet vi. Mehr vi-commands googlen)
Schliesslich wollen wir der Kiste noch abgewöhnen, sich irgendwelchen code von "zu hause" herunterzuladen und auszuführen, dazu:
 
vi /bin/thinclient
und dort eine  Zeile auskommentieren, eine Zeile ergänzen, so dass dort steht:
# . /tmp/.thenclient.sh
cp /tmp/.thinclient.sh /tmp/thinclient-$(date '+%Y%m%d-%H%M') 
 
Speichern, und die Kiste ist gerootet. 
Weiter geht's mit telnet, ich habe mich da an diese Anleitung gehalten, Varianten zum Vergleich. Und auf deutsch.
Es wird jetzt ein spezieller Kernel installiert, um Schreibschutz aufzuhaben, und im zweiten Schritt der Redboot Boot Loader der Kiste neu konfiguriert. Diese Schritte müssen ungestört ablaufen, sonst ist die Kiste hin.
 
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWrt:~# Connecting to ipkg.k1k2.de[85.10.200.90]:80
openwrt-ar531x-2.4-v 100% |**************************|   512 KB    00:00 ETA
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ... [w]
root@OpenWrt:~# reboot
 
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://ipkg.k1k2.de/hack/out.hex
root@OpenWrt:~# Connecting to ipkg.k1k2.de[85.10.200.90]:80
out.hex 100% |*******************************| 4096 00:00 ETA
root@OpenWrt:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
Unlocking RedBoot config ...
Erasing RedBoot config ...
Writing from out.hex to RedBoot config ... [w]
root@OpenWrt:~# reboot
 
Die fonera bootet jetzt nicht mehr vollstaendig, sie hört auf die IP 192.168.1.254 und lauscht auf port 9000 auf eine telnet-Verbindung. In der Beschreibung stand, dies tue sie nur für 10 Sekunden, aber bei mir hielt es länger vor.
So, Ethernet-Kabel direkt von der Fonera zum Rechner, dem auch eine route in das subnet legen und dann:
telnet 192.168.1.254 9000
 
Für den nächsten Schritt, ein normales Openwrt auf der Fonera zu installieren, brauchen wir auf dem Rechner einen tftp - Server, der den Kernel und das root.squashfs serviert. Der Rechner war in diesem Fall ein Linux Mint Maya und nach etwas Probieren habe ich den atftpd installiert, wobei ich ihn für seinen kurzen Einsatz direkt aus der cli als daemon gestartet habe. Das ging nicht gleich auf Anhieb, Konfigurationshilfe war nützlich und zusätzlich war dieser Bug zu umschiffen. Es ist ratsam, mit dem atftp - client die korrekte Funktion des Servers zu testen...
Und Openwrt - Kamikaze 8.09 und Backfire 10.03 sollen beide gehen, ich habe es dann nach etwas Schwanken mit backfire 10.03.1 versucht, was letztlich auch geht. (Vielleicht haette ich dann besser gleich trunk genommen, denn mit IPv6 holperte es etwas) Die Versionen stehen nebeneinander unter http://downloads.openwrt.org/ - ich habe  openwrt-atheros-vmlinux.lzma und openwrt-atheros-root.squashfs gezogen und in das Ausliefer-Verzeichnis des atftpd, bei mir /srv/atftpd, gelegt.

So, wenn der tftp-Server läuft, geht es zurueck in die telnet-Shell der fonera und zum RedBoot -Prompt. Da wird jetzt erst mal die Verbindung gesetzt, -h ist die IP des Rechners mit dem tftpd-Server, -l (ein kleines L) die IP der kleinen Kiste. 

RedBoot> ip_address -h <192.168.1.20> -l <192.168.1.254>/24

Also das kernel image laden, memory wipen, kernel flashen. Dauert etwas:

load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma
fis init
fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7

Und anschliessend das root-file system:

load -r -b %{FREEMEMLO} openwrt-atheros-root.squashfs
fis create rootfs

So, das dauert nun nochmal einiges länger, nicht ans Kabel kommen, stattdessen Kaffe kochen oder ein bad nehmen oder so.

 

Irgendwann ist er fertig und man sieht wieder den RedBoot> - Prompt, jetzt kann man sich überzeugen, dass auch wirklich der neue kernel zum booten konfiguriert ist:

fconfig -l -n

Yo, reboot und rein in's Vergnügen:

reset

OpenWrt meldet sich, immer noch unter 192.168.1.254 mit der WebOberfläche, man wird aufgefordert, ein root-Passwort zu setzen und kann sich dann durch die Konfig-Optionen bewegen. Mit Lan und Wifi in einer Bridge vereint ist der Nutzen einer Firewall auf dem Geraet eh fraglich, bei mir schien sie vorrangig damit befasst, alle durchgehenden Pakete wegzufressen. Input, output forward auf accept zu setzen und ausser lan: alle zonen (sprich: die leere wan-zone) zu löschen scheint geholfen zu haben.

IPv6 ging anfangs auch nicht, hier half nach

opkg update
opkg install kmod-ipv6  ip 
/etc/init.d/network restart

noch das Anlegen einer route mit

ip -6 route add 2000::/3 via 2001:db8::dead:c0de metric 256

, die Seiten der OpenWrt-Docu und, als alles zu hängen schien, ein reboot nicht nur der fonera sondern auch des Lan-seitigen Rechners...

Und als Treppenwitz, der auch das anfangs angesprochene Thema, wann Sachen so kaputtgehen, aufnimmt:
als nun mit der fonera und IPv6 alles klappte, jedenfalls im Lan, war plötzlich nach aussen kein IPv6 mehr erreichbar. Der HE-Tunnel hatte sich verabschiedet, was etwa alle 18 Monate vorkommt und nach einer mail an den Support binnen Minuten gefixt wird.
 

Mit IPv6 sind Adressen nun nicht eben knapp und ein Interface kann etliche globale IPs haben - wie kann man Einfluss darauf nehmen, welche davon für ausgehende Verbindungen genutzt wird?

Ich fand ein nützliche Beschreibung der Auswahl, zwei Infos daraus waren mir nützlich:

- Wenn mehrere globale Adressen alle anderen Auswahlkriterien bestanden haben, nimmt Linux die zuletzt hinzugefügte.
- Man kann bestimmte Adressen als "deprecated" markieren, so dass sie bei der Auswahl nicht berücksichtigt werden.
ip -6 addr change 2001:db8:F00::BA2/128 dev eth0 preferred_lft 0
(Hm. So steht's da, aber im Test passiert etwas ganz anderes: die Adresse wird nicht als deprecated markiert, stattdessen steht da nun valid_lft forever preferred_lft forever. Statt dem beabsichtigten 'Mach schnell mal 'ne neue Adresse' ist es ein: 'Nimm jetzt immer diese' geworden, grad das Gegenteil.)

 

Nicht alles geht so, wie ich es erwartet hätte:  eine manuell (in /etc/network/interfaces) vergebene IPV6 und privacy extension. Ich würde halt gern einem Rechner eine 'nette' IPv6 verpassen, was mit dem hex-Zeichensatz und etwas leetspeak ja gut möglich ist. Ein besonders schoenes beispiel sieht man etwa mit host facebook.com  . Und gleichzeitig möchte ich für von dem Rechner ausgehende Verbindungen die privacy extensions aktivieren, also Adressen mit scope global temporary dynamic verwenden. Und das klappt nicht (verlässlich). Nach einem reboot sehe ich zuweilen eine temp Adresse verwandt, aber bald schon ist es doch die manuelle Adresse, die in den Logs auftaucht. 
cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr gibt eine 2 aber ip -6 addr listet nur eine globale Adresse mit valid_lft forever preferred_lft forever.

Ist Autokonfiguration aktiv, dann bleibt die automatische IP, die ja nach einer festen Regel gebildet wird, stabil, solange man nicht mit der MAC herumspielt. (Man erkennt die automatischen IPs daran, dass an der Grenze zum letzten Drittel, also Byte 12 und 13, immer ff:fe steht.) Und dann werden für ausgehende Verbindungen auch die temporären Adressen verwandt. 

 

(Page 1 of 6, totaling 27 entries) » next page