Jump to content

Running multiple servers on different subdomains but same IP


notla49285

Recommended Posts

notla49285

As per the title, I currently have my server running via a domain, which is linked to a DNS service, which leads to my network, gets forwarded to the appropriate port and internal IP, and all is good.

 

I have just bought a Synology DS918+ and, after issues with my old router (in another thread), a Synology RT2600ac. I'm looking at comparing running the server from the current PC and also from the NAS to see if it's viable to move it over to the NAS, however I don't seem to be able to differentiate which server the incoming traffic goes into. I can't get the DNS to direct to a specific port, so how do I get my router to check which traffic is intended for the current Emby server, and which goes to the new (test) one?

 

So essentially what I'm after is:

 

https://mycurrentserver.mydomain.com --> DNS --> External IP : Current server port --> Router --> Port Forward --> Current server

 

and

 

https://mytestserver.mydomain.com --> DNS --> External IP : Test server port --> Router --> Port Forward --> Test server

Edited by notla49285
Link to comment
Share on other sites

notla49285

A reverse proxy on your DS918+ its probably the best solution.

 

Ok I'll give up then as I've looked into reverse proxies before and had absolutely no idea what I was looking at, and the guides didn't match the tools downloaded.

Link to comment
Share on other sites

darkassassin07

In your case especially since this is intended to be temporary it would be easier to set each server on a different port. Then just specify, in the url you use to connect, which port you want to connect to.

 

Example:

Server A on port 8096

Server B on port 8097

 

Connect to server A with

Http://example.domain:8096

And B with

Http://example.domain:8097

 

 

 

 

A reverse proxy will just allow you to use a single port and specify which server to forward that to with a sub domain:

http://servera.example.domain

 

 

Btw the dns service doesn't supply the port number, only the IP of your network. http uses port 80 by default, https is 443, but you can override that by adding :<port> to the url as shown above.

Edited by darkassassin07
Link to comment
Share on other sites

notla49285

 

Thanks for the link, but that hasn't worked. It would help if all the screenshots weren't in French for one thing, especially as the guide is in English...

 

I don't know how the hell they can use this without enabling "Allow remote connections" in Emby's settings, but the moment I switched this off I got kicked out everywhere. Also my reverse proxy is going haywire and sending me to the wrong IPs internally, will post what I've done shortly.

Link to comment
Share on other sites

darkassassin07

Im pretty sure if your proxy passes the X-Forwarded-For header to emby with the actual ip of the client, emby will see that as an external connection (assuming that client ip is external). Otherwise, as far as emby is concerned, the client connection is coming from the proxy ip which, if on the same network, is a lan connection. Thus, no 'allow remote connections' needed.

 

Problem with that is any traffic from outside your network (ie anything that goes through the proxy) will show up as the ip of the proxy and have no indication what that actual client ip is in embys logs/reporting systems. (they should still be in the proxys logs though)

 

 

I have my emby server setup to allow remote connections, however the only way to reach it from wan is via cloudflare(secured with ssl client certs from cf to nginx) > my wan ip > nginx > then to emby. Emby receives the original client ip via the X-Forwarded-For header, however nginx logs it as well, and those logs are what I tend to pay attention to.

Edited by darkassassin07
Link to comment
Share on other sites

mastrmind11

this ^^

 

but also, simply specifying different ports on each server will work too, esp if this is a temporary setup.

Link to comment
Share on other sites

notla49285

Good job I saved my massive post or I'd be pretty pissed right now, I pressed reply and got redirected here and the post disappeared which judging by previous behaviour on this site I was expecting.

 

It won't let me add pictures to my post, I don't have time to retype it with text only at the moment, will post later.

Edited by notla49285
Link to comment
Share on other sites

notla49285

Here is what I was supposed to post:

 

I've been following this guide >> https://www.grahamleggat.com/blog/2017/8/21/synology-reverse-proxy-server

 

I have a domain with Namecheap, for the purposes of this guide I'll change names, the domain will be called mydomain.com. I have a naming convention for the devices on my home network, which for this example I'll change to X-Men. I removed all port forwarding and DNS settings in the router (Synology RT2600ac) and NAS (Synology DS918+) before starting this.

Test Emby server (NAS): Xavier
Current Emby server (desktop PC): Magneto
Network: XMansion

Firstly, here are the settings for my domain:

