… Ich verwende feste IPv6-Adressen für Host und Gäste, das Routing läuft über den Host (Also nicht die virtuellen MAC-Adressen, die es inzwischen gibt). Für den Host gilt: eth0=OVH-Netz,br0=Netz mit den Gästen. Ich schreibe nur die nötigen Befehle – da die Config je nach Linux-Distri verschieden sind überlasse ich euch das übersetzen selbst (bei mir tuts aus Faulheit die rc.local). Wie man IPv6-Abkürzt (führende 0en weglassen, kürzen per ::) erklärt bei Bedarf google.

Host:
Als erstes benötigt der Host natürlich eine feste Adresse. Hierzu geht ihr in den OVH-Manager und sucht euer IPv6-Subnet (Steht bei Interfaces in der Server-Übersicht). Ich gehe hier von 2001:41D0:F0F0:F0F0::/64 aus. Das bedeutet, dass euch die IPs 2001:41D0:F0F0:F0F0:0000:0000:0000:0001 bis 2001:41D0:F0F0:F0F0:FFFF:FFFF:FFFF:FFFE gehören – genug Platz. Der Einfachheit halber nummeriere ich nur die letzte Zahl durch – ist aber natürlich keine Pflicht.

Als erstes erhält der Host auf beiden(!) Interfaces eine IP:

ifconfig eth0 inet6 add 2001:41D0:F0F0:F0F0::1/64
ifconfig br0 inet6 add 2001:41D0:F0F0:F0F0::99/64

Zudem benötigen wir ein Routing. Teilweise erhält der Server bereits über die IPv6-Autokonfiguration die korrekten Routen von OVH. Dummerweise unterstützen einige Switche bei OVH kein IPv6 und blockieren diese Autokonfiguration, daher funktioniert es nicht bei jeden. Da es nichts schadet die Route fest einzutragen werden wir das tun. Die Router-IP ermittelt sich wie folgt:

OVH-Hilfe
Der Router (Standardgateway) für jede IPv6 befindet sich immer auf IP:v:6:FF:FF:FF:FF:FF

Ein Beispiel:

Die IPv6 des Servers: 2001:41D0:1:46e::/64 wird zu 2001:41D0:1:4 + 5 Mal FF.
IPv6 Gateway: 2001:41D0:1:4FF:FF:FF:FF:FF

Die IPv6 des Servers: 2001:41d0:1:209::/64 wird also zu 2001:41d0:1:2 + 5 Mal FF.
IPv6 Gateway: 2001:41d0:1:2FF:FF:FF:FF:FF

In unserem Beispiel ergibt sich also der Router 2001:41D0:F0F0:F0FF:FF:FF:FF:FF. Die Route setzen wir mit

route -A inet6 add 2000::/3 gw 2001:41D0:F0F0:F0FF:FF:FF:FF:FF

Da wir zudem den Host als Router verwenden wollen benötigen wir Forwarding, das schalten wir mit diesem Befehl ein:

sysctl -w net.ipv6.conf.all.forwarding=1

Um auch zu wissen wo die Gäste hin sollen tragen wir hier entsprechende Routen ein. Ich habe es pro Host gemacht, sollte aber auch blockweise funktionieren:

route -A inet6 add 2001:41D0:F0F0:F0F0::10 dev br0
route -A inet6 add 2001:41D0:F0F0:F0F0::11 dev br0

Zum Schluss folgt dann der IPv6-Fubar, der meine Probleme auslöste: Ich nenns mal das IPv6-NAT. Die komplette Erklärung was und warum das nötig ist (“Proxy the neighbors”) habe ich am Ende verlinkt.

sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy 2001:41D0:F0F0:F0F0::10 dev eth0
ip -6 neigh add proxy 2001:41D0:F0F0:F0F0::11 dev eth0

Wichtig hierbei: Das eth0 ist kein Typo! Die Zeile bedeutet, dass der Host auf dem Interface eth0 bekannt geben soll, dass er für die genannte IP eine passende Route kennt.

Auf dem Gast sind dann nur analog zu oben die IPs einzurichten, die IP des Host-Interface br0 spielt dabei den Router:

ifconfig eth0 inet6 add 2001:41D0:F0F0:F0F0::10/64
route -A inet6 add 2000::/3 gw 2001:41D0:F0F0:F0F0::99

Weitere Ressourcen:

• OVH-Hilfe: IPv6
• IPv6 – Proxy the neighbors (or come back ARP – we loved you really)

