Tinypoxy with Iptables for Website Testing

Tinypoxy with Iptables for Website Testing

February 6, 2021
software, sysadmin, web

TL;DR version

I have foo.example, and metoo.example on server A and I want to test them on server B, and I’m willing to setup a odd little mousetrap to do it…

So I have multiple DNS domains that are self hosted. None of them are really anything more than a hobby. As such, they get hosted “on the cheap” – meaning I do a lot of grunt work to keep the costs down. That also means they move around. This means updates, upgrades, and server moves. Well, how do you test a new version of a server while leaving the old one in place?

Well, typically, I just override DNS in /etc/hosts. However, the more sites involved the uglier that solution gets. I came up with a solution recently involving tinyproxy and iptables. Initially, I wondered if there was a better way. So I asked the Source of All Geek Knowledge. I did not get a reply. However having used my little hack, I find it useful and somewhat elegant – even though it is a bit “Rube Goldberg-esque”. Note: this is not a real practical solution unless you have a lot number of virtual sites. It works for me because I already had most of the pieces in place (desktop Linux and iptables setup).

Setup #

DISCLAIMER:
I am assuming the reader is comfortable with iptables concepts and basic syntax. If iptables are a new concept, this is probably not a good solution to consider. It is a bit convoluted.

Scenario: Moving sites “foo.example” and “metoo.example” from server A to server B. Requirement: A Linux box for tinyproxy and iptables. For this scenario, I am going to assume a Linux VM: C – on the desktop machine (no additional firewall).

  • Install tinyproxy on C and configure the proxy port. I believe the default it port 8888.
  • Configure your iptables on C rules for Destination NAT (DNAT):
    • Rewrite all tcp traffic going to the IP of A with the IP of B

Example:

iptables -t nat -I OUTPUT -d <IP.of.Server.A> -p tcp -j DNAT --to-destination <IP.of.Server.B>
  • Configure your test work station to use tinyproy on VM C as either the system proxy, or (my preference), configure Firefox to use C:8888 as its network proxy. I like the latter option because it is easy to setup and allows me to have a “test browser” rather than a “test system”.

With this setup, both foo.example, and metoo.example still resolve in DNS to <IP.of.Server.A>, but network traffic (TCP only in this case) leaving VM C will get redirected to the new server B.

Using C as your proxy basically hijacks traffic bound for the old “current production” server and routes it to a test server.

Once you are done testing, remove the proxy configuration until the next move (or just leave it for on-going development).