6

I work in an environment where there are multiple locations, and in each locations we have the same IP addressing scheme, that is, we have many machines (one in each location) that share the same IP address (the hostnames are different though). Naturally, there is no communication between these locations, and also no DNS. I connect to each location in turn, by opening VPN tunnels. My workstation is Linux.

I am trying to develop a system to allow me to work as safely as possible in this environment. I would like to use hostnames instead of IP addresses directly, as we have an easy-to-remember naming convention. The problems I have encountered so far are: 1) logging in by mistake to a different machine, because a tunnel was open to the wrong location, and 2) ssh having a different host with the same IP but a different hostname in known_hosts, and refusing to connect.

So far, I am thinking of creating a different /etc/hosts and ~/.ssh/known_hosts file for each location (e.g. /etc/hosts.location1), and using a location switching script to automatically switch between these files by copying the version customized for my target location over the default file (e.g. cp /etc/hosts.location1 /etc/hosts). Ideally, this script will eventually be integrated with the software that I use to open VPNs to the different locations.

My question is: is there a better way to do this? Is there any functionality in ssh or the linux name resolution that I'm missing out on?

Many thanks.

Edit: this is a production environment, and I am looking for a workstation solution to this problem.

Dan Nestor
  • 220
  • 1
  • 2
  • 7
  • 6
    Setup IPv6, and give your devices unique addresses. – Zoredache Oct 12 '13 at 09:51
  • Either what @Zoredache says or changing the adressing scheme on the sites. – Frederik Oct 12 '13 at 10:01
  • Maybe you could do some port forwarding - for example your localhost listens to ports from 10000-10100 that map to those hosts so if you connect to loclhost:10001 that connection goes to site1:22, then localhost:10002 to site2:22, etc. You don't even need to mess with the hosts file because you can use your .ssh/config file and name the hosts there. But this would only work for ssh. – Jure1873 Oct 12 '13 at 10:19
  • Forgot to mention, this is a production environment, so any changes such as changing IP are out of the question. I am looking for a solution on my workstation. – Dan Nestor Oct 12 '13 at 10:53
  • @Jure1873: interesting idea, however there are far too many sites and machines (15 sites, hundreds of machines in each) for this to be viable. Also, I would prefer name resolution via hosts to work for other protocols as well. – Dan Nestor Oct 12 '13 at 10:55
  • Even though it is a production environment, IP changes can still be made - it is just a little more complex :) – Frederik Oct 12 '13 at 12:17
  • Now you have seen [the dark side of RFC 1918](https://tools.ietf.org/html/rfc1627). Anything you do, _anything at all_, is merely a nasty workaround. You really do need IPv6, and as soon as possible. Preferably years ago. – Michael Hampton Oct 12 '13 at 18:26
  • Out of interest, what's the rationale of having the same IPv4 addresses in different sites? – Simon Catlin Oct 12 '13 at 20:24
  • Your solution of using a script to manage separate /etc/hosts and known_hosts sounds viable (given the incredibly undesirable constraints of the environment), but make sure you include a purging mechanism in your script to handle any name caching (nscd, dnsmasq, etc). – Joshua Miller Oct 12 '13 at 21:08
  • @SimonCatlin: I can't be sure, really. The duplicate IP addresses seem to occur in our oldest datacenters, so my best guess would be that the earlier release versions did not allow for changing IPs. Thankfully, a practice that has since ceased, as newer location seem not to be affected by this. – Dan Nestor Oct 13 '13 at 11:15
  • @SimonCatlin I have seen SOHO router products that are hard configured for 192.168.1.0/24, apparently an attempt to minimize the configuration options for people buying these things. My first home router was like this. – Skaperen Oct 13 '13 at 23:24
  • We also have had a similar issue because of old servers / systems with some kind of bmc controllers configured for 172.x.y.z, that are the same on all sites and very difficult to change. – Jure1873 Oct 15 '13 at 14:50

3 Answers3

1

You mention that you VPN to each site. Could each site have a DNS server (or two) which have their own site domain (site1.mycorp.com, site2.mycorp.com) and use something like Bind views (http://www.zytrax.com/books/dns/ch7/view.html) to provide IP addresses to named hosts to VPN networks?

This way, you could give each host in every site a unique FQDN (barney.site1.mycorp.com and rubble.site2.mycorp.com) and these hosts will only resolve properly when you are VPNed to the correct site and that Bind view responds. In each site, barney.site1.mycorp.com and rubble.site2.mycorp.com could potentially have the same IP address. But they wouldn't resolve externally or if you were connected to the wrong VPN.

This isn't so a much a "workstation" solution. But if you have the ability to add nodes (VMs or physical hosts) to each site (which don't necessarily need to be part of production), then this could be a solution. If you already have production DNS that you are comfortable modifying, then you might already be able to leverage views and naming that is present.

Andy Shinn
  • 4,131
  • 8
  • 38
  • 55
  • Thanks, but as I said, there is no DNS, nor do I have the possibility to alter the environment, unfortunately. – Dan Nestor Oct 14 '13 at 08:47
0

Can you do anything at the remote sites, like drop a file in $HOME or edit bashrc? For instance I have at one site's /etc/bashrc:

  [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[SITE1 \u@\h \W]\\$ "

which helps avoid ambiguity. You could set your prompt to include cat .site_name for instance, if you can install that file.

Also look at using .ssh/config for host name definitions. You can have:

Host app1.site1
HostName 10.11.12.13
User service

etc. and then use ssh app1.site1 and rely on strict host key checking to keep you safe. I'm assuming that sshd was allowed to create its own host keys. If the machines have identical host keys, then you're going to have trouble with that.

Lastly, you could write an ssh wrapper script. Consult the routing table (netstat -nr) to find the VPN endpoints and disallow wrong behavior based on endpoint IP. Roughly: safe_ssh site hostname and besides rotating your known_hosts files, if the destination for your remote network is not for the site value you specified, then bail out with an error message. You could probably work something out with ssh connection multiplexing if you wanted the script to bring up and down the VPN as well.

Bill McGonigle
  • 647
  • 5
  • 8
-1

Is giving each machine a unique IP (as well as it's common, presumably RFC 1918 IP) a solution? We use this approach, we have a number of machines with a RFC 1918 IP alias, but they all have a unique "public" IP.

devicenull
  • 5,572
  • 1
  • 25
  • 31