CNAME Record | emby | xmansion-xavier.synology.me
CNAME Record | emby-xavier | xmansion-xavier.synology.me
URL Redirect | emby | https://emby.mydomain.com
URL Redirect | emby-xavier | https://emby-xavier.mydomain.com

1. [NAS] Signed up for the free DDNS from the NAS, called xmansion-xavier.synology.me.

2. [Domain] Added the "emby" CNAME and redirect record as above.

3. [Router] Forwarded port 443 in my router to the internal static IP of my NAS. I have not allowed any other ports.

4. [NAS] Created a Let's Encrypt certificate for the NAS itself as per the above guide, for xmansion-xavier.synology.me, which went through fine.

5. [NAS] In Control Panel > Application Portal > Reverse Proxy, I added the following:

Description: Emby
Source Protocol: HTTPS
Source Hostname: emby.mydomain.com
Source Port: 443
Enable HSTS: Yes
Enable HTTP/2: Yes
Enable access control: No
Destination Protocol: HTTPS
Destination Hostname: 192.168.1.39
Destination Port: 49153

6. [Domain] Created a SSL certificate for emby.mydomain.com (certificate.crt, private.key, ca_bundle.crt) and then created a password-protected version (certificate.pfx) to load into Emby.

7. [NAS] Added the above SSL certificate to Control Panel > Security > Certificate.

8. [Emby] Added the above SSL certificate and password in Advanced Settings.

9. [NAS] In Control Panel > Security > Certificate, clicked Configure, then associated the above SSL certificate with the "Emby" reverse proxy.

-- The above setup seemed to work, however I've discovered this afternoon that it only works on a web browser when visiting https://emby.mydomain.com, and not with the Android app (it just can't find my server at all) --

10. [Domain] Added the "emby-xavier" CNAME and redirect records as above.

11. [NAS] In Control Panel > Application Portal > Reverse Proxy, I added the following:

Description: Emby-Xavier
Source Protocol: HTTPS
Source Hostname: emby-xavier.mydomain.com
Source Port: 443
Enable HSTS: Yes
Enable HTTP/2: Yes
Enable access control: No
Destination Protocol: HTTPS
Destination Hostname: localhost
Destination Port: 59153

12. [Domain] Created a SSL certificate for emby-xavier.mydomain.com (certificate.crt, private.key, ca_bundle.crt) and then created a password-protected version (certificate.pfx) to load into Emby.

13. [NAS] Added the above SSL certificate to Control Panel > Security > Certificate.

14. [Emby] Added the above SSL certificate and password in Advanced Settings.

15. [NAS] In Control Panel > Security > Certificate, clicked Configure, then associated the above SSL certificate with the "Emby-Xavier" reverse proxy.

The end result is:

  •     Nothing works on the Android app at all (I'm signing in via Emby Connect, it's listing the servers registered to me - Magneto and Xavier - but neither of them can be found).
  •     https://emby.mydomain.com will work properly in a web browser and I can connect to the Magneto server with no problems and the SSL certificate is fine.
  •     https://emby-xavier.mydomain.com returns an SSL error because of a mismatching certificate, and I get forwarded to the Magneto server, instead of the Xavier server.
Edited by notla49285
Link to comment
Share on other sites

darkassassin07

"Destination Protocol: HTTPS

Destination Hostname: 192.168.1.39

Destination Port: 49153

"

 

One issue I see, is you are using https between the emby server and the proxy, but are using an ip address for that connection. Without a valid hostname thats listed on the cert, that connection will be insecure and tbh shouldn't be letting you connect at all.

 

The proxy is what is handling the ssl connection between it and the client, it's not necessary to secure the link from proxy>backend when they are on the same trusted network.

  • Like 1
Link to comment
Share on other sites

notla49285

"Destination Protocol: HTTPS

Destination Hostname: 192.168.1.39

Destination Port: 49153

"

 

One issue I see, is you are using https between the emby server and the proxy, but are using an ip address for that connection. Without a valid hostname thats listed on the cert, that connection will be insecure and tbh shouldn't be letting you connect at all.

 

The proxy is what is handling the ssl connection between it and the client, it's not necessary to secure the link from proxy>backend when they are on the same trusted network.

 

I did wonder about that later on so I've now changed it to HTTP on the local connection (proxy -> Emby server). It's made no difference to the URL going to the wrong server, but I'll wait a while and try it later.

 

