You are here

Netzwerk

World IPv6 Day

Heute ist World IPv6 Day. Punkt.

Das ist eine Aussage, die man erstmal langsam verarbeiten muss, denn den meisten Leuten dürfte das herzlich egal sein. Und eigentlich kann Otto Normal User mit dem Begriff an sich noch nicht einmal etwas anfangen. Aber der Tag ist dennoch wichtig, weil es keine neuen IP Adressen der bisherigen Art (IPv4) gibt. Die Einführung der nächsten Generation des Internet Protokolls (IP) läuft aber seit Jahren schleppend: die Provider bieten vielfach kein natives IPv6 an, weil die Kunden es nicht nachfragen. Die Kunden fragen es nicht nach, weil die Webseiten kein IPv6 anbieten. Die Webseitenbetreiber stellen nicht auf IPv6 um, weil niemand es benutzt. Und dazwischen hängen noch die Hersteller von Router-Hardware, die vielfach auch lange Zeit kein IPv6 unterstützten. Somit blieb die neue Version der IP-Adressierung bislang vielfach nur den interessierten Freaks vorbehalten, die sich irgendwelcher Tunnelmechanismen bedienten. Aber langsam wendet sich das Blatt ja.

Heise und Spiegel berichten auch über den World IPv6 Day. Spiegel schreibt zum Beispiel: 

Telekom-Sprecher Lichtenthäler betonte, dass von dieser "stillen Umstellung" kein Nutzer etwas merken werde: "Bestandskunden müssen gar nichts tun, weil sie auch in den nächsten Jahren weiterhin mit ihren IPv4-Protokollen online sein können." Provider wie die Telekom bauten dafür derzeit einen Parallelbetrieb auf. Die Telekom will die einzelnen Datenpakete von Anfang 2012 an durchgehend sowohl via IPv4 als auch via IPv6 durch ihre Leitungen jagen können. "Es gibt keine Pläne, IPv4 abzuschalten", betonte Lichtenthäler.

Noch völlig offen ist Lichtenthäler zufolge die Frage, ob künftig alle Geräte dauerhaft identifiziert werden könnten. Technisch sei es zwar möglich, eine von zwei Bestandteilen der IPv6-Adressen bei der Einwahl der Geräte ins Netz stets per Zufallsgenerator zu erneuern und so für eine Anonymisierung zu sorgen. "Dabei gilt es aber, die Bequemlichkeit der Nutzer mit der Privatsphäre abzuwägen", sagte der Telekom-Sprecher.

Der Telekom-Sprecher spricht hierbei zwei Punkte an: zum einen geht es bei diesem World IPv6 Day darum, daß die Anbieter ihr Angebot sowohl über IPv4 als nun auch über IPv6 erreichbar machen und zum anderen soll dies dann eventuelle Probleme im Netzwerk aufdecken. Dabei ist natürlich fraglich, wie praxisnah dieser Test-Tag sein wird, wenn die Provider keine IPv6 Adressen an die eigenen Kunden verteilen. Insofern dürften in der Tat die normalen Kunden nichts von diesem Tag mitbekommen. Aber es ist immerhin schon mal ein Schritt in die richtige Richtung.

Zum anderen gibt es bei IPv6 auch ein paar Schattenseiten. Dadurch, daß nun durch den größeren Adressraum so dermaßen viele IP-Adressen zur Verfügung stehen, wird nicht nur die IP-Adresse länger und schwieriger zu merken, sondern jedes Gerät kann eine eigene IP-Adresse bekommen, die sich unter anderem von ihrer MAC-Adresse ableitet. Dadurch wird der Rechner oder das Gerät eigentlich permanent identifizierbar, allein durch die IP-Adresse. Vom Datenschutz-Standpunkt betrachtet ist dies natürlich unschön. Aber es gibt durchaus Methoden, wie man dies verhindern kann. Heise hat hierzu, zu den sogenannten Privacy Extensions, eine Anleitung auf ihren Seiten, wie man das in den verschiedenen Betriebssystemen konfigurieren kann.

