1. yes it does require a host with a static IP
2. VPN clients generally auto-reconnect by themselves.
On Sat, Oct 7, 2017 at 11:56 AM, James Harper
> I would use an IPSEC or OpenVPN (or whatever) connection back to a central
> location and access from that way.
I was going to reply "use a VPN" but you beat me to it. That's the right
On Sat, Oct 07, 2017 at 01:38:05PM +1100, cory seligman wrote:
Correct me if I'm wrong, but they both depend
heavily on me having a server
with a static IP elsewhere.
Yes. If you have two hosts with dynamic IPs that need to communicate, there
is no way for either of them to know with any certainty what the other host's
IP address is at any given time, so the only reliable way to communicate is
via a host with a static IP address known (or discoverable, e.g. via DNS) to
both of the dynamic IP hosts.
If both dynamic hosts establish a VPN connection to the static IP host,
packets between the two are just routed back and forth as normal with no fuss.
If either or both of them have to restart their upstream connection and get
a new dynamic IP, then they just re-establish the VPN and any communication
between the two is unaffected (aside from timeout issues - e.g. an ssh
connection won't drop immediately, but will eventually time out if one of the
hosts doesn't re-establish its connection within a reasonable time)
This also works if you have more than two hosts with dynamic IP addresses.
A single static IP host can act as a central VPN communications hub for an
arbitrarily large number of dynamic IP "clients".
If you have just one host with a dynamic IP and another with a static IP, the
dynamic host should establish a VPN connection directly to the static host.
If you don't currently have any hosts with a static IP, look around for the
cheapest & closest (network-wise) & lowest-latency co-hosting or VPS provider
you can find and run the VPN service on that.
google for "cheap VPS australia":
The key things you want are:
1. a static IP
2. a real VPS with root access so you can run openvpn or whatever,
**NOT** just a virtual web server or a restricted container.
3. if it's mostly ssh traffic, you don't really need to care about
upload/download limits on the VPS. You can transfer bulk files via
your S3 service anyway.
You probably can't find anything for under $10/month inside Australia but if
that's too expensive AND you can tolerate the latency introduced by a trip
back and forth across the Pacific (about 200ms each way) or the Pacific & the
Atlantic (about 350ms each way) you can find a VPS in the US or Europe for
For ssh, ~400ms would be annoying but (just) usable, but that's still 0.4
seconds between each keystroke, which makes editing command lines a major PITA.
IMO interactive ssh at 700+ms would be far too annoying to use.
One simple solution to that is to keep another shell or a text editor open in
another window, edit your commands there and copy-paste into the ssh session.
There's also a useful program on github that can make interactive ssh sessions
far more tolerable over high-latency links:
From the README:
This is wrapper around ssh(1) which allows it to do local line editing
before sending it to remote host (also known by names such as telnet line
mode, line-by-line, line mode, line buffered mode, canonical mode, cooked
mode, RFC 1184)
It is inspired by line-by-line editing mode in telnet(1) of old.
While most of the time you're much better served by char-by-char mode
(which is only mode openssh provides), line-by-line mode is much preferred
when you use SSH over high latency ("terrible ping") links (and/or high
TCP packet loss links) such as low wireless signal, overloaded (or flaky)
GPRS EDGE mobile networks and such - because you can do all the line
editing locally without involving network. Only when you press enter is
whole line sent at once in just one TCP packet (as opposed to dozens of
them in char-by-char mode!)
sshlm allows you to interactively choose whether to use line-by-line (with
local line editing) or common char-by-char mode.
See USAGE.txt for instructions.
Apparently putty (which is available for Linux) has a line-editing mode. Dunno
if putty's plink command has that too...probably not - putty itself is a terminal
emulator as well as an ssh client. plink is just another command line tool like
Do both method also require that some process
periodically check whether
the connection is still up and re-try?
Most VPN software will automatically reconnect, or can easily be configured to do
so. You shouldn't need any hacky cron jobs or similar.
craig sanders <cas(a)taz.net.au>