Allgemeine Infos zu IPv6, die grundsätzliche Konfiguration unter Linux und die Einrichtung eines SixXS-Tunnels werden bereits ausgezeichnet im IPv6-Wiki von Ralf Krüdewagen beschrieben, daher werde ich hier nicht nochmals darauf eingehen.

Stattdessen erzähle ich über ein paar Dinge zu DHCP und DNS, die mir erst heute klar geworden sind und zeige, wie die technische Umsetzung funktioniert. Mag sein, dass ich mich hier und da nicht ganz korrekt ausdrücke… Feedback ist willkommen. :-)

Zusammengefasst sind Stand heute folgende Funktionen möglich:

• IPv6-Tunnelnutzung mit SixXS
• Router Advertisement mit radvd
• DHCP-Server für IPv4 / IPv6
• DNS-Server für IPv4 / IPv6
• dynamische DNS-Updates (DDNS) für IPv4 / IPv6

Im Doppelpack

Ich bin bisher davon ausgegangen, dass man entweder “radvd” oder einen IPv6-fähigen DHCP-Server für die dynamische Zuweisung von IP’s verwendet. Richtig ist aber, dass beide Dienste als Team arbeiten. radvd verkündet im Netz lediglich das IPv6-Prefix, also das zu verwendende Subnetz und Angaben zum Router. Clients weisen sich anhand dieser Informationen selbst eine IP-Adresse zu. Wird nur radvd eingesetzt, spricht man von Stateless Address Autoconfiguration. In diesem Szenario können sich Clients bereits im Netz bewegen und mit anderen IP-Adressen/Hosts kommunizieren.

In einem typischen (Heim-)Netzwerk reicht das jedoch nur sehr selten. Das wohl wichtigste Feature ist das Zuweisen eines DNS-Servers. Hinzu kommen Optionen wie z.B. Domain-Name, Such-Suffixe, PXE oder WPAD-Angaben. Genau hier setzt der DHCP-Server auf, der den radvd sinnvoll ergänzt.

Kurz: IP-Adressen kommen vom radvd, Zusatz-Optionen vom DHCP-Server. Man spricht hier von “Stateful Address Configuration”. (siehe auch IPv6-Autokonfiguration bei Wikipedia).

Die technische Umsetzung:

Die radvd-Konfiguration wird auf ein Minimum reduziert. Wichtig ist die Option “AdvManagedFlag on”. Die Angabe eines prefix-Bereichs entfällt.

“/etc/radvd.conf”:

interface eth0
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 10;
}

Ich nutze unter openSUSE 11.4 den ISC DHCP Server (RPM-Paket “dhcp-server”), derzeit in der Version 4.2.1. Dieser Dienst besteht aus zwei Komponenten, “dhcpd” für IPv4 und “dhcpd6″ für IPv6. Ich beschäftige mich in diesem Artikel ausschließlich mit Letzterem. Die DHCP-Konfiguration wird in zwei Dateien vorgenommen:

“/etc/sysconfig/dhcpd” (Auszug):

DHCPD6_INTERFACE="eth0"

“/etc/dhcpd6.conf” (<- auf die “6″ achten!):

authoritative;
ddns-update-style interim;
ddns-updates off;

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.info-refresh-time 21600;

allow leasequery;

log-facility local7;

subnet6 2001:xxxx:yyyy::/64 {

        range6 2001:xxxx:yyyy:: /64;

        option dhcp6.name-servers 2001:xxxx:yyyy::1;
        option dhcp6.domain-search "ipv6.site site";
}

(IP-Adressen wurden anonymisiert)

Wenn nun beide Dienste gestartet wurden und keine Firewall im Weg ist, sollten Clients bereits in der Lage sein, eine IPv6-Adresse inkl. Router- und DNS-Server-Adresse zu beziehen. In Kürze werde ich außerdem beschreiben, wie dynamische DNS-Updates mit IPv6 funktionieren.

