search

TCPShield / RealIP

The Spigot, Bungee and Velocity plugin that parses client IP addresses passed from the TCPShield network.
https://tcpshield.com
MIT License
145 stars 52 forks source link

Incompatiability with ViaVersion #50

Closed d2k11 closed 1 year ago

d2k11 commented 3 years ago

I run a 1.16 server. I use ViaVersion so that people connecting from older versions can connect to the server just fine.

However, the people connecting to my server using older versions of Minecraft (1.12 being the most common) don't get their real IP revealed, it just shows the IP of my proxy server.

Steps to reproduce:

  1. Set up a Paper or Spigot server with TCPShield, ViaVersion, and ViaBackwards installed.
  2. Connect to the server.
  3. See the proxy IP in console as opposed to the real IP.
szferguson commented 3 years ago

Hi,

Thanks for your report. We have tried with the steps indicated but have been unable to reproduce. Did you have ProtocolLib installed in your case? If so, could you also let me know the Java version used?

Thanks

d2k11 commented 3 years ago

Yes. ProtocolLib was installed, and Java is on Java 11.

Also note I am using TCPShield 2.4. 2.5 doesn't work with the reverse proxy I'm using yet. If you can reproduce this bug on 2.4 but not 2.5 I will close this issue.

d2k11 commented 3 years ago

Oops, accidentally closed the issue. Reopened :)

szferguson commented 3 years ago

Can you elaborate more on the incompatibility issues you described with your reverse proxy (on 2.5)?

d2k11 commented 3 years ago

I'm using Infrared reverse proxy. 2.5 broke Infrared since Infrared sends the payload that was correct in 2.4 but is no longer accepted in 2.5 because of the new payload validation; I'm waiting for it to update.

trev-sharp commented 3 years ago

I'm using Infrared reverse proxy. 2.5 broke Infrared since Infrared sends the payload that was correct in 2.4 but is no longer accepted in 2.5 because of the new payload validation; I'm waiting for it to update.

Hi, I am another contributor to this. I am not sure what you mean by this, the payload data was the same throughout 2.4 and 2.5, it's just 2.4 ignored some of the validation sections in the payload. Are you able to send debug information showing what payload data is received, or if it's another error entirely. If we get 2.5 working for you, then your original issue should be fixed. Thanks

d2k11 commented 3 years ago

https://github.com/haveachin/infrared/issues/71

This is the issue as marked by Infrared. It points out specific lines of code & errors that I helped to debug (I worked with the original poster in diagnosing the error).

trev-sharp commented 3 years ago

haveachin/infrared#71

This is the issue as marked by Infrared. It points out specific lines of code & errors that I helped to debug (I worked with the original poster in diagnosing the error).

Thanks for the insight, I'm still a little confused on how Infrared causes the signature to be removed completely, and preserve every other section (at least it isn't outlined in the issue). As I see, this issue would have occurred on versions 2.3 and lower as well; this isn't a "new" bug from this specific version. I'll be happy to work on this issue once I get more information on the Infrared side of things.

d2k11 commented 3 years ago

Infrared sent the payload without the signature, which worked in 2.4. It seems that in 2.5 it's looking for 4 payload arguments (the original 3 + the signature) and when Infrared only sends the original 3 arguments (without the signature) RealIP ignores the request since there is no validation signature.

trev-sharp commented 3 years ago

Infrared sent the payload without the signature, which worked in 2.4. It seems that in 2.5 it's looking for 4 payload arguments (the original 3 + the signature) and when Infrared only sends the original 3 arguments (without the signature) RealIP ignores the request since there is no validation signature.

Yeah, but I'm referring to why Infrared removes the signature argument at the end, this could be fixed with slight tweaking on TCPShield's end if its something simple.

d2k11 commented 3 years ago

I don't believe the signature argument was present (or required/enforced) in 2.4.

trev-sharp commented 3 years ago

I don't believe the signature argument was present (or required/enforced) in 2.4.

It was present, just ignored along with the timestamp verification. The current verification system was used in older versions (discluding the IP whitelisting with CIDR). 2.4 looked for only 2 sections which allowed this issue to fly under the radar. But I still don't know why Infrared removes the end of the payload.

haveachin commented 3 years ago

Infrared doesn't remove the signature. The feature @gcurtiss is talking about upgrades the handshake packet to mimic what TCPShield would send. This enables the preservation of IP addresses like HAProxy protocol does without needing BungeeCord or other HAProxy solutions.

Here is the function that upgrades the handshake.

trev-sharp commented 3 years ago

Infrared doesn't remove the signature. The feature @gcurtiss is talking about upgrades the handshake packet to mimic what TCPShield would send. This enables the preservation of IP addresses like HAProxy protocol does without needing BungeeCord or other HAProxy solutions.

Here is the function that upgrades the handshake.

That makes way more sense now, thanks for clearing that up 👍🏻. So I guess the solution is to turn that option off since IP manipulation is already handled by TCPShield.

realDragonium commented 3 years ago

That makes way more sense now, thanks for clearing that up 👍🏻. So I guess the solution is to turn that option off since IP manipulation is already handled by TCPShield.

There is a slight problem here, TCPShield the service isnt being used. This is the only way it makes sense what is happening would be if @gcurtiss refer to RealIP as TCPShield if i look at the first message:

... server with TCPShield ... installed.

Its possible to have a client connection: client -> tcpshield -> infrared -> backend there is only an issue with the status of an server since the cname record is different from the domain being send by tcpshield. Which could be solved by adding a second config to you infrared which has the domain name of the domain and also point that to your server. It doesnt matter or the "realIP" config value is turned on or off. (this is perhaps a different issue at the TCPShield backend, status requests are being send to the target ip with the player address address being 127.0.0.1:25565 and the domain being the registered domain and not the cname subdomain which is being used as server address. )

If you try to connected with a server which has RealIP 2.5 and you try to join with client -> infrared -> backend you will get this issue of missing a signature, which easily can be solved by making the tcpshield-ips.list file and putting in there the cidr of the proxy server(s). This doesnt work but it should...?