[CoLoCo] Remote Access

[Neal McBurnett]

On Fri, May 09, 2008 at 07:22:51AM -0600, Kevin Fries wrote:
> OK, again, from my original message:
> 
> A <-> FW <-> Internet <-> FW <-> B
> 
> Both firewalls are Nat firewalls.  So machine A might have an address of
> 192.168.1.100 and machine B might have an address of 192.168.0.2.  But
> they are not on the same segment and using addresses that are not able
> to be routed over the Internet.  If either had a public, static IP, VNC
> alone could be a solution.  But, without one side or the other having a
> public IP, neither side can initiate the communication to the other.
> 
> Also in my original message, I mentioned two other solutions: Creating a
> tunnel via an intermediary; and Hamachi.  Hamachi allows you to have
> multiple machines route to a 5.x.x.x network through their servers.  It
> like a product-ized version of going through an intermediary.
> 
> Going through an intermediary says you place a machine on the Internet,
> such as in a server farm or co-location facility.  Then both machines
> can initiate the communications with the intermediary.  The intermediary
> can then route traffic between the two socket connections.  The
> intermediary can not initiate the connection, but once one of the
> endpoints does, it will be able to communicate back through the NAT
> firewall because the firewall will map the session back to the
> originating machine.
> 
> Only once this problem is solved, can SSH or VNC provide the service.
> But until the two machines can see each other, neither SSH or VNC can do
> anything.  The machines can not see one another.
> 
> The original posting was asking if anyone knew of any other tools other
> than Hamachi or setting up an Internet intermediary to get this done.
> It appears that you guys don't have any more or better ideas than I did.
> Oh well, it was worth a try.  I was hoping that someone knew something I
> didn't in this arena.  As of last night, I started the inevitable
> struggle with Hamachi, and see if I can get it stable enough to be
> worthwhile.  History is not on my side here, but what the heck!

This is a pretty famous problem.  But note that each machine can be
configured via NAT to have a public ip address and port that can be
used - you just have to figure it out and specify it on the other
machine.  Read more at

http://en.wikipedia.org/wiki/NAT_traversal

e.g.
 the most promising IETF standards are Realm-Specific IP (RSIP) and
 Middlebox Communications (MIDCOM). SOCKS, as the oldest NAT control
 protocol, remains valid and is widely available, while Universal Plug
 and Play (UPnP) is attractive for home/SOHO use because it might be
 widely supported by vendors of small gateways.

I haven't looked at the status recently, but that's where I'd start.

You may have other requirements in terms of usability, but one way I'd
use this stuff would be to have each box keep its ip address
up-to-date at a place like dyndns.org (in case its dynamic ip
changes), and its port forwarding up-to-date with its firewall using
the protocols mentioned above, and then the other can find it any
time.

But yeah - it is still a bit of a mess.  IPV6 should help, when that
bigger mess is sorted out :/

Neal McBurnett                 http://mcburnett.org/neal/