0

We have a number of situations where a client application needs to be migrated from one host to another in an active production network. The servers continue to run other applications.

The problem is that the remote application usually runs on an embedded system of some kind, and for reasons of risk avoidance, no changes are permitted to the configuration of these remote applications.

I can see that a router with (probably a fair amount) of NAT configuration can be made to transparently effect this change to force the traffic to another host on the network without touching the device. We might be able to convince some network level changes, but even these are not really welcome.

Firstly, is this the correct approach if the freezing cannot be avoided, and secondly, does anyone have any ideas (or even better a ready iptables ruleset) to implement something like this?

Edit

I was being intentionally non-specific, but this may help to clarify things. The client applications are typically embedded devices with proprietary TCP stream protocols. The constraint is specifically that we cannot change the device configuration, and would strongly prefer not to change the network or server configurations. This is both driven by risk from uncertainty and the availability of tools to manage the devices. There are many different types of devices with with a specific profile and this no single general solution.

This really requires some hardware interposed at the edge of the network to implement the redirection.

I realise that this can not exactly be considered good practice, but is something that we have inherited and have no control over. As we move forward, we will change the protocols to ones where the devices either are suitably configurable, or use devices that act as servers to avoid this problem.

A diagram showing a typical required configuration is shown below.

Required configuration

Pekka
  • 530
  • 5
  • 15
  • I'd like to know a bit more about what the application does and how it's addressed. If it's a web app, I'd start by looking at apache and mod_proxy. For long-term stability, I'd recommend using separate hostnames for each application, so that they're not bound to specific hosts. – Jenny D Dec 13 '13 at 11:44
  • @Jenny D The clients (as now clarified) do not use HTTP. A web proxy is unfortunately not an option. – Pekka Dec 14 '13 at 10:19

4 Answers4

2

Given your constraints, I would suggest a firewall that redirects TCP traffic based on source IP. It can be easily done with ipf or iptables, or any dedicated firewall box I can think of offhand.

Here's some basic iptables suggestions to get you started:

First, tell the server to do forwarding (if not already done)

sysctl net.ipv4.ip_forward=1

Then, setup a rule for the particular source IP of the device that you want to have redirected:

iptables -t nat -A PREROUTING -s 1.1.1.1 -p tcp --dport 1111 -j DNAT --to-destination 2.2.2.2:1111

(Here, 1.1.1.1 is the source, 2.2.2.2 is the new target and the port on the target is 1111)

You also need to tell iptables to masquerade the IP

iptables -t nat -A POSTROUTING -j MASQUERADE
Jenny D
  • 27,780
  • 21
  • 75
  • 114
  • Jenny This is much what I have considered - and looked at configuring. One of the concerns is that the router needs to have two NICs configured for the same subnet to be able to slot between the device and the network. I have not had success with straightforward iptables configuration. – Pekka Dec 15 '13 at 14:28
  • Could you add a second network to the servers themselves, and make the NATing server the router for that network? – Jenny D Dec 15 '13 at 15:11
  • Jenny D Unfortunately no. The configuration of the existing equipment is static. We have considered even placing a filter application on the servers, but find that the risks of changing these (quite old) systems makes this quite unattractive. This is precisely why this is a challenge. – Pekka Dec 15 '13 at 16:33
0

It depends on your situation and in the amount of steps it takes a client to reach the server application.

Usually you copy one client for testing, the actual application server and create a new application server redesigned for your copy'd client.

The amount of steps is used to determine at which step you send a request to then new application server. a bit like this (this should be done all virtual copy'd and separate from the real thing)

Client -> request -> sep1 -> stop2 -> server this -> server that -> done.

So step "server that" is the first step you should look into and redirect that to your new application server. if that works in the fake environment you go to step "server this" and to "stop2" and so on until you have done the whole redesigned new application server. this is more of a breakdown model than a actual iptables rule but i hope you get the idea.

  • While your solution is an approach for migrating clients across to a new host, our problem is that the client will remain and still be used for an extended period. We are trying to migrate the server to a new host without touching the client. – Pekka Dec 14 '13 at 10:21
0

We have subsequently had a Mikrotik router configured as a bridge with support for L3 address translation.

The Router is placed between the Device and the Network and dynamically translates each Ethernet Frame containing the IP address of Host to that of Host'.

I have had proposals that used a purely router based solution by introducing an additional network segment between the two ports in the router, but feel that the L2 solution is more likely to be stable.

The anticipated traffic rates are so low that an entry level RB750 provides more than sufficient bandwidth.

Pekka
  • 530
  • 5
  • 15
-1

This is why DNS was invented. Don't hardcode IP addresses in your embedded devices, as they will change over time (as you see now). Moving services to another host is then simply updating the DNS name used for that service.

Dennis Kaarsemaker
  • 19,277
  • 2
  • 44
  • 70
  • Correct. As I indicated, we inherited the landscape with the current devices. Further, some do not have DNS clients and are restricted to IP addresses. – Pekka Dec 14 '13 at 11:47