2

I'm trying to use an OVH node as a reverse proxy for several minecraft servers(mostly for DDoS protection and firewall customisation). The minecraft hosts are also running ubuntu, either 12.04 or 14.04, and the OVH has ubuntu on it. Currently I've tried doing this:

sysctl net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport port -j DNAT --to-destination ip:port
iptables -t nat -A POSTROUTING -j MASQUERADE

This mostly works fine, with the exception of the obvious, that all the clients have the same IP as the server i've done this on. Is there any way i can set any of these devices up so that it preserves the original source IP? I've read that tcpproxy (http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/proxies/TcpProxy) is a good solution to this, but i see no reason this problem would not continue.

I also wonder if using this would cause replies from the minecraft server to bypass the proxy, leaking the real IP's, which i would like to avoid.

muru
  • 193,181
  • 53
  • 473
  • 722
user3407675
  • 135
  • 2
  • 2
  • 7
  • You could set up "virtual" ports, then forward to a specific server's minecraft port depending on that port number. This way they all retain the same IP and all traffic flows through the proxy server. Of course, you'd have to have one set of rules per server on your proxy as well. It looks like after relaying the initial handshake, the tcproxy server is finished and the client connects directly to the server after that. – Chuck R Oct 27 '14 at 19:30
  • I don't think that preserving the IP would work for the proxy since a response from a different IP address than the one that was originally connected to would be ignored since the client isn't expecting it. – Chuck R Oct 27 '14 at 19:38
  • And this is what i was thinking also. Hence why it would direct connect to the client. How would i go about setting up these virtual ports? Is this done via iptables also, if so is there any guids/documentation/keywords i should google on this? Or any better software to look for. I've been debating Sshuttle as a possible solution. – user3407675 Oct 27 '14 at 19:43

1 Answers1

2

Preserving the IP address of the proxied server wouldn't work in your situation. If the client originally connects to the proxy (we'll say proxy:1111) and gets a response from minecraft1:2525, what does the client do with it. There's no way for the client to map this response to the original request.

Keep doing it the way you're doing it.

Instead, you could use multiple rule sets on a range of ports. So, for example, minecraft1 is proxy:1111, minecraft2 is proxy:1112, mincraft3 is proxy:1113, etc.

Then you could set up your rules like this:

iptables -t nat -A PREROUTING -p tcp --dport 1111 -j DNAT --to-destination ip:port
iptables -t nat -A PREROUTING -p tcp --dport 1112 -j DNAT --to-destination ip:port
iptables -t nat -A PREROUTING -p tcp --dport 1113 -j DNAT --to-destination ip:port
iptables -t nat -A POSTROUTING -j MASQUERADE

Then, to connect to minecraft1, you'd use proxy:1111. For minecraft2, proxy:1112, etc. The port that the actual Minecraft servers are running on doesn't matter since the rules will relay to the correct port.

Chuck R
  • 4,848
  • 2
  • 26
  • 37
  • The only issue with this, is i can't discriminate players based on IP, so if someone has a wish to spam the server, i can't IPban them without banning every player. I did fear this might be the only option however. Do you think possibly uisng a sortta VPN like sshuttle might help with this? Or is IPtables nat as good as it gets? – user3407675 Oct 27 '14 at 19:48
  • Sure you can! `iptables -t nat -A PREROUTING --source [banned IP] -J DROP` should do the trick. (Not that IP banning is effective what-so-ever in all honesty). – Chuck R Oct 27 '14 at 19:54
  • Heck, you can even add some counters to iptables so that you can add them to the firewall block list if they make too many connections, too fast for example. I'll leave that as an exercise for you ([here's a starter link](http://www.digitalsanctuary.com/tech-blog/debian/using-iptables-to-prevent-ssh-brute-force-attacks.html)) – Chuck R Oct 27 '14 at 19:59