2

I have a web server that hosts 200+ domains but it needs to be moved to another data center and get a new IP address. But since all DNS settings have to be updated manually, I thought about whether you could set up some kind of transparent proxy at the old IP address that forwards all http/https traffic to the new IP. So visitors do not discover the move to the DNS is being corrected.

My first thought was to use nginx for it, but thinking it will cause problems with SSL certificates on the domains. Is there a good way to solve the problem?

The Tech Guy
  • 21
  • 1
  • 1
  • 3
  • 2
    How many IP addresses do we talk about? One? And why did you not use a CNAME for that so that a simple change would redirect all domains? – TomTom Jul 10 '21 at 21:55
  • 1
    at first reduce the ttl of any record to a minimum, after that wait for 3-5 days, verify that. make an initial sync of your old to new server. set local a domain name to the new IP via hosts look for any errors. it will usually not make any issue to have the same certificate on 2 server simultaneously. verify, and if it's OK you can change the real entry's, remind to Remove the hosts entry – djdomi Jul 10 '21 at 22:02
  • 2
    Assuming your server runs linux, you don't even need to run nginx. Just run something like `socat -T 900 TCP-LISTEN:443,reuseaddr,fork TCP-CONNECT:newserver:443` on the old server (make sure it restarts, survives reboots, ...). That'll forward the connection on a TCP basis and save you the headache of configuring nginx right. – Guntram Blohm Jul 11 '21 at 07:10

3 Answers3

5

I use the following migration process in these cases:

  1. Change DNS TTL to minimum value
  2. Wait for DNS TTL to update
  3. Copy keys / certificates to new server
  4. Put site to maintenance mode
  5. Synchronise files/database to new server
  6. Set up reverse proxy from old server to new server
  7. Remove maintenance mode on new server
  8. Change DNS entries to point to new server

Step 6 ensures that end users don't end up to the old server even though their DNS has resolved to the old server IP.

After this, keep monitoring the old server logs to see when traffic has stopped there. Then you can dismantle the old setup.

Reverse proxy is set up using proxy_pass directive. If end user IP address is important information, you need to add it into HTTP headers on the old server -> new server requests, and tell new server to use the header value as the IP address.

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
  • It was also a bit in the direction I had thought, but did not really think I can find a way to handle the https part without having to install all the SSL certificates on the proxy server as it somewhere does not really need the data but only must receive and forward data. It must be both 80/HTTP and 443/HTTPS traffic. – The Tech Guy Jul 11 '21 at 11:14
  • You might be able to use nginx `stream` module to forward the TCP connection as-is to the new server. In that case only new server would need all the certificates. – Tero Kilkanen Jul 11 '21 at 12:36
2

You may first want to decide (or estimate) what you want to sacrifice when you are moving:

  1. Ease of the transition (if a lot of the points below are important, the transition will be a project instead of a task, you may as well not have the expertise needed available)
  2. Downtime (is it possible to execute the whole transition at night or whenever your users' activity is minimal?)
  3. The consistency of the access logs (it may be quite important and the http or tcp proxy will mask the remote IP addresses)
  4. The consistency of the data shown to the users (is it acceptable some of the users to see stale data?)
  5. The possibility of content updates for a while
  6. The data safety (in quite a few cases it is important to keep the data absolutely safe from corruption and/or leaks even if this means some downtime)
  7. The time available (your hosting contract running out)
  8. The user session consistency (this is formally included in point 4 but deserves additional consideration because of the differnt possible mitigations)

Depending on the combination of the above, you may want to use one or more of these:

  • TCP proxy (like socat)
  • HTTP proxy (nginx, squid, etc...)
  • A complex routing/VPN solution to allow a single server to respond to requests on 2 IP adresses
  • Database replication
  • Virtual machine migration

The things you will want no matter of the strategy chosen, are:

  1. DNS TTL lowering (you may increase it back after everything is ready)
  2. A Backup - yes, bad things do happen during transitions and migrations.
  3. A plan
  4. A plan for going back if the transition plan fails.
fraxinus
  • 624
  • 3
  • 5
  • +1 for mentioning the issue of migrating the live database (or VM). This is the hard part of migrating a site without bothering users and risking data loss. I have good experiences with MySQL and circular replication for this. If done correctly there is also no need to rush any of the steps. – mvds Jul 12 '21 at 06:19
  • One more for the list: user session consistency. If sessions are stored in the database this is covered, but e.g. file/redis based sessions need their own migration or any active user will find its session killed the instant they start talking to the new host. – mvds Jul 12 '21 at 06:22
0

Another alternative is to use a combination of NAT, a VPN and policy routing.

You set up a VPN between the servers in the old and new locations, on the server in the old location you use destination NAT to redirect incoming traffic down the VPN. On the server in the new location you use policy routing to ensure that replies to traffic that came from the VPN goes back down the VPN.

Peter Green
  • 4,211
  • 12
  • 30