vpnDarknet wrote:It wouldn't connect for me so I changed the server address to {redacted}
Acting as the neighbourhood curmudgeon, I do my duty by warning that direct IP-based connections to individual node instances are brittle, in that any problems with that particular instance will result in a hard-fail for the entire session. Such "problems" are routine parts of large-scale production network management and are, as such, not entirely uncommon: instance hits session-count cap and loadbalances to other nodes and/or other instances; instance is down for maintenance or software update, instance is subject to short-term DoS, datacentre in which node resides has a connectivity glitch, etc.
As such, the officially supported - and strongly recommended - "remote" target for cryptofree sessions from Android is:
linux-cryptofree.cryptostorm.net
Additionally, the following four
HAF-based redundant TLD remote mappings will also pull from the same pool of deployed cryptofree linux/*nix instances:
linux-cryptofree.cryptostorm.org
linux-cryptofree.cryptostorm.nu
linux-cryptofree.cstorm.pw
linux-cryptofree.cryptokens.ca
These four cryptofree balancers are 100% interchangeable - pick whichever you want. Note that, alas, in the current build of the Android OpenVPN client used in this thread, there is no support for the
"--remote-random" conf parameter. A shame, as that's something we use elsewhere within our network architecture to add yet another layer of hostname-lookup resilience in the face of TLD-based cache poisoning, BPG-level, or brute-censorship attacks on specific canonical domains and/or TLDs that serve as part of our session connection framework.
If any of these five HAF resolvers don't return an IP when queried (either manually, or just via inclusion in the "remote" parameter of an Android session connection), that's something the network admin team here would really like to hear about. It could be that there's some system-level problem and we'll be able to squash a bug. It could be transient and will resolve all by itself (DNS, as deployed in the wild, is based substantially on black magic, occult worship, and the blessings of the god of chaos himself: Cthulu). It could be evidence of an organised attack on access to our network, or it could be something specific to your local network/handset/wireless provider environment. In any of these cases (apart from the Cthulu matter), there's benefits to poking at the issue rather than working around it with a hard-coded IP.
Finally, given that cryptofree is definitionally a
load-balanced network service, we really need the flexibility at the network level to ensure we can stripe sessions across instances in something resembling a coherent manner; unfortunately, folks hitting specific session IPs prevent us from doing that with their network connection attempts, and that in turn ripples through the fabric of the entire system-level process of keeping resources available for session connections. There's a fascinating mathematical structure that underlies the cryptofree approach to decentralised resource balancing... I'd be happy to go on for much longer describing it, but tl;dr it breaks when people hard-code IPs. So don't - please - if possible.
All that said, we don't block IP-to-instance connections (yes, we could if we wanted to; no, we're not going to) and instead I routinely issue these dire, long-winded, boring warnings as an alternative method of keeping these IP-based profiles reasonably in check. Yes: you're welcome.
As cryptofree has sped thru beta testing into something resembling a production deployment, we've been lax in getting proper documentation out to the membership - we hope folks will continue to help backfill that need via contributions here in the forum, and we appreciate the understanding that our unconventional "build it, deploy it, document it on the fly" methodology here sounds astonishingly dumb... but in this case might be somewhat less dumb given the benefit of having the service accessible even as we smooth out the documentary requirements, collaboratively.
Cheers,
cryptofree_client_android1_4.conf
Thanks very much, will continue going through as it's been a good read so far! Ta