IPv6-Testbetrieb für heise online [2. Update]
IPv6 ergänzt auf der Transport-Ebene IPv4, da sollte es kein Problem sein, eine bestehende Web-Site auch per IPv6 anzubieten: Einfach den Server auf eine IPv6-Adresse konfigurieren und fertig. Doch damit fängt die Admin-Arbeit erst an ...
- Johannes Endres
Update
Seit dem 11. Mai 2009 setzen wir die weiter unten beschriebene Technik zum Anpassen der URLs ein. Damit sind die Darstellungsfehler behoben und auch die Atom-Feeds enthalten die jeweils korrekten Links.
2. Update
Am 16. September 2010 schalten wir versuchsweise IPv6 parallel zu IPv4 für www.heise.de ein. Die technischen Details finden Sie auf der Seite "Der IPv6-Tag ".
IPv6 ist schon seit vielen Jahren das Netzwerk der Zukunft und kommt doch nicht so recht in Gang. Dabei funktioniert der Internetzugang eigentlich schon ohne größere Probleme. Denn die verbreiteten Betriebssysteme unterstützen das Protokoll längst. Und beginnend mit Windows Vista stellt Microsoft das lokale Netzwerk schrittweise auf IPv6 um.
Firmenkunden können sich zwar bei Hardware-Herstellern und Providern mit IPv6-tauglichen Gerätschaften und Diensten versorgen. Doch für Heimanwender und kleiner Büros entwickelt sich erst langsam ein Angebot. Auch bei den Internet-Seiten und anderen Diensten sieht es im IPv6 noch recht einsam aus.
heise online
Anfang März startete der Testbetrieb für heise online über IPv6. Unter der Adresse http://www.six.heise.de sind die meisten Inhalte von www.heise.de auch per IPv6 erreichbar.
Zunächst läuft das IPv6-Angebot im Probebetrieb, um Erfahrungen zu sammeln. Das ist auch einer der beiden Gründe, unterschiedliche Hostnamen für die IPv4- und IPv6-Server zu verwenden. Würden beide Angebote unter demselben Namen laufen, könnte der Internet-Surfer nicht leicht entscheiden, über welche Verbindung er zugreifen möchte. Je nach Kombination aus Browser(version), Betriebssystem und Einstellungen würde der URL http://www.heise.de mal per IPv6 und mal per IPv4 aufgerufen. Da die Inhalte noch nicht identisch sind, wollen wir diese Entscheidung jedoch lieber Ihnen überlassen.
Der zweite Grund ist, dass in manchen der Kombinationen nur eine Fehlermeldung erscheinen würde. Denn die meisten IPv6-tauglichen Betriebssysteme richten automatisch ein IPv6-Interface ein. Das bedeutet aber keineswegs, dass über den nächsten Router hinaus eine Verbindung bis zum Server möglich ist. Wenn der Browser es dann bevorzugt per IPv6 versucht, fragt er zunächst die IPv6-Adresse zum Namen ab (AAAA-Record). Diese DNS-Auflösung funktioniert auch über IPv4 und würde eine gültige IPv6-Adresse zurückliefern. Der Verbindungsaufbau zu dieser Adresse schlägt dann aber fehl und der User erhält die Meldung "www.heise.de nicht erreichbar". Das stimmt zwar nicht, weil die Verbindung per IPv4 durchaus möglich wäre. Doch weil der User vielleicht noch nie von IPv6 gehört hat, und auch an der Fehlermeldung nicht erkennen kann, was genau schief gelaufen ist, bleibt ihm www.heise.de verborgen.
Aus diesen beiden Gründen benutzt beispielsweise auch Google einen anderen Namen für den IPv6-Zugang zu seinem Index des IPv4, nämlich ipv6.google.com.
Per Proxy
Per Proxy
Die Seiten von www.heise.de liefert nicht ein einziger Server aus, sondern ein Cluster vielen Maschinen. Die Verbindung zum Internet stellt ein Loadbalancer her, der die Anfragen der Surfer verteilt und die Antworten zurückliefert.
Diese ganze Infrastruktur auf IPv6 umzustellen, wird ein erheblicher finanzieller und Arbeits-Aufwand. Um schon vorher Erfahrungen zu sammeln, haben wir uns für den Probebetrieb für eine einfachere Lösung entschieden: www.six.heise.de ist ein Reverse-Proxy, der seinerseits per IPv4 über den Loadbalancer auf www.heise.de zugreift.
Apache-Konfiguration
Als Proxy-Server kommt Apache mit dem Modulmod_proxy zum Einsatz.
Zunächst aktivieren wenige zusätzliche Zeilen in der VirtualHost-Definition auf www.six.heise.de den Proxy:
ServerName www.six.heise.de
ProxyPass / http://www.heise.de/
ProxyPassReverse / http://www.heise.de/
Über ServerName muss der Server wie üblich seinen Namen erfahren. ProxyPass legt fest, an welchen externen Server die Anfragen durchgereicht werden sollen. Die hier gezeigte Zeile bedeutet, dass relativ zum Root von www.six.heise.de alle URLs ungeändert bei www.heise.de abgefragt werden sollen.
mod_proxy kann den gesamten Inhalt eines Servers in einem Verzeichnis eines anderen einbinden. Dazu teilt man ihm in der ProxyPass-Direktive das Verezeichnis auf dem Proxy (zum Beispiel /mirror/example/) und den dort einzublendenden URL (zum Beispiel http://www.example.com/) mit:
ProxyPass /mirror/example/ http://www.example.com/
Bei www.six.heise.de liegt der Fall etwas einfacher, weil dort ja alle Seiten von www.heise.de unter denselben Pfaden erscheinen sollen. Daher genügt als Pfadangabe der einfache Schrägstrich.
Der Proxy reicht mit den HTML-Seiten auch die meisten HTTP-Header an den Client durch, die er vom Server bekommt. Doch in den Headern Location, Content-Location und URI steht eventuell www.heise.de statt www.six.heise.de. Die Korrektur leistet für die Header die ProxyPassReverse-Zeile: Sie ersetzt http://www.heise.de durch den eingestellten ServerName und den Pfad /.
Die Dokumentation zu mod_proxy empfiehlt, bei einem Reverse-Proxy zusätzlich ProxyRequests Off zu setzen. Damit wird verhindert, dass der Server wie ein üblicher Proxy funktioniert, der vom Client auch Anfragen für ganz andere Server annimmt und deren Seiten durchreicht. Doch diese Funktion ist ohnehin per Default ausgeschaltet.
URL-Umschreibung
URL-Umschreibung
Doch wegen der unterschiedlichen Host-Namen ist es damit allein noch nicht getan. Denn in den Seiten von www.heise.de stecken viele absolute URLs, die mit <a href="http://www.heise.debeginnen.Würde www.six.heise.de diese einfach durchreichen, würde der erste Klick auf einen solchen Link den IPv6-Surfer wieder auf den IPv4-Server werfen.
Grundlegend können wir das lösen, indem wir unserem CMS beibringen, je nach Transport-Technik verschiedene Hostnamen in die Links einzubauen. Doch die Voraussetzung dafür ist, dass das CMS überhaupt mitbekommt, mit welcher IP-Version die Anfrage hereinkommt. Neben Programmierung am eigentlichen CMS wären dafür auch massive Eingriffe in den Cluster nötig.
Alternativ könnten wir auch www.heise.de komplett auf relative URLs umstellen. Neben Umbauten am CMS würde das auch bedeuten, die an verschiedenen Stellen noch vorhandenen statischen HTML-Seiten zu bearbeiten.
Daher gehen wir für den Probebetrieb einen anderen Weg: Der Proxy durchforstet die HTML-Seiten und ersetzt alle absoluten Links auf www.heise.de durch solche auf www.six.heise.de.
Erster Versuch: mod_proxy_html
RequestHeader unset Accept-Encoding
Für das Umschreiben der Links setzten wir zunächst das Modul mod_proxy_html, das nicht aus dem Apache-Projekt stammt. Es bearbeitet den Datenstrom genauso, wie er von www.heise.de abgerufen wird. Daher müssen die HTML-Seite als Text übertragen werden und nicht etwa komprimiert. Da der Client aber eventuell per Accept-Encoding-Header die Kompression vorschlägt, entfernt der Proxy diesen Header mit Hilfe des Moduls headers_module:
Für die Link-Änderung genügen dann zwei Direktiven:
SetOutputFilter proxy-html
ProxyHTMLURLMap http://www.heise.de/ /
SetOutputFilter veranlasst Apache, die Daten überhaupt durch mod_proxy_html zu schicken. Schließlich ersetzt die ProxyHTMLURLMap-Zeile jedes Auftreten von http://www.heise.de in einer URL durch /, macht also aus allen absoluten URLs auf dem Server relative, die damit automatisch auf www.six.heise.de verweisen.
Es stellte sich jedoch heraus, dass mod_proxy_html für heise online nicht geeignet ist. Denn es versucht die HTML-Seiten komplett zu analysieren, was zu zwei Problemen führt. Zunächst sind die RSS-Feeds kein HTML, sondern XML, sodass mod_proxy_html sie nicht bearbeiten kann. Deshalb verwiesen auch die per IPv6 abgerufenen Feeds weiterhin auf die IPv4-Seiten.
Und zweitens verschluckt sich mod_proxy_html gelegentlich an komplexeren Konstruktionen, wie komplizierten Javascripten, die HTML ausgeben oder einigen CSS-Konstruktionen. Das führt dann zum Beispiel dazu, dass das Modul doppelte Anführungszeichen, die innerhalb des Scripts einen String einschließen, durch die HTML-Version " ersetzt.
if(plug)
{
document.write("
");function loadFlashMiddle21(){
...
Damit ist das Script kaputt und der Browser kann die Seite nicht richtig darstellen, wie das Bild rechts zeigt.
Viel besser: mod_substitute
Als Lösung stellte sich das Apache-Standard-Modul mod_substitute heraus. Es ersetzt Strings in den ausgelieferten Daten, ohne das HTML zu analysieren. Das Modul definiert die Direktive Substitute, die als Paramter einen Ersetzungsbefehl ähnlich dem des Unix-Editors sed erwartet: Ein s gefolgt von einem Trennzeichen, dem alten Text (bei Bedarf als Regular Expression), wieder dem Trennzeichen, dem neuen Text und einem abschließenden Trennzeichen:
Substitute s/alt/neu/
Darauf können noch verschiedene Optionen folgen, die genauer bestimmen, wie ersetzt wird. Für heise online setzen wir davon drei: i sorgt dafür, dass der Servername auch mit Großbuchstaben gefunden wird. Mit n werden Regular Expressions deaktiviert, was den Vergleich beschleunigt und q verhindert, dass der veränderte Text erneut durchsucht wird. Das wäre nur bei komplexeren Ersetzungen sinnvoll, deren Ergebnis wieder den Suchstring enthalten kann. Da das beim Servernamen nicht passiert, spart auch q etwas Zeit. Da der zu ersetzende String http://www.heise.de/ Schrägstriche enthält, benutzt man als Trenner besser ein anderes Zeichen.
mod_substitute ersetzt den Suchtext gnadenlos überall, wo er auftaucht. Daher sollte man ihm nur die Seiten verfüttern, in denen wirklich etwas ersetzt werden soll. Für heise online sind dies die HTML- und XML-Seiten sowie die Atom-Feeds, jeweils ausgewiesen durch ihren Content-Type. Insgesamt sieht der Abschnitt der Konfiguration, der die URLs umschreibt, daher so aus:
AddOutputFilterByType SUBSTITUTE text/html
AddOutputFilterByType SUBSTITUTE text/xml
AddOutputFilterByType SUBSTITUTE application/atom+xml
Substitute s;http://www.heise.de/;http://www.six.heise.de/;inq
Allerdings hat mod_substitute auch einen Nachteil: Es ersetzt eben wirklich alle Vorkommen von http://www.heise.de/ durch http://www.six.heise.de/. Je nach Zugangstechnik sehen Sie daher hier unterschiedliche Texte: http://www.heise.de/. Wie man an diesem Artikel erkennt, ist es durchaus möglich, den URL vor der Umwandlung zu schützen. Doch wenn der Schreiber das nicht tut, verändert mod_substitute ungewollt den Text. Das dürfte überall dort zu Verwirrung führen, wo wirklich zwischen dem IPv4- und dem IPv6-Server unterschieden wird, zum Beispiel in den Foren oder bei den Fehlermeldungen zum IPv6-Service.
Für Ihre Rückmeldungen und Anregungen haben wir eigene Seiten mit einem Wiki und einem Ticket-System eingerichtet. Per Mail erreichen Sie das IPv6-Team unter six@heise.de.
Der IPv6-Tag am 16. September
Der IPv6-Tag am 16. September
Am IPv6-Tag sollen unsere Seiten auch unter dem Namen www.heise.de per IPv6 ausgeliefert werden. Derzeit liegt der IPv6-Verkehr unter 1 % der Zugriffe. Weil noch kein großer Provider einen Zugang anbietet, wird das wohl auch einige Zeit so bleiben. Daher lohnt es sich noch nicht, die gesamte Server-Landschaft inklusive Loadbalancer und Datenbanken IPv6-tauglich zu machen. Vielmehr soll der schon als www.six.heise.de erreichbare Proxy auch den IPv6-Verkehr für www.heise.de abwickeln. Das ist sogar etwas einfacher als bei www.six.heise.de, weil der Proxy sich die URL-Umschreibung sparen kann.
Zunächst bekommt der Proxy eine zusätzliche IPv6-Adresse (2a02:2e0:3fe:100::7), damit in der Apache-Konfiguration daran ein zusätzlicher Virtual Host hängen kann. Zur Vereinfachung verbindet ein Eintrag in /etc/hosts dies Adresse mit dem Namen wwwself-if.heise.de, der nur für die Apache-Konfiguration benutzt wird. Dort sieht der Eintrag ganz ähnlich aus, wie bei www.six.heise.de:
<VirtualHost wwwself-if.heise.de:80>
ServerName www.heise.de
ServerAdmin webadmin@heise.de
# Directory / greift nicht bei Proxy
<Location />
Order allow,deny
allow from all
</Location>
# Dies ist der spannde Teil, die Proxy-Konfiguration
ProxyPass / http://www.heise.de/
ProxyPassReverse / http://www.heise.de/
ProxyRequests Off
# mod_proxy_html kann selbst mit gzip nichts anfangen
# deshalb muss das Ent- und Packen explizit hier stehen
SetOutputFilter INFLATE;DEFLATE
</VirtualHost>
HTTPS
Fast genauso sieht der Eintrag für den Port 443 aus, auf dem der per HTTPS erreichbar ist. Damit das funktioniert, haben wir das SSL-Zertifikat für www.heise.de auf den Proxy kopiert. Denn der muss in die HTTP-Anforderungen hineinschauen und deshalb die Pakete entschlüsseln. Anschließend verpackt er sie wieder, um per IPv4 und HTTPS die geforderten Seiten zu holen und sie mit demselben Zwischenschritt weiterzuleiten. Der Proxy steht in demselben Rechenzentrum wie die IPv4-Server und ist auch sonst genauso gut gesichert. Das zwischenzeitliche Entpacken der Daten stellt also keine Sicherheitslücke dar.
DNS-Eintrag
Dann fehlt nur noch der DNS-Eintrag mit dem AAAA-Record. Den machen wir am 16.9. und löschen ihn am Abend wieder. Unser DNS läuft ohnehin mit einer sehr kurzen Lebensdauer der Antworten (TTL, Time to live). Daher sollte der AAAA-Record nach dem Abschalten bei uns auch recht schnell wieder aus den DNS-Caches verschwinden. Wer etwas Ähnliches vorhat und mit längerer TTL arbeitet, sollte sie schon im Vorfeld herunterfahren, damit die DNS-Umschaltung schnell funktioniert.
Mit dem DNS-Eintrag könnten wir uns auf fantastische Weise in den Fuß schießen: Falls der Proxy den Namen www.heise.de per DNS auflöst, bekommt er seine eigene Adresse und leitet die Anfragen also an sich selbst weiter – und der Leser bekommt nie etwas zu sehen. Daher muss die IPv4-Adresse (und nur diese) von www.heise.de in der hosts-Datei stehen. Und in /etc/host.conf muss die Zeile order hosts,bind sicherstellen, dass der Proxy wirklich den hosts-Eintrag dem DNS vorzieht.
()
