So, I have some idea on what a reverse proxy does and will be using nginx (with the neat proxy manager UI) for my setup.
However, I’m not completely clear what exactly I want it to do and how I cn use it to run different services on one machine. I’m especially unclear on the ports configuration … tutorials will say things like “change the listening port to xxx for that service and to port yyy for the other service”
How does this work, which ports can I use and how do I need to configure the respective services?
EDIT: thanks everybody, your replies did help me a lot! I have my basic setup now up and running using portainer + nginx + fail2ban.
Sounds smart. Good luck. I went the easy way and just did Cloudflare Tunnels to my apps and am starting to set up and look in to using Cloudflare access to give it all forces 2FA
One big thing they’re used for is sort of multiplexing port 80/443. You have one daemon listening on them, and you can have multiple domains pointing at the same IP. The reverse proxy will figure out which backend service to forward requests too.
Proxies like Caddy and I think Traefik also automatically manage SSL certificates. In many cases you could have your application server handle SSL, but usually it’s a good idea to have dedicated software for this.
Could you have a look at my answer to the poster above - would multiplexing mean, that I configure my internal IP 0.0.0.0:XXXA for one service and 0.0.0.0:XXXB for another?
Yeah that’s exactly right! You have the proxy listen on 80/443 and use the subdomains to proxy to the respective other services that you have listen to other ports. Make sure those other ports are not open to the outside, though, as that would allow someone to bypass the proxy. In you example, you would change away from 0.0.0.0 to 127.0.0.1, which means the port is only open to the loop back interface, not the other ones. This happens accidentally especially when using docker for the app service. Also you should probably run some firewall to block all ports that you don’t wish to expose.
I’d really suggest you take a look at Caddy for the reverse proxy. It completely handles SSL certificate creation and renewal so you don’t have to do anything.
So a reverse proxy is sort of like a phonebook or directory, it routes outside requests to the appropriate place. So imagine your reverse proxy is a receptionist, someone comes in and says “hey I am looking for plex.mydomain.com” the receptionist would then use the phonebook and say “ok if you are looking for plex.mydomain.com, go to building 192.168.1.10 (the ip), room 9000 (the port)”
Since you are asking about dockerized services, the networking for those can be done in several different ways, but the one thing that really matters is that each service needs to have a unique combination of ip and port, because only 1 service can live at each address. With docker, you could set up multiple services that use the host server’s ip, in which case each container will need to be on different ports, or you could have it so each container has its own ip, in which case the port can be anything.
This makes it clearer to my, would you mind helping me to understand all steps for my usecase.
I want to run a lemmy instance and a mastodon instance on the same VPS, using the same domain but different subdomains - lmy.my-domain.tld and mstdn.my-domain.tld. I have my VPS IP address and setup the 2 subdomains with my domain provider (both subdomains are resolving the same IP).
I also did setup nginx on my server and can install SSL certificates for both of these domains. I’m now at the step where lmy.my-domain.tld should by directed to the lemmy service and mstdn.my-domain.tld to the mastodon service. As I understand it, both services listen to the ports 80 (http) and 443 (https). Do I now setup a room/building for Lemmy / Mastodon respectively where I tell nginx that lmy.my-domain.tld is at 0.0.0.0:3001 and mstdn.my-domain.tld is at 0.0.0.0:3002 for example. And in the config files for each of these installs I’d specify “0.0.0.0:300x” respectivly?
(also have to make sure, that these docker installs don’t mess with my nginx config by themselves, right?)
It sounds like what you need to do at this point is find what IP address your lemmy instance and mastodon instance containers are using on your VPS. you can do “docker inspect containername” and look for the IP address in there. it might be something like 172.16.0.1 for lemmy and 172.17.0.1 for mastodon. then you want to set up your reverse proxy to point lmy.my-domain.tld to 172.16.0.1:80 (or whatever port you set lemmy to use) and then mstdn.my-domain.tld to point to 172.17.0.1:80 (again, port might be different, i dont know what the default port is)
-IF- both of the containers are using the same IP, then you will need to make sure that they are using different ports. if they are on the same ip and same port, whichever container loads 2nd will fail to properly load, because when a port is taken on an IP address, it is reserved and nothing else can try to listen on that port.
I’ll provide an ELI5, though if you actually want to use it you’ll have to go beyond ELI5.
You contact a web service via a combination of IP address and port. For the sake of simplicity, we can assume that domain name is equivalent to IP address. You can then compare domain name/port with street name/street number: you need both to actually find someone. By default, some street numbers are really standard, like 443 is for regular encrypted connection. But you can have any service on any street number, it’s just less nice and less standard. This is usually done on closed networks.
Now what happens if you have a lot of services and you want all of them reachable at address 443? Well basically you are now in the same situation as a business building with a lobby. Whenever you want to contact a service, you go to 443, ask the reception what floor they are in, and they will direct you there. The reception desk is your proxy: just making sure you talk to the right people.
IPv4 version: Think of your public IP:Port as the office building, your internal IP:Port as the floor number, and reverse proxy as the reception on that floor.
(Your public IP:Port is routed to your internal IP:Port by the NAT on your router. The router knows which public port relates to which internal IP:Port due to the port forwarding rules you setup.)
IPv6 version: Think of your public IP:Port as the office, and the reverse proxy as the reception.
The following will be common to both IP protocols.
The port is usually 80 or 443, because reverse proxy is used for HTTP(S) connections, and by default those connections use the aforementioned ports.
When someone connects to your IP:Port, they ask the reverse proxy “hey, can you bring me to Mr. https://my-awesome-plex.xyz ?” and the reverse proxy will act as a middleman between that someone and the actual server that is serving that domain name.
The reverse proxy, as a middleman, forwards your requests to the server, and the server’s response is forwarded back to you by the reverse proxy too.
And just to make things complete… Why do we use reverse proxies?
To hide the identity of the actual server. This is easy to understand - you are only ever talking to the proxy, never the actual server. It’s just that your messages are continually forwarded to the actual server.
To save IP addresses. (One public address can serve multiple websites, if the actual servers are given only private IP addresses.)
To load balance. The reverse proxy can direct one to another server if the first server is overloaded. This requires a website to be served by more than one server though, and selfhosters like us never really need it.
To prevent attacks. If the reverse proxy realises that someone has been making too many connections to https://my-awesome-nas.com, the reverse proxy can reject subsequent connections. This is how Cloudflare works.
Caching. If the middleman remembers that the server responded “what is the answer to everything” with “42”, then the next time someone asks the same question again, the middleman will simply reply with the same response. This takes off the workload on the server.
Since you already got a lot of ELI5s, here is a basic to-do to get you up and running. From my experience, since I use the exact same setup as you describe.
Set up your containers in a way you can reach them from you local network (e.g. http://123.456.789.10:123)
Get a domain name (you can get one at the registrar of your choice, e.g. mydomain.com)
Forward Hostname/IP: 123.456.789.10 (if you get an error later on, you can use the docker container name if NPM and your container are connected to the same Docker network)
Port: 123
Via access lists you can provide a very basic username/pw login to protect your sites (you can do more and cooler stuff with Authelia)
Add an A-record for mydomain.com and the public IP of your server (you can google public IP to find it out)
Add a CNAME record for the subdomain with name mycontainer and target mydomain.com
open port 443 of your server in your router
If everything worked right, you can visit mycontainer.mydomain.com, your DNS server will resolve this to your public IP and forwards the request to nginx, which will serve the data of your local container
A reverse proxy delegates HTTP requests to the web servers that should respond. It may also decrypt from HTTPS and/or cache them, it static content is served.
If you are using containers, the web servers running inside the containers are proxied. That means the delegation forwards the requests to the container which web server has to respond to.
Yeah, but you have to admit that children wouldn’t ask you what a reverse proxy is. I tried my best to write short, omitting details and in a simple language.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Sounds smart. Good luck. I went the easy way and just did Cloudflare Tunnels to my apps and am starting to set up and look in to using Cloudflare access to give it all forces 2FA
One big thing they’re used for is sort of multiplexing port 80/443. You have one daemon listening on them, and you can have multiple domains pointing at the same IP. The reverse proxy will figure out which backend service to forward requests too.
Proxies like Caddy and I think Traefik also automatically manage SSL certificates. In many cases you could have your application server handle SSL, but usually it’s a good idea to have dedicated software for this.
Could you have a look at my answer to the poster above - would multiplexing mean, that I configure my internal IP 0.0.0.0:XXXA for one service and 0.0.0.0:XXXB for another?
Yeah that’s exactly right! You have the proxy listen on 80/443 and use the subdomains to proxy to the respective other services that you have listen to other ports. Make sure those other ports are not open to the outside, though, as that would allow someone to bypass the proxy. In you example, you would change away from 0.0.0.0 to 127.0.0.1, which means the port is only open to the loop back interface, not the other ones. This happens accidentally especially when using docker for the app service. Also you should probably run some firewall to block all ports that you don’t wish to expose.
I’d really suggest you take a look at Caddy for the reverse proxy. It completely handles SSL certificate creation and renewal so you don’t have to do anything.
thank you, that clears things up a bit. Now it’s to play around with it, until I get it up and running :)
For future reading this “multiplexing” is called SNI inspection/routing and it can only be used when TLS/SSL is in use.
So a reverse proxy is sort of like a phonebook or directory, it routes outside requests to the appropriate place. So imagine your reverse proxy is a receptionist, someone comes in and says “hey I am looking for plex.mydomain.com” the receptionist would then use the phonebook and say “ok if you are looking for plex.mydomain.com, go to building 192.168.1.10 (the ip), room 9000 (the port)”
Since you are asking about dockerized services, the networking for those can be done in several different ways, but the one thing that really matters is that each service needs to have a unique combination of ip and port, because only 1 service can live at each address. With docker, you could set up multiple services that use the host server’s ip, in which case each container will need to be on different ports, or you could have it so each container has its own ip, in which case the port can be anything.
This makes it clearer to my, would you mind helping me to understand all steps for my usecase. I want to run a lemmy instance and a mastodon instance on the same VPS, using the same domain but different subdomains - lmy.my-domain.tld and mstdn.my-domain.tld. I have my VPS IP address and setup the 2 subdomains with my domain provider (both subdomains are resolving the same IP).
I also did setup nginx on my server and can install SSL certificates for both of these domains. I’m now at the step where lmy.my-domain.tld should by directed to the lemmy service and mstdn.my-domain.tld to the mastodon service. As I understand it, both services listen to the ports 80 (http) and 443 (https). Do I now setup a room/building for Lemmy / Mastodon respectively where I tell nginx that lmy.my-domain.tld is at 0.0.0.0:3001 and mstdn.my-domain.tld is at 0.0.0.0:3002 for example. And in the config files for each of these installs I’d specify “0.0.0.0:300x” respectivly? (also have to make sure, that these docker installs don’t mess with my nginx config by themselves, right?)
It sounds like what you need to do at this point is find what IP address your lemmy instance and mastodon instance containers are using on your VPS. you can do “docker inspect containername” and look for the IP address in there. it might be something like 172.16.0.1 for lemmy and 172.17.0.1 for mastodon. then you want to set up your reverse proxy to point lmy.my-domain.tld to 172.16.0.1:80 (or whatever port you set lemmy to use) and then mstdn.my-domain.tld to point to 172.17.0.1:80 (again, port might be different, i dont know what the default port is)
-IF- both of the containers are using the same IP, then you will need to make sure that they are using different ports. if they are on the same ip and same port, whichever container loads 2nd will fail to properly load, because when a port is taken on an IP address, it is reserved and nothing else can try to listen on that port.
I’ll provide an ELI5, though if you actually want to use it you’ll have to go beyond ELI5.
You contact a web service via a combination of IP address and port. For the sake of simplicity, we can assume that domain name is equivalent to IP address. You can then compare domain name/port with street name/street number: you need both to actually find someone. By default, some street numbers are really standard, like 443 is for regular encrypted connection. But you can have any service on any street number, it’s just less nice and less standard. This is usually done on closed networks.
Now what happens if you have a lot of services and you want all of them reachable at address 443? Well basically you are now in the same situation as a business building with a lobby. Whenever you want to contact a service, you go to 443, ask the reception what floor they are in, and they will direct you there. The reception desk is your proxy: just making sure you talk to the right people.
IPv4 version: Think of your public IP:Port as the office building, your internal IP:Port as the floor number, and reverse proxy as the reception on that floor.
(Your public IP:Port is routed to your internal IP:Port by the NAT on your router. The router knows which public port relates to which internal IP:Port due to the port forwarding rules you setup.)
IPv6 version: Think of your public IP:Port as the office, and the reverse proxy as the reception.
The following will be common to both IP protocols.
The port is usually 80 or 443, because reverse proxy is used for HTTP(S) connections, and by default those connections use the aforementioned ports.
When someone connects to your IP:Port, they ask the reverse proxy “hey, can you bring me to Mr. https://my-awesome-plex.xyz ?” and the reverse proxy will act as a middleman between that someone and the actual server that is serving that domain name.
The reverse proxy, as a middleman, forwards your requests to the server, and the server’s response is forwarded back to you by the reverse proxy too.
And just to make things complete… Why do we use reverse proxies?
To hide the identity of the actual server. This is easy to understand - you are only ever talking to the proxy, never the actual server. It’s just that your messages are continually forwarded to the actual server.
To save IP addresses. (One public address can serve multiple websites, if the actual servers are given only private IP addresses.)
To load balance. The reverse proxy can direct one to another server if the first server is overloaded. This requires a website to be served by more than one server though, and selfhosters like us never really need it.
To prevent attacks. If the reverse proxy realises that someone has been making too many connections to https://my-awesome-nas.com, the reverse proxy can reject subsequent connections. This is how Cloudflare works.
Caching. If the middleman remembers that the server responded “what is the answer to everything” with “42”, then the next time someone asks the same question again, the middleman will simply reply with the same response. This takes off the workload on the server.
Since you already got a lot of ELI5s, here is a basic to-do to get you up and running. From my experience, since I use the exact same setup as you describe.
A reverse proxy delegates HTTP requests to the web servers that should respond. It may also decrypt from HTTPS and/or cache them, it static content is served.
If you are using containers, the web servers running inside the containers are proxied. That means the delegation forwards the requests to the container which web server has to respond to.
This is more like an ELI35 for sys engineers…
Yeah, but you have to admit that children wouldn’t ask you what a reverse proxy is. I tried my best to write short, omitting details and in a simple language.
Help understanding Reverse Proxies - Lemmy.world
If I can add to this … what’s the sort of etymology for the term. Why is it a reverse proxy exactly?