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 ...
 
 

IPv6-Tunnel und Privatheit

Friday, March 9. 2012

 Wer in den letzten 3+ Jahren irgendwo eine Forendiskussion über IPv6 verfolgt hat, kennt den Alarmismus der NAT-Jünger und dynIP-Vertrauenden. Mit IPv6 komme das Ende der Anonymität im Netz, dann habe jeder Anschluss seine feste IP, jede IP sei dem Inhaber klar zuordnenbar und die Anwälte der Contentindustrie und andere Datensammler könnten unbehindert auf die einzelnen zugreifen.
Man kennt auch die Gegenargumente: 
deren stärkstes ist, dass die Anonymität der dynamischen IPs mit IPv4 mit Zwangstrennung wie in Deutschland üblich, nur scheinbar ist, weil der Staat und die Anwälte routiniert auf die Logs der ISP zugreifen, in denen festgehalten ist, welchem Anschlussinhaber zu welcher Zeit welche dynamische IP zugeteilt war. Und das Anonymität, also die Chance, sich hinter einer IP verstecken zu können, nie ein beabsichtigtes Feature des Netzes gewesen ist.
Mit einem konkreten Vorwurf lässt sich schon jetzt der Schluss von einer dynamischen IPv4 auf einen Anschlussinhaber mit einem gewissen legalen Aufwand ziehen. Und mit IPv6 ändert sich daran nichts wirklich.

Soweit die Vorrede, jetzt kommt das aber: dass ich mich mit IPv4 schon daran gewöhnt habe, dass ein Webserver, den ich besuche, nicht mit einem schlichten whois meinen Namen und Adresse, Telefonnummer aus der IP in den Logs ermitteln kann. Ein wenig legaler Aufwand soll schon sein.

Und da gibt es jetzt zwischen den beiden namhaften/relevanten Anbietern von IPv6-Tunneln, Sixxs.net und he.net, einen markanten Unterschied. 
Mal angenommen ich gehe auf einen IPv6-faehigen www server via eines HE.net -Tunnels und meine IP sei 2001:470:DB8::CAFE:AFFE:F00:BA2. Und jemand sieht das im Server Log und macht ein whois.
Dann bekommt er im Wesentlichen:

NetRange:       2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR:           2001:470::/32
OriginAS:       
NetName:        HURRICANE-IPV6

Dem folgt noch eine Menge HE-spezifisches, aber die Rückverfolgung endet bei dem Schluss: ist via HE unterwegs.
 
So, und das gleiche via SIXX, whois 2001:6f8:DEMO::1  (ich haette gern das Beisepiel wie oben mit db8 (debate) gebildet, aber ein Netz mit der Adresse ist wirklich vergeben)
 
inet6num:        2001:6f8:DEMO::/48
netname:         SIXXS-NET-DU9876-RIPE
descr:           SixXS assignment to end-user DU9876-RIPE
 
Den Handle 'DU9876-RIPE' (das ist konkret ein Beispiel-dummy!!) gebe ich nun in das Sixx-Whois-Formular ein und bekomme 
person Dummy User
address Teststr.. 5
address 12345 Berlin
address Germany
e-mail dummy@userdomain.de
mnt-by DU9876-MNT
phone +49 170 1234567
 
(Wohlgemerkt: das ist von einem echten Beispiel genommen und alles Persönliche außer der Hausnummer und Stadt ist mit dummy user test anonymisiert. Wenn ich wollte, könnte ich den Besucher dieses Blogs um Feedback anrufen oder -mailen)
 
Hm. Ehrlich gesagt ist mir die Art, wie HE das umsetzt, doch einiges lieber. Zwei meiner drei an IPv6 angetunnelten Lan hatte ich ja eh schon bei HE, ich habe nun auch das Dritte umgestellt.
 

IPv6-Tunnel mit he.net unter ubuntu

Tuesday, May 18. 2010

Es gibt verschiedene Tunnelbroker für IPv6overIPv4, Sixxs.net und he.net (tunnelbroker.net)  sind die bekanntesten. Für adsl mit wechselnden IPv4-adressen, wie hier üblich, hält sixxs.net den praktischen daemon aiccu bereit, der, einmal mit den Eckdaten wie Tunnel-ID, Passwort, Server-IP versorgt, den Aufbau des Tunnels und die Aktualisierung der Endadrese bei Wechsel der dynamischen IP ganz wunderbar erledigt, so dass man da keinen Aufwand der Konfiguration hat.

Nun habe ich leider mit sixxs immer wieder Netzwerkprobleme erlebt, ein Ping > 300ms bremst schon sehr spürbar, wenn alle Browser etc vorzugsweise IPv6 benutzen. Ich habe deshalb zu tunnelbroker.net umgestellt, aber die Frage der Konfiguration kommt damit neu auf.

Auf der Detail-seite zu einem mit tunnelbroker.net eingerichteten Tunnel bekommt man zwar (für versch. betriebssysteme) eine beispielkonfiguration angezeigt, die ich (linux-route2) so wie sie kam in die Kommandozeile pasten konnte und schon lief der Tunnel. aber nach der nächsten Zwangstrennung geht dann wieder nichts mehr.Und jedesmal per Hand ist keine Option.

Bei mir ist ein alter p3-Rechner der Router und so kann ich /etc/ppp/ip-up und /ip-down verwenden, Scripte, die in diesen Ordnern liegen, werden bei Herstellung bzw. Trennung der Verbindung automatisch aufgerufen, mit nützlichen Parametern wie etwa Localip und Remoteip. Programme wie fetchmail, postfix etc legen hier bei der Inwstallation Eintraege an und in beiden Ordnern habe ich ein kleines shell-script für meine eigenen Zwecke, hier als Beispiel /etc/ppp/ip-down.d/ip-down-local

#!/bin/sh

# this script is called from ip-down
# to hold actions I want to happen whenever the IP-Connection is stopped     

BASENAME=`basename $0`

INTERFACE=$1
DEVICE=$2  
SPEED=$3
LOCALIP=$4
REMOTEIP=$5

case "$INTERFACE" in

ppp0*)
        # he-ipv6 anlegen
        /usr/local/bin/heIpv6-del.sh
        ;;

*)
    # dont know...
    ;;
esac | logger -t $BASENAME

Entsprechend gibt es auch ein /etc/ppp/ip-up.d/ip-up-local, hier sind die relevanten Zeilen

# tunnelbroker updaten
    /usr/local/bin/tunnelbroker_update.sh $4               

    # he-ipv6 anlegen
    /usr/local/bin/heIpv6-add.sh $4

Und die drei hier aufgerufenen Scripte in /usr/local/bin lauten

heIpv6-del.sh:
ip -6 route flush dev he-ipv6
ip link set he-ipv6 down
ip tunnel del he-ipv6

heIpv6-add.sh
ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local $1 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f0a:12ef::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

tunnelbroker_update.sh
#!/bin/sh
curl -k "https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$1&pass=0000000000000000000000000000000&user_id=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&tunnel_id=11111";


(bei dem Aufruf von curl, - 1 Zeile! - muss man die Parameter mit den eigenen daten setzen, hinter pass gehoert der md5-Hash des Passwortes (echo -n 'yourpassword' | md5sum), user_id ist nicht der Username sondern die userID von der tunnelbroker-Seite - auch ein MD5-Hash, tunnel_id ist die global tunnel ID - eine 5stellige Zahl.)


(Page 1 of 1, totaling 3 entries)