Da CouchDBs SSL-Unterstützung bei der Replikation derzeit nutzlos ist (für das Szenario, dass ich in einem fremden Netz unterwegs bin und der Netzbetreiber Man-in-the-middle spielt um meine Daten abzugreifen), musste ich mir eine Alternative überlegen.

Folgende Punkte gilt es zu beachten:

• Die Kommunikation darf nicht unverschlüsselt das Telefon verlassen und darf erst in einem vertrauenswürdigen Netz entschlüsselt werden.
• Die Kommunikation darf nicht an das falsche Ziel (Man-in-the-middle) geschickt werden.
• Nach Möglichkeit sollte die Lösung ressourcensparend sein.

Meine Wahl ist ein OpenVPN-Tunnel, über den nicht die Defaultroute läuft, sondern eine spezifische Route für alle IPs, auf denen ich später eine CouchDB laufen lassen möchte. Das sieht in etwa so aus:

$ cat /etc/openvpn/n900.up.sh
#!/bin/sh
ip -6 a a 2001::vpn:1/48 dev $1
ip -6 r a 2001::couch:1/112 via 2001::gw:1 dev $1

Damit das OpenVPN einigermaßen performant läuft, sollte man laut diesem Paper die Parameter cipher AES-256-CBC und comp-lzo wählen.

Auf der Gegenseite, also auf 2001::couch:1 konfiguriert man nun die zusätzliche Adresse und grenzt den Zugriff via ip6tables auf den VPN-Client ein:

# ip -6 a a 2001::couch:1/112 dev eth0 preferred_lft 0
# ip6tables -N couch
# ip6tables -A couch -d 2001::couch:1/128 -s 2001::vpn:1/128 -j ACCEPT
# ip6tables -A couch -d 2001::couch:1/128 -j REJECT
# ip6tables -I INPUT 5 -j couch

Die Angabe preferred_lft 0 bewirkt, dass diese IP nicht als Source-IP für ausgehende Verbindungen benutzt wird (sondern nur als zusätzliche IP zur Verfügung steht).

Auf meinem Telefon muss nun sichergestellt sein, dass OpenVPN dauerhaft läuft, damit die einzig mögliche Route zu 2001::couch:1 durch das VPN läuft. Auf der Gegenseite wäre die einzige Möglichkeit, an die Daten zu kommen, sich als 2001::vpn:1 auszugeben (IP address spoofing), was aber in meinem Fall nicht funktioniert, da mein IPv6-Tunnel und das VPN sich im selben Netz befinden. Falls das nicht so wäre, müsste man 2001::couch:1 auch in das VPN stecken.