4
\$\begingroup\$

I want to create a network where the main servers IP is never exposed to the client. By going throught tunnels.

Here is a sample: http://dl.dropbox.com/u/12304631/eliteots/mc/network.jpg

Problem

  • By making tunnels through dedicated servers I hope to solve latency issues from some clients that are far away from the main server.

  • But even if this does not succeed, I wish to hide my main server to avoid network attacks directly against it. So the main server only communicates with the tunnel hosts, which then communicates with the clients.

So by creating several tunnels I will be able to let customers easily access the main server by switching tunnel if their preferred tunnel is currently under attack. This is not my problem, should be easy to program, however the network configurations between tunnel and main server is the issue because of my lack of experience in this area.

Requirements

  • I am not talking about a simple http proxy, I want this to solution to operate on all ports. Or at least the configured ports. Only transmitting TCP.

  • I do not wish any encryption on the traffic between the vpn and main server, I think it should be as fast as possible.

  • I am working on an MMORPG, which is why I put so much effort into learning this. The worst thing that can happen to a customer is to be kicked from game server unable to login to finish their needs.

  • I only operate in an linux environment server-based. (Debian/Ubuntu).

Solution idea

I heard having an openVPN server might be what I need.

But I have problems operating it, I find it quite complex. First off, I want to know, is this even possible in OpenVPN? If so, how should I configure the network logics?

I am open to try out any free solutions you may find/recommend me!

Improve this question
\$\endgroup\$
4
  • 2
    \$\begingroup\$ I know this is about a game server, but this seems more like a networking question which probably belongs on a different SE site. Perhaps even on stackexchange.com itself. \$\endgroup\$
    – Richard Marskell - Drackir
    Mar 2, 2012 at 1:11
  • 4
    \$\begingroup\$ Is it any improvement if your competitors bring down all the tunnel computers instead of your main server? Something still has to have a public IP address. \$\endgroup\$
    – Jimmy
    Mar 2, 2012 at 1:21
  • 3
    \$\begingroup\$ Off topic like Richard said. FAQ gives this rule of thumb: "Would a professional game developer give me a better/different/more specific answer to this question than other programmers?" In this case: it's just a networking question so no. \$\endgroup\$
    – doppelgreener
    Mar 2, 2012 at 2:04
  • \$\begingroup\$ I don't think the typical concepts for large scale business information systems can be used without adaptation for MMORPGs. To give some examples for such details: You need to handle encryption differently for web applications because the browser checks that the name in certificate matches the name of the frontend server. For web applications content delivery networks for static content play an important role to reduce latency. But many MMORPGs include the static data in bulk downloads and fight with with the latency of "dynamic content" (e. g. fights) \$\endgroup\$
    – Hendrik Brummermann
    Mar 2, 2012 at 10:55

6 Answers 6

Reset to default
10
\$\begingroup\$

Speaking as somebody who's been paid to do this.. In a standard MMO server network configuration, you have three main pieces:

A point server. This server has a public IP address, and contains nothing of value. When a client chooses to connect to the game, the first thing it does is query this server. This server provides the IP addresses (and ports, if relevant) for the available server proxies. This can be as simple as providing this data via a standard web server, if you like. In most point server implementations, the point server will do some geolocation on the requester and provide only the nearest proxy or proxies to that user. Additionally, most implementations will have the point server be in constant contact with all of those proxies to determine which ones are busy and which aren't, in an effort to balance user load between them. This server may have a static IP address, or may have a registered DNS name. This is the only server which must maintain a single presence on the internet for the lifetime of the game; all others may be moved as desired.

One or more proxy servers. These servers have two network cards: One network card has a public IP address, and faces the internet. One is on your private server farm LAN, and has an internal IP address which can't be reached by the internet. These are the "gateways" into the server farm, and ideally are widely spaced around the world, so all users will have at least one proxy near them. All outside traffic to the server farm must pass through one of these proxies. These proxies are responsible for authenticating that the end user is a real user, and (with the help of authentication servers inside the server farm) they perform login authentication. Once a user is authenticated satisfactorally, the proxy servers bundle together requests from that user with other requests from other users, and sends those bundled requests into the server farm to be handled.

The server farm itself. This may be one computer or many. All are on a private LAN which cannot be directly reached from the Internet. Batches of requests are received from various proxies, are split up into individual requests, and are handled by the servers in the farm. Any responses to those requests are batched up again and sent back to the originating proxies, which split up the responses and forward them out to the users.

The net effect is that your server isn't on the internet at all -- it cannot be directly reached because it has no public IP address allocated to it. This is the only sane way to handle a high-demand game server to keep it from being a target to DDOS and other attacks. Individual proxy servers can be attacked, but not the server itself, which is where your core data resides.

If necessary (when under attack or etc), you can move your proxy servers around, just update the data returned by the point server to point to the new locations of the proxy servers, and you're good to go; no server reboot or anything required.

