How to redirect traffic from a server to another?

Forwarding web traffic

This can come in very helpful when switching servers and wanting to avoid any downtime while the updated DNS entries propagate over 48 hours through the Internet. This is esp. important for websites with

1. Make sure you meet the requirements. You need:
   1. Your old server has to be a Linux / Unix based server, so that rinetd can be installed.
   2. root access to your old server for installing rinetd
2. Copy over your websites and databases. You might want to put community websites into maintenance mode first because it's impractical and spammy to write hundreds of users an e-mail saying they should not add content over the next half an hour …
3. Install rinetd. On your old server, execute (assuming Debian or Ubuntu): apt-get install rinetd
4. Configure rinetd. For web traffic, the following lines in /etc/rinetd.conf are enough (see the docs for details, and use your new server's IP address instead of xxx.xxx.xxx.xxx of course):
   0.0.0.0 80  xxx.xxx.xxx.xxx 80
   0.0.0.0 443  xxx.xxx.xxx.xxx 443
5. Stop your webserver. So, do something like service apache2 stop. rinetd can only work successfully if nothing else is connected to the ports it shoud bind to. If there is something else listening, it will result in no redirections and a huge rinetd log file containing messages like 22/Mar/2013:19:35:47 0.0.0.0 0 (null) 0 0 0 accept-failed - [source].
6. Start rinetd. That's simply service rinetd restart.
7. Test it. If your websites still work, they are now served by the new server, since you disabled the wevserver on the old one.
8. Change your DNS records. To make everyones requests switch to the new server, point your sites DNS records to the new server.

Forwarding e-mail traffic

You can now migrate e-mails with a similar approach, something along these lines:

netstat -t -l -p
service courier-imapd stop
service courier-imaps stop
service courier-pop3d stop
service courier-pop3s stop
service postfix stop

Then add more forwarding rules in /etc/rinetd.conf – in my case I now have these in total:

# any private mail system
0.0.0.0         24        xxx.xxx.xxx.xxx   24
# SMTP
0.0.0.0         25        xxx.xxx.xxx.xxx   25
# Secure SMTP
0.0.0.0         26        xxx.xxx.xxx.xxx   26
# HTTP
0.0.0.0         80        xxx.xxx.xxx.xxx   80
# POP3
0.0.0.0        110        xxx.xxx.xxx.xxx  110
# IMAP
0.0.0.0        143        xxx.xxx.xxx.xxx  143
# HTTPS
0.0.0.0        443        xxx.xxx.xxx.xxx  443
# IMAP over TLS
0.0.0.0        993        xxx.xxx.xxx.xxx  993
# POP3 over TLS
0.0.0.0        995        xxx.xxx.xxx.xxx  995

And finally restart rinetd to make it pick up the new config:

service rinetd restart

Alternative approaches

• Using iptables. It also is about redirecting traffic at NAT / TCP level. However, this it is more difficult to understand and to configure, since it is meant as a full-featured software firewall.
• Using remote databases. If all your sites support using a database on a different host (Drupal, WordPress etc. all can do that), you can do it as follows. The advantage is, you can move your sites one by one, so can take time to iron out any issues on the new server without having to prepare that for all sites at once (which would mean copying over databases twice, once to test and once to take in new changes). A disadvantage of this is that it only works for websites, not for e-mails. Step by step:
  1. Put your site in maintenance mode for a short time.
  2. Move your site and its database over to the new server.
  3. Test your site on the new server by bending DNS at your own machine (edit /etc/hosts if you are on Linux).
  4. Edit your site configuration on your old server to use the remote databases on the new one.
  5. Optionally (if your site has user-generated files), set up an rsync / scp / ftp synchronization job to push or pull new and updated files to the new server, called by a cron job every 15 minutes or so.
  6. Disable maintenance mode again and test if the site on the old server still works (remember to disable DNS bending again!).
  7. Adapt your DNS configuration to point  to the new server. After 48 hours at latest, nobody will access the old server any more.