Still working on it, but it seems stable enough that we'll probably take it out of the testing phase soon.
And FYI, the path is actually:
Okay maybe I made up that last one..
The whole point of this is to get users more exit IPs by using VPSes without risking any cryptographic keys or auth data by storing that data on a VPS, or risking disclosure of client IPs. If one of these voodoo VPSes gets pwned or the hoster admin gets into it, they'd be able to sniff/hijack plaintext packets the same way any attacker would be able to if they hacked into any one of the hops (routers) between CS and the thing on the internet you're connecting to (or if they directly hacked the the thing on the internet you're connecting to). Or they could drop all encrypted packets in an attempt to force someone to use plaintext. That's why it's always a good idea to keep an eye on any instabilities in your internet, as it could possibly be an attack (like suddenly being able to only reach HTTP sites and not HTTPs).
The other benefit here is that this setup will make correlation attacks much harder. Even if an attacker gets access to the voodoo VPS, they won't be able to retrieve any real client IPs.
For example, when I connect to the VPN using the Indonesian voodoo instance (named "tahu") and locally run a `ping 126.96.36.199`, tahu sees:
~]# tcpdump -ni any host 188.8.131.52
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:18:58.988574 IP 10.5.63.85 > 184.108.40.206: ICMP echo request, id 1, seq 1586, length 40
14:18:58.988602 IP 220.127.116.11 > 18.104.22.168: ICMP echo request, id 1, seq 1586, length 40
14:18:59.007800 IP 22.214.171.124 > 126.96.36.199: ICMP echo reply, id 1, seq 1586, length 40
14:18:59.007813 IP 188.8.131.52 > 10.5.63.85: ICMP echo reply, id 1, seq 1586, length 40
Keep in mind that some confusing POSTROUTING SNAT via iptables is happening here, which tcpdump doesn't see since it's happening at a point in the kernel after tcpdump gets/displays the packets.
So although it appears as though google's public DNS just responded to the non-internet accessible 10.5.63.85 IP, trust me that it didn't :)
The packet's source gets rewritten before it goes out and the duplicate packet is dropped.
I've verified this by running tcpdump on another server and pinging it locally (while logged into tahu), and it does in fact only get the one ping request.
Anyways, thanks to the GRE tunnel between the core and the voodoo nodes, the voodoo node can talk (send packets to) a VPN client on the core using this 10.whatever IP without having to know the real, internet accessible IP of the client.
That means the only way a correlation attack would be useful when hacking the voodoo node is if the attacker can also get you to goto a page that discloses your VPN IP (by exploiting the WebRTC/STUN vuln, for example).
The final idea here is still to have the user first connect to a "jump" or "entry" VPS node. All the entry node would do is forward packets to the core. Since the packets are encrypted by OpenVPN on the client-side, and the decryption only happens by OpenVPN on the core, the entry VPS never gets access to anything that would make decryption possible.
So with that final setup, pwning the entry would be pretty much useless as the most you could do is see all the IPs of the people trying to use it, but you wouldn't be able to cross reference that with destination IPs since you can't tell what the final destination IP is (or you could block all packets, but that would just prevent someone from using that entry node, and they would hop onto the next one). pwning the voodoo VPS would mean the same thing, but reversed (you can see where packets are going but not where they're coming from).
I hope that answers some of your questions :-)