And that's pretty much all there is to it!

Improve this answer
\$\endgroup\$
5
  • 1
    \$\begingroup\$ The point server contains nothing of value?!? It gives the client the addresses of the real servers where it should connect, so if someone hacks the point server to make it "point" to his own... \$\endgroup\$
    – o0'.
    Mar 3, 2012 at 9:59
  • 1
    \$\begingroup\$ @Lohoris: I meant that it doesn't have access to account information, passwords, credit card data, etc. I think that was pretty obvious from context, but apologies if you were confused. In regards to your postulated attack against it, even if such an attack was successful, it would not yield any user data, no logins or passwords, no credit card details, and could be trivially cleaned up again with no damage done to anything inside or outside of the game. If you'd really like to talk more about this attack vector, then please do feel free to ask. \$\endgroup\$
    – Trevor Powell
    Mar 3, 2012 at 11:31
  • \$\begingroup\$ It would be a man-in-the-middle attack: the user connects to your server instead of the game server, so you get his password when he logs in, and you can use it to connect yourself to the game server. \$\endgroup\$
    – o0'.
    Mar 3, 2012 at 11:50
  • 4
    \$\begingroup\$ Nobody ever sends their password to the server any more; instead, we cryptographically prove that we know what the password is based upon random challenge-response interactions, without actually sending the password over the wire. Similarly, we defend against man-in-the-middle attacks using public key cryptography; during the mutual authentication stage of connecting, the proxy server signs all its messages to the client, including its own IP address, so the client software can tell that it's not talking to a legit server and disconnect. \$\endgroup\$
    – Trevor Powell
    Mar 3, 2012 at 22:20
  • \$\begingroup\$ Honestly, this sort of network protocol hardening has been pretty much effective and unchanged over the last decade. It's why these days, cyberattacks are generally made against a service's core servers, instead of trying to intercept the network traffic. \$\endgroup\$
    – Trevor Powell
    Mar 3, 2012 at 22:25
3
\$\begingroup\$

It sounds like you just want a proxy and firewalls in front of your main server to cut down on mischief.

OpenVPN is not going to fix that, and not likely to ever decrease latency ;)

If you reduce the attack surface far enough, the attackers who are not very well-resourced will mostly become minor concerns- and you'll have bigger worries, like site perf and scaling....

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

Don't waste your time searching for solutions for this. Make your game, and make it work with a public server. THEN implement a solution to what you're asking for. You are wanting to build a house, but you're fixating on what the gate at the driveway is like.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

Tunnels will Grow your latency, not reduce it.

Why don't you just use a frontend with failover IP:s ?

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Possible front end server solutions

OpenVPN will provide a complete protocol stack on top of the protocol stack that is already there. Therefore there is quite a bit of overhead.

If you just want to forward specific TCP ports, stunnel (with encryption) and rinetd (without encryption) are very easy to setup.

On linux, this can even be done directly in the kernel without user space applications using iptables.

Core issues

As far as MMORPGs are concerned, I have the feeling that this whole approach might be focusing on the wrong end. For systems, that are accessed by masses of users, it is usually much more important to get the scalability on the backend server farm right.

While your approach may be able to handle stupid brute force denial of service attacks well, there are important short comings:

  • If you redirect legitimate users away from a DoSed frontend server, any non trivial DoS will adapt to this redirection.
  • Game actions go right through the forwarding (for example herds of bots destroying the in-game value of looted items).

  • Exploits for bugs will go right through the forwarding (for example buffer overflows, integer overflows, quest logic errors, race conditions)

  • Unless you move logic to the frontend servers and/or cache data on the frontend severs, latency will increase. You end up with the sum of the latency from the user to the frontend server and the latency from the frontend server to the backend.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

As other answers have mentioned, using a VPN solution isn't the right choice here. Not only are you not going to solve your problem with it, you're going to make it worse. Here's why:

Tunnels are going to increase your latency, not lower it - you're not only adding some level of processing time, you're also forcing traffic to take a probably non-ideal route.

On top of that, they're not making anything any more secure. If your game client has the ability to get onto the VPN, then anyone who has access to your game client has access to your VPN. Attackers can again attack your server, but now they have two possible targets - the VPN servers or the game server. You still need to properly control access to the server on your VPN network as you would otherwise, with a firewall and probably a load balancer or other front-end.

This is possibly the most important rule in MMO development. Never trust the client. This isn't just for game design, and this question is a perfect example of why.

Instead, design your server architecture in a way that's both scalable and able to fail-over nicely. Commonly, this means having front-end servers (both in the sense of multiple machines, and multiple processes) that do nothing more than authenticate users and pass on or filter traffic; and having multiple actual game-running server machines/processes that can be respawned if they fail, or added to as more capacity is needed.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .