Hi everybody.

How should I setup reverse proxy for my services? I’ve got things like jellyfin, immich a bitwarden running on my Debian server in docker. So should i install something like nginx for each of these also in docker? Or should I install it from repository and make configs for each of these docker services?

Btw I have no idea how to use something like nginx or caddy but i would still like to learn.

Also can you use nginx for multiple services on the same port like(443)?

    • WhyJiffie@sh.itjust.works
      cake
      link
      fedilink
      English
      arrow-up
      6
      ·
      2 months ago

      tailscale is not the same as nginx or any reverse proxy, though. I don’t expose anything publicly, but I still wouldn’t stop using a reverse proxy

  • Sean@infosec.pub
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 months ago

    I prefer doing nginx on the host (vs a container), & have different configs for each service. You can have multiple services on the same port, it can be controlled via DNS instead (i.e.: access Jellyfin.domain.com & bitwarden.domain.com, both of 443).

    Ive tried Caddy once or twice but couldn’t get it working, so i just stick with nginx & cert or to automatically get certificates from my internal CA

    • Octavusss@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      2 months ago

      Yeah but when I last tried nginx on my bitwarden host and another on my jellyfin host i could access the one for bitwarden on port 81 of my server but couldn’t access the other nginx web page on port 85 even though i have written it in docker compose file and the port 85 was also open on my server.

      • Sean@infosec.pub
        link
        fedilink
        English
        arrow-up
        5
        ·
        2 months ago

        It looks like jhdeval mentioned this already, but you may need to review your config file. By default, you would likely have nginx listening on ports 80 & 443 for requests to a specific address (i.e.: jellyfin.domain.com) which would be configured in your DNS, & then nginx would direct the jellfin 443 traffic to port 85 to access Jellyfin. Same principle for Bitwarden. If you have your nginx config files, i \ we could take a look & see if we spot any issues.

        • Octavusss@lemm.eeOP
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          2 months ago

          I’m currently cannot post it here and also since it didn’t work the first time I’m using only http for jellyfin and immich but i can later post the docker config for bitwarden.

    • Avid Amoeba@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      I’m doing the same with Apache in a container. Using Let’s Encrypt with DNS challenge for SSL certificate. The DNS records point to the reverse proxy IP which is only accessible via VPN (Tailscale). 😂

      • Sean@infosec.pub
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        nginx + certbot \ acme for certs from my local Step-CA, proper DNS & I just use a WireGuard VPN on-demand for when I leave my house. As soon as I’m off my Wi-Fi I have the VPN active so I don’t need to expose anything more than 1 port for that to work =]

        I might look at Tailscale, if only because I’ve seen plenty of people say that’s how they connect, so worth looking into =]

        • Avid Amoeba@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          2 months ago

          If you want to stay fully self-hosted, look into Headscale. You could run it locally with a port open, or you could throw it on the tiniest cloud VM somewhere and have zero ports open at home.

    • WhyJiffie@sh.itjust.works
      cake
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      my last experience with it was a half empty documentation, and a config structure that signaled to me that they dropped a lot of features for v2 release that they initially wanted to have, which has additionally made understanding their config structure harder. and that hasn’t improved for years.

  • ohshit604@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    4
    ·
    2 months ago

    Reverse proxying was tricky for me, I started with Nginx Proxy Manager and it started out fine, was able to reverse proxy my services in the staging phase however, once I tried to get production SSL/TLS certificates it kept running into errors (this was a while ago I can’t remember exactly) so that pushed me to SWAG and swag worked great! Reverse proxying was straight forward, SSL/TLS certificates worked well however, overall it felt slow, so now I’m using Traefik and so far have no complaints.

    It’s honestly whatever works for you and what you prefer having.

  • irmadlad@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    I recommend Caddy. It’s very easy to deploy, and configuring it is a snap. This tutorial helped me out a bunch. There is a Docker version of Caddy, tho I have never used it. I figured, Caddy would do better installed on bare metal. I use Caddy in conjunction with Duckdns.org. Caddy also takes care of renewing your certs when it’s time.

  • iAmTheTot@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    Nginx Proxy Manager was easy to learn as a beginner. I’d recommend it as a learning tool, if nothing else, and if you want to switch to other solutions later you can.

  • y8h8do3a2vg5@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    2
    ·
    edit-2
    2 months ago

    This may be a controversial approach, but I recently had to set up reverse proxy along with DNS configuration and certificate handling. I pair programmed with an LLM.

    My experience was this… I described what I wanted to set up, my objectives (like containerisation, zero touch deployment, idempotence, etc) and it gave me a starting point. It threw a few bad ideas in but I also asked it to help me stress test against the objectives. I think it’s all just about working now. I learned a lot about shell, docker, nginx, terraform, VM metadata, data persistence, pulling it all in from a git repo, bootstrapping nginx with self-signed certificates, auto renewal, vscode devcontainers and more. Honestly I’m worried about what a pro would make of my code, but I made huge steps in a relatively short time. Disclaimer: I am a software engineer who was keen to learn this stuff and get moving quickly.

    I would definitely consider this approach if you’re new to the area.

  • Encrypt-Keeper@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 months ago

    What is your goal, simplest to configure? industry standard? Secure options set by default? Do you need a gui or are you fine with config files?

    • Octavusss@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      Something secure and easy to understand and setup for beginner. The easier the better. I don’t mind writing config files if I can understand it.

      • Encrypt-Keeper@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        2 months ago

        Nginx Proxy Manager is probably your best bet at this stage. It’s a simple to use GUI with QOL features like automatic certificate acquisition built on top of the industry standard Nginx. It should do everything you need it to do and it’s hands down the easiest to get started with.

        When you reach the point that you’re trying to do something outside the scope of Nginx Proxy Manager’s gui, that would be a good time to get into another solution that’s config file based. My weapon of choice here is Caddy. I LOVE how simple and minimal the configuration is and it does a lot of things by default that other solutions don’t.

        Plain Nginx is a solid tool but working with it directly will be the least straightforward and beginner friendly of all the solutions. Only reason I’d recommend straight Nginx is if you want experience with it for work.

        Traefik, don’t bother with until you have an actual reason to use it over other solutions (Like you’re getting into clustering or kubernetes or anything else that requires dynamic configuration instead of static.)

  • jhdeval@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 months ago

    Nginx, caddy and haproxy are 3 choice for reverse proxy. The way a reverse proxy works is it looks on port 80 and 443 for requests to a DNS connection. Like say you want to go to jellyfin you may have a DNS entry for jellyfin.personalsite.tld the reverse proxy will then take that and redirect the connection to the proper port and server behind your firewall. You do not need multiple reverse proxies. In the case of haproxy and nginx (only ones I have experience with) you create a “back end connection” like explained above and it will redirect. In the case of nginx it is very small I installed it natively and setup configs for each of my services for easy maintenance.

    • Octavusss@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      2 months ago

      Okay and in that case can you please point me in the right direction how should i write the nginx configs for each of my services and also make ssl certificates?

  • ippocratis@lemmy.ml
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    2 months ago

    While using a web server before your self hosted micro services is the obvious answer and caddy the easier to configure, as a beginner you should also consider taiscale funnels. You dont need to mess with router stuff like port forward or caring if you ISP have your router behind a cgnat which is kinda norm nowadays , also dont have to care for a domain name dynamic DNS stuff . You could have a look to my quick how to . All you need is running a script , the ports and desired names of your subdomains and your tailscale auth key. https://ippocratis.github.io/tailscale/

    • Octavusss@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      Well I already got static IP from my ISP and configured Wireguard on my directly on my router so I think I’m good.

      • ippocratis@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        2 months ago

        The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy . Its just more straightforward for a beginner.

        Personally I closed my router ports and switched to tailscalr funnels after using caddy with mutual TLS for years.

        • CapitalNumbers@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          maybe silly question but does tailscale tunnel operate in a similar fashion to a cloud flare tunnel? as in you can remotely access your internal service over https?

        • WhyJiffie@sh.itjust.works
          cake
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy .

          they did not say they want it public, and that’s an additional security burden they may not need

          • ippocratis@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            2 months ago

            He he didnt but thats what he meant

            I mean 99% of users use reverse proxy for https public access

            Also read the threat replies …

            That’s what this thread is about

            No?

            • WhyJiffie@sh.itjust.works
              cake
              link
              fedilink
              English
              arrow-up
              1
              ·
              2 months ago

              if that’s true, I assume it is because they don’t know about the security consequences, nor about more secure ways. and for 99% that is the worst solution, because they won’t tighten security with a read only filesystem, DMZ and whatnot, worse, they won’t be patching their systems on schedule, but maybe in a year.

              99% users should not expose any public services other than wireguard or something based on it. on a VPS the risk my be lower, but on a home network, hell no!

              • ippocratis@lemmy.ml
                link
                fedilink
                English
                arrow-up
                1
                ·
                2 months ago

                Ok I’m not any networking expert but I think you are overestimating the risk here.

                Opening a port doesn’t mean you are opening your whole home network just the specific services you want. And those not directly but with a web server in front of them . Web servers talked in this tgread that sit in front of open ports are well audited . I think that measures like mtls a generic web server hardening are more than ok to not ever be compromised.

                But yeah I’m surely interested to listen if you could elaborate.

                Thanks

                • WhyJiffie@sh.itjust.works
                  cake
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  2 months ago

                  Opening a port doesn’t mean you are opening your whole home network just the specific services you want.

                  until a new high severity vulnerability gets discovered and some bot exploits it on your server, taking it over. and you won’t even know. if they were a bit smart, you won’t notice it ever either.

                  but there’s more! its not only the reverse proxy that can be exploited! over the past few years, jellyfin has patched a dozen vulnerabilities, some of which allowed execution of arbitrary system commands. one of the maintainers have expressed that nobody should be running those old versions anymore, because they are not safe even only on the LAN. and this was just jellyfin.