'Lost' the default config location

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

'Lost' the default config location

LilFag
Noob here , so please bear with me.  I have a reverse proxy working so if I
https://mysite.com/footyscore the page will launch. However if I browse to
http or https://mysite.com the default welcome to nginx page loads. I want
to change this (change the root) so that my roundcube webmail will launch.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286385,286385#msg-286385

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: 'Lost' the default config location

Francis Daly
On Tue, Dec 03, 2019 at 05:28:32AM -0500, chewiesw wrote:

Hi there,

> Noob here , so please bear with me.  I have a reverse proxy working so if I
> https://mysite.com/footyscore the page will launch. However if I browse to
> http or https://mysite.com the default welcome to nginx page loads. I want
> to change this (change the root) so that my roundcube webmail will launch.

It might be that just adding

  location = / { return 301 /footyscore/; }

to your config will work -- that should cause any request to
https://mysite.com/ to be invited to make a new request for
https://mysite.com/footyscore/, which should then work as it currently
does.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Controlling Access on and off LAN

Rhys Ferris

Hello everyone,

Hopefully this is a simple question with a simple answer.

First my actual goal:

I'm hosting one server: domain.net which at domain.net serves a basic homepage and uses iframes to proxy several other services, which are defined in location blocks: domain.net/service.

I want to allow all IPs to access domain.net and the services proxied inside of it. However I want to restrict direct access to domain.net/service from outside my LAN.

What I've got so far:

I've set up my location blocks for my services to begin with:
allow 192.168.x.x/25;
deny all;
which very effectively blocks access from outside my LAN. However it still blocks the services when proxied from within domain.net, I think because I am using "proxy_set_header X-Real-IP $remote_addr;" so the proxied request is arriving at the location block with an external IP. I looked but could not find documentation on the proxy_set_header X-Real-IP statement (I even ventured to page 2 of google :-P) to try to get it to proxy the request as if my server running nginx had made the request.

What I would like from y'all:

  1. If there is a better way to achieve my goal, please tell me. I don't have my heart set on this, its just all I could figure.
  2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake the internal IP? or is that even the correct header to be using?

Thanks very much for your time,
Rhys Ferris

Sample location block:

        location /service/ {
            allow 192.168.136.128/25;
            deny all;
            proxy_pass http://prometheus:1234/service/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

-- 
Sent from Thunderbird on Ubuntu 19.10

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Access on and off LAN

Francis Daly
On Fri, Dec 06, 2019 at 10:14:12PM -1000, Rhys Ferris wrote:

Hi there,

> I'm hosting one server: domain.net which at domain.net serves a basic
> homepage and uses iframes to proxy several other services, which are
> defined in location blocks: domain.net/service.
>
> I want to allow all IPs to access domain.net and the services proxied
> inside of it. However I want to restrict direct access to
> domain.net/service from outside my LAN.

Reading that, and reading the config, I'm afraid that I'm not sure what
you are trying to achieve.

Note that "iframe" and "proxy" are unrelated concepts; it is possible
that that might change the understanding of the requirement.

My first guess is that you want to allow anyone to access
domain.net/service; and you want LAN-users to be able to access
prometheus:1234/service; and you want off-LAN users to not be able to
access prometheus:1234/service directly.

Is that it?

>  1. If there is a better way to achieve my goal, please tell me. I don't
>     have my heart set on this, its just all I could figure.

As above -- I'm not sure what the goal is, so I can't offer a suggestion.

>  2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake
>     the internal IP? or is that even the correct header to be using?

I suspect that that's also part of the goal; I'm unclear on what the aim
there is either.

Possibly your whole question is clear to others; in which case they will
be able to respond in due time.

But in case it's not, it may be helpful for others if you can describe
your goal in other words.

Thanks,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Access on and off LAN

Rhys Ferris
Thanks for the reply. I'll try to do better:

I have domain.net which is a gateway to all my services. It has buttons
on the side for them all and then loads them in an iframe under the url
domain.net/#Service. The services themselves are proxied by nginx at
domain.net/service. This is Organizr if you've heard of it
(https://github.com/causefx/Organizr).

I want to force IPs outside of my LAN to access everything through
domain.net as it has a logon to use any of the services. I only want
direct access to domain.net/service available to my LAN.

One more way of looking at it. When a user uses the organizr front end
and uses a services, they get some menu bars hosted by nginx as well as
an iframe containing domain.net/service, but it is served through
domain.net/#Service.

When I block external IPs from domain.net/service, the iframe inside of
domain.net/#Service also gets blocked.

As I think through this it occurs to me I don't think the config change
needs to be in nginx, but in organizr. I need organizr to request to
content from a local IP. Not sure if that is possible, but I'll hit them
up. Thanks for helping me work through it.

On 12/8/19 3:50 AM, Francis Daly wrote:

> On Fri, Dec 06, 2019 at 10:14:12PM -1000, Rhys Ferris wrote:
>
> Hi there,
>
>> I'm hosting one server: domain.net which at domain.net serves a basic
>> homepage and uses iframes to proxy several other services, which are
>> defined in location blocks: domain.net/service.
>>
>> I want to allow all IPs to access domain.net and the services proxied
>> inside of it. However I want to restrict direct access to
>> domain.net/service from outside my LAN.
> Reading that, and reading the config, I'm afraid that I'm not sure what
> you are trying to achieve.
>
> Note that "iframe" and "proxy" are unrelated concepts; it is possible
> that that might change the understanding of the requirement.
>
> My first guess is that you want to allow anyone to access
> domain.net/service; and you want LAN-users to be able to access
> prometheus:1234/service; and you want off-LAN users to not be able to
> access prometheus:1234/service directly.
>
> Is that it?
>
>>  1. If there is a better way to achieve my goal, please tell me. I don't
>>     have my heart set on this, its just all I could figure.
> As above -- I'm not sure what the goal is, so I can't offer a suggestion.
>
>>  2. How do I use the proxy_set_header X-Real-IP $remote_addr; to fake
>>     the internal IP? or is that even the correct header to be using?
> I suspect that that's also part of the goal; I'm unclear on what the aim
> there is either.
>
> Possibly your whole question is clear to others; in which case they will
> be able to respond in due time.
>
> But in case it's not, it may be helpful for others if you can describe
> your goal in other words.
>
> Thanks,
>
> f
--
Sent from Thunderbird on Ubuntu 19.04



_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Access on and off LAN

Ian Hobson-3
In reply to this post by Rhys Ferris
On 07/12/2019 08:14, Rhys Ferris wrote:
 >
 >         Hello everyone,
 >
 > Hopefully this is a simple question with a simple answer.
 >
 >
 >         First my actual goal:
 >
 > I'm hosting one server: domain.net which at domain.net serves a basic
 > homepage and uses iframes to proxy several other services, which are
 > defined in location blocks: domain.net/service.
 >
 > I want to allow all IPs to access domain.net and the services proxied
 > inside of it. However I want to restrict direct access to
 > domain.net/service from outside my LAN.
 >

Not 100% clear on your requirements, but I would approach it like this.

a) Mount the /service server on a new port - say 8080
b) Mount a dummy server on another port that always returns 404;

   server dummy {
      listen 9090;
      location / {
        return 404;
      }
   }

