© suze, Photocase.com

Wenn Sie einen Web- und Mailserver betreiben und damit rechnen, dass User aus Asien Kurs auf Ihren dedizierten Server nehmen, sollten Sie ihn fit für IPv6 machen. Denn primär sind die vier Milliarden Bewohner dieses Kontinents von der IPv4-Adressenknappheit betroffen – und damit IPv6-Anwender der ersten Stunde.

Das lokale Netz der Firma auf IPv6 umzustellen, ergibt in den nächsten Jahren wenig Sinn (siehe vorhergehenden Artikel). Anders bei gemieteten dedizierten Servern oder solchen, die mit einer echten IPv4-Adresse Teil des Internets sind. Wenn Sie Kunden aus Asien haben, die mit nativem IPv6 ins Internet gehen, sollten Sie Ihre per IPv4 angebotenen Services auch für IPv6 fit machen. Das wird in erster Linie Ihr Webangebot betreffen, als Nächstes vielleicht Ihren Mailserver. Dieser Workshop demonstriert Schritt für Schritt ein sinnvolles Vorgehen, denn es gibt einiges zu beachten.

Die ersten Grübel-Rauchwolken steigen nach der Frage auf, wie viele Adressen Sie benötigen und wie groß das IPv6-Netz werden soll. Wenn Ihr Mail- und Webserver lediglich eine IPv4-Adresse hat und Sie ihn zusätzlich mit einer IPv6-Adresse versorgen möchten, reicht durchaus auch eine einzelne Adresse beziehungsweise ein /64-Netzwerk.

Um den Erfolg Ihrer Konfigurationsmühen zu testen, brauchen Sie einen lokalen Rechner, bei dem IPv6 aktiv ist. Wer keinen IPv6-ISP hat, kann die Dienste eines Tunnelbrokers wie zum Beispiel Sixxs.net [1] in Anspruch nehmen (siehe vorhergehenden Artikel). Alternativ bauen Sie einen IPv6-in-IPv4-Tunnel zu dem zu konfigurierenden Server auf, was auch innerhalb einer Open-VPN-Verbindung realisierbar ist. Dafür lassen Sie sich von Ihrem Provider ein entsprechend großes IPv6-Netz bereitstellen, das Sie in kleine /64er-Netze teilen und eines davon auf den Tunnel konfigurieren.

DNS vorbereiten

Bevor Sie anfangen die neuen IPv6-Adressen auf dem Server zu konfigurieren, treffen Sie einige Vorbereitungen. Hierzu gehören valide DNS-Reverse-Einträge für die künftig verwendeten IPv6-Adressen (Abbildung 1). Da Linux-Systeme IPv6 für ausgehende Verbindungen vorziehen, sobald eine IPv6-Adresse lokal konfiguriert ist, sollte die Vorwärts- sowie Rückwärtsauflösung konsequent gleichlautende Ergebnisse produzieren. Empfehlenswert ist es allerdings, dass Sie anfangs mit einem testfreundlichen separaten DNS-Namen operieren, beispielsweise »ipv6.Domainname.de« .

Abbildung 1: Gleich zu Beginn legen Sie für die IPv6-Adressen entsprechende DNS-Reverse-Einträge an – hier zu sehen am Beispiel des Webhosters Strato, bei dem Kunden den DNS-Eintrag selber vornehmen oder auch die Zone auf eigene Nameserver delegieren dürfen.

Konsistente DNS-Einträge sind zum Beispiel zwingend, wenn sie Mail per SMTP an einen anderen IPv6-Gegenpunkt schicken, der zur Spamabwehr die Konsistenz des DNS-Eintrags des übermittelnden Servers überprüft. Viele Mailserver sind so konfiguriert, dass sie die Mails bei nicht vorhandenem oder inkonsistentem DNS-Eintrag abweisen.

Knackpunkt Firewall

Sobald Sie Ihrem Server eine IPv6-Adresse zuweisen, steht dieser ohne weiteren Schutz mitten im Internet. Das liegt daran, dass die Linux-Firewall in den meisten Fällen nicht für IPv6 vorkonfiguriert ist und der Kernel per se alle Verbindungen akzeptiert. Mit

netstat -anp | grep ":::" | grep LISTEN

