That's the standard behavior. Read the documentation for whatever reverse proxy you want to use.
this post was submitted on 02 Oct 2024
31 points (86.0% liked)
Selfhosted
40296 readers
344 users here now
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
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
The standard is that everything gets captured by the proxy? I want to leave the HTTP and Gemini servers public. I also want those and SMB to remain accessible on the LAN.
No, the standard is that it routes only what you configure.
Wonderful. Thank you!
For what it's worth, though, you can proxy other services, like Gemini or gopher, through the same proxy for simplicity's sake.
I just don't put the ports on the proxy config.
So those ports that I don’t put in the config remain publicly accessible? That would be perfect.
The ports you don't put in are not publicly routed.
I use NPM and only have 3 services routed outside my network.
A typical use case is to forward a single port to the proxy, then set the proxy to map different subdomains to different machines/ports on your internal network. Anything not explicitly mapped by the reverse proxy isn’t visible externally.
First of all, doesn't Navidrome have authentication? So, I don't see why exposing it to the public is a problem.
Second, some reverse proxies support basic auth. This way, you can password-protect some services and is useful if the service does not have its own authentication. Here as an example snippet for Caddy:
example.com {
basic_auth {
# Username "Bob", password "hiccup"
Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
}
reverse_proxy myservice:8000
}
You'll have to look up the docs for other reverse proxies.
Thanks. You’re right about Navidrome supporting authentication. I’m using HTTP instead of HTTPS, though. I was advised to use a reverse proxy to avoid potential legal issues.
What's your reason for using HTTP? That seems like a really bad idea this day in age, ESPECIALLY if that's something you're going to make available on the internet.
They’re lightweight sites that exist to be accessed by vintage computers which aren’t powerful enough to run SSL.
Gotcha... as long as you understand that any device that receives that traffic can see exactly what's in it! (no sarcasm intended at all... if you're informed of the risk and OK with it, then all is well!)
I have a general idea. I appreciate the info :). I’ve made a point of having nothing sensitive in the contents or the requests (I don’t have any forms, for example. It’s all static pages).
How will a reverse proxy help?
Things that a reverse proxy is often used for:
- making multiple services hosted on the same IP and port
- SSL termination so that the wider world speaks https and the proxy speaks http to the server. This means the server doesn't have to do its own key management
- load balancing services so multiple servers can serve the same request (technically a load balancer but I believe some reverse proxies do basic load balancing)
- adding authentication in front of services that don't have their own (note that some of the protections/utility is lost if you use http. Anyone who can see your traffic will also be able to authenticate. It's not zero protection though because random internet users probably can't see your traffic)
- probably something I'm forgetting
Do any of these match what you're trying to accomplish? What do you hope to gain by adding a reverse proxy (or maybe some other software better suited to your need)?
Edit: you say you want to keep this service 'private from the web'. What does that mean? Are you trying to have it so only clients you control can access your service? You say that you already have some services hosted publicly using port forwarding. What do you want to be different about this service? Assuming that you do need it to be secured/limited to a few known clients, you also say that these clients are too weak to run SSL. If that's the case, then you have two conflicting requirements. You can't simultaneously have a service that is secure (which generally means cryptographically) and also available to clients which cannot handle cryptography.
Apologies if I've misunderstood your situation
Thank you for the very informative reply.
The HTTP and Gemini services are for vintage clients, but I would like the reverse proxy to keep my media collection private (and maybe SSH and SMB too). So I’m serving to modern clients in the case of reverse proxy. I was told that port forwarding is no longer considered secure enough and that if my media gets publicly exposed I could be liable for damages to license holders.
Reverse proxies don't keep anything private. That's not what they are for. And if you do use them, you still have to do port forwarding (assuming the proxy is behind your router).
For most home hosting, a reverse proxy doesn't offer any security improvement over just port forwarding directly to the server, assuming the server provides the access controls you want.
If you're looking to access your services securely (in the sense that only you will even know they exist), then what you want is a VPN (for vpns, you also often have to port forward, though sometimes the forwarding/router firewall hole punching is setup automatically). If the service already provides authentication and you want to be able to easily share it with friends/family etc then a VPN is the wrong tool too (but in this case setting up HTTPS is a must, probably through something like letsencrypt)
Now, there's a problem because companies have completely corrupted the normal meaning of a VPN with things like nordvpn that are actually more like proxies and less like VPNs. A self hosted VPN will allow you to connect to your hone network and all the services on it without having to expose those services to the internet.
In a way, VPNs often function in practice like reverse proxies. They both control traffic from the outside before it gets to things inside. But deeper than this they are quite different. A reverse proxy controls access to particular services. Usually http based and pretty much always TCP/IP or UDP/IP based. A VPN controls access to a network (hence the name virtual private network). When setup, it shows up on your clients like any other Ethernet cable or WiFi network you would plug in. You can then access other computers that are on the VPN, or given access to to the VPN though the VPN server.
The VPN softwares usually recommended for this kind of setup are wireguard/openvpn or tailscale/zerotier. The first two are more traditional VPN servers, while the second two are more distributed/"serverless" VPN tools.
I'm sorry if this is a lot of information/terminology. Feel free to ask more questions.
That is such a clear explanation and makes a lot of sense, thank you again.
Since the services I’m interested in serving are authenticated then it sounds like HTTPS is what I need (which is what originally made the most sense to me). That’s a relief. I just need to figure out how to have separate HTTP and HTTPS services hosted from the one ARM service.
You have two options for setting up https certificates and then some more options for enabling it on the server:
1: you can generate a self signed certificate. This will make an angry scary warning in all browsers and may prevent chrome from connecting at all (I can't remember the status of this). Its security is totally fine if you are the one using the service since you can verify the key is correct
2: you can get a certificate to a domain that you own and then point it at the server. The best way to do this is probably through letsencrypt. This requires owning a domain, but those are like $12 a year, and highly recommended for any services exposed to the world. (You can continue to use a dynamic DNS setup, but you need one that supports custom domains)
Now that you have a certificate you need to know, Does the service your hosting support https directly. If it does, then you install the certificates in it and call it a day. If it doesn't, then this is where a reverse proxy is helpful. You can then setup the reverse proxy to use the certificate with https and then it will connect to the server over http. This is called SSL termination.
There's also the question of certificate renewal if you choose the letsencrypt option. Letsencrypt requires port 80 to do a certificate renewal. If you have a service already running on port 80 (on the router's external side), then you will have a conflict. This is the second case where a reverse proxy is helpful. It can allow two services (letsencrypt certificates renewal and your other service) to run on the same external port. If you don't need port 80, then you don't need it. I guess you could also setup a DNS based certificate challenge and avoid this issue. That would depend on your DNS provider.
So to summarize:
IF service doesn't support SSL/https OR (want a letsencrypt certificate AND already using port 80)
Then use a reverse proxy (or maybe do DNS challenge with letsencrypt instead)
ELSE:
You don't need one, but can still use one.
Thank you again for the response. The summary is very helpful too.
It looks like I don’t need the reverse proxy, since the sensitive services* support authentication and HTTPS.
I would need the lighttpd service to be available over unsecured HTTP too, but if that’s not possible I could always use a different subdomain.
- A small music and film library
I’m afraid that when I install a reverse proxy, it’ll take my other stuff online and causes me various headaches that I’m not really in the headspace for at the moment.
If you don’t configure your other services in the reverse proxy then you have nothing to worry about. I don’t know of any proxy that auto discovers services and routes to them by default. (Traefik does something like this with Docker services, but they need Docker labels and to be on the same Docker network as Traefik, and you’re the one configuring both of those things.)
Are you running this on your local network? If so, then unless you forward a port to your server on the port your reverse proxy is serving from, it’ll only be accessible from the local network. This means you can either keep it that way (and VPN in to access it) or test it by connecting directly to your server on that port and confirm that it’s working as expected before forwarding the port.
Thank you so much. That clears up all my doubts. I’m running an ARM server ok the lan with port forwarding for HTTP (80) Gemini (1965) and SMB (not forwarded).
I made a typo in my original question: I was afraid of taking the services offline, not online.
I made a typo in my original question: I was afraid of taking the services offline, not online.
Gotcha, that makes more sense.
If you try to run the reverse proxy on the same server and port that an existing service is using (e.g., port 80), then you’ll run into issues. You could also run into conflicts with the ports the services themselves use. Likewise if you use the same outbound port from your router. But IME those issues will mostly stop the new services from starting - you’d have to stop the services or restart your machine for the new service to have a chance to grab the ports while they were unused. Otherwise I can’t think of any issues.
That’s reassuring. Thanks, I was struggling with the concept and where to start but I should be fine now since I’m handy enough with a terminal.
My method:
VPS with reverse proxy to my public facing services. This holds SSL certs, and communicates with home network through WireGuard link configured on my router.
Local computer with reverse proxy for all services. This also has SSL certs, and handles the same services as the VPS, so I can have local/LAN speeds. Additionally, it serves as a reverse proxy for all my private services, such as my router/switches/access point config pages, Jellyfin, etc.
No complaints, it mostly just works. I also have my router override DNS entries for my FQDN to resolve locally, so I use the same URL for accessing public services on my LAN.
Thanks! Is the point of reverse-proxying your public-facing services to make them private?
It's mostly so that I can have SSL handled by nginx (and not per-service), and also for ease of hosting multiple services accessible via subdomains. So every service is its own subdomain.
Additionally, my internal network (as in, my physical LAN) does not have any port forwarding enabled
everything is over WireGuard to my VPS.
A reverse proxy is basically a landing place that acts as a middle man between the client and the server. Most people set it up so that all traffic on 80 or 443 go to the reverse proxy, and then the reverse proxy gets the correct website based on the host header of the request.
If you are currently serving multiple websites on your server, then that means you are serving each website on a different port.
So, just make sure that the reverse proxy is serving on a port that is not used by your other sites. It will only respond on it's own port, and it will only serve the site(s) that you have configured in the proxy.
You'll be fine!
Thanks, that’s a great explanation. I’m looking forward to being able to SSH in without port forwarding.
I would use a VPN to ssh
I agree that you would want a VPN for that. Look into something like tailscale.
How are you currently serving publicly?
Linux running HTTP and Gemini servers. This is fine from home using port forwarding and afraid.org’s dynamic DNS.