marzametal wrote:DudeOfLondon wrote:A few days ago the "find the quickest node" button showed different servers while testing a few times in row.
But now it seems to show always the same server, which is for me the server that is geographically the closest to my place.
The CS staffers are aware of it... when they implemented HAF v1.1, it broke "find the quickest node" functionality. The next widget release will include a fixed button, or total removal.
I believe widget 2.2 will remove the function as we work on a logical syntax that makes sense with a properly cluster-based topology. Because, in clustered context, there's inherent (and valuable, opsec-wise) stochasticity in which exact node (and instance) is mapped by a given cluster or balancer A Record. So we'll need to do some Monte Carlo-ish probabilistic/iterative test queries to see what connection meets a given parameter. There's also the structural divergence between
pings and
throughput - "fastest" sort of hand-waves this and we'd like to come up with an heuristic that really captures the desires of members when they are picking such connection optimisation parameters.
My preference is to do this with additional HAF-level balancers, somehow. This may not be possible, but there's an elegance to the solution that continues to lead me to hope I can work it out in a way that meets production requirements.
This "fastest connection" option is one that gets bullshitted alot by "VPN clients" out there. I've taken a few apart & done iterative reconnect tests with them, as I was curious what sort of heuristic they implemented. Pretty much every one was just faking the whole thing. They pick from an ordered list, or have a hard-coded "fastest connection" that happens to be the cheapest datacentre, or whatever. Reminds one of the
faked 'server status' page... which itself is hardly the only example of that particular mendacity.
Anyway...
In the meantime, I gotta' start looking for a firewall that can handle hostnames. Won't be able to use W7 firewall anymore since it is based on IP. Who can be bothered updating IPs all the time. Just today, Maple spat out another IP after I had updated it yesterday.
A firewall that operates based on hostname mappings that are themselves one-to-many categorical entities risks getting into recursive logical loops of the
Turing 'halting problem' type of NP Complete algorithmic expressions... which isn't good if you're a firewall
However, I think we (df, actually) have come up with a way to do a form of balancer that is actually IP-based, versus hostname-based. Still quite some testing to do before we could present a publicly-callable example for members... but I think it's logically sound, and I think we'll be able to make use if it in -for example - a really wildly effective defensive technique against IP-based national blocking of cryptostorm network resources (i.e. Great Firewall). This still leaves the recursive firewall problem, however...
We do have a realtime list of all IPs associated with all nodes currently in production on the network - perhaps we can find a way to make that callable so firewall-based setups can rsync to that and thus have a current iptables rules-chain by definition (rather than manually being updated). If there's demand for such a function, I believe we can do it in a security-appropriate context (ask for a hashed token as part of the script query, for example - just to cut down on spammy queries, perhaps?).
Anyway, that likely deserves a separate thread in the leakblock forum, if anyone's game to continue the discussion...
Cheers,
~ pj
cstorm_narwhal21.zip
cstorm_narwhal21.exe