sehen Sie, welche gerade laufenden Applikationen auf eingehende IPv4- sowie auch automatisch auf IPv6-Verbindungen reagieren würden. Das erkennen Sie an den drei Doppelpunkten »:::« in der IP-Adresse gefolgt vom Namen des entsprechenden Programms.

Jetzt steht viel Fleißarbeit an, denn alle Firewallregeln, die Sie in IPv4 angelegt haben, müssen Sie noch einmal für IPv6 nacharbeiten. Andernfalls riskieren Sie, dass interne Dienste über IPv6 aus dem Internet erreichbar sind. Schenken Sie auch Ihrer Linux-Version etwas Beachtung: Gerade bei Kernels älterer Enterprise-Distributionen beherrscht IP6tables Dinge wie Connection-Tracking nicht. Hier hilft nur ein Kernel- oder Distributions-Upgrade.

Beachten Sie beim Schreiben der Regeln, dass die ICMPv6-Kommunikation auf den vom System selbstständig generierten lokalen IPv6-Adressen (fe80::/10) erlaubt bleibt, damit die Neighbor Solicitation beziehungsweise das Neighbor Advertisement (eine Art IPv6-ARP) sauber funktionieren. Ohne ICMPv6 kommt kein IPv6-Datenverkehr zustande. Erfolgt die Konfiguration des Defaultgateway für IPv6 über so genannte Router Advertisements, achten Sie zudem darauf, dass diese von der lokalen Adresse des Routers (fe80::/10) aus an eine IPv6-Multicast-Adresse (ff02::1) gesendet werden.

Abgesehen von den genannten Netzen hat es sich bewährt, erst einmal alle eingehenden Verbindungen vollständig abzuweisen. Wenn Sie dann getestet haben, dass die entsprechende Konfiguration der Applikation in Ordnung ist, öffnen Sie in der Firewall die ermittelten Ports Zug um Zug. Insbesondere sollten Sie vor den abweisenden Regeln außerdem eine »ACCEPT« -Regel setzen, die von der Source-Adresse Ihres Testrechners aus eingehende Verbindungen als gutartig klassifiziert. Andernfalls können Sie nämlich von dort aus die IPv6-Funktionen des Servers nicht testen.

IPv6-Adresse konfigurieren

Steht die Firewall, konfigurieren Sie die IPv6-Adressen des Linux-Servers. Sich die IPv6-Adresse vom Provider per DHCPv6 zuteilen zu lassen, wäre zwar technisch machbar, ist jedoch nicht sonderlich verbreitet. Vermutlich müssen Sie die Adresse selber manuell konfigurieren. Daraus ergibt sich aber auch der Vorteil, dass die Wahl der Adresse einer bewussten Entscheidung folgt. Die Konfiguration der Adresse erledigen Sie wie gewohnt über ein (vielleicht grafisches) Setup-Tool der Distribution oder die Konfigdateien in »/etc« .

Häufiger Stolperstein ist das IPv6-Defaultgateway. Viele Netze arbeiten mit den Router Advertisements, die das Defaultgateway automatisch zuweisen. Andere Anbieter verlangen, das Gateway manuell zu konfigurieren. Dies ist vor allem in Netzsegmenten vorzuziehen, in denen der Netzbetreiber nicht sicherstellt, dass die Server ohne Probleme weiterarbeiten, sobald sie ein entsprechendes Gateway in der Routingtabelle haben.

Von Ihrem mit einer IPv6-Adresse ausgerüsteten Server aus versuchen Sie nun zu pingen. Empfehlenswert ist »ping6 Defaultgateway« , die Adresse kriegen Sie gegebenenfalls über »ip -6 route show« heraus (Abbildung 2). Dann probieren Sie eine externe IP, zum Beispiel »ipv6.google.com« . Klappt mindestens ein Ping nicht, überprüfen Sie das Serversetup einschließlich der Konfiguration des Defaultgateway sowie die Firewall.

Abbildung 2: Die Kommandos »ip -6 addr show« und »ip -6 route show« lesen die IPv6-Konfiguration aus. Wenn Sie eine lokale Adresse aus dem Bereich fe80::/64 anpingen möchten, müssen Sie zusätzlich das entsprechende Interface angegeben, da das Netz auf allen Interfaces anliegt.

Gelingt es nicht, die Probleme kurzfristig zu lösen, dekonfigurieren Sie besser die IPv6-Adresse vorläufig wieder. Das Linux-System präferiert nämlich IPv6 ab dem Moment, wenn es eine IPv6-Adresse und ein Gateway hat. Wenn der Stack nicht ordentlich funktioniert, müssen die Programme erst in einen Timeout laufen, bevor sie einen Fallback auf IPv4 versuchen – dies kann Produktivsysteme an den Rand der Benutzbarkeit führen.

Beim europäischen IP-Koordinationszentrum RIPE [2] finden Sie übrigens eine Testseite, mit der Sie die Dualstack-Konnektivität testen können (Abbildung 3). Sie zeigt gut aufbereitet und in Echtzeit an, ob eine Reihe von Dualstack-Testservern erreichbar ist. Funktioniert alles, können Sie sich nun auf die eigentlichen Applikationen konzentrieren.

Abbildung 3: Über den Dual Stack Connectivity Chart des RIPE NCC können Sie erfahren, ob Ihre IP-Konfiguration in Ordnung ist und welche großen Server Sie erreichen können.

Die erste Verbindung

Ab sofort sind die freigeschalteten Dienste Ihres Servers von außen per IPv6 erreichbar. Als erste Applikation – wenn die Firewall nichts dagegen unternimmt – vielleicht der meist korrekt vorkonfigurierte SSH-Daemon. Wenn Ihr Administrations-PC – wie eingangs beschrieben – über einen nativen IPv6-Zugang verfügt oder Sie einen Tunnelbroker in die Pflicht nehmen, kann’s sofort losgehen.

Wenn Sie einen eigenen Tunnel betreiben, müssen auf Ihrem Server das IPv6-Forwarding und die Firewall entsprechend eingestellt sein. Auf dem Client-PC setzen Sie die IPv6-Defaultroute auf die IPv6-Adresse des Server-Tunnelinterface.

Apache mit Dualstack

Weiter geht’s mit dem Webserver: Sofern Sie bislang die Apache-Standardkonfigurationen ohne virtuelle Hosts verwenden, sind in der Regel keine weiteren Einstellungen notwendig. Anders jedoch, wenn Sie mit virtuellen Hosts arbeiten. Dann wenden Sie sich der Direktive »NameVirtualHost« zu, die mehrere virtuelle Hosts an eine IP-Adresse bindet. Die Direktive eignet sich für IPv4 und IPv6 gleichermaßen:

# Standard bei IPv4
NameVirtualHost 85.214.7.192
# Bei einer IPv6-Adresse
NameVirtualHost [2a01:238:10b:3000::1]
# Für alle verwendbaren Adressen
# einschl. IPv4 und IPv6
NameVirtualHost *

Das Klammern ist für die IPv6-Adressen zentral, da »NameVirtualHost« die Trennung von IP-Adresse und Portnummer anhand eines Doppelpunkts erwartet, die IPv6-Adressen aber ebenfalls Doppelpunkte aufweisen.

Je nachdem, wie bei Ihrem Apache die virtuellen Hosts konfiguriert sind, müssen Sie eventuell die »VirtualHost« -Sektionen duplizieren. Der Grundsatz lautet: Wenn bei der »VirtualHost« -Direktive ein Domainname angegeben ist, reicht dies bereits aus, um den Virtual Host über IPv4 sowie IPv6 zu erreichen [3].

Sind dagegen IP-Adressen konfiguriert, müssen Sie für jede eine eigene Sektion anlegen. Am besten kopieren Sie die bestehende Konfiguration für IPv4 und ersetzen im Duplikat die IPv4- durch die IPv6-Adresse (Listing 1). Sobald Sie mehrere virtuelle Hosts auf die gleiche IP-Adresse legen, ist der entsprechende »NameVirtualHost« -Eintrag obligatorisch. Wenn Sie sowieso mit mehreren »VirtualHost« -Einträgen hantieren, bietet es sich an, unterschiedliche Error-Logfiles schreiben zu lassen, IPv6-bedingte Fehler sind so schneller zu finden.

