Forums Archived

This forum has been archived. No new posts can be made and no new users can sign up. It remains here for reference only.

Find the new forums here

  • Add a new option for enabling UsingReverseProxy in New Instance Defaults

Add a new option for enabling UsingReverseProxy in New Instance Defaults

  • 304 Views
  • Last Post 28 October 2019
  • Topic Is Solved
AbhorrentJoel posted this 28 October 2019

It might be helpful to provide a toggle for UsingReverseProxy in New Instance Defaults so that those with reverse proxy setup in Nginx (or maybe Apache2) for instances other than the main ADS can automatically have the option set upon creation. Furthermore, it may worth making replicating the option from the ADS by default - if it is enabled on the ADS, the New Instance Default for UsingReverseProxy should be true.

I have every instance accessible only through the reverse proxy, so this could certainly make setting new instances up that little bit faster.

amp reverse-proxy
Order By: Standard | Newest | Votes
Mike posted this 28 October 2019

That's a bad way to set things up, ADS itself should talk directly to the instances without a reverse proxy and the instances should be firewalled out/locally bound. Only ADS would then need to know about the proxy.

AbhorrentJoel posted this 28 October 2019

I think perhaps I misunderstood the use of the option in this case then. If I enabled the UsingReverseProxy option on the instances, would would actually change?

At this moment of time, I have UsingReverseProxy enabled on the main ADS and on none of the instances. None of the instances nor the main ADS is allowed through the firewall to be accessible remotely. The reverse proxy is set up on port 443 with Nginx where the "/" location proxies to the ADS (localhost:8080), and let's say Minecraft instance is running on localhost:8081 and location "/Minecraft01/" proxies to that.

In short, as an example:

An example with the Nginx reverse proxy config:

location / {
    proxy_pass              http://localhost:8080;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version      1.1;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";

    proxy_redirect          off;
    proxy_buffering         off;
    client_max_body_size    10240M;
}

location /Minecraft01/ {
    proxy_pass              http://localhost:8081/;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version      1.1;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";

    proxy_redirect          off;
    proxy_buffering         off;
    client_max_body_size    10240M;
}

Are there any fundemental issues with this setup?

Cheers

Mike posted this 28 October 2019

Yeah, you shouldn't try and access the instances directly. You should access them via ADS and managing them.

The design of the ideal setup is that only ever one instance is exposed to the outside world, that being ADS. ADS goes behind a reverse proxy to provide SSL - and then ADS takes care of providing access to individual instances.

AbhorrentJoel posted this 28 October 2019

Alright, that I can understand. I thought there was something a bit funny about the individual instances themselves not being reverse proxied by default. Although this just raises more questions if you could please review and answer:

  • In the case of unmanaged instances (where they cannot be accessed via ADS):
    • Is the above setup advisable? I could not see any other way since it is independent of the ADS.
  • In the cases of managed instances:
    • What if I want to create local users on a per-instance basis? This is because global users (created on the ADS) can see all instances (which is not good in my opinion) when they login and can also see user activity on the ADS in the notifications.
    • If I have created a local user, they cannot login to the ADS so they need to access to the instance directly - how can they otherwise access the panel?

I am not disregarding what you are saying, I am just trying to understand how it should be setup under certain circumstances. Your advice would certainly be appreciated.

Mike posted this 28 October 2019

Unmanaged instances shouldn't be used, support for them is going to be removed from ADS at some point.

If you want to create instance specific users, simply log into that user directly. Right now the URLs for single instances is a little messy - but that is going to be improved soon. You can find it by getting the iframe URL from an instance that is being managed.

In the future it'll be done via subdomains/subdirectories.

AbhorrentJoel posted this 28 October 2019

So going the iframe reveals an address like https://example.com/?remote=[InstanceID] (where InstanceID is replaced with the actual Instance ID) but going to this address just takes me to the ADS login so logging into it won't do anything (since the user is only on the local instance).

I would imagine your method is correct, and my initial thoughts were that the parameters after the domain are not passed through the proxy to the ADS. But now I am not sure about this because giving it different parameters (such as typing random characters) seems to lead to a blank page.

Anyway, if I try to go to https://example.com/?remote=[InstanceID] it does not seem to bring me to the specific instance page but rather the page for the ADS, and logging in just says "No access to specified instance". The console for the ADS just says "Authentication failure for user testuser from 127.0.0.1 - User is locked to instance [InstanceID]"

I think I need to have a little play and see whether the parameters are being passed properly, and perhaps even open the ports through iptables and allow only my IP address to see if the proxy is messing with anything. In the meantime, can you shine some light on this issue?

By the way, I do like the idea of this being done through subdomains/subdirectories in the future.

Live Chat Register to post
Categories
Search
Popular Tags
This Weeks High Earners
Hot Topics
Close