P.S.: Das Blog und fast alle anderen Seiten auf diesem Server laufen ja schon seit längerem im Dual-Stack Modus und sind somit sowohl über IPv4 als auch IPv6 erreichbar und bisher habe ich keine Probleme damit feststellen können.

UPDATE: Heise hat einen neuen Artikel, in dem auch auf einige Statistiken und Graphen verlinkt wird.

Kategorie: 
 

Wenn man mal was ändert...

Wenn man mal was an der Konfiguration von bestimmten Sachen ändert, dann funktioniert es hinterher nicht mehr. So geschehen nun am Sonntag bei meiner StrongSwan/IPsec-Installation bei meinem Roadwarrior Setup. Aus irgendwelchen Gründen war nämlich der VPN-Verkehr nicht verschlüsselt, was ja den Sinn und Zweck eines VPNs etwas ad absurdum führt.

Also begann ich, an der Konfiguration hier und da was zu ändern - mit dem Resultat, daß nun gar nichts mehr geht. Insofern ist die Sicherheit im VPN auch irgendwie wieder hergestellt. ;-) 

Naja, mal gut, daß ich ein Backup habe. Muss ich mich dieser Tage nochmal mit beschäftigen. Allerdings bin ich bei diesem Thema auch wieder über das Thema PPTP vs. L2TP/IPsec gestolpert. Vermutlich werde ich beides versuchen, umzusetzen. PPTP scheint mir der Standard bei Windows zu sein, während es L2TP/IPsec auf OSX ist. Und vielleicht komme ich auch dann mal dazu, vom Setup mit PSKs auf Zertifikate umzusteigen. Ich hab also in der nächsten Zeit genügend zu basteln... ;-)

UPDATE:
So, nachdem ich das Backup bemüht habe und ein bißchen was beim xl2tpd geändert habe, habe ich nun wieder eine funktionierende und verschlüsselte VPN-Verbindung. :)

Kategorie: 
 

Fritzbox, Fernwartung VPN und eigener DynDNS

Ich hab mir mal wieder ein kleines Problemchen ausgedacht. Gegeben sind zwei Fritzboxen, ein Rootserver und zwei Dialup-Verbindungen. Die Fritzboxen sollen untereinander und jeweils zum Rootserver ein VPN per IPsec aufbauen. Zwischen den beiden Fritzboxen funktioniert das ja per der AVM-eigenen Software ja problemlos mit der Einrichtung. Wenn man nun zu einem Rootserver mit Strongswan eine Verbindung aufbauen will, muss man laut Anleitung im Internet die Config-Dateien etwas anpassen. Soweit scheint es mehr oder weniger Standard zu sein.

Das Lustige kommt nun: gleichzeitig will ich noch von DynDNS.org weg- und hin zu einer Self-Hosted-Lösung kommen. Auch dafür gibt es einige Howtos im Netz und die Fritzbox unterstützt das ja auch. Das Problem ist nun aber die VPN-Verbindung, die per se erstmal einen Hostnamen als FQDN in der Config voraussetzt. Wenn nun aber das Subnetz, in dem der Nameserver steht, per IPsec abgesichert ist, dann wird das Update solange nicht funktionieren bis die IPsec Verbindung aufgebaut ist. Ohne DNS Update aber kann die IPsec Verbindung nicht aufgebaut werden. Also eine Kausalitätsschleife, sozusagen.

Falls also jemand eine Lösung für dieses Problem hat, würde ich mich über Ideen oder Hinweise freuen. :-)

Kategorie: 
 

Mac OSX VPN und DNS Abfragen

Wenn ich unterwegs bin, nutze ich in fremden Netzen natürlich eine VPN-Verbindung zu meinem Server mittels L2TP/IPSEC. Die Verbindung zum VPN-Server funktioniert tadellos. Allerdings habe ich einige Probleme mit dem DNS. Bei bestehender VPN-Verbindung gehen die Anfragen am VPN vorbei und mit der öffentlichen IP des UMTS-Providers zum Beispiel raus. Bei meinem Nameserver werden solche Anfragen abgelehnt (allow-recursion { ournets;} ;).