Das trifft meine Beschäftigung in den letzten Tagen ganz gut. Ich habe bereits länger auf meinem Mailserver sieve im Zusammenspiel mit Dovecot im Einsatz. Als Frontend ist nach vim und dem Thunderbird-Plugin schlussendlich ein (inzwischen integriertes) Plugin für meinen Webmailer Roundcube zum Einsatz gekommen. Im Gegensatz zu den vorherigen Lösungen ist es hier über eine GUI möglich sich einfache Regeln, wie aus vielen Mailprogrammen bekannt, zusammen zu klicken. Inzwischen gibt es eine Weiterentwicklung, welche einige lang erwartete Features mitbringt. Leider verlief mein Test nicht ganz wie geplant.

Erste Beobachtung: Immer wenn man ein Sonderzeichen verwendet ist der Webmailer nicht mehr nutzbar. Die aktuelle Sitzung wird beendet, versucht man sich neu einzuloggen kann man Mails lesen, ein Klick auf die Filterseite führt aber zu einem neuen Absturz. Einzige Lösung: Das Filterscript mit einem anderen Editor löschen. Nicht ganz was ich wollte, aber eine Nachfrage beim Entwickler verheißt nichts Gutes: Kein Fehler in der Richtung bekannt. So weit so schlecht.

Sinnvollste Möglichkeit: Testserver hochziehen (LVM-Snapshots ftw) und Problem einschränken. Schnell war klar: Es muss wohl an der Config liegen. Auf einem frischen Server ließ sich die aktuelle Roundcube mit Plugin nutzen, auf der Kopie des Produktivservers tritt immer wieder der Fehler auf. Etwas hin und her – ratlosigkeit. Der Testserver konnte auf dem Filterserver des Testservers problemlos arbeiten, also kann es nicht am Mail-/Filterserver. Auch die Kopie des Programmverzeichnisses vom Produktiv auf den frischen Testserver arbeitete dort problemlos. Doch die Konfiguration? Also nahezu das komplette /etc vom frischen Testserver auf die Produktivkopie gezogen, PHP-FCGI auf mod_apache, etc, etc – nada. Einziger Unterschied, der mir auffiel war 64< ->32Bit – das wirds ja wohl kaum sein.

Hilft nichts – der Holzhammer muss her: Das komplette Plugin mit echos durchsetzt und huh – der Abbruch passiert beim Speichern der Session. OK, generell würde ich ja sagen nicht korrekt escaped, aber warum tritt es dann nur auf einem Server auf?!

Stunden später war mir dann meine eigene Blindheit auch klar: Ich hatte zwar alle Daten kopiert, aber nicht die Datenbank. Die hatte ich zwar kurz verglichen, aber ein kleines aber verhängnisvolles habe ich übersehen. Roundcube nutzte in den ersten Versionen ASCII als Zeichencodierung für die in MySQL gespeicherte Session-Table. Dies wurde irgendwann auf UTF8 umgestellt, jedoch nur in den Scripten für Neuinstallationen – die Update-Datei enthält keine entsprechende Konvertierung. Da mein RC schon lange läuft hing die Tabelle entsprechend auf ASCII und machte bei UTF8-Zeichen in der Session die Fliege. 3 Tage gebastel und ein ALTER TABLE später funktioniert nun alles – so kann man sich auch beschäftigen…

YotaWeb2 – WARNING – /dev/sda, failed to read SMART Attribute Data
YotaWeb2 – WARNING – /dev/sda timeout
YotaWeb2 – CRITICAL – ata1.00: failed to IDENTIFY (I/O error, err_mask=0×4)
YotaWeb2 – CRITICAL – raid1: Disk failure on sda1, disabling device.
YotaWeb2 – CRITICAL – raid1: Disk failure on sda3, disabling device.

Testen wir mal, ob der Bereitschaftstechniker noch wach ist…

Hallo Herr Florian Knodt,
ich als begeisterter und zufriedener Kunde von Yotaweb würde gerne ein Angebot erhalten, welches ich im Auftrag des **** einholen möchte.
…
Ich bitte aufgrund dieser Informationen um eine Kostenaufstellung und ggf. ein Gespräch.

Tja, dumm, dass sich meine Bemühungen bezüglich einer Firma Yotaweb (o.Ä.) ständig nach hinten verschieben.

[...]er hat einen Mailrouter bekommen[...]Was können wir nun da machen?

Eventuell lässt sich der Mailrouter ja bei gebraucht eBay verkaufen, ansonsten übernehme ich in solchen Fällen die Eliminierung des “Routers” gegen einen kleinen Obulus in Form einer SMTP-Fehlermeldung…

–Edit–
Ich höre grade, dass ABS atm Registrierungen und Abmeldungen nicht verarbeitet. Dürfte daran liegen, dass momentan GUI und Backend auf verschiedenen Server liegen, werde ich morgen beheben.