01 <VirtualHost 85.214.7.192:80>
02 ServerName domain1.de
03 ServerAlias www.domain1.de
04 [...]
05 </VirtualHost>
06 <VirtualHost [2a01:238:10b:3000::1]:80>
07 ServerName domain1.de
08 ServerAlias www.domain1.de
09 [...]
10 </VirtualHost>

Virtuelle Domains

Wenn Ihnen die IPv6-Zuweisung zumindest ein /64er-IPv6-Netz hat zuteil werden lassen, können Sie auch jedem Virtual Host eine eigene IPv6-Adresse geben. Die virtuellen Webserver brauchen sich danach keine einzelne IPv6-Adresse mehr zu teilen und der entsprechende »NameVirtualHost« -Eintrag wird ebenfalls überflüssig.

Das eröffnet zudem für jeden virtuellen Host den Weg zu einem eigenen SSL-Zertifikat. Ein praktischer Wert stellt sich allerdings nur ein, wenn Sie das Gleiche für IPv4 realisieren, da ja die erdrückende Mehrheit der User mit IPv4-Clients surft. Wer so genannte Multidomain- oder Wildcard-Zertifikate verwendet, ist sowieso aus dem Schneider. Er ordnet dem »VirtualHost« stets den gleichen SSL-Schlüssel und das gleiche SSL-Zertifikat zu.

Den Webserver testen

Sie nähern sich dem Ende der Einrichtungsarbeiten: Konfigurieren Sie nun den vorher angelegten DNS-Namen »ipv6.Domainname.de« als »VirtualHost« . Der »DocumentRoot« sollte auf ein Verzeichnis zeigen, in dem bereits ein Contentmanagement-System oder statische Webinhalte installiert sind. Auf diese Weise testen Sie Ihre Webapplikation en passant auf deren IPv6-Fähgkeit.

Um die IPv6-Funktion des Webservers zu prüfen, rufen Sie einfach im Browser des Clients »http://ipv6.Domainname.de« auf. Jetzt sollten Sie den Webinhalt sehen, den Sie im »DocumentRoot« hinterlegt haben. Da im DNS für »ipv6.Domainname.de« nur die IPv6-Adresse vorliegt, kann die TCP/IP-Verbindung wirklich nur eine mit IPv6 sein.

Wer mit Heartbeat oder auf andere Weise ein Failover-Setup betreibt, sollte auf einen IPv6-spezifischen Umstand achten: Erfahrungen zeigen, dass im Linux-System eine ganz kurze Zeit vergeht, bis sich ein Apache-Server auf eine zuvor konfigurierte IPv6-Adresse binden kann. Gegebenenfalls bauen Sie in den Heartbeat-Skripten ein kurzes Delay ein. Bereits wenige Sekunden reichen als Verzögerung aus, damit der Apache sich problemlos auf die IPv6-Adresse binden kann.

Der ab sofort korrekt laufenden Dualstack-Apache wird Ihnen wahrscheinlich wenig Probleme bereiten. Webstatistiken, wie beispielsweise Webalizer sie zusammenträgt (Abbildung 4), stören sich in der Regel nicht an IPv6-Adressen.

Abbildung 4: Apache-Logfile-Tools wie Webalizer haben in der Regel keine Probleme mit dem Interpretieren von IPv6-Verbindungen und arbeiten im Dualstack-Betrieb klaglos weiter.

Der Mailserver im Dualstack-Betrieb

Vermutlich wollen Sie auch Ihren Mailserver bereit machen fürs neue Internet. Hier warten die üblichen Probleme in der Darstellung der IPv6-Adressen in den Konfigurationsdateien auf Sie. Der hier als Beispiel dienende Exim trennt IP-Adressen in seiner Konfiguration mit einem Doppelpunkt. Darum müssen Sie ein anderes Trennungszeichen definieren – und zwar hinter der Option mit einer spitzen Klammer. Es folgt das neue Trennungszeichen. Beispiel:

hostlist relay_from_hosts = <; 85.214.7.0/24; 2a01:238:10b::/56

Sofern Sie mehrere IPv6-Adressen gleichzeitig auf einem System konfigurieren, sollten Sie bestimmen, welcher Dienst welche IPv6-Adresse verwendet. Bei Exim dürfen Sie im entsprechenden SMTP-Transport definieren, mit welcher konfigurierten IPv6-Adresse der Mailserver ausgehende Verbindungen aufbaut. Auch hier hantieren Sie wegen der IPv6-Adressen mit einem anderen Trennzeichen:

driver = smtp
interface = <; 85.214.7.192;2a01:238:10b:3310::11

Ohne das Trennzeichen wählt der Kernel die IPv6-Adresse für ausgehende Verbindungen, meist die zuletzt konfigurierte IP. Eine feste Konfiguration ist darum vorzuziehen, sobald Sie einzelnen Diensten extra IP-Adressen zuweisen oder die Kommunikation nach außen mit einer festgelegten IP-Adresse erfolgen soll.

ACLs, Graylisting, Proxys

Eine häufige Fußangel legen ACLs aus, die reglementieren, welche IP-Netze ohne Authentifizierung Mails annehmen (Relaying) oder Mails abweisen. In den Einstellungen für das Relaying sollten Sie als Erstes das eigene IPv6-Netz eintragen, damit Mails durchkommen, wenn sie das System über IPv6 erreichen.

Wer Graylisting mit einem MySQL-Backend in seiner Mailkonfiguration realisiert, sollte darauf achten, dass die Felder für die IP-Adresse lang genug sind (39 Bytes). Auch hier sollten Sie alles testen, was mit IPv6 zu tun hat. Hierzu richten Sie die IPv6-Adresse beziehungsweise den IPv6-Test-Hostnamen vorübergehend als Mailserver im Mailclient ein. Wenn es nicht auf Anhieb funktioniert, prüfen Sie neben der Mailserver-Konfiguration auch den Client.

Es gibt eine Vielzahl Proxydaemons, die nicht IPv6-kompatibel sind, zum Beispiel für Virenerkennung oder PGP-Verschlüsseln. Oft hilft es, die Proxydienste testweise zu deaktivieren. Als permanente Lösung bietet sich eine feste IPv4-Adresse im Mailclient an. Alternativ funktionieren auch Ausweich-Domainnamen wie zum Beispiel »ipv4.mail.Domainname.de« .

Die Hochzeit

Nach den abgeschlossenen Tests gilt es nun, die Host- und Domainnamen parallel auf IPv4 und IPv6 umzustellen. Hierzu tragen Sie in den entsprechenden DNS-Einstellungen geeignete »AAAA« -Records für IPv6 im DNS ein. Wählen Sie für den DNS-Eintrag eine sehr geringe TTL, sofern Ihnen das möglich ist. Das hilft in Notfällen die IPv6-Adresse schnell wieder abzuklemmen, ohne dass das DNS-Caching den letzten Zustand lange konserviert.

Nachdem Sie die DNS-Einstellungen um die IPv6-Einträge erweitert haben, sollten Sie die umgestellten Namen testen. Zuvor starten Sie aber den Apache-Dienst neu, speziell wenn Sie DNS-basierte virtuelle Hosts verwenden. Wenn alles in Ordnung ist, ändern Sie abschließend den DNS-Reverse-Eintrag auf den korrekten Namen und entfernen die Testdomain »ipv6.Domainname.de« wieder.

IPv4 erzwingen, wo es notwendig ist

Manchmal ist es erforderlich, den Client dazu zu zwingen, weiterhin nur mit IPv4 auf einen Service zuzugreifen. Dies trifft meist dann zu, wenn eine Applikation nicht passend für IPv6 konfiguriert beziehungsweise nicht kompatibel ist. Dazu tragen Sie zum Beispiel lediglich in der Firewall folgende Regel ein:

ip6tables -A INPUT -j REJECT -p tcp-dport 25 --reject-with tcp-reset

Sie quittiert IPv6-Verbindungen auf den SMTP-Port 25 mit einem TCP-Reset, was ein Failback auf IPv4 forciert, wenn der Domainname als IPv4- und als IPv6-Adresse definiert ist. Wäre nur ein Drop oder ein einfaches Reject in der Firewall konfiguriert, könnte die Clientapplikation Schwierigkeiten bekommen und der Server verzögert antworten. (jk)