Jump to content

Recommended Posts

Posted

Traditional proxy selection

Not sure why you've included that, Its already present in l2jserver configuration. I wouldn't rely on some unknown program to do that for me.

 

Autoproxy

Its cool, but giving players the choice of proxy is even better. Keep in mind that closest location is not always properly routed, so you might have better ping at a farther location than a closer one.

 

Shortcomings:

The said possible usages are already covered by the default configuration present in the l2jserver where you can setup multiple gameserver listings listening at different IPs, but relocating to the same gameserver instance. Even having such proxies hiding the real gameserver ip, they do not offer any solution if they are not configured properly. If a proxy gets DDOSed and it proxies all traffic as usual, it would just send the DDOS traffic to the gameserver nevertheless... ugh. So a knowledgeable person who is able to setup a proper proxy VPS is required to fully benefit from this.

Apart from that, sure, maybe you can detect if a proxy is stressed, but do tell me please, how can it transfer a player to another proxy if the machine is stressed so much that is not responding to anything? At huge attacks, you can't even make a ssh session, how do you think your request to change proxy server to all players is going to reach them? This solution only works for light attacks. Even so, even if it works, that would force players to see the loading screen which will ruin their immersion. Imagine they are at siege or some event and they suddenly get a loading screen in the middle of the pvp. Also the inability to see the actual IP of the player is yet again another sign of misconfigured proxy.

 

You even haven't specified where this program is meant to be run. At client or at server? If its ran at the server, then its pretty much useless because nobody should rely on such a program - a properly configured proxy tunneling using l2j's default config is pretty much everything. If its ran at client, basically if every player must run it even if its in background, I do wonder how you've implemented this stuff to work.

 

Overall you've fixed nothing. You've created a program that already offers what l2j has. The only interesting feature is the ability to switch proxy servers while ingame, but that feature is so flawed still, that is not useful to have it. You have 2 major flaws in it. The first one is the fact that you still need to be connected to the stressed proxy before you can switch to a light proxy, which doesn't guarantee at all that the player will receive the required packet that would change its proxy connection. A more proper solution will be that somehow the client listens for incoming packets of other proxies directly, in that case you do not need to wait for the unstable stressed proxy to send a proxy change request. The next flaw is that its not seamless enough. The connection change must happen instantly, no loadind screens no nothing. The connection itself should be interchanged seamlessly. That might require some kind of reverse engineering in l2 client to check if such thing is possible. If you can fix those two flaws, then you have some future for your idea. But for now, it does not provide anything new, its just fancy program does does what l2j already does itself.

Posted (edited)
45 minutes ago, Elfocrash said:

Not present on aCis, or any other project that's not based on l2jserver post proxy support

 

That's only true when the servers have different throughput or load.

 

It's a reverse proxy. By definition that would be impossible to do that's why there is a query for it.

 

The main server knows who is where, so when the proxy stops pinging back in time due to an attack, it will automatically transfer those players to the next healthy proxy.

 

It's run on the server and it has a lot more logic that a simple proxy tunneling configuration including but not limited to health, max size, failover, recovery, port hopping, analytics etc.

 

It sounds to me like you confuse reverse proxies with tunnelin proxies.

The player is indeed connected to the server via the proxy but the server can choose where to put the player while he is connected to the proxy. He can detach the player from the existing proxy, connect him to the new one and the player will just see the loading screen. Unless the proxy server that's being attacked doesnt go down in an instant, the server will automatically transfer the players to a healthy proxy and trigger a circuit breaker pattern on the unhealthy one.

 

Since the connection is a TCP connection there is no way to do this without a loading screen of some sorts. It's basic TCP. There is a reason why you must have this screen and it's part of the magic behind the proxy change.

 

L2j might have the ability to add proxies, that's 5 lines of code, but the job that the services do and the proxy orchestration / load balancing that happens hasn't been done before, at least not in something I have seen in l2j. It's not "just a proxy".

 

Also if it's done already (as described), feel free to point me to an implementation. I'd be very interested to see how you can do all this with tunneling proxy implementation.

 

Because you might be on the go and you wanna manage the server while not able to login.

 