Hier mal ein bißchen Config im Überblick: 

OSX ifconfig ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
    inet 10.148.224.25 --> 10.64.64.64 netmask 0xff000000
ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
    inet 178.63.123.171 --> 178.63.83.104 netmask 0xffff0000
 
OSX netstat -rn Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            178.63.83.104      UGSc           18       10    ppp1
default            10.64.64.64        UGScI           3        0    ppp0
10                 ppp0               USc             1        0    ppp0
10.64.64.64        10.148.224.25      UH              5       12    ppp0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1     5330     lo0
178.63             ppp1               USc             1        0    ppp1
178.63.83.104      10.64.64.64        UGHS           31     2741    ppp0
 
OSX /etc/resolv.conf nameserver 178.63.83.104
nameserver 192.168.0.1
VPN Server syslog named[27551]: client 89.204.153.153#12738: query (cache) 'heise.de/A/IN' denied

Per UMTS bekomme ich eine RC1918 IP (10.148.224.25 auf ppp0) und per VPN weise ich mir eine öffentliche IP zu (178.63.123.171 auf ppp1). Bei den VPN-Einstellungen in OSX ist konfiguriert, daß der gesamte Verkehr über die VPN-Verbindung gehen soll. Wie man aber am syslog Auszug vom VPN-Server sehen kann, werden die Anfragen zwar an den richtigen Nameserver gestellt, allerdings von der öffentlichen IP des UMTS-Providers aus. Diese steht natürlich nicht in der Nameserver-Konfiguration in ACL für ournets drin, also der berechtigten Hosts, die auch für rekursive Abfragen Anfragen stellen dürfen.

Die Frage ist also, wie man es OSX beibringt, auch DNS Anfragen über den VPN-Tunnel zu routen? Hat da jemand eine Idee oder Lösung? Als ich selber RFC 1918 IPs benutzt und diese genattet habe, hat alles funktioniert. Seit ich die öffentliche IP benutze, funktioniert es nicht mehr. Strange.

Kategorie: 
 

IPv6 Test bei Heise

Am Donnerstag, also vor 2 Tagen, gab es bei Heise.de den IPv6-Tag. Heise hatte bisher schon seinen Inhalt weitestgehend unter six.heise.de per IPv6 zur Verfügung gestellt, aber halt getrennt von der eigentlichen Webseite. Am Donnerstag nun hatte Heise testweise für einen Tag den DNS für heise.de um einen IPv6 Eintrag (AAAA) ergänzt, so daß die Seite sowohl per IPv4 als auch per IPv6 aufgerufen werden konnte. Seit gestern gibt es nun die ersten Ergebnisse.

Das Resümee ist wenig überraschend: der Test verlief erfolgreich. Von rund 1 Mio. Besuchern pro Tag gab es nur eine Handvoll, die die Seite nicht aufrufen konnten. Und selbst bei den wenigen Problemen hatte sich das meist dann als eine Fehlkonfiguration herausgestellt oder konnte anderweitig schnell und problemlos gelöst werden.

Somit bestätigt Heise eigentlich nur meine eigenen Erfahrungen mit IPv6: es funktioniert tadellos und es gibt keinen Grund, einen Umstieg bzw. den Doppelbetrieb von IPv4 und IPv6 weiter hinaus zu zögern. Es wäre also schön, wenn Heise bald komplett auf IPv6 umsteigt und diesem Beispiel möglichst viele große Seiten folgen würden. Aber nicht nur die Seitenbetreiber müssen etwas tun, sondern vor allem auch die Internetprovider müssen anfangen, IPv6 nativ über DSL oder Funk anzubieten. Besonders im Mobilfunknetz macht es Sinn, IPv6 anstatt privater IPv4 Adressen (RFC 1918) einzusetzen.

Kategorie: 
 

Pages

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer