ein Stückchen Zukunft
zeyel sollte jedem von euch inzwischen ein Begriff sein. Im Rahmen dieses "Projekts" muss ich mich natürlich mit allen möglichen zukunftssicheren Technologien auseinandersetzen. Das bisher größte Problem ist wohl IPv6.
Also nicht IPv6 selbst sondern eher die Tatsache, dass IPv6 teilweise schlecht oder gar nicht unterstützt wird. Bestes beispiel: unser erster Server, auf dem wir angefangen haben. Dort liegt ein /28 IPv4 Netz sowie eine hand voll einzelne IP Adressen an, die dann an die verschiedenen VMs verteilt werden. Von ursprünglich XenServer sind wir auf das (in meinen augen) durchsichtigere libvirt und kvm umgestiegen. Das läuft auch alles recht gut. IPv6 ist dank dem Hoster auf diesem Server nahezu unmöglich, denn wir haben dort wirklich und warhaftig EINE (1) GANZE IPv6 Adresse.
Auf dem 2. Server ist das ganze genau umgekehrt. Dort liegt eine IPv4 Adresse an und ein /64 IPv6 Netz an. Jetzt bekommt jede VM ein kleines IPv6 Netz und dafür nur eine Host-Interne IPv4 Adresse die dann per NAT ins Internet kommt.
So weit, so gut. IPv6 ist mit libvirt noch etwas hakelig aber wenn man iptables bedienen und routen in Linux anlegen kann ist das kein problem. Das Größere Problem ist, von einem IPv4 DSL Anschluss auf IPv6 Server zu kommen. Das einfachste wäre natürlich einfach dem Server eine IPv4 Adresse zu verpassen, aber das will ich nicht. Erstens, weil es Geld kostet, zweitens, weil ich wissen will, wie gut man einen IPv6 Server per IPv4 erreichbar machen kann und drittens, weil ZUKUNFT!
Hier zuhause habe ich zwar schon Nativ IPv6 auf meinem DSL Anschluss, aber unterwegs hätte ich vielleicht auch ganz gerne Zugang zu meinen Mails (die auf einem IPv6-Only-Server liegen) und ständig so einen IPv6 Tunnel mit sich rumzutragen erscheint mir etwas unpraktisch. Um meine Entscheidung zu verstehen hier kurz unser Mail-System:
Das eigentliche Mailsystem ist ein CentOS System mit Postfix und Dovecot. Um ein wenig ausfallsicherheit zu haben, habe ich 2 VMs die nicht auf unseren Systemen gehosted sind als Mail-Gateway eingerichtet. (Seit kurzem auch mit ASSP Spamfilter.) Diese beiden VMs stehen also im MX und Geben die Mails dann weiter an den eigentlichen Mailserver. Sollte dieser mal nicht verfügbar sein. bleiben die mails so lange auf den gateways, bis sie zugestellt werden können.
Nachdem diese beiden VMs sowohl IPv4 als auch IPv6 können, bin ich auf die Idee gekommen, einen TCP Proxy einzusetzen, der dann SMTP und IMAP an den Mailserver weitergibt. Als erstes ist mir HAProxy eingefallen, weil ich diesen schon kannte. Seit einer weile kann der auch schon IPv6. Also installiert und ausprobiert.
Dummerweise war ich hier zu Optimistisch. Er kann zwar IPv6, aber nur im Frontend. Er kann also nur auf IPv6 Requests hören, aber nicht auf IPv6 Server weiterleiten. Also muss was anderes her. Als nächstes bin ich auf fproxy gestoßen. Der erschien mir recht vielversprechend und einfach zu konfigurieren. Auf den ersten Blick hat das dann auch geklappt, aber nicht so wirklich gut. Mein Mail Client hat zwar irgendwie mitbekommen, dass es neue Mails gibt und hat sie auch in der Liste dargestellt, öffnen ließ sich die Mail aber nicht. Woran genau das lag, kann ich nicht sagen, aber ich habe nach weiterem suchen, bin ich auf tcpproxy gestoßen (bei dem Namen hätte man den irgendwie auch früher finden können). Und der tut jetzt schon seit einigen tagen genau das, was ich will. Ist von der bedienung sehr ähnlich zu fproxy und kann (wie die beiden anderen lösungen) auch ein bisschen load balancing auf mehrere Backend-Server. Auch wenn sich für Load-Balancing lösungen HAProxy in meinen Augen besser eignet.
Heute habe ich noch mein zweit-Smartphone mit meinem Mail-Account ausgestattet. Das hat mir dann aber plötzlich gesagt, mein Passwort sei falsch (was es definitiv nicht war). Ein Kurzer Blick ins Server-Log zeigte, dass Dovecot standardmäßig nur 10 Connections pro user und IP erlaubt. Das hochzustellen hätte vielleicht eine weile gereicht, aber spätestens, wenn da mal ein paar mehr postfächer liegen und immer mehr leute per IPv4 durch den Proxy gehen, reicht das nicht mehr. Deswegen musste noch folgende einstellung in die Dovecot config:
remote 2a01:4f8:d13:2906::2 {
mail_max_userip_connections = 0
}
diese schaltet die limitierung für alle Clients aus, die durch den Proxy kommen. Ist zwar nicht schön, geht aber wohl nicht anders...