c) Firewall off the 8080 port at the LAN firewall, so it cannot be
reached from outside, only by proxy_pass from nginx.
d) In the Iframe, request /services from port 80 as usual.
e) Use map to map valid referer valued to 8080 and
invalid ones to the dummy port

map $http_referer $port {
    default 9090
    ~*($http_referer) 8080;
}

f) Proxy_pass to the port

location /service/ {
         # setup other proxied headers if needed
         proxy_pass https://192.168.0.??:$port;
         return 404;
     }

Code untested. The other methods I though of used if, which is slow.

Note - some browsers may not send refer headers and will get 404s. If
this is a problem, set up advice on your 404 page.  Faking referer is
easy but pointless here.

Regards

Ian
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Access on and off LAN

Francis Daly
In reply to this post by Rhys Ferris
On Sun, Dec 08, 2019 at 02:29:57PM -1000, Rhys Ferris wrote:

Hi there,

thanks for the extra description.

> I have domain.net which is a gateway to all my services. It has buttons
> on the side for them all and then loads them in an iframe under the url
> domain.net/#Service. The services themselves are proxied by nginx at
> domain.net/service. This is Organizr if you've heard of it
> (https://github.com/causefx/Organizr).
>
> I want to force IPs outside of my LAN to access everything through
> domain.net as it has a logon to use any of the services. I only want
> direct access to domain.net/service available to my LAN.

I think I'm still not understanding the intended data flow.

It does sound like the /#Service is purely a cosmetic "overlay" on
/service, and it is still the end client that actually access /service
either way -- but in that case /#Service would be pointless, and its
login controls would be ineffective.

So I guess I am missing something.

> One more way of looking at it. When a user uses the organizr front end
> and uses a services, they get some menu bars hosted by nginx as well as
> an iframe containing domain.net/service, but it is served through
> domain.net/#Service.

"iframe" is irrelevant to nginx.

"/#Service" is irrelevant to nginx.

If the end client directly accesses /service, that is the request that
nginx will see.

The only alternative would be if the client accesses Organizr through
some url, and Organizr accesses /service on the client's behalf; in
that case, nginx will see the request to /service from Organizr, and
so nginx could block any other access to /service. (And should do so,
if Organizr is doing some form of access control.)

> When I block external IPs from domain.net/service, the iframe inside of
> domain.net/#Service also gets blocked.

I wonder, if you want to investigate this further...

without the IP block, when you use the web application normally, do
nginx logs show the requests to /service coming from the same client IP
address as the original request to /; or are they coming from a separate
Organizr address?

If you are doing any kind of "real-ip" conversion in that nginx instance,
turn it off for this logging.

> As I think through this it occurs to me I don't think the config change
> needs to be in nginx, but in organizr. I need organizr to request to
> content from a local IP. Not sure if that is possible, but I'll hit them
> up. Thanks for helping me work through it.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx