Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatiability with ViaVersion #50

Closed
d2k11 opened this issue May 15, 2021 · 15 comments
Closed

Incompatiability with ViaVersion #50

d2k11 opened this issue May 15, 2021 · 15 comments

Comments

@d2k11
Copy link

d2k11 commented May 15, 2021

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
Copy link
Member

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
Copy link
Author

d2k11 commented May 17, 2021

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 d2k11 closed this as completed May 17, 2021
@d2k11 d2k11 reopened this May 17, 2021
@d2k11
Copy link
Author

d2k11 commented May 17, 2021

Oops, accidentally closed the issue. Reopened :)

@szferguson
Copy link
Member

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

@d2k11
Copy link
Author

d2k11 commented May 19, 2021

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
Copy link
Contributor

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
Copy link
Author

d2k11 commented May 19, 2021

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).

@trev-sharp
Copy link
Contributor

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
Copy link
Author

d2k11 commented May 19, 2021

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
Copy link
Contributor

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
Copy link
Author

d2k11 commented May 19, 2021

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

@trev-sharp
Copy link
Contributor

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
Copy link

haveachin commented May 21, 2021

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
Copy link
Contributor

trev-sharp commented May 21, 2021

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
Copy link

realDragonium commented Jun 13, 2021

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...?

@d2k11 d2k11 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants