Hi Francis. Thanks a ton for your suggestions.
On Sun, Apr 9, 2017 at 5:58 PM, Francis Daly <[email protected]> wrote: > On Sun, Apr 09, 2017 at 05:27:31PM +0530, Ajay Garg wrote: > > Hi there, > > > Unfortunately, our backen-service(s) (on port 2000 in the example) is > > ssh-reverse-tunnel, having two layers of machines behind them. The > > terminating-node for sure cannot be changed. > > "In general", reverse-proxying to a different part of the url hierarchy > needs back-end support. In the specific case of your system, maybe it > does not need anything special. Only you can tell. > > > Looking at your explanations, I guess then we will have to open a port > for > > every service. > > So, for example, port 2001 for proxying to service running on ssh-tunnel > at > > 2000, > > You could. > > Or, you could have nginx listening on public:2000 and proxy_pass'ing > to local:2000, so you don't have to remember the public/private port > mappings. > > Or you could have nginx listening on one port, and have multiple server{} > blocks, so that userA connects to A.example.com which proxy_pass'es > to local:2000; and userB connects to B.example.com which proxy_pass'es > to local:2002. > I doubt I would be allowed to do this, since we would be using a fixed IP (instead of the costly multiple DNS-addresses). > > Or, you could (potentially) have nginx listening on one port, with one > server{} block, where anyone who authenticates as userA is proxy_pass'ed > to local:2000 and anyone who authenticates as userB is proxy_pass'ed > to local:2002. > I would be very much interested if this case is possible. Kindly let know how to do the proxy-routing based upon credentials. This will really solve our last core issue (opening multiple ports), while preserving all the feature-sets. So, will be grateful to hear back from you on how to implement this :) Once again, thanks a ton for the speedy, detailed responses !! Thanks and Regards, Ajay > > In each of those cases, the reverse-proxying is not to a different part > of the url hierarchy, so the original concern does not apply. > > Each case has its own costs and benefits, regarding future maintenance > within nginx and external to nginx. All can work. Only you can decide > which suits you best. > > > That brings me to my last question as per > > http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html. If > there > > isn't an issue with opening multiple nginx-listening-ports to the public, > > then I guess we are done. > > Until you exhaust resources on your system, nginx does not care how many > listening ports it opens. > > Good luck with it, > > f > -- > Francis Daly [email protected] > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > -- Regards, Ajay
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
