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:
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.