I’ve got Immich working great on Unraid, but if I’m on my network I can’t really use it. Just fails to resolve the dns. I looked it up and it’s that my router doesn’t support hairpin or something. It’s a Aginet hb810. I found a workaround in the Immich client where you can add a second entry that’s network specific, but it doesn’t seem to work very reliably.

What are my options?

  • cecilkorik@lemmy.ca
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    18 hours ago

    I’d argue that your internally hosted site should not be published on ports other than 80/443. Published is the key word here, because the sites themselves can run on whatever port you want and if you want to access them directly on that port you can, but when you’re publishing them and exposing them to the public you don’t want to be dealing with dozens of different services each implementing their own TLS stack and certificate authorities and using god-knows-what rules for security and authentication. You use a proxy server to publish them properly. And there’s no reason you can’t or shouldn’t use that same interface internally too. Even though you technically might be able to directly access the actual ports the services are running on on your local network, you really probably shouldn’t, for a lot of reasons, and if you can, maybe consider locking that down and making those services ONLY listen on 127.0.0.1 or isolated docker networks so nothing outside the proxy host itself can reach them.

    If you don’t want your services to listen on 80/443 themselves that’s reasonable and good practice, but something should be, and it should handle those ports responsibly and authoritatively to direct incoming traffic where it needs to go no matter the source. Even if (or especially if) you need to share that port with various other services for some reason, then either way you need it to operate that port as a proxy (caddy, nginx, even Apache can all do this easily). 443 is the https port, and in the https-only world we should all be living in, all https traffic should be using that port at least in public, and the https TLS connection should be properly terminated at that port by a service designed to do this. This simplifies all sorts of things, including domain name management and certificate management.

    tl;dr You should have a proxy that publishes all your services on port 443 according to their domain name. When https://photos.mydomain.com/ comes in, it hits port 443 and the service on port 443 sees it’s looking for “photos”, handles the certificates for photos, and then decides that immich is where it is going and proxies it there, which is none of anyone else’s business. Everyone, internal or external, goes through the same, consistent, and secure port 443 entrance to your actual web of services.

    • tko@tkohhh.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      18 hours ago

      The challenge here is that the host is Unraid, which publishes its own interface on 80/443. My reverse proxy is of course handling all requests for my sites, but that is ALSO running on a container, and must be listening on something other than 80/443 when using host or bridge networking.

      So, if I’m following along correctly, I would need to put my reverse proxy on a different host (bare metal or VM) in order for it to listen on 80/443.

      • cecilkorik@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        14 hours ago

        I’m not too familiar with unraid but from a little research I just did it seems like you’re right. That does seem like a really unfortunate design decision on their part, although it seems like the unraid fans defend it. Obviously, I guess I cannot be an unraid fan, and I probably can’t help you in that case. If it were me, I would try to move unraid to its own port (like all the other services) and install a proxy I control onto port 443 in its place, and treat it like any other service. But I have no idea if that is possible or practical in unraid. I do make opinionated choices and my opinion is that unraid is wrong here. Oh well.

        • tko@tkohhh.social
          link
          fedilink
          English
          arrow-up
          1
          ·
          14 hours ago

          Totally fair… I appreciate you engaging with me, your perspective is appreciated! I won’t defend Unraid’s choice when it comes to the UI ports, but I will simply say that there are things that are really nice about Unraid from a usability standpoint.

          Thanks again for your thoughts!

          • cecilkorik@lemmy.ca
            link
            fedilink
            English
            arrow-up
            2
            ·
            14 hours ago

            Convenience is great until it becomes inconvenient. But that’s a journey we all make :)