I did fix the Android issue - Android is connecting via Emby Connect, the Magneto Emby server was telling Emby Connect to come in on port 49153, which my router was then rejecting (as it's only allowing 443). The URL worked because that was coming in on 443 and getting directed appropriately. So I set the external HTTPS port to 443 in Emby advanced settings, public HTTP is 8096 but it makes no difference because all connections are redirected to 443, internal HTTPS again doesn't matter [Edit: see note] because I'm connecting via HTTP, so internal HTTP is set to 8096, which is what the proxy is now forwarding to.

 

I don't know whether changing the public HTTPS ports on both Magneto and Xavier will make any difference to the incorrect redirect, I'll try it again in about an hour and in the morning.

 

Note: Internal HTTPS port does matter, I had set this as 443, same as external port, and I'm not sure what the exact routing was but it seemed to get caught up in a loop and both internal and external connections broke/timed out. I reset this back to 8920 and left the external as 443 and this fixed the issue.

Edited by notla49285
Link to comment
Share on other sites

darkassassin07

Both your public https ports should be 443, and each of your sub-domains should re-direct to the local http port of each server via the proxy. (local ports are the port the software is actually using on its local machine, public ports are what emby connect + the apps use to reach those local ports from wan)

 

 

If both your sub-domains are landing at the same server, you have an issue with the proxy config itself and where its redirecting. I'm not familiar with the particular proxy your using so I'll leave that to someone with a bit more knowledge.

Edited by darkassassin07
Link to comment
Share on other sites

notla49285

Both your public https ports should be 443, and each of your sub-domains should re-direct to the local http port of each server via the proxy. (local ports are the port the software is actually using on its local machine, public ports are what emby connect + the apps use to reach those local ports from wan)

 

This is how they are both now set. I now have a bizarre problem, if I'm outside of my home network and attempt to visit emby-xavier.mydomain.com, it goes nowhere, doesn't even timeout it just hangs. When visiting the same URL on my local network, I get redirected to port 8001, which is the internal HTTPS port of the router management console :huh: dafuq?? Will try again in the morning. Edit: This is still the same this morning. I've tried changing the target in the reverse proxy from localhost to the actual static internal IP of the NAS and this hasn't worked either. Firefox is returning the error "The page isn't redirecting properly"

 

Anybody got any experience with the built-in reverse proxy on Synology DS models?

Edited by notla49285
Link to comment
Share on other sites

notla49285

Now both Magneto and Xavier are broken and I'm getting the "The page isn't redirecting properly" error for both.

 

I'm getting tired of this now, I hate reverse proxies.

Edited by notla49285
Link to comment
Share on other sites

notla49285

Ok so basically this isn't possible on Synology NAS, I don't know what the hell is going on but the system is unusable and I'm sick and tired of it. I've just reverted to getting my router to redirect straight to my current Emby server rather than messing with this reverse proxy nonsense.

Link to comment
Share on other sites

darkassassin07

I haven't used a synology nas myself, but from a little bit of looking around I did find this guide from late 2017 that appears to be fairly accurate compared to what I know of my nginx setup:

 

https://www.grahamleggat.com/blog/2017/8/21/synology-reverse-proxy-server

 

 

Specifically at this step where you are setting up the reverse proxy rules:

Reverse+Proxy.png?format=1000w

 

For the current server running on a machine separate from the nas:

 

Source:

Protocol - https

Hostname - currentserver.mydomain.com

Port - 443

 

Destination:

Protocol - http

Hostname - <current-server-lan-ip>

Port - 8096

 

 

For the emby server thats running on the nas:

 

Source:

Protocol - https

Hostname - nasserver.mydomain.com

Port - 443

 

Destination:

Protocol - http

Hostname - localhost (you can also use the nas lan ip here)

Port - 8096

 

 

Both emby servers configurations should be set to:

Local http port - 8096

Public https port - 443

External domain - <source hostname from above>

Secure connection mode - handled by reverse proxy

 

And each server should be reachable from lan using http://<lan-ip-of-server>:8096

As well as once this whole setup is working correctly https://<server>.mydomain.com

 

Be sure that your domain names are correctly returning either your wan ip or your nas lan ip (only while on lan ofc) and that incoming port 443 on your internet connection is forwarded to 443 of the nas lan ip.

 

As far as I can tell that should all lead to a working setup, but again I have never actually been infront of the synology interface myself.

 

If that still doesn't work we could consider writing a custom nginx site config and dropping it in /usr/local/etc/nginx/sites-enabled acording to a comment here: https://forum.synology.com/enu/viewtopic.php?t=141343

 

 

 

 

 

 

 

 

 

 

/edit fail.... I just noticed the guide I posted is the same one you posted above. If this comment doesn't turn out to be usefull, let me know and I'll post an example manual nginx config.

Edited by darkassassin07
Link to comment
Share on other sites

notla49285

I think I've found the issue here: I didn't have the secure connection mode set to reverse proxy. I changed both Emby servers back to 8096/443/their own domains/reverse proxy, redirected the router again, re-added the reverse proxies to the NAS and rebooted the NAS.

 

Magneto (existing server) is now running fine via the reverse proxy, however I've tried to test Xavier (new test server) and the Emby package is refusing to start. Like SERIOUSLY, I didn't think much else could go wrong that I haven't seen before...

 

So now I'm going to presume the reverse proxy is working and it's now Emby that's broken :angry:

Link to comment
Share on other sites

darkassassin07

Please post the log file from the server thats failing to start.

 

With no other info I would guess miss-config leading to port conflict. If the proxy is using 8096 on the nas when it shouldn't be, emby cant bind to that port and start. But I'd need the log to confirm that.

 

(I'm heading to bed, probably wont reply again till tomorrow)

Link to comment
Share on other sites

notla49285

Please post the log file from the server thats failing to start.

 

I've spent the past 20 minutes trying to find it, still nothing. When clicking Run, the Emby package appears on my dashboard/homescreen and in the package centre it says "Starting..." then after a few seconds it stops and disappears from my dashboard again.

 

Only way I can see of accessing files on my server is via File Station or by navigating to the network share, neither of which show the embysvr folder. I can find the embysvr user in Control Panel and that's the closest I've got. Short of running command line (which I think requires SSH, something else I have no idea about), I don't know what to do.

Edited by notla49285
Link to comment
Share on other sites

darkassassin07

Well, I do see the startup at 18:51 in the first log file. It gets as far as loading the opensubtitles.dll then it just abruptly ends with no errors.

 

@@Luke @@Happy2Play do you guys have any advice here?

Edited by darkassassin07
Link to comment
Share on other sites

darkassassin07

Note: Internal HTTPS port does matter, I had set this as 443, same as external port, and I'm not sure what the exact routing was but it seemed to get caught up in a loop and both internal and external connections broke/timed out. I reset this back to 8920 and left the external as 443 and this fixed the issue.

I just noticed this while re-reading the thread. If you set the local https port of the emby server thats on the nas to 443, emby will not be able to start as the reverse proxy is already bound to that port.

 

 

If you can track down /emby-server/programdata/config/system.xml (thats the location on my windows server anyway)

And fix the lines:

<HttpServerPortNumber>8096</HttpServerPortNumber>

<HttpsPortNumber>8920</HttpsPortNumber>

 

I would think emby will start again. Though I'm still just assuming the issue is port conflict and not something else.

 

 

 

 

The https port you set will determine what port emby will bind to when it starts, but once actually setup and running, you will only be accessing emby via the http port.

Edited by darkassassin07
Link to comment
Share on other sites

notla49285

I just noticed this while re-reading the thread. If you set the local https port of the emby server thats on the nas to 443, emby will not be able to start as the reverse proxy is already bound to that port.

 

 

If you can track down /emby-server/programdata/config/system.xml (thats the location on my windows server anyway)

And fix the lines:

<HttpServerPortNumber>8096</HttpServerPortNumber>

<HttpsPortNumber>8920</HttpsPortNumber>

 

I would think emby will start again. Though I'm still just assuming the issue is port conflict and not something else.

 

 

 

 

The https port you set will determine what port emby will bind to when it starts, but once actually setup and running, you will only be accessing emby via the http port.

 

Nailed it! Mostly. I found the system.xml file using SSH terminal and copied it somewhere accessible, deleted the original, changed my copy and attempted to put it back, but it kept refusing to copy due to permissions. I used sudo but then Emby didn't have read permissions as it belonged to root so I deleted it again. Not thinking, I started Emby up without the system.xml file, which meant that I got taken through the setup process again, however my libraries, users and permissions were already there, I just needed to reconfigure remote access and the certificate.

 

Both reverse proxies are now pointing to the respective servers, depending on the URL used to access them. Thank you for your help @@darkassassin07, at some point I'll write a full guide on how to do this as it's very confusing, but I need a rest.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...