1. Ich gehe von einer bereits erfolgten Drupal-Standard-Installation aus (siehe z.B. Quick install for beginners). Die Standard-Website ist demnach unter “http://example.com” erreichbar. Ziel dieser Anleitung ist es, eine weitere Site über die Adresse “http://www.beispiel.de” bereit zu stellen.
2. Im Drupal-Installationverzeichnis existiert ein Ordner namens “sites“. Darin wird für jede zusätzliche Site ein neuer Unterordner erstellt. Wir erstellen also den Ordner “sites/www.beispiel.de“.
3. Im Ordner “sites” existiert u.a. bereits der Ordner “default“. Aus diesem Ordner kopieren wir die Datei “settings.php” in den soeben neu erstellten Ordner “www.beispiel.de“.
4. Nun muss die Datei “settings.php” angepasst werden. Wir verwenden der Einfachheit halber die Datenbank der Drupal-Hauptinstanz mit und müssen daher nur ein separates Tabellen-Prefix eintragen, damit Drupal nicht durcheinander gerät: Im Array “$databases” (ca. Zeile 181) tragen wir ein Prefix ein, z.B.

   $databases = array (
     'default' =>
     array (
       'default' =>
       array (
         'database' => 'drupal',
         'username' => 'drupal',
         'password' => 'secret',
         'host' => 'localhost',
         'port' => '',
         'driver' => 'mysql',
         'prefix' => 'site1_',
       ),
     ),
   );

    

5. Anschließend sorgen wir noch mittels “chmod” und/oder “chown” dafür, dass der Webserver-User im Ordner “sites/www.beispiel.de” schreiben darf.
6. Die Anpassung der Drupal-Dateien ist nun fast abgeschlossen. Nun muss (falls noch nicht geschehen) dafür gesorgt werden, dass der DNS-Name “www.beispiel.de” auf den Webserver zeigt und dass der Webserver über diesen Namen auf die Drupal-Installation zeigt. Diese Basics sind nicht Teil dieser Anleitung. :-)
7. Sind diese Vorbereitungen getroffen, kann man mit einem Webbrowser “http://www.beispiel.de/install.php” aufrufen. Es erscheint dann wie bereits in der Installationanleitung (siehe 1.) gezeigt, der Einrichtungsdialog für die neue Site.
8. Nach der Durchführung ist die neue Site dann über “http://www.beispiel.de” verfügbar.

In Drupal 7 hat man außerdem die Möglichkeit, dieser zusätzlichen Site weitere Aliase zu geben. Verweist man beispielsweise mit den ServerAlias “beispiel.de” (also ohne “www“) ebenfalls auf die Drupal-Installation, kann man dafür sorgen, dass man – statt auf die default-Site – direkt bei der neuen Site (“www.beispiel.de“) landet.

Dazu kopiert man im Ordner “sites” die Datei “example.sites.php” zu “sites.php“, ebenfalls im Ordner “sites“. Für jeden zusätzlich gewünschten Alias fügt man der Datei eine neue Zeile hinzu:

$sites['beispiel.de'] = 'www.beispiel.de';
$sites['test.ganzanderedomain.de'] = 'www.beispiel.de';

Drupal findet diese Datei automatisch, wenn sie existiert und setzt die Konfiguration entsprechend um. Neben diesen explizit gesetzten Einstellungen, versucht Drupal auch automatisch, eine passende Site zur aufgerufenen URL zu finden. Dies ist ein Auszug aus der Datei “sites/example.sites.php“:

For example, for a fictitious site installed at
http://www.drupal.org/mysite/test/, the 'settings.php'
is searched in the following directories:

1. sites/www.drupal.org.mysite.test
2. sites/drupal.org.mysite.test
3. sites/org.mysite.test

4. sites/www.drupal.org.mysite
5. sites/drupal.org.mysite
6. sites/org.mysite

7. sites/www.drupal.org
8. sites/drupal.org
9. sites/org

10. sites/default

Weiterführend gibt’s hier eine Anleitung zum Updaten einer Drupal-MultiSite-Umgebung.

Preface:

Ich betreibe u.a. einen DHCP-Server, einen Proxy-Server und einen Webserver.
Was liegt also näher, als diese drei Dienste miteinander zu koppeln, mit dem Ziel, die Information “Proxy-Server” automatisch zu verteilen, anstatt jedem Browser und jedem System im Netzwerk manuell einen Proxy-Server einzutragen. Außerdem betreibe ich auf verschiedenen Systemen “netz-interne” Webserver, die ich direkt aufrufen möchte, ohne den Proxy zu verwenden.

Hier also die Beschreibung des Zusammenspiels:

Ich arbeite hier mit Diensten unter Linux. Das Ergebnis (die automatische Verteilung der Proxy-Konfiguration) funktioniert für Linux und Windows. Möglicherweise bzw. bestimmt funktioniert das auch für den Mac, aber ich mache hier keine Aussagen zu etwas, das ich nicht selbst getestet habe.

Ziel:

• Verwendung eines Proxy-Servers für alle oder ausgewählte Systeme/Browser
• Subnetz-abhängige Verwendung des Proxy-Servers

Voraussetzungen:

• Linux-System (z.B. openSUSE)
• DHCP-Server (ISC)
• Proxy-Server (z.B. Squid)
• Webserver (z.B. Apache)

Wie diese Voraussetzungen geschaffen werden, ist nicht Teil dieser Anleitung. Ich gehe davon aus, dass diese Dienste eingerichtet sind und funktionieren. Mein Webserver heißt “wpad.mein.privates.netz.de” und der Proxy-Server läuft auf Port 3128 und trägt den Namen “proxy.mein.privates.netz.de”.

Erstellung der WPAD-Datei:

Diese Datei enthält einen “Fahrplan” für den Browser, damit er entscheiden kann, ob und wenn ja, welchen Proxy-Server er verwenden soll. Eine genaue Beschreibung des Aufbaus und der Funktionen einer WPAD-Datei findet sich hier.

Meine sieht folgendermaßen aus:

Das bedeutet: kein Proxy für den eigenen Rechner und kein Proxy für Webserver im eigenen Subnetz.

Diese Datei unter dem Namen “wpad.dat” (case-sensitive) auf dem Webserver abgelegt. Wichtig ist an dieser Stelle, dass die Datei direkt im Web-Root und nicht in einem Unterverzeichnis liegt

Konfiguration des DHCP-Servers:

Ich verteile den Proxy-Verweis für das gesamte Subnet, wer möchte, kann das natürlich auch anders (z.B. pro Host) machen.

Hier die Auszüge aus der /etc/dhcpd.conf:

Ganz besonders wichtig ist das Leerzeichen bei der Pfadangabe “…/wpad.dat ”.

Es existiert unter Umständen das Problem, dass der Internet Explorer beim Verarbeiten des Pfades das letzte Zeichen abschneidet und so die Datei nicht mehr gefunden werden kann. Das Leerzeichen am Ende stellt also einen Workaround dar.

Da nicht alle Browser die DHCP-Optionen abfragen können, ist es sinnvoll, im Nameserver einen Host namens “wpad” anzulegen, dessen Webserver die WPAD-Datei bereitstellt. Somit können “DHCP-unfähige” Browser dennoch eine Proxy-Konfiguration beziehen, denn der Hostname “wpad” wird dabei als Standard verwendet. Leider ist es mit dieser Variante nicht möglich, für Subnetze oder gar einzelne Hosts verschiedene WPAD-Dateien anzubieten. Der gemeinsame Nenner wäre hier das Domain-Suffix des Clients.

Ich habe mittels Wireshark zwei bei mir installierte Browser überprüft:
Der Internet Explorer 7 lässt sich Lease-Informationen vom DHCP-Server geben, um dort die entsprechende WPAD-Option zu erhalten, falls gesetzt. Der Firefox 2.0.0.8 sucht nach einem Gerät mit dem Namen “wpad” im Netz. Dabei werden die auf dem lokalen PC eingetragenen DNS-Suchsuffixe nacheinander abgearbeitet.

Browser-/Systemkonfiguration:

Nun muss dem Browser / dem System nur noch beigebracht werden, dass er die Proxy-Einstellungen automatisch beziehen soll. Im Internet-Explorer wird das über das Aktivieren der Option “Automatische Suche der Einstellungen” bei “Extras -> Internetoptionen… -> Verbindungen -> LAN-Einstellungen” erledigt. Beim aktuellen Firefox geschieht das über “Einstellungen -> Erweitert -> Netzwerk -> Einstellungen (Verbindung) -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen”.

Nachdem DHCP-Server und Browser neu gestartet wurden, kann man nun überprüfen, ob alles wie erwartet funktioniert. Der erste Schritt wäre, eine beliebige URL aufzurufen und im Webserver-Log zu überprüfen, ob die Datei “wpad.dat” erfolgreich vom surfenden Rechner abgerufen wurde. Ist das der Fall, kann man nun anhand des Proxy-Logfiles erkennen, ob der Proxy oder eine direkte Verbindung vom Browser genutzt wird. Dazu werden einfach interne und externe URLs aufgerufen.

Wichtiger Hinweis: Wenn die WPAD-Datei nicht abgerufen werden konnte, arbeiten Mozilla, Firefox und Internet-Explorer stillschweigend mit einer direkten Verbindung.

Nachwort:

Falls jemand diese Anleitung gebrauchen kann/konnte oder einen Fehler gefunden hat, würde ich mich über ein Feedback freuen.

UPDATE:

Bei Problemen mit WPAD und RSS-Feeds könnte eventuell diese Seite helfen.