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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4452 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20191208/54fe0a12/attachment.bin>