Hej everyone. My traefik setup has been up and running for a few months now. I love it, a bit scary to switch at first, but I encourage you to look at, if you haven’t. Middelwares are amazing: I mostly use it for CrowdSec and authentication. Theres two things I could use some feedback, though.


  1. I mostly use docker labels to setup routers in traefik. Some people only define on router (HTTP) and some both (+ HTTPS) and I did the latter.
- labels
      - traefik.enable=true
      - traefik.http.routers.jellyfin.entrypoints=web
      - traefik.http.routers.jellyfin.rule=Host(`jellyfin.local.domain.de`)
      - traefik.http.middlewares.jellyfin-https-redirect.redirectscheme.scheme=https
      - traefik.http.routers.jellyfin.middlewares=jellyfin-https-redirect
      - traefik.http.routers.jellyfin-secure.entrypoints=websecure
      - traefik.http.routers.jellyfin-secure.rule=Host(`jellyfin.local.domain.de`)
      - traefik.http.routers.jellyfin-secure.middlewares=local-whitelist@file,default-headers@file
      - traefik.http.routers.jellyfin-secure.tls=true
      - traefik.http.routers.jellyfin-secure.service=jellyfin
      - traefik.http.services.jellyfin.loadbalancer.server.port=8096
      - traefik.docker.network=media

So, I don’t want to serve HTTP at all, all will be redirected to HTTPS anyway. What I don’t know is, if I can skip the HTTP part. Must I define the web entrypoint in order for redirect to work? Or can I define it in the traefik.yml as I did below?

