hashtable wrote:The voodoo network is unique / insane ? I can't explain it verbally, but something below the threshold of my consciousness understands the topology of the network.
My sense is that, thus far, we've done a suboptimal job of explaining what voodoo really is. Not for lack of trying, mind you... I suspect instead that we're too close to the operational side of it, within the team, to step back and put it into words in a way that's really useful.
At a topological level, it's not hideously complex - for me, visualising what's going on is obvious... in hindsight!
One of the challenges is that, in the usual "multi-hop" snake oil
diagram out there, it's all made to look simple and easy to do. Of course, the only reason that's the case is that they're not actually implementing
anything: it's just a diagram! For example...
Ok sure, looks good. But, when I try to figure out what's going on, at a routing and cryptographic level (respectively) with this kind of thing... it just isn't at all clear to me how it's actually working, and what runs where. This is typical. The technical explanation
accompanying this diagram...
When connecting to a normal singlehop VPN service your Internet traffic is routed through a single VPN server. With a multihop VPN service it is routed through 2 or more VPN servers in different jurisdictions. This technology has been carefully incorporated into the IVPN network using the same 256 bit OpenVPN encryption as the singlehop VPN servers.
? Well, I feel better knowing that "this technology" (whatever that means) has been "carefully incorporated" into the network in question - hate to think what a sloppy, careless, devil-may-care attitude might bring into the equation on a project like this.
And, despite entire threads on the subject in all sorts of enthusiasm-laden security discussion boards (here's one
), it's rare to get a technically cogent explanation of what these are supposed to be doing, in detail, at a systems admin or network design level. No, it's not your imagination - the explanations really are incoherent, basically, to the point of gibberish. One reads alot of "I'm using sixteen hops and three loops and a double-twist of SSH tunnelling as a cherry on top" kinds of fanciful, boastful statements - and surely some of those folks actually know how to make such monstrosities pass packets, perhaps... but mostly I question whether any of that stuff has gone beyond the, shall we say, highly theoretical stage and entered production.
One more example, and I promise I'll stop (for now): this suspiciously vague multi-hop marketing page
describes itself this way:
Quad VPN works on the basis of daemon that simultaneously connects a separate VPN server with all other VPN servers. Each VPN server can simultaneously be a backend server, a frontend server or a transit server. Thus, there's formed a global server network with no chances to track the traffic route.
I'm not saying this is impossible - each server acting as any of the various requirements in a four-tier
network topology - but... I've no idea what administrative tools would be used to manage such a exponentially-complex, emergent network topology on the fly. And I have no idea what a "daemon that simultaneously connects a separate VPN server with all other VPN servers" means, in context: an openvpn
Anyhow, over the years I've invested a good chunk of time in studying how these multi-hop things work, and after much frustration and conclusion that (not surprisingly) I was probably just not smart enough to make sense of them, I came to the slow realisation that most of the ways they are described make absolutely no sense whatsoever
- not even at an overview/summary level. No wonder they seemed like gibberish to me; they are.
It's a subject I could keep pouring time into forever, basically - because it's fascinating, and I am sure that mixed in with the gibberish and puffery there's some actually interesting tidbits of brilliance out there, somewhere - but it isn't relevant to cryptostorm, or voodoo, or actually offering a functional service to our full membership that actually does what it says.
In fact, doing multi-layered, tiered network topologies - as any CNE or similar can say she learned early in her training - requires clear thinking, good design skills, and a fundamental awareness of what
one is looking to build. These aren't the places to "make it up as you go," and debugging them when they don't work is all but impossible if that clarity of mind is absent.(as our voodoo alpha testers already know, and as others will be discovering in their own voodoo adventures shortly, traceroute results whilst running across voodoo trajectories are... entertainingly surprising, even to us - again, it's the OSI layer thing, and one needs to be really precise on what traceroute or any other network-path-discovery tool is actually doing, within the context of a voodoo route, to make sense of the results that come from doing these tests in the voodoo context; good times!)
To me, what's a bit of a challenge is keeping the (of course, falsely-reified) OSI layers straight in my mind as I work out what's happening where. Of course, we can skip of that stuff in explaining voodoo... but, in doing so, there's a fundamental loss of coherence as to how the network has been restructured.
Anyhow, I suspect someone will come along and in an elegant paragraph, nail an explanation that is both accurate and compact... but that someone, for obvious reasons, is unlikely to be yours truly.
It worked during testing - it was slow - but I expected that.
We made no effort whatsoever to perf-tune voodoo during the alpha test. Despite that, I've absolute confidence - more than a hunch, but still not based on empirical results just to be clear - that we'll see no performance hit (apart from, for longer voodoo trajectories in a physical sense, longer pingtimes through the segments as a whole) from two-tiered voodoo. If anything, and with the time and opportunity to do some intensive testing in production context, I predict we'll see better overall throughput metrics once we learn how to really make the voodoo segments sing.
The test only used one exit node - but the whitepaper talks about creating vps endpoints on the fly? Does that mean the ip address resolved will change in flux as needed, even though the same cores are being used?
The IP address visible to the outside internet is that of the exitnode
, not the supernode. So, yes, whenever an exitnode is changed then the IP address of the underlying session will change. And, yes, in full deployment we'll have supernodes with a constellation of exitnode options spoking out from the, that will be chosen by members as they prefer. The single-exitnode nature of the alpha test voodoo trajectories was simply to keep the test in a small enough box for us to be able to get good empirical results out of the experiment.
The fun really starts, by the way, when we put jumpnodes ("entry nodes" is another label for them, but doesn't seem to be sticking as compared to jumpnodes) into the mix and have a three-tier voodoo topology. That enables, for example, a local jumpnode within the PRC, and we're able to GRE tunnel traffic out through the Great Firewall as we choose - which may well be very useful when dealing with GF-based blocks of anti-censorship tools used by those in mainland China.
And so forth.