Even if its not present in some servers, that doesn't mean the solution should be separate from the server. It can be easily integrated taking examples from l2j.

 

Next, saying that its a reverse proxy means nothing. You just did a bad routing. If preserving real IP was impossible when routing, internet wouldn't be able to function.

 

Next, if a proxy stops pinging properly the main server, how can it transfer its players, since it can't even ping the main server? xD

 

Next, the extra features are just extra sugar added. If the program cannot achieve its main purpose, why does anyone need the extra features? Also nearly all of those features can be done with simple administration setup. Port hopping? Why would anyone need that? I have all my proxies connecting to my main server at port 7777, there is no need to have extra ports. Explain me, why do I need those extra ports? You've just added an extra feature to resolve the issue of your poor routing, which needs extra ports...

 

I would also like to know the difference between reverse and tunneling proxies and why you've chose one over the other.

 

"Unless the proxy server that's being attacked doesnt go down in an instant." Yeah, thats the fine line between a bad program and a good program. There are no "unless this happens..." in a good program. Basically your program becomes totally useless if you get one decent ddos thrown at your server.

 

My question is, whats the point of the tons of features that your program has, if it cannot do its main purpose and that is to protect the gameserver properly? Also saying that there is nothing more you can do about the flaws is just very bad practice. There is always something you can do to fix a flaw.

 

I already have much better private solution which I cannot share. l2jserver's configuration is the base of the idea. The rest is up to the person to create the infrastructure behind it. That was the main idea we had in mind with @UnAfraid when we did that config for l2jserver. We used such solution for nearly 10 years. The only thing that had to be done is that which is not part of the gameserver, basically creating tunnels for every proxy and source routing the data from there. This is why I keep telling you that you are wrong. You just have made a fancy program that ignores the necessary system configuration that must be done for a proper protection. It just creates the illusion of safety until an attacker comes.

Edited by Nik
Posted
12 minutes ago, Elfocrash said:

Again, what I mean by "proxy" and what you mean by "proxy" seems to not be the same. I call proxy the service I'm running that deals with a lot of stuff including the proxy support. 

So basically you call your service "proxy" and that service connects the gameserver and the remote VPSes, players connect to an IP that belongs to one of the VPSes and your service relocates all the traffic of the player from the VPS to the gameserver?

Posted (edited)

OOOOOOOOOOOOOOOOOOOOOOOOOOOHHHHHHHHHHHHHHHHHHHHH

So its just a higher level application that is trying to do stuff that can be done at lower level. I thought you had implemented it at a lower level. That would explain why you have no idea of what I talk about.

 

43 minutes ago, Elfocrash said:

Nop, you're wrong. I'm outsourcing the responsibility to it's own app, ignoring the 100% useless system config that is completely unnecessary to provide a proper and more robust protection from the punny tunnelin solution that you disturbed. This isn't 2008 any more. We can do better.

 

@UnAfraid we are not 2008 anymore, its time to drop your GRE tunnels and iptables rules and start using this solution!!!

Edited by Nik
Posted

By lower level I meant lower network level.

 

And yes, I tag team in order to show him something funny. We do really enjoy reading funny mxc stuff. The funniest part is that I try to explain where your mistakes are in your "protection", yet you think your solution is top notch and has no problems at all.

 

And yes, my "archaic" solution is 5 terminal commands per machine, yet you've managed to make a whole app to do similar thing, just much worse xD

 

Oh, and thanks for that disclaimer, its nice comedy.

4 hours ago, Elfocrash said:

Disclaimer, this is NOT your usual shitty tunnelling proxy that you setup on the machine level. This is a reverse proxy implementation purely done in software that acts like an elastic load balancer.

 

  • Haha 1
Posted (edited)

had hard time to find innovation here, your post could only contain 1 simple graph of packet life cycle and it would explain what stands behind it better :D

 

You skipped interesting part - how do you handle client side in your IP hopping? since TCP doesn't let you change established ends, i guess L2 client connection is never re-established in this case and stays connected all the time to some single point of contact (behind which you do all the fun stuff)? If so, it screams single point of failure, and i hardly would call it better solution than whats used now.

Edited by AlmostGood

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...