entryPoints:
  ping:
    address: ':88'
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
  websecure:
    address: ":443"

  1. I use homepage (from benphelps) as my dashboard and noticed, that when I refresh the page, all those widgets take a long time to load. They did not do that, when I connecte homepage to those services directly using IP:PORT. Now I use URLs provided by traefik, and it’s slow. It’s not really a problem, but I wonder, if I made a mistake somewhere. I’m still a beginner when it comes to this, so any pointers in the right direction are apprecciated. Thank you =)
  • lemmyvore@feddit.nl
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    9 months ago

    You can skip serving 80 but good practice dictates that you should enable the HSTS header if you do that, so that browsers know to not even try HTTP.

     traefik.frontend.headers.STSSeconds: "31536000"
     traefik.frontend.headers.STSIncludeSubdomains: "true"
     traefik.frontend.headers.STSPreload: "true"
    
    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      9 months ago

      Thank you for your answer. If I do that, can I still connect via HTTP and the browser will then redirect? I don’t think I have a problem with remembering HTTPs, but my family will…

      • lemmyvore@feddit.nl
        link
        fedilink
        English
        arrow-up
        6
        ·
        9 months ago
        1. If a user types just a domain name in the browser bar (without adding http:// or https://) the browser will try https:// first. If it sees a HSTS header it will refuse to ever access that domain over http://, period, for as long as the header says (this applies to later visits too, the browser will remember that it must not use http://).
        2. If it’s the very first time the user visits your domain and they explicitly type http:// or follow a link that used http://, it depends. If they have a browser setting or addon that automatically upgrades http:// to https:// it will either put them in the first scenario silently, or issue a warning that asks them if they’re sure they want to proceed non-encrypted.
        3. If they get past all these safeguards and attempt to connect to your port 80, again it depends. If they manage to connect to your server it would help if there’s a redirect to https:// there but the damage has already been done…
        4. …because if their ISP (or your ISP, or their company, or the owner of that coffeeshop WiFi they’re using, or someone in their household etc. etc.) is hijacking HTTP connections, the visitor will never reach your port 80. The hijacker will connect to your 443 on their behalf and use their requests to port 80 to relay content pulled from 443, and eavesdrop on everything both ways, obtaining logins and other private info in the process.

        So as you can see whether you maintain a redirect on 80 or not is not very important. Ideally your visitors should never attempt unencrypted connections at all. If they do and get hijacked your redirect will be irrelevant.

        Redirects on 80 to 443 are relevant if your website is old and gets a significant amount of traffic from http:// links out there, which it cannot afford to miss.

        • Pete90@feddit.deOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          9 months ago

          Thank you so much for your thorough answer, this is very much a topic that needs some reading/watching for me. I’ve checked and I already use all of those headers. So in the end, from a security standpoint, not even having port 80 open would be best. Then, no one could connect unencrypted. I’ll just have to drill into my family to just use HTTPS if they have any problems.

          It was interesting to see, how the hole process between browser and server works, thanks for clearing that up for me!

        • ItsMikeB@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          8 months ago

          So are you essentially saying it’s better to not even have an entrypoint on port 80 in your config at all despite using a redirect, or would using the HSTS header still prevent someone from explicity requesting your domain via http:// entirely in your examples 3 and 4?

          And is this only related to allowing external requests on port 80 because the client could potentially have their connection hijacked? If you were to allow an entrypoint on port 80 from internal IP ranges only this is not a possibility (assuming your lan isn’t compromised by some other means), right?

          Thankfully, I haven’t needed to expose any services so I just use a VPN for now, but I haven’t gotten around to enabling valid ssl certs for internal traffic as an additional layer of security either. I hadn’t even considered the scenario you described, so it seems like it’s better to just go the route of https everywhere and not even use an entrypoint on port 80 regardless.

          • lemmyvore@feddit.nl
            link
            fedilink
            English
            arrow-up
            2
            ·
            8 months ago

            Serving 80 on the LAN should be OK as long as you have reasonable control over all the Ethernet wires and WiFi access points.

            would using the HSTS header still prevent someone from explicity requesting your domain via http:// entirely in your examples 3 and 4?

            You can’t control what clients do, you can only control what your server does.

            In case 4 the hijacking took place before they even got to your server so it doesn’t matter anymore.

            In case 3, if they manage to make it to your server and you have a redirect from 80 to 443 and HSTS on 443 they will narrowly escape future hijacks. So a redirect is not technically a bad thing to have, provided you also have HSTS.

            • ItsMikeB@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              8 months ago

              You can’t control what clients do, you can only control what your server does.

              Exactly, I should have said what would the server do when clients try to connect via http:// with and without the HSTS header but I see what you mean now. Thanks for the explanation!

              • lemmyvore@feddit.nl
                link
                fedilink
                English
                arrow-up
                1
                ·
                8 months ago

                One more thing, to make sure everything is clear: the HSTS header only matters over TLS. Servers are not supposed to give it over plain connections (could be faked) and browsers must ignore it if it’s not TLS.

  • mbirth@lemmy.mbirth.uk
    link
    fedilink
    English
    arrow-up
    2
    ·
    9 months ago

    I think the redirect must go into the dynamic configuration, not the static one. But yes, you can setup a generic redirect. I did it like this:

    http:
    
      routers:
    
        redirect-https:
          rule: HostRegexp(`{catchall:.*}`) 
          entrypoints: web
          middlewares: redirect-https
          service: dummy
    
      services:
    
        dummy:
          loadbalancer:
            servers:
              - url: "about:blank"
    

    This is in a file 010-redirect-https.yml in my Traefik’s dynamic configuration directory. And it works for all http URLs.

    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      I didn’t even know that you could have a whole dynamic config directory, I just use one file. I’m guessing I can just as well put it there? And the dummy service simply acts as a place holder?

      • mbirth@lemmy.mbirth.uk
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 months ago

        Exactly! It didn’t work without providing any service item, so I had to specify something.

        I use the dynamic configuration to add some static routes to other devices and non-Docker services in my local network.

  • chiisana@lemmy.chiisana.net
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    9 months ago

    Do you have more than one network in Docker?

    If so, you’d want to add a label to tell traefik which network to use; if memory serves, I think it is literally traefik.docker.network=traefik_default or something like that, where traefik_dedault should reflect the network the service is sharing with traefik — I put mine on the traefik default network from docker compose, hence the name but you may have other design.

    Edit: sorry I’m on mobile right now, and I just saw you do have traefik docker network bit already, but it says media. Is that network where traefik have access?

    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      Each service stack (e.g. media, iso downloading) has it’s own network and traefik is in each of those networks as well. It works and seperates the stacks from each other (i don’t want stack a to be able to access stack b, which would be the case with a single traefik network, I think.)

      • chiisana@lemmy.chiisana.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 months ago

        If you don’t mind, can you please try disabling all but one or two stacks and see if your homepage responds faster?

        I think although your setup may work, and is definitely better than me dumping everything into the Traefik gateway network, I can’t help but to wonder if Traefik picked up some overhead with each additional network it gets added to…?

        • Pete90@feddit.deOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          I did what you suggested and reduced (1) the number of running services to a minimum and (2) the networks traefik is a member of to a minmum. It didn’t change a thing. Then I opened a private browser window and saw much faster loading times. Great. I then set everything back and refreshed the private browser window: still fast. Okay. Guess it’s not Traefik after all. The final nail in the coffin for my theory: I uses two traefik instances. Homepage still loads its widgets left to right, top to bottom (the order from the yaml file). The order doesn’t correspond to the instances, it’s more or less random. So I’m assuming the slowdown has something to do with (a) either caching from traefik or (b) the way Homepage handels the API request: http://IP:PORT (fast) or https://subdomain.domain.de. Anyway, thanks for your help!

          • chiisana@lemmy.chiisana.net
            link
            fedilink
            English
            arrow-up
            1
            ·
            9 months ago

            Humph… I wonder what’s the actual underlying issue here. Such a strange one!! Hope you’re able to figure it out at some point!

        • Pete90@feddit.deOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          That’s a great idea, I’ll give it a try tomorrow. The weird thing is, the webuis load just fine, at least 90+ of the time is almost instant…

  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    8 months ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    HTTP Hypertext Transfer Protocol, the Web
    HTTPS HTTP over SSL
    IP Internet Protocol
    SSL Secure Sockets Layer, for transparent encryption
    TLS Transport Layer Security, supersedes SSL
    VPN Virtual Private Network

    5 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.

    [Thread #603 for this sub, first seen 15th Mar 2024, 13:45] [FAQ] [Full list] [Contact] [Source code]