[Traefik - Proxy/Loadbalancer] Ervaringen & Discussie

[lxz]

Ik krijg ook een foutmelding bij 2.2 -> 2.3. Bij mij gaat het niet om passTLSCert, maar hierom:

code:

Cannot start the provider *file.Provider: /rules/middlewares.yaml: field not found, node: authResponseHeaders"

ik kan niet vinden dat dit deprecated is. Ga nu eerst maar even terug naar 2.2, dan werkt het allemaal weer

--edit--
het zal hier wel mee te maken hebben:

File Provider
The file parser has been changed, since v2.3 the unknown options/fields in a dynamic configuration file are treated as errors.

[ Voor 31% gewijzigd door lxz op 11-12-2020 15:21 ]

[joost308]

@lolgast . Heb ff gezocht in alle bestanden die in mijn rules directory staan maar helaas geen hits op 'passTLSCert'

Files in mijn rules map zijn: tls.yml

code:

tls:
  options:
    TLSv13:
      minVersion: VersionTLS13
      cipherSuites:
        - TLS_AES_128_GCM_SHA256
        - TLS_AES_256_GCM_SHA384
        - TLS_CHACHA20_POLY1305_SHA256
      sniStrict: true
    default:
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      sniStrict: true

Dan de middlewares.yml (daar lijkt hij de melding op te geven maar ik heb alle opties gecontroleerd en zie geen deprecated zaken (in 2.2 ook geen problemen)

code:

http:
  middlewares:
    redirect:
      redirectScheme:
        scheme: https
    hsts:
      headers:
        sslRedirect: true
        stsPreload: true
        stsSeconds: 315360000
        stsIncludeSubdomains: true

en dan heb ik nog wat file based sites. Die zijn allemaal in deze format opgemaakt:

code:

http:
  routers:
    websiteX-secure:
      rule: Host("x.y.z")
      entryPoints:
        - websecure
      service: service-websiteX@file
      middlewares:
        - hsts
      tls:
        certResolver: le

    websiteX:
      rule: Host("x.y.z")
      entrypoints:
        - web
      service: service-websiteX@file
      middlewares:
        - redirect

  services:
    service-websiteX:
      loadBalancer:
        servers:
          - url: https://IP

Ik hoop dat jullie nog wat slims weten wat ik over het hoofd zie

[lxz]

Weet niet of het case sensitive is, maar je hebt entrypoints staan bij websiteX en entryPoints bij websiteX-secure.

[joost308]

thnx voor de hulp . Jullie opmerkingen zaten in de goede richting.
Blijkbaar waren mijn file based hosts niet allemaal gemaakt vanuit dezelfde template . In 2 bestanden zat een typo. In 2.2.x (en lager) gaat hij gewoon door en werkt het (maar niet helemaal zoals bedacht) maar in 2.3.x valt hij erover en gaat hij inderdaad niet door met het laden van de directory based configs.
Mijn issue zat in 2 configs waar middelware ipv middleware stond . Ik heb voor de zekerheid ook de "" en `` nu conform de handleiding toegepast en alle configs opgeschoond/gelijk getrokken en presto... kan bijwerken naar 2.3.x zonder problemen.

[JBS]

Gebruik al een tijdje Traefik 1, en wilde nu de overstap naar 2 maken waarbij ik deze tutorial volg https://blog.jswart.xyz/posts/traefik-routing/
Bij het starten van de Traefik V2 container zie ik in de log

level=error msg="The ACME resolver \"letsencrypt\" is skipped from the resolvers list because: unable to get ACME account: permissions 755 for acme.json are too open, please use 600"

<knip>

\\Edit: Middels 'touch' acme.json aanmaken, dan de rechten naar 600 zetten en dan de Traefik v2 docker starten lost het probleem om.

[ Voor 36% gewijzigd door JBS op 17-12-2020 18:11 ]

[JBS]

Gisteren succesvol gemigreerd van Traefik 1 naar 2. Beide in Docker, dus had Traefik 1 achter de hand mocht het met 2 niet lukken. Op de een of andere manier lukte het werken met labels in mijn Docker Compose met Traefik 1 niet, met Traefik 2 werkt dat wel.

Drie punten:

• Waar ik vooral tegenaan gelopen ben, is dat de werkwijze rondom het werken met losse rule files in 2.2 anders werkt dan in 2.3. Mijn opzet met rule files werkte in 2.3 niet, in 2.2 direct.
  Toevallig mensen van 2.2 of lager naar 2.3 geüpgraded die hier ook tegenaan gelopen zijn?
• De labels voor Docker Compose heb ik gemaakt op basis van de labels onder 'Container Configuration' in deze tutorial https://blog.jswart.xyz/posts/traefik-routing/
  Wat me opvalt is dat het werkt met en zonder het laatste label, dat vind ik wat verwarrend. Is dat logisch?

  - traefik.http.services.servicename.loadbalancer.server.port=serviceport

• Iemand hier Traefik 2.x goed kunnen inregelen voor de Docker container linuxserver/unifi-controller? Zowel met Docker Compose labels als met een file rule wil het niet werken en krijg ik een Internal Server Error terug. Benaderen op INTERN_IPADRES:PORT werkt uiteraard wel gewoon.

[ Voor 43% gewijzigd door JBS op 18-12-2020 15:53 ]

[mithras]

JBS schreef op vrijdag 18 december 2020 @ 15:26:
Drie punten:

• De labels voor Docker Compose heb ik gemaakt op basis van de labels onder 'Container Configuration' in deze tutorial https://blog.jswart.xyz/posts/traefik-routing/
Wat me opvalt is dat het werkt met en zonder het laatste label, dat vind ik wat verwarrend. Is dat logisch?
[...]

Staat ook in de documentatie, maar de service wordt automatisch aangemaakt als je die niet defineert (of koppelt aan een routere). Als een docker container één poort exposed, pakt Traefik die poort. Als je een container hebt met meerdere poorten, moet je sowieso de loadbalancer service gebruiken omdat Traefik niet kan gokken hoe het verkeer moet lopen.

• Iemand hier Traefik 2.x goed kunnen inregelen voor de Docker container linuxserver/unifi-controller? Zowel met Docker Compose labels als met een file rule wil het niet werken en krijg ik een Internal Server Error terug. Benaderen op INTERN_IPADRES:PORT werkt uiteraard wel gewoon.

Laat je definitie eens zien?

[JBS]

mithras schreef op zaterdag 19 december 2020 @ 13:04:
[...]
Staat ook in de documentatie, maar de service wordt automatisch aangemaakt als je die niet defineert (of koppelt aan een routere). Als een docker container één poort exposed, pakt Traefik die poort. Als je een container hebt met meerdere poorten, moet je sowieso de loadbalancer service gebruiken omdat Traefik niet kan gokken hoe het verkeer moet lopen.

[...]
Laat je definitie eens zien?
Duidelijk. Voor de UniFi container is die regel dus wel nodig, maar ook mét die regel werkt het niet. Met onderstaande labels krijg ik een 'Bad Gateway'

YAML:

unifi-controller:
  image: linuxserver/unifi-controller
  container_name: unifi-controller
  environment:
    - PUID=1000
    - PGID=1000
  volumes:
    - ${USERDIR}/docker/unifi:/config
  ports:
    - 3478:3478/udp
    - 10001:10001/udp
    - 8080:8080
    - 8081:8081
    - 8443:8443
    - 8843:8843
    - 8880:8880
    - 6789:6789
  restart: unless-stopped
  labels:
    - traefik.enable=true
    - traefik.http.middlewares.unifi-redirect.redirectscheme.scheme=https
    - traefik.http.routers.unifi-redirect.entrypoints=web
    - traefik.http.routers.unifi-redirect.middlewares=unifi-redirect
    - traefik.http.routers.unifi-redirect.rule=Host(`unifi.domeinnaam.nl`)
    - traefik.http.routers.unifi.entrypoints=websecure
    - traefik.http.routers.unifi.rule=Host(`unifi.domeinnaam.nl`)  
    - traefik.http.routers.unifi.tls.certresolver=letsencrypt     
    - traefik.http.services.code.loadbalancer.server.port=8443

Ook met onderstaande rule toml file krijg ik deze 'Bad Gateway'

YAML:

[http]
 [http.middlewares]
   [http.middlewares.unifi-redirect.redirectScheme]
       scheme = "https"

 [http.routers.unifi-redirect]
   entrypoints = ["web"]
   rule = "Host(`unifi.domeinnaam.nl`)"
   middlewares = ["unifi-redirect"]
   service = "unifi"

 [http.routers.unifi]
   entrypoints = ["websecure"]
   rule = "Host(`unifi.domeinnaam.nl`)"
   service = "unifi"
   [http.routers.unifi.tls]
       certResolver = "letsencrypt"

 [http.services]
   [http.services.unifi.loadbalancer]
     [[http.services.unifi.loadBalancer.servers]]
       url = "https://192.168.178.24:8443"

Dit terwijl https://192.168.178.24:8443 gewoon netjes de UniFi controller opent.

[lolgast]

@JBS Misschien is hij onvolledig, maar ik zie geen network in je docker-compose file..? Dan kan hij ook niet aan Traefik gekoppeld zijn lijkt me.

Verder moet er volgens mij iets van https://doc.traefik.io/tr...rview/#insecureskipverify toegevoegd worden aan Traefik om de Unifi Controller te laten werken

[JBS]

@lolgast De docker netwerken kan ik inderdaad nog netter/beter toepassen, maar zonder hiervan iets in de Docker Compose op te nemen komt ie in docker_default.

YAML:

[serversTransport]
  insecureSkipVerify = true

Bovenstaande opgenomen in traefik.toml en de Docker Compose labels aangepast naar en het is opgelost.

YAML:

labels:
    - traefik.enable=true
    - traefik.http.routers.unifi.rule=Host(`unifi.domeinnaam.nl`)
    - traefik.http.routers.unifi.entrypoints=websecure
    - traefik.http.routers.unifi.tls=true
    - traefik.http.routers.unifi.tls.certresolver=letsencrypt
    - traefik.http.services.unifi.loadbalancer.server.scheme=https
    - traefik.http.services.unifi.loadbalancer.server.port=8443

Thanks voor de goede richting @lolgast !

[ Voor 118% gewijzigd door JBS op 19-12-2020 14:29 ]

[lolgast]

@JBS Ik weet het! Voeg dit label eens toe

YAML:

      - traefik.http.services.unifi.loadbalancer.server.scheme=https

Lekker snugger van me, er was al een edit...

[ Voor 20% gewijzigd door lolgast op 19-12-2020 14:43 ]

[kdbruin]

Ook hier aan het stoeien om over te stappen van v1 naar v2. Hierbij maak ik gebruik van de beschrijving op https://www.smarthomebeginner.com/traefik-2-docker-tutorial/ welke ik ook gebruikt heb voor de v1 configuratie. Aangezien ik via Dyn een domain naam heb, heb ik daarvoor wat aanpassingen gemaakt maar als ik naar de dashboard pagina van Traefik ga, krijg ik "too many redirects" als error. Ik zie wel dat er netjes een LE certificaat is aangevraagd en opgeslagen.

Ik gebruik de volgende docker compose file:

code:

version: "3.7"

########################### NETWORKS
networks:
  t2_proxy:
    external:
      name: t2_proxy
  default:
    driver: bridge

########################### SERVICES
services:

# Traefik 2 - Reverse Proxy
  traefik:
    container_name: traefik
    # the chevrotin tag refers to v2.2.x but introduced a breaking change in 2.2.2
    image: traefik:2.2.1
    restart: unless-stopped
    command: # CLI arguments
      - --global.checkNewVersion=true
      - --global.sendAnonymousUsage=true
      - --entryPoints.http.address=:80
      - --entryPoints.https.address=:443
      - --entryPoints.traefik.address=:8080
      - --api=true
#      - --api.insecure=true
#      - --serversTransport.insecureSkipVerify=true
      - --log=true  
      - --log.level=DEBUG # (Default: error) DEBUG, INFO, WARN, ERROR, FATAL, PANIC
      - --accessLog=true
      - --accessLog.filePath=/traefik.log
      - --accessLog.bufferingSize=100 # Configuring a buffer of 100 lines
      - --accessLog.filters.statusCodes=400-499
      - --providers.docker=true
      - --providers.docker.endpoint=unix:///var/run/docker.sock
      - --providers.docker.defaultrule=Host(`{{ index .Labels "com.docker.compose.service" }}.$DOMAINNAME`)
      - --providers.docker.exposedByDefault=false
      - --providers.docker.network=t2_proxy
      - --providers.docker.swarmMode=false
      # Load dynamic configuration from one or more .toml or .yml files in a directory.
      - --providers.file.directory=/rules
      - --providers.file.watch=true # Only works on top level files in the rules folder
      - --certificatesResolvers.lets-encrypt.acme.email=$LETSENCRYPT_EMAIL
      - --certificatesResolvers.lets-encrypt.acme.storage=/acme.json
      - --certificatesResolvers.lets-encrypt.acme.httpChallenge.entryPoint=http
    networks:
      - t2_proxy  
    security_opt:
      - no-new-privileges:true
    ports:
      - target: 80
        published: 80   
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host
      - target: 8080
        published: 8080
        protocol: tcp
        mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - $DOCKERDIR/traefik2/rules:/rules
      - $DOCKERDIR/traefik2/acme/acme.json:/acme.json
      - $DOCKERDIR/traefik2/traefik.log:/traefik.log
      - $DOCKERDIR/shared:/shared
    environment:  
      - LE_EMAIL=$LETSENCRYPT_EMAIL
    labels:
      - "traefik.enable=true"
      # HTTP-to-HTTPS Redirect
      - "traefik.http.routers.http-catchall.entrypoints=http"
      - "traefik.http.routers.http-catchall.rule=HostRegexp(`{host:.+}`)"
      - "traefik.http.routers.http-catchall.middlewares=redirect-to-https"
      - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
      # HTTP Routers  
      - "traefik.http.routers.traefik-rtr.entrypoints=https"
      - "traefik.http.routers.traefik-rtr.rule=Host(`traefik.$DOMAINNAME`)"
      - "traefik.http.routers.traefik-rtr.tls=true"
      - "traefik.http.routers.traefik-rtr.tls.certresolver=lets-encrypt"
      ## Middlewares 
      - "traefik.http.routers.traefik-rtr.middlewares=middlewares-basic-auth@file"

Voor HTTP authenticatie is de volgende middleware gedefinieerd:

code:

[http.middlewares]
  [http.middlewares.middlewares-basic-auth]
    [http.middlewares.middlewares-basic-auth.basicAuth]
      realm = "Traefik2 Basic Auth"
      # Be sure to mount the volume through docker-compose.yml
      usersFile = "/shared/.htpasswd"

Als ik naar http://traefik.mijn-domein/dashboard/ ga dan wordt eerst om het wachtwoord gevraagd en daarna krijg ik een "too many redirects" error. Ik zie wel dat in de adresbalk dan https staat in plaats van http. Ook zie ik dat er netjes een certificaat door Let's Encrypt is opgehaald voor het genoemde domein.

Ik ben al diverse malen over de code gegaan maar zie geen rare dingen. Suggesties?

[Jazco2nd]

@kdbruin deze methode is veel simpeler en werkt hier heel goed: https://blog.jswart.xyz/posts/traefik-routing/
Ook voor services die niet in Docker draaien: https://blog.jswart.xyz/posts/traefik-without-containers/
Smarthomebeginner heeft echt nogal overdreven guides merk ik. Het heeft me wel goed op weg geholpen met mijn homeserver maar ik gebruik nooit de volledige methodes die ze daar schrijven.


Andere vraag:
Weet iemand misschien een simpele SMTP container die werkt icm Traefik in Docker?
Ik gebruikte https://github.com/namshi/docker-smtp maar dan komen alle mails die door je docker containers worden gestuurd in je spam. Het moet dus via een TLS verbinding verzonden worden.

Ik heb nog geen concreet voorbeeld gevonden van een smtp container icm Traefik labels voor de certificaten.

[ Voor 36% gewijzigd door Jazco2nd op 29-12-2020 23:48 ]

[kdbruin]

@Jazco2nd Ik had daar ook al even gekeken maar zal het nog wat beter gaan bestuderen, vooral hoe ik met Let's Encrypt aan de gang kan zonder gebruik te maken van Cloudflare CDN.

[qwasd]

Jazco2nd schreef op dinsdag 29 december 2020 @ 23:46:
@kdbruin deze methode is veel simpeler en werkt hier heel goed: https://blog.jswart.xyz/posts/traefik-routing/
Ook voor services die niet in Docker draaien: https://blog.jswart.xyz/posts/traefik-without-containers/
Smarthomebeginner heeft echt nogal overdreven guides merk ik. Het heeft me wel goed op weg geholpen met mijn homeserver maar ik gebruik nooit de volledige methodes die ze daar schrijven.


Andere vraag:
Weet iemand misschien een simpele SMTP container die werkt icm Traefik in Docker?
Ik gebruikte https://github.com/namshi/docker-smtp maar dan komen alle mails die door je docker containers worden gestuurd in je spam. Het moet dus via een TLS verbinding verzonden worden.

Ik heb nog geen concreet voorbeeld gevonden van een smtp container icm Traefik labels voor de certificaten.

Is het met deze methode ook mogelijk Google OAuth in te richten in combinatie met Cloudflare?
Die uitleg van smarthomebeginner is inderdaad heel overdreven en ook op basis van de oude versie.
Ik draai nu nginx proxy manager en wil graag overstappen maar het lukt nog niet echt.
Wil graag unifi controller en bitwarden configureren maar nog een extra layer authenticatie d.m.v. Google OAuth.

[Jazco2nd]

@qwasd geen idee. Maar je noemt nou net 1 ding die ik ook heb en het nut niet inzie om deze online te exposen: Unifi Controller. Die draait bij mij ook. Maar doet gewoon z'n ding. Waarom zou je daarbij willen komen wanneer je niet thuis bent?

Voor paswoorden gebruik ik Keepass, het DB bestandje van Keepass wordt gewoon gesynced met mijn devices (Syncthing) dus heb ik het ook niet voor nodig..
En voor File management gebruik ik FileRun ipv Nextcloud, simpeler, lichter en veel sneller. Die heeft 2FA ingebouwd.

Maar ik had wel dit gebookmarked voor als ik een service ga draaien die het wel nodig heeft, omdat het niet-Google is en zou werken icm Traefik:

https://github.com/authelia/authelia

[ Voor 13% gewijzigd door Jazco2nd op 30-12-2020 11:49 ]

[qwasd]

Jazco2nd schreef op woensdag 30 december 2020 @ 11:48:
@qwasd geen idee. Maar je noemt nou net 1 ding die ik ook heb en het nut niet inzie om deze online te exposen: Unifi Controller. Die draait bij mij ook. Maar doet gewoon z'n ding. Waarom zou je daarbij willen komen wanneer je niet thuis bent?

Voor paswoorden gebruik ik Keepass, het DB bestandje van Keepass wordt gewoon gesynced met mijn devices (Syncthing) dus heb ik het ook niet voor nodig..
En voor File management gebruik ik FileRun ipv Nextcloud, simpeler, lichter en veel sneller. Die heeft 2FA ingebouwd.

Maar ik had wel dit gebookmarked voor als ik een service ga draaien die het wel nodig heeft, omdat het niet-Google is en zou werken icm Traefik:

https://github.com/authelia/authelia

De web interface heb ik wel eens nodig om wat aan te passen.
Maar ik heb het inmiddels voor elkaar.

Ik heb nu een docker draaien met Traefik versie 2.3.6
Echter werkt unifi (8443) alleen met een tcp router en heb dus 2FA geconfigureerd met een koppeling naar mijn account op ui.com. Dus wel 2FA op mijn on premise Unifi controller.
Voor overige applicaties heb ik nu Google Oauth beschikbaar als ik deze nodig heb.
Per applicatie kan ik nu kiezen voor geen, basic of auth authenticatie d.m.v. een label in Docker.

Authelia zag ik inderdaad ook voorbij komen op https://www.smarthomebeginner.com/docker-authelia-tutorial. Binnenkort maar eens naar kijken...

Het enige waar ik nu nog tegenaan loopt is dat ik de dashboard (web) van Traefik niet op ip kan benaderen (bijvoorbeeld zonder authenticatie) op mijn LAN. Iemand die weet hoe ik dit kan oplossen?

[ Voor 6% gewijzigd door qwasd op 30-12-2020 16:59 ]

[lolgast]

@qwasd Dat komt waarschijnlijk omdat je die poort vanaf je host niet doorzet naar je dockercontainer, maar hem via de URL rechtstreeks aanspreekt naar het container IP-adres.

Als je dat lokaal op IP:PORT wilt laten werken zul je dus je docker-compose file even moeten aanvullen met dat poortnummer

[qwasd]

lolgast schreef op maandag 4 januari 2021 @ 12:04:
@qwasd Dat komt waarschijnlijk omdat je die poort vanaf je host niet doorzet naar je dockercontainer, maar hem via de URL rechtstreeks aanspreekt naar het container IP-adres.

Als je dat lokaal op IP:PORT wilt laten werken zul je dus je docker-compose file even moeten aanvullen met dat poortnummer

Nee dit was het niet.
Het was dat insecure mode op off stond en ik de dashboard api moest allowen met een regel. Opgelost dus.

[Jazco2nd]

Vraagje, ik gebruik een service (FileRun, soort NextCloud maar niet open source, max 10 users gratis) waarbij de licentie is gekoppeld aan mijn sub.domein.tld. Erg irritant, je kan je subdomein niet wijzigen, dan werkt de service niet ivm "license is linked to a different domain".

Nu gebruik ik de volgende labels voor deze dienst:

Hoe kan ik hier een redirect toevoegen zodat ik ook bbb.domein.tld kan gebruiken? Dat deze gewoon redirect doet naar aaa.domein.tld, zodat de service nog gewoon daaraan gekoppeld blijft?

code:

    labels:
      - traefik.enable=true
      - traefik.http.middlewares.filerun-redirect.redirectscheme.scheme=https
      - traefik.http.routers.filerun-redirect.entrypoints=web
      - traefik.http.routers.filerun-redirect.middlewares=filerun-redirect
      - traefik.http.routers.filerun-redirect.rule=Host(`aaa.$DOMAIN`)
      - traefik.http.routers.filerun.entrypoints=websecure
      - traefik.http.routers.filerun.rule=Host(`aaa.$DOMAIN`)
      - traefik.http.routers.filerun.tls.certresolver=letsencrypt
      - traefik.http.services.filerun.loadbalancer.server.port=80

Ik had eerst gewoon bij mijn domeinprovider een CNAME ingesteld van aaa.domein.tld naar bbb.domein.tld (naast de bestaande CNAME aaa.domein.tld > domein.tld). Dat werkt niet. CNAME ALIAS ook niet. Ik begrijp dat dat ook niet gaat werken, een redirect moet de webserver verzorgen.
Maar hoe moet ik dan bbb.domein.tld registreren bij mijn domeinprovider om dit te laten werken?

Ik ben echt een traefik noob, maar besteed heel af en toe uren en uren, veel trial en error om dingen werkend te krijgen. Die post ik dan ook direct op github voor de betreffende services. Dit stukje, kan ik niet zo gauw iets simpels voor vinden om te testen, zonder risico dat ik mijn huidige labels stukmaak.

[ Voor 11% gewijzigd door Jazco2nd op 10-01-2021 02:13 ]

[lolgast]

@Jazco2nd Ik heb er geen ervaring mee, maar je zou een redirectregex kunnen gebruiken.
https://doc.traefik.io/traefik/middlewares/redirectregex/

Je CNAME/A-record moet uiteraard blijven bestaan, anders is je IP voor die url niet publiekelijk bekend

Zou ik nu ik er over nadenk eens moeten opzetten, ik heb nu een nginx containertje met 1 pagina draaien voor een simpele redirect🙈

[ Voor 16% gewijzigd door lolgast op 10-01-2021 13:20 ]

[lxz]

Ik gebruik hier inderdaad ook een redirect container voor, namelijk deze: https://hub.docker.com/r/schmunk42/nginx-redirect/

Ben benieuwd of dat ook (handiger) kan met traefik.

[lolgast]

Het kan slimmer/handiger/met Traefik
@lxz @Jazco2nd

YAML:

  test:
    image: nginx:alpine
    restart: always
    container_name: nginx-test
    labels:
      - traefik.http.routers.nginx-test.rule=Host("nextnextfinish-it.nl")
      - traefik.http.routers.nginx-test.entrypoints=https
      - traefik.http.routers.nginx-test.tls=true
      - "traefik.http.routers.nginx-test.middlewares=test-redirectregex"
      - "traefik.http.middlewares.test-redirectregex.redirectregex.regex=^https://nextnextfinish-it.nl/"
      - "traefik.http.middlewares.test-redirectregex.redirectregex.replacement=https://tweakers.net"
      - traefik.enable=true
    networks:
      - traefik

Bovenstaande redirect https://nextnextfinish-it.nl naar https://tweakers.net (ja je kunt dat testen ). Zonder dat je daar een HTML file voor hoeft te maken. Bovenstaande doet niet heel veel meer dan de container van @lxz natuurlijk, je moet nog steeds een aparte container draaien. Maar als je de labels onderdeel zou maken van de traefik container zelf of in het geval van @Jazco2nd van de service die je toch moet draaien, dan heeft het wel meerwaarde in mijn ogen

In mijn geval echter draaide ik voorheen een containertje dat de volgende pagina serveerde en dan is het draaien via Traefik wel een heel stuk sneller in het redirecten. (zo hoef ik 'ons' nummer bij AFAS niet te onthouden en kan ik toch overal de omgeving openen zonder na te denken )

HTML:

<html>
<meta http-equiv="refresh" content="0; URL='https://63251.afasinsite.nl/'" />
</html>

---

edit:
Een groot voordeel is dat je services kunt combineren als ze via een subdomein beschikbaar zijn

YAML:

  test:
    image: nginx:alpine
    restart: always
    container_name: nginx-nnf
    labels:
      - com.centurylinklabs.watchtower.enable=true
      - traefik.http.routers.nginx-nnf.rule=HostRegexp("nextnextfinish-it.nl", "{subdomain:[a-z]+}.nextnextfinish-it.nl")
      - traefik.http.routers.nginx-nnf.entrypoints=https
      - traefik.http.routers.nginx-nnf.tls=true
      - "traefik.http.routers.nginx-nnf.middlewares=nnf-redirectregex,test-redirectregex"
      - "traefik.http.middlewares.nnf-redirectregex.redirectregex.regex=^https://nextnextfinish-it.nl/"
      - "traefik.http.middlewares.nnf-redirectregex.redirectregex.replacement=https://tweakers.net"
      - "traefik.http.middlewares.test-redirectregex.redirectregex.regex=^https://test.nextnextfinish-it.nl/"
      - "traefik.http.middlewares.test-redirectregex.redirectregex.replacement=https://63251.afasinsite.nl"
      - traefik.enable=true
    networks:
      - traefik

Bovenstaande redirect de hoofdpagina naar Tweakers, en mijn test subdomein naar AFAS. In 1 container. Alle subdomeinen die buiten de regex vallen komen gewoon op index.html binnen.

[ Voor 35% gewijzigd door lolgast op 10-01-2021 13:56 ]

[bart.koppers]

Nice!
Vraag me af of als de redirect plaats vindt vóór de container wordt bereikt, of er dan nog wel een Nginx-container voor nodig is.
(Voor een fallback, ja)

Het kan denk Ik zelfs zonder container, via de @file directive

[lolgast]

@bart.koppers Nee daar is geen aparte container voor nodig. Als je dit toevoegt aan je toch al draaiende Traefik container ben je klaar.

Ik heb bovenstaande nu draaien via een nginx:alpine container zonder volumemappings. Maar je hebt íets nodig om de labels/middlewares aan te hangen

[RobertMe]

lolgast schreef op zondag 10 januari 2021 @ 20:08:
@bart.koppers Nee daar is geen aparte container voor nodig. Als je dit toevoegt aan je toch al draaiende Traefik container ben je klaar.

Ik heb bovenstaande nu draaien via een nginx:alpine container zonder volumemappings. Maar je hebt íets nodig om de labels/middlewares aan te hangen

Maar dat gaat natuurlijk alleen op als je de Docker provider gebruikt. Als je de file provider gebruikt kun je daarin de router + een (dummy) service + de middleware vastleggen. Dan hoef je het ook niet aan een container te koppelen.

[bart.koppers]

RobertMe schreef op zondag 10 januari 2021 @ 21:21:
[...]
Als je de file provider gebruikt kun je daarin de router + een (dummy) service + de middleware vastleggen. Dan hoef je het ook niet aan een container te koppelen.

Klopt, met file-provider net even getest, en dat gaat echt prima.
Geen container nodig
Omdat de rules dynamisch worden uitgelezen bij mij, een kwestie van - toch wel nauwkeurig opgesteld - bestandje plaatsen en allerlei redirects zijn mogelijk.

Echt mooi spul, Traefik.

[lolgast]

Werkt inderdaad ook prima. Voor de volledigheid, dit is de dezelfde config maar dan via de file-provider. En dan heb je inderdaad geen extra container nodig, dus zo draait het nu bij mij. Goede toevoeging

YAML:

http:
  routers:
    nnf:
      entryPoints:
        - https
      service: service-nnf
      rule: HostRegexp("nextnextfinish-it.nl", "{subdomain:[a-z]+}.nextnextfinish-it.nl")
      tls: {}
      middlewares:
        - nnf-redirect@file
        - test-redirect@file
  
  middlewares:
    nnf-redirect:
      redirectRegex:
        regex: "^https://nextnextfinish-it.nl/"
        replacement: "https://tweakers.net"

    test-redirect:
      redirectRegex:
        regex: "^https://test.nextnextfinish-it.nl/"
        replacement: "https://63251.afasinsite.nl"

  services:
    service-nnf:
      loadBalancer:
        servers:
          - url: localhost

[M4RTiN]

Ik ben aan het experimenteren met DNS challenge, zodat ik wildcard certificaten kan gebruiken. maar ik heb geen provider die ondersteund wordt door Traefik.

Weet iemand dat als ik de manual methode ga gebruiken, dat ik éénmalig dns records moet updaten, of dat dit elke keer moet gebeuren wanneer het certificaat wordt vernieuwd?

[peterstr]

Dat moet iedere 3 maanden gebeuren.

Wat je kunt doen is je privoder vragen of je via een API of andere methode dit proces kunt automatiseren.

ik zelf zit bijk bhosted en heb dt eens gevraagd. En mij werd gezegd dat dit zou kunnen ben alleen even de link kwijt naar de methode's die ze me aangaven. Heb het zelf ook nooit geprobeerd.

Waar het op neer komt is dat je middels scripts een DNS text record kunt aanpassen. En daarvoor moet je dus iets van een geautomatiseerde inlog procedure hebben.

[peterstr]

Maar je kunt ook voor ieder subdomain dat je hebt een eigen certificaat laten maken door Traefik. Dan heb je geen omkijken naar de verleningen. Dan kan Traefik dat samen met Lets-Encrypt zonder dat je die DNS challenche handmatig moet aanpassen.

[M4RTiN]

Ik zal er induiken met m'n provider,ben bang dat daar niet veel gaat uitkomen.

Ik wil graag de wildcard gebruiken zodat ik een intern ip adres via een interne DNS server op een fqdn kan laten werken. We krijgen nu zo vaak een certificaat error waar we graag vanaf willen.

[peterstr]

Toevallig vandaag op het docker forum ook iemand tegengekomen die ook certificaten oor lokaal gebruik wilde hebben. Hij is uitgekomen op stunnel.org . Misschien ook iets voor jou.

https://forums.docker.com/t/ssl-for-docker-apps/102903/

[qwasd]

M4RTiN schreef op woensdag 13 januari 2021 @ 21:33:
Ik ben aan het experimenteren met DNS challenge, zodat ik wildcard certificaten kan gebruiken. maar ik heb geen provider die ondersteund wordt door Traefik.

Weet iemand dat als ik de manual methode ga gebruiken, dat ik éénmalig dns records moet updaten, of dat dit elke keer moet gebeuren wanneer het certificaat wordt vernieuwd?

Waarom zet je je domein/dns van je huidige provider niet naar cloudflare? Met cloudflare kun je dmv een api key heel makkelijk gebruik maken van de DNS challenge in Traefik.

[qwasd]

M4RTiN schreef op woensdag 13 januari 2021 @ 23:32:
Ik zal er induiken met m'n provider,ben bang dat daar niet veel gaat uitkomen.

Ik wil graag de wildcard gebruiken zodat ik een intern ip adres via een interne DNS server op een fqdn kan laten werken. We krijgen nu zo vaak een certificaat error waar we graag vanaf willen.

Dit gebruik ik ook maar dan met Cloudflare.
Mijn domein zit echter bij Neostrada.
DNS servers kun je dan bij je hosting partij laten verwijzen naar Cloudlare (Free subscription).

Zelf heb ik mijn traefik niet open staan voor het internet (80+443). Wildcard certificaat wordt gedaan via DNS challenge.

Een voorbeeld voor mijn Bitwarden (password manager) docker is dat ik wel een A host (record) heb aangemaakt in Cloudflare die verwijst naar mijn interne ip (192.168.1.10 / non proxied) van mijn docker machine. (dit kan uiteraard ook gewoon op je router als die dit ondersteunt of een interne dns server).

Op deze manier kan ik als ik niet thuis ben met VPN (Wireguard) connecten naar thuis en werkt Bitwarden dus met SSL door de Traefik Proxy.

Hetzelfde geldt voor als ik geen gebruik maak van VPN en gewoon thuis ben verbonden met wifi.
Zo heb ik bijvoorbeeld mijn Edgerouter en Edgeswitch ook voorzien van de wildcard certificaat. Hier gebruik ik dan een afzonderlijke yml bestand voor met de router/service.

[ Voor 15% gewijzigd door qwasd op 14-01-2021 03:41 ]

[lolgast]

Ik gebruik intern gewoon dezelfde FQDN als extern. Dan kun je gebruik maken van hetzelfde certificaat.

Overigens was het willen gebruiken van een wildcard certificate voor mij de reden om over te stappen op TransIP destijds

[Hmmbob]

+1 voor beide statements: ik gebruik dezelfde namen voor zowel intern als extern, en wildcard via TransIP.

Enig dingetje wat je kán hebben is "hairpin NAT" issues, dat je router het niet snapt/goed verwerkt als je vanaf je LAN een server probeert te benaderen die ook op je LAN zit, maar via het externe IP.

[peterstr]

Hmmbob schreef op donderdag 14 januari 2021 @ 10:08:
Enig dingetje wat je kán hebben is "hairpin NAT" issues, dat je router het niet snapt/goed verwerkt als je vanaf je LAN een server probeert te benaderen die ook op je LAN zit, maar via het externe IP.

Ik Gebruik hiervoor de interne DNS server op mijn router (Mikrotik) waar ik dezelfde domein namen gebruik als extern maar dan met de interne adressen. De clients zoeken eerst de interne DNS op voordat ze buiten de deur gaan kijken en dus krijg je dan je interne adres terug.

Ik heb overigens voor iedere domein naam een eigen certificaat. Werkt ook goed.

[lolgast]

Ik gebruik AdGuard om reclame te blokkeren en al mijn devices hebben die dus als DNS servers. AdGuard kan ook zogenaamde DNS-rewrites uitvoeren dus daar staan mijn domeinen gewoon naar het interne IP van Traefik. Met uitzondering van 1 URL, die draait op mijn Home Assistant omgeving.


Kan niet zeggen dat ik hierdoor ooit issues heb gehad

[Hmmbob]

Heej, interessant! Nu gebruik ik zelf ook AdGuard, maar dankzij de NAT loopback op de (Mikrotik) router geen last meer. Wel mooie oplossing zo!

[M4RTiN]

peterstr schreef op donderdag 14 januari 2021 @ 10:14:
[...]


Ik Gebruik hiervoor de interne DNS server op mijn router (Mikrotik) waar ik dezelfde domein namen gebruik als extern maar dan met de interne adressen. De clients zoeken eerst de interne DNS op voordat ze buiten de deur gaan kijken en dus krijg je dan je interne adres terug.

Ik heb overigens voor iedere domein naam een eigen certificaat. Werkt ook goed.

Zo heb ik het vandaag ook opgelost :-)

[mca2]

Ik probeer al een tijdje wildcard certificaten aan de praat te krijgen. HTTP-challenge ging prima maar wildcards is toch andere koek. NB, het gaat hier om een simpele thuis server met een paar apps erin, ik ben dus zou vrij geweest alles in 1 docker-compose.yml te zetten maar ik krijg de foutmelding

code:

error msg="Unable to obtain ACME certificate for domains \"\" : unable to generate a certificate in ACME provider when no domain is given" providerName=myresolver.acme

Maar hij heeft veel de default certificaten voor al mijn domains die ik bij TransIP heb, dus die api lijkt wel te werken

code:

debug msg="Serving default certificate for request: \"domain.com\""`

code:

version: "3.3"

services:
        traefik:
                image: "traefik:v2.3"
                container_name: "traefik"
                command:
                        - "--log.level=DEBUG"
                          # allow dashboard access without password, default port 8080
                        - "--api.insecure=true"
                        - "--api.dashboard=true"
                          # enable docking provider
                        - "--providers.docker=true"
                          # do not expose docker, unless told so
                        - "--providers.docker.exposedbydefault=false"
                          # entrypoints
                        - "--entrypoints.web.address=:80"
                        - "--entrypoints.websecure.address=:443"
                          # https redirection
                        - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
                        - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
                        - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
                          # http challenge
                          #- "--certificatesresolvers.myresolver.acme.httpchallenge=true"
                          # - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
                          # dns challenge
                        - "--certificatesresolvers.myresolver.acme.dnschallenge=true"
                        - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=transip"
                        - "--certificatesresolvers.myresolver.acme.dnschallenge.delayBeforeCheck=0"
                        - "--certificatesResolvers.myresolver.acme.dnschallenge.resolvers=ns0.transip.net"
                        - "--certificatesresolvers.myresolver.acme.email=[e-mail]"
                        - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.traefik.tls.certresolver=myresolver"
                        - "traefik.http.routers.traefik.tls.domains.main=domain.com"
                        - "traefik.http.routers.traefik.tls.domains.sans=*domain.com"
                ports:
                        - "80:80"
                        - "443:443"
                          # port for dashboard api
                        - "8080:8080"
                environment:
                        - "TRANSIP_ACCOUNTNAME_FILE=[e-mail]"
                        - "TRANSIP_PRIVATE_KEY_PATH=./transip_private.key"
                volumes:
                        - "./letsencrypt:/letsencrypt"
                        - "/var/run/docker.sock:/var/run/docker.sock:ro"
                        - "./transip_private.key:/transip.key:ro"
        whoami:
                image: "traefik/whoami"
                container_name: "simple-service"
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.whoami.rule=Host(`whoami.domain.com`)"
                        - "traefik.http.routers.whoami.entrypoints=websecure"
                        - "traefik.http.routers.whoami.tls.certresolver=myresolver"
                        - "traefik.http.routers.whoami.middlewares=testauth"
                        - "traefik.http.middlewares.testauth.basicauth.users=user:XXXXXXXXXXXXX"

[ Voor 3% gewijzigd door mca2 op 16-01-2021 19:48 ]

[qwasd]

mca2 schreef op zaterdag 16 januari 2021 @ 17:31:
Ik probeer al een tijdje wildcard certificaten aan de praat te krijgen. HTTP-challenge ging prima maar wildcards is toch andere koek. NB, het gaat hier om een simpele thuis server met een paar apps erin, ik ben dus zou vrij geweest alles in 1 docker-compose.yml te zetten maar ik krijg de foutmelding

code:

error msg="Unable to obtain ACME certificate for domains \"\" : unable to generate a certificate in ACME provider when no domain is given" providerName=myresolver.acme

Maar hij heeft veel de default certificaten voor al mijn domains die ik bij TransIP heb, dus die api lijkt wel te werken

code:

debug msg="Serving default certificate for request: \"domain.com\""`

code:

version: "3.3"

services:
        traefik:
                image: "traefik:v2.3"
                container_name: "traefik"
                command:
                        - "--log.level=DEBUG"
                          # allow dashboard access without password, default port 8080
                        - "--api.insecure=true"
                        - "--api.dashboard=true"
                          # enable docking provider
                        - "--providers.docker=true"
                          # do not expose docker, unless told so
                        - "--providers.docker.exposedbydefault=false"
                          # entrypoints
                        - "--entrypoints.web.address=:80"
                        - "--entrypoints.websecure.address=:443"
                          # https redirection
                        - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
                        - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
                        - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
                          # http challenge
                          #- "--certificatesresolvers.myresolver.acme.httpchallenge=true"
                          # - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
                          # dns challenge
                        - "--certificatesresolvers.myresolver.acme.dnschallenge=true"
                        - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=transip"
                        - "--certificatesresolvers.myresolver.acme.dnschallenge.delayBeforeCheck=0"
                        - "--certificatesResolvers.myresolver.acme.dnschallenge.resolvers=ns0.transip.net"
                        - "--certificatesresolvers.myresolver.acme.email=[e-mail]"
                        - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.traefik.tls.certresolver=myresolver"
                        - "traefik.http.routers.traefik.tls.domains.main=domain.com"
                        - "traefik.http.routers.traefik.tls.domains.sans=*domain.com"
                ports:
                        - "80:80"
                        - "443:443"
                          # port for dashboard api
                        - "8080:8080"
                environment:
                        - "TRANSIP_ACCOUNTNAME_FILE=[e-mail]"
                        - "TRANSIP_PRIVATE_KEY_PATH=./transip_private.key"
                volumes:
                        - "./letsencrypt:/letsencrypt"
                        - "/var/run/docker.sock:/var/run/docker.sock:ro"
                        - "./transip_private.key:/transip.key:ro"
        whoami:
                image: "traefik/whoami"
                container_name: "simple-service"
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.whoami.rule=Host(`whoami.domain.com`)"
                        - "traefik.http.routers.whoami.entrypoints=websecure"
                        - "traefik.http.routers.whoami.tls.certresolver=myresolver"
                        - "traefik.http.routers.whoami.middlewares=testauth"
                        - "traefik.http.middlewares.testauth.basicauth.users=user:XXXXXXXXXXXXX"

Ik had dit laatst toen ik het bestand acme.json niet de juiste permissies had gegeven. (chmod 600)
Het kan natuurlijk ook ergens anders in zitten.
Zie onderstaande mijn settings maar dan met cloudflare.

code:

      - --entrypoints.https.http.tls.certresolver=dns-cloudflare
      - --entrypoints.https.http.tls.domains[0].main=$DOMAINNAME
      - --entrypoints.https.http.tls.domains[0].sans=*.$DOMAINNAME
      # - --entrypoints.https.http.tls.domains[1].main=$DOMAINNAME2 # Pulls main cert for second domain
      # - --entrypoints.https.http.tls.domains[1].sans=*.$DOMAINNAME2 # Pulls wildcard cert for second domain
      - --providers.docker.network=traefik_proxy
      - --providers.docker.swarmMode=false
      - --providers.file.directory=/rules # Load dynamic configuration from one or more .toml or .yml files in a directory
      - --providers.file.watch=true # Only works on top level files in the rules folder
      #- --certificatesResolvers.dns-cloudflare.acme.caServer=https://acme-staging-v02.api.letsencrypt.org/directory # LetsEncrypt Staging Server - uncomment when testing
      - --certificatesResolvers.dns-cloudflare.acme.email=$CLOUDFLARE_EMAIL
      - --certificatesResolvers.dns-cloudflare.acme.storage=/acme.json
      - --certificatesResolvers.dns-cloudflare.acme.dnsChallenge.provider=cloudflare
      - --certificatesResolvers.dns-cloudflare.acme.dnsChallenge.resolvers=1.1.1.1:53,1.0.0.1:53
      - --certificatesResolvers.dns-cloudflare.acme.dnsChallenge.delayBeforeCheck=90 # To delay DNS check and reduce LE hitrate

Ik zie wel dat je onderstaande niet in je docker-compose file hebt staan:

code:

- --entrypoints.https.http.tls.certresolver=dns-cloudflare

Wel heb je onderstaande in je labels staan (die heb ik er niet in staan):

code:

- "traefik.http.routers.traefik.tls.certresolver=myresolver"

Kun je anders debug log eens aanzetten en de log hier posten?

[ Voor 5% gewijzigd door qwasd op 16-01-2021 22:26 ]

[mca2]

een nulletje erbij deed wonderen

code:

- "traefik.http.routers.traefik.tls.domains[0].main=domain.com"
- "traefik.http.routers.traefik.tls.domains[0].sans=*.domain.com"

Alleen struikelt hij nu over de key-file

code:

level=debug msg="legolog: [WARN] [*.domain.com] acme: cleaning up failed:
transip: error for _acme-challenge.domain. in CleanUp: could not get token from
authenticator: error requesting token: Your key signature is invalid or API is not
enabled in your account

De api staat aan, met of zonder whitelisting maakt geen verschil en geeft dezelfde foutmelding. Ik heb een paar verschillende keys aangemaakt maar steeds met deze foutmelding. Welk vinkje mis ik?

Edit: mijn login was niet mijn mailadres maar de username

[ Voor 34% gewijzigd door mca2 op 17-01-2021 00:07 ]

[Jazco2nd]

Kan iemand mij helpen uitleggen waarom iets zomaar werkt, iets wat ik al lang wil uitproberen maar niet deed omdat ik bang was een halve dag te klooien zonder resultaat.

Ik heb Traefikv2 via het blog van Jean Swart dat hier vaak voorbij komt opgezet, via Docker, eigen domein, werkt.

4 services zijn via Traefik exposed online. 3 daarvan draaien in Docker en zijn dus via https://sub.mijndomein.mijntld bereikbaar.

Nu heb ik nog een aantal andere services die alleen binnen het LAN toegankelijk zijn. Ik baal dat ik steeds IP:poort moet invullen. Ik gebruik echter ook AdGuardHome, draait op dezelfde server buiten Docker om en is ingesteld als de DNS server in mijn router.

In AGH kan ik een DNS redirect instellen. Idealiter stel ik mijndomein.mijntld in met als IP het lokale LAN IP van mijn server. Dan zijn alle lokale docker services die daarop draaien bereikbaar via een makkelijke link:poort.

Maar ik was ervan overtuigd dat dat nooit zou kunnen werken: ik moet immers ook binnen LAN de https://sub.mijndomein.mijntld kunnen gebruiken, enkele van deze diensten weigeren namelijk te werken anders en van 1 is de licentie zelfs aan het domein gekoppeld.

ik heb daarom in AGH een ander domein verzonnen: anderdomein.tld die verwijst naar mijn interne LAN IP van de server. Puur en alleen voor mijn lokale services.

Nu stel ik net brutaal ook gewoon even mijndomein.mijntld in, verwijzend naar mijn LAN server IP. Tot mijn grote verbazing werkt HTTPS://sub.mijndomein.mijntld wel gewoon!

Hoe kan dat? De labels van Traefik verwachten toch juist dat je van buitenaf afkomstig bent, het SSL certificaat is toch vast ook wel gekoppeld aan je externe IP? Anders ben je toch niet "beveiligd"?

Ik dacht iets van Traefik te snappen.. maar juist nu iets werkt (wat ik graag wilde maar niet had verwacht) snap ik het niet meer..

[FireDrunk]

Een SSL certificaat is niet gekoppeld aan een IP adres, en als jouw browser het certificaat wat door Traefik opgestuurd wordt vertrouwd, is er niets aan de hand. Of dat certificaat via Wifi, ethernet, een Nullmodem kabel of een parkiet komt, maakt niet uit.

Wat je kan doen:

- Geef Traefik 2 IP Adressen, en maak op die 2 IP Adressen 2 Entrypoints aan.
- Forward in je router/modem poort 80 en 443 naar het eerste entrypoint
- Zet je interne DNS op het 2e entrypoint ( je interne IP adres, waar je modem dus *niet*) naar toe staat.
- Zet in de labels voor je interne services, dat ze alleen beschikbaar mogen zijn op het 2e entrypoint.

Dan zou het goed moeten gaan.

Waarom het nu werkt: Als services niet beperkt zijn tot een entrypoint, mag je van alle kanten traefik binnen komen, en worden alle services gewoon op alle kanten geleverd. Traefik ziet ook niet (zomaar) het verschil tussen intern en extern verkeer. Voor hem is het allemaal gewoon een HTTP verbinding.

[ Voor 18% gewijzigd door FireDrunk op 21-01-2021 07:59 ]

[lolgast]

@Jazco2nd
Ik heb het vermoeden dat je wat dingen niet snapt inderdaad. Gelukkig zijn er meerdere wegen naar Rome. Traefik heeft in mijn ogen een prima route aangelegd om te volgen

Traefik doet niets meer dan services publiceren via zijn eigen IP-adres. Als jij Traefik kan benaderen, kun je in principe alle services benaderen die je aan Traefik hebt gekoppeld. Natuurlijk snappen ze bij Traefik ook dat dat niet altijd wenselijk is. Daarom kun je verschillende methodes gebruiken om te zorgen dat je sommige services enkel vanaf bepaalde subnetten/IP-adressen kunt bereiken.

Ik heb bijvoorbeeld Proxmox draaien als hypervisor, met handige web UI. Deze hangt dus achter Traefik. Maar die mag absoluut niet via het internet benaderbaar zijn. Dus heb ik een middleware aangemaakt waarin staat welke IP-adressen wél gebruik mogen maken van die service: https://doc.traefik.io/traefik/middlewares/ipwhitelist/. Mijn code:

YAML:

http:
  middlewares:
    ipwhitelistinternal:
      ipWhiteList:
        sourceRange:
          - "192.168.4.0/24"
        ipStrategy:
          depth: 0

Op die manier haalt Traefik het certificaat voor je op, kun je de website benaderen op https://URL en hoef je niet bang te zijn dat hij vanaf buiten benaderd wordt.

De DNS rewrite in AdGuard laat je voor je domein gewoon naar het IP-adres/host-adres van Traefik verwijzen.

[Hmmbob]

Jazco2nd schreef op woensdag 20 januari 2021 @ 23:26:
Hoe kan dat? De labels van Traefik verwachten toch juist dat je van buitenaf afkomstig bent, het SSL certificaat is toch vast ook wel gekoppeld aan je externe IP? Anders ben je toch niet "beveiligd"?

Een certificaat is gekoppeld aan een server, niet aan een IP.

Wat je browser eigenlijk doet is:

Opzoeken van ip-adres van sub.mijndomein.mijntld. Welk IP adres dan ook (intern of extern) gebruikt hij om contact te leggen met de server: "Hallo server op IP ....., ik wil graag de pagina / van sub.mijndomein.mijntld van je ontvangen". De server reageert hierop met een sleuteluitwisseling op basis van het certificaat, waarna de vercijferde verbinding opgezet is en je de pagina toegestuurt krijgt.

Zo kun je dus ook veel verschillende hosts/pagina's hebben op 1 server: omdat jouw browser netjes aangeeft wat hij wil ontvangen van de server weet de server welk certificaat hij moet gebruiken om de beveiligde verbinding op te zeggen.

Hope this helps?

[Brggmn]

Is er iemand die dit al werkend heeft gekregen met versio als provider?

[TheDweep]

Heb sinds de kerst een RPi 4 cluster draaien met Portainer, Traefik 2, en Nextcloud. Ik wil hier Pi-hole en Firefly III aan toevoegen. Pihole loopt al vast op de compose file, dus ben eerst met Firefly aan de slag gegaan.

Voor Firefly heb ik de config voor Nextcloud als de basis gebruikt en hier wat kleine wijzigingen doorgevoerd, maar ik krijg Firefly niet aan de praat.

Zodra ik de Middlewares weghaal krijg ik bad gatewary en wanneer ik de middlewares laat zoals ze zijn, krijg ik 404. Ik snap/zie niet waar het probleem zit:

code:

      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.fireflyiii.rule=Host(`firefly.example.com`)"
        - "traefik.http.routers.fireflyiii.entrypoints=websecure"
        - "traefik.http.routers.fireflyiii.tls.certresolver=letsencryptresolver"
        - "traefik.http.services.fireflyiii.loadbalancer.server.port=80"
        - "traefik.docker.network=traefik_traefik-public"
        - "traefik.http.routers.fireflyiii.middlewares=fireflyiii-header"
        - "traefik.http.middlewares.fireflyiii-header.headers.stsIncludeSubdomains=false"
        - "traefik.http.middlewares.fireflyiii-header.headers.STSPreload=true"
        - "traefik.http.middlewares.fireflyiii-header.headers.framedeny=true"
        - "traefik.http.middlewares.fireflyiii-header.headers.STSSeconds=315360000"
        - "traefik.http.middlewares.fireflyiii-header.headers.forceSTSHeader=true"
        - "traefik.http.middlewares.fireflyiii-header.headers.X-Forwarded-Proto=https"

Verder doet Traefik het volgende:

code:

    command:
      # Docker swarm configuration
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=traefik-public"

      # Configure entrypoint
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"

      # SSL configuration
      - "--certificatesresolvers.letsencryptresolver.acme.httpChallenge=true"
      - "--certificatesresolvers.letsencryptresolver.acme.httpChallenge.entrypoint=web"
      - "--certificatesresolvers.letsencryptresolver.acme.email=[e-mail]"
      - "--certificatesresolvers.letsencryptresolver.acme.storage=/letsencrypt/acme.json"

      # Global HTTP -> HTTPS
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--entrypoints.web.http.redirections.entryPoint.scheme=https"

      labels:
        - "traefik.enable=true"
        - "traefik.http.services.traefik.loadbalancer.server.port=8081"
        - "traefik.http.routers.http-catchall.rule=hostregexp(`{host:.+}`)"
        - "traefik.http.routers.traefik.tls=true"
        - "traefik.http.routers.traefik.tls.certresolver=letsencryptresolver"
        - "traefik.http.routers.http-catchall.entrypoints=web"
        - "traefik.http.routers.http-catchall.middlewares=redirect-to-https@docker"
        - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"

Wie kan mij een duw in de goede richting geven?

[mca2]

Traefik draait inmiddels prima met een wildcard certificaat voor mijn domein. Ook heb ik inmiddels een paar services draaien, die het prima doen. Echter lukt het mij niet Unifi aan de praat te krijgen. De container en logon op het portal werkt allemaal prima maar er wordt geen enkel device gedetecteerd. Het lijkt of Unifi op het interne Traefik netwerk zit (172.x) ipv het daadwerkelijke netwerk (192.168.x).

Ik heb alles in 1 docker-compose file staan en gebruik het default netwerk met daarin deze service voor Unifi. Wat gaat er hier mis?

code:

unifi:
                image: "ghcr.io/linuxserver/unifi-controller"
                container_name: unifi
                environment:
                        - PUID=1000
                        - PGID=1000
                        - MEM_LIMIT=1024M #optional
                volumes:
                        - ./unifi/config:/config
                        - ./unifi/autobackup:/usr/lib/unifi/data/backup/autobackup
                ports:
                        - 3478:3478/udp
                        - 10001:10001/udp
                        - 8080:8080
                        - 8443:8443
                        - 1900:1900/udp #optional
                        - 8843:8843 #optional
                        - 8880:8880 #optional
                        - 6789:6789 #optional
                        - 5514:5514 #optional
                restart: unless-stopped
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.unifi.rule=Host(`unifi.mydomain.com`)"
                        - "traefik.http.routers.unifi.entrypoints=websecure"
                        - "traefik.http.routers.unifi.tls=true"
                        - "traefik.http.routers.unifi.tls.certresolver=myresolver"
                        - "traefik.http.services.unifi.loadbalancer.server.scheme=https"
                        - "traefik.http.services.unifi.loadbalancer.server.port=8443"

Edit: toch niet, volgens onderstaande kijkt de controller op het juiste netwerk. Maar waarom ziet de controller mijn Flex Mini switch en AP-AC-Lite dan niet?

[ Voor 5% gewijzigd door mca2 op 02-02-2021 23:04 ]

[mithras]

TheDweep schreef op dinsdag 2 februari 2021 @ 18:04:
Zodra ik de Middlewares weghaal krijg ik bad gatewary en wanneer ik de middlewares laat zoals ze zijn, krijg ik 404. Ik snap/zie niet waar het probleem zit:

[...]

Wie kan mij een duw in de goede richting geven?

Die middleware heb je helemaal niet nodig volgens mij? Denk dat het probleem ergens anders zit. Dit zijn mijn labels namelijk met een werkende Firefly iii (in Ansible format, maar je kan het prima volgen):

code:

labels:
  - "traefik.enable=true"
  - "traefik.docker.network={{ traefik_docker_network }}"

  - "traefik.http.routers.firefly.entrypoints=websecure"
  - "traefik.http.routers.firefly.rule=Host(`{{ firefly_public_domain }}`)"
  - "traefik.http.routers.firefly.tls=true"
  - "traefik.http.routers.firefly.tls.certresolver=le"

  - "traefik.http.routers.firefly_http.entrypoints=web"
  - "traefik.http.routers.firefly_http.rule=Host(`{{ firefly_public_domain }}`)"
  - "traefik.http.routers.firefly_http.middlewares=redirect-to-https"

Ik zou vooral even de logs checken van Firefly zelf (naam van je eigen container even aanpassen):

docker logs -f firefly-app

Het zou zomaar kunnen liggen aan je docker netwerken. Ik heb een dedicated firefly netwerk waar de db en app in zitten. Vervolgens zit de app óók gekoppeld aan het Traefik netwerk. Via de labels geef je aan dat Traefik connectie legt via het Traefik netwerk.

[TheDweep]

mithras schreef op woensdag 3 februari 2021 @ 09:30:
[...]
Die middleware heb je helemaal niet nodig volgens mij? Denk dat het probleem ergens anders zit. Dit zijn mijn labels namelijk met een werkende Firefly iii (in Ansible format, maar je kan het prima volgen):

code:

labels:
  - "traefik.enable=true"
  - "traefik.docker.network={{ traefik_docker_network }}"

  - "traefik.http.routers.firefly.entrypoints=websecure"
  - "traefik.http.routers.firefly.rule=Host(`{{ firefly_public_domain }}`)"
  - "traefik.http.routers.firefly.tls=true"
  - "traefik.http.routers.firefly.tls.certresolver=le"

  - "traefik.http.routers.firefly_http.entrypoints=web"
  - "traefik.http.routers.firefly_http.rule=Host(`{{ firefly_public_domain }}`)"
  - "traefik.http.routers.firefly_http.middlewares=redirect-to-https"

Ik zou vooral even de logs checken van Firefly zelf (naam van je eigen container even aanpassen):

docker logs -f firefly-app

Het zou zomaar kunnen liggen aan je docker netwerken. Ik heb een dedicated firefly netwerk waar de db en app in zitten. Vervolgens zit de app óók gekoppeld aan het Traefik netwerk. Via de labels geef je aan dat Traefik connectie legt via het Traefik netwerk.

Dank je wel. In het Firefly topic heb ik beide compose files en de logging neergezet, maar het leek mij handiger om het in dit topic verder te bespreken omdat ik vermoed dat het in mijn Traefik config zit.

https://gathering.tweakers.net/forum/view_message/65514696

[bart.koppers]

mca2 schreef op dinsdag 2 februari 2021 @ 22:34:
Traefik draait inmiddels prima met een wildcard certificaat voor mijn domein. Ook heb ik inmiddels een paar services draaien, die het prima doen. Echter lukt het mij niet Unifi aan de praat te krijgen. De container en logon op het portal werkt allemaal prima maar er wordt geen enkel device gedetecteerd. Het lijkt of Unifi op het interne Traefik netwerk zit (172.x) ipv het daadwerkelijke netwerk (192.168.x).

Ik heb alles in 1 docker-compose file staan en gebruik het default netwerk met daarin deze service voor Unifi. Wat gaat er hier mis?

Dit is eigenlijk geen Traefik-issue, meer een netwerk/Unifi issue.

Je zegt het zelf ook al: de Unifi container hangt in het default (docker) netwerk. Dat is een L3 netwerk.
Voor de device discovery is L2 nodig.

Nou is discovery meestal maar kort nodig, mn voor het adopten (*).
Makkelijkste is jouw 2 devices een factory reset geven, discovery via mobiel oid (of tijdelijke Unifi controller op laptop), en via interface/wizard (of set inform) de host op unifi.jouwdomain.com te zetten.

Andere oplossingen/opties - met meer netwerk-voodoo , maar zijn als je ze kent mss wel sneller:

- Als je zelf een DNS-server hebt draaien (en kan instellen), zorg dan dat hostname ‘unifi’ in jouw netwerk resolvet naar jouw hostname/IP. Het kan ook via DHCP.
- Of hang de container in een host-network of macvlan, en proxy via file-provider van Traefik de poort 8443 door.

(*) zie voor meer details https://help.ui.com/hc/en...-Remote-UniFi-Controllers

[Jazco2nd]

@TheDweep Je Nextcloud labels moet je niet als default zien voor andere apps.
Kijk liever naar deze guide als basis en gebruik die labels als default. Enkele apps hebben extras nodig zoals OnlyOffice en wellicht Nextcloud.

offtopic:
Pihole heeft dit natuurlijk alleen nodig voor DoH, als je dat niet gebruikt (en dat hoeft niet vanzelfsprekend te zijn, DOH versleuteld alleen de verbinding naar de eerste DNS provider, niks bij de DNS provider en ook niks van die naar alle andere providers toe, die zien dus allemaal je volledige, onversleutelde request), zijn Traefik labels overbodig. Je kan immers ook gewoon een Unbound containertje toevoegen, die ervoor zorgt dat geen enkele DNS provider een compleet beeld heeft van je domain requests.
Of overstappen op AdGuardHome (ook open-source en slechts een enkele binary dus geen container nodig) die zelfs al het QUIC dns protocol ondersteund.. wat DOH overbodig maakt.

[slijkie]

Zeer fijn systeem, maak er al vrij lang gebruik van. Ook fijn om er een topic hier over te zien.

[TheDweep]

Jazco2nd schreef op woensdag 3 februari 2021 @ 14:24:
@TheDweep Je Nextcloud labels moet je niet als default zien voor andere apps.
Kijk liever naar deze guide als basis en gebruik die labels als default. Enkele apps hebben extras nodig zoals OnlyOffice en wellicht Nextcloud.

offtopic:
Pihole heeft dit natuurlijk alleen nodig voor DoH, als je dat niet gebruikt (en dat hoeft niet vanzelfsprekend te zijn, DOH versleuteld alleen de verbinding naar de eerste DNS provider, niks bij de DNS provider en ook niks van die naar alle andere providers toe, die zien dus allemaal je volledige, onversleutelde request), zijn Traefik labels overbodig. Je kan immers ook gewoon een Unbound containertje toevoegen, die ervoor zorgt dat geen enkele DNS provider een compleet beeld heeft van je domain requests.
Of overstappen op AdGuardHome (ook open-source en slechts een enkele binary dus geen container nodig) die zelfs al het QUIC dns protocol ondersteund.. wat DOH overbodig maakt.

Ik heb het met de minimale labels gedaan, maar firefly blijft ontoegankelijk. In het dashboard van Traefik staat hij er keurig tussen zonder foutmeldingen. Ik snap het niet.

Edit: en ook het certificaat wordt keurig geregeld voor het juiste subdomein, maar toch gateway timeout.

Edit 2: heb net een docker compose gemaakt voor whoami en die aangeslingerd en die doet het prima.

AdGuard in plaats van Pihole ga ik eens uitzoeken

[ Voor 6% gewijzigd door TheDweep op 03-02-2021 20:42 ]

[Jazco2nd]

Ik ben erg benieuwd wat de meningen hier zijn over Caddy of Swag voor je homeserver.

Caddy: https://caddyserver.com/
Nu ik Caddy heb ontdekt: dat is schrikbarend eenvoudig alternatief voor Traefik. Het is zo simpel dat ik me afvroeg of het wel kon werken dus heb het reeds ff voor 1 container getest. Het werkt gewoon. Geen labels nodig, 1 regel in de caddy conf file per service en je bent klaar! Bizar!

Waarom vind je online in bijna alle moderne guides dan aanbevelingen voor Traefik?
Is Traefik met zijn middleware extra veilig tov Caddy?

En dan Swag: https://github.com/linuxserver/docker-swag
1 container die alles doet wat Traefik ook doet plus Fail2ban. Is dit een meer traditionele benadering? Het is ook een stuk simpeler op te zetten dan Traefik, maar heb dit niet geprobeerd.

Caddy is het eenvoudigst, doet by default alles wat je nodig hebt, vandaar zo simpel op te zetten, Swag lijkt ook eenvoudig en lijkt meer security minded, gebruikt losse onderdelen zoals nginx en fail2ban.

Waarom heb ik dan avonden besteed om Traefik uit te vogelen

[Dacuuu]

Jazco2nd schreef op dinsdag 9 februari 2021 @ 13:03:
Ik ben erg benieuwd wat de meningen hier zijn over Caddy of Swag voor je homeserver.

Caddy: https://caddyserver.com/
Nu ik Caddy heb ontdekt: dat is schrikbarend eenvoudig alternatief voor Traefik. Het is zo simpel dat ik me afvroeg of het wel kon werken dus heb het reeds ff voor 1 container getest. Het werkt gewoon. Geen labels nodig, 1 regel in de caddy conf file per service en je bent klaar! Bizar!

Waarom vind je online in bijna alle moderne guides dan aanbevelingen voor Traefik?
Is Traefik met zijn middleware extra veilig tov Caddy?

En dan Swag: https://github.com/linuxserver/docker-swag
1 container die alles doet wat Traefik ook doet plus Fail2ban. Is dit een meer traditionele benadering? Het is ook een stuk simpeler op te zetten dan Traefik, maar heb dit niet geprobeerd.

Caddy is het eenvoudigst, doet by default alles wat je nodig hebt, vandaar zo simpel op te zetten, Swag lijkt ook eenvoudig en lijkt meer security minded, gebruikt losse onderdelen zoals nginx en fail2ban.

Waarom heb ik dan avonden besteed om Traefik uit te vogelen

Ik draai al een tijdje de swag container. Doet het heerlijk. Er zit een hele lading aan configs bij voor de bekendere programma's. Maar eigenijk stelt het allemaal maar weinig voor.

Als je het nog simpeler wil dan heb je ook nog https://nginxproxymanager.com/

[lolgast]

Het 'mooie' van Traefik is natuurlijk dat als je de container down brengt, de hele service ook weg is. Mits je met labels werkt dan, als je in Traefik handmatige rules gebruikt ga je alsnog nat.

Verder is het denk ik potato potáto

[FireDrunk]

Jazco2nd schreef op dinsdag 9 februari 2021 @ 13:03:
Ik ben erg benieuwd wat de meningen hier zijn over Caddy of Swag voor je homeserver.

Caddy: https://caddyserver.com/
Nu ik Caddy heb ontdekt: dat is schrikbarend eenvoudig alternatief voor Traefik. Het is zo simpel dat ik me afvroeg of het wel kon werken dus heb het reeds ff voor 1 container getest. Het werkt gewoon. Geen labels nodig, 1 regel in de caddy conf file per service en je bent klaar! Bizar!

Waarom vind je online in bijna alle moderne guides dan aanbevelingen voor Traefik?
Is Traefik met zijn middleware extra veilig tov Caddy?

En dan Swag: https://github.com/linuxserver/docker-swag
1 container die alles doet wat Traefik ook doet plus Fail2ban. Is dit een meer traditionele benadering? Het is ook een stuk simpeler op te zetten dan Traefik, maar heb dit niet geprobeerd.

Caddy is het eenvoudigst, doet by default alles wat je nodig hebt, vandaar zo simpel op te zetten, Swag lijkt ook eenvoudig en lijkt meer security minded, gebruikt losse onderdelen zoals nginx en fail2ban.

Waarom heb ik dan avonden besteed om Traefik uit te vogelen

Het mooie van Traefik is dat de configuratie bij de applicatie zit, en niet in een centrale config.
Jij vindt dat misschien super handig, maar in een grote enterprise waar je 50 applicaties achter Traefik hangt, is het rete onhandig als die uit 1 config komen.

Het is juist handig dat je labels kan gebruiken, omdat beheerders de configuratie kunnen wijzigen, zonder dat ze de applicatie zelf hoeven te wijzigen.

Zo hebben wij een scheiding van minimaal 3 repo's:
1 repo met de broncode van de applicatie, en de Dockerfile die er een container van maakt.
1 repo met de deployment code die die Docker container inclusief traefik configuratie op een cluster deployed
1 repo met een deployment van Traefik zelf.

Applicatie wijziging? Repo 1
Deployment wijziging? Repo 2
Traefik upgrade? Repo 3

Scheiding van verantwoordelijkheden is belangrijker dan een extreem simpele configuratie.

Edit:
Als je echt zo min mogelijk configuratie wil, is er een 'expose by default' optie in Traefik.
Dan zet ie gewoon alles open zonde config, en poogt hij 'default' dingen te doen

[ Voor 4% gewijzigd door FireDrunk op 09-02-2021 14:27 ]

[JBS]

Toevallig hier Traefik gebruikers die via een rule toml bestand een subdomein willen doorsturen naar een specifiek Grafana dashboard?

Een link als http://192.168.178.24:4000/d/abcd/pv brengt me direct bij het gewenste dashboard in Grafana. Voeg ik deze URL toe aan het Traefik rule bestand, dan kom ik via het subdomein steevast uit bij het standaard Grafana dashboard, en niet bij dit specifieke dashboard in Grafana.

Wellicht iemand met eenzelfde use case hier waarbij dit wel gelukt is?

[lolgast]

@JBS Geen ervaring mee, maar volgens mij is de addprefix middleware daarvoor
https://doc.traefik.io/traefik/middlewares/addprefix/

[JBS]

@lolgast Dank voor de richting, die add prefix lijkt inderdaad relevant, hoewel ik twijfel of deze voor mijn doel de oplossing is.

prefix is the string to add before the current path in the requested URL. It should include a leading slash (/).

In het voorbeeld wordt /foo toegevoegd aan de URL, voor de /bar/.
In mijn geval wil ik graag dat een subdomein uitkomt op een interne locatie wat een IP adres met poort is aangevuld met /d/abcs/pv. Voor veel andere zaken zoals mijn NAS werkt een dergelijke opzet, maar de toevoeging achter het interne adres doet het voor dit specifieke doel in de soep lopen.

Voor de volledigheid mijn rule bestand.

YAML:

[http]
 [http.middlewares]
 
   [http.middlewares.pv-redirect.redirectScheme]
       scheme = "https"
       

 [http.routers.pv-redirect]
   entrypoints = ["web"]
   rule = "Host(`pv.domein.nl`)"
   middlewares = ["pv-redirect"]
   service = "pv"

 [http.routers.pv]
   entrypoints = ["websecure"]
   rule = "Host(`pv.domein.nl`)"
   service = "pv"
   [http.routers.pv.tls]
       certResolver = "letsencrypt"

 [http.services]
   [http.services.pv.loadbalancer]
     [[http.services.pv.loadBalancer.servers]]
       url = "http://192.168.178.24:4000/d/abcs/pv"

Traefik 2.2.1.1.

[mithras]

JBS schreef op dinsdag 16 februari 2021 @ 08:06:
@lolgast Dank voor de richting, die add prefix lijkt inderdaad relevant, hoewel ik twijfel of deze voor mijn doel de oplossing is.


[...]


In het voorbeeld wordt /foo toegevoegd aan de URL, voor de /bar/.
In mijn geval wil ik graag dat een subdomein uitkomt op een interne locatie wat een IP adres met poort is aangevuld met /d/abcs/pv. Voor veel andere zaken zoals mijn NAS werkt een dergelijke opzet, maar de toevoeging achter het interne adres doet het voor dit specifieke doel in de soep lopen.

De middleware zorgt toch dat een incoming request intern een prefix krijgt in het pad zodat het request richting de service de prefix bevat Dus dat zou toch moeten lukken?

• Middleware: prefix met /d/abcs/pv
• Router: pv gekoppeld aan service pv en met middleware van hierboven
• Service: pv met loadbalancing URL "http://192.168.178.24:4000"

Als het goed lees van de docs (niet zelf getest) heb je nu een extern punt voor Traefik "https://pv.domein.nl" dat intern (via middleware en de service) wordt doorgestuurd naar "http://192.168.178.24:4000/d/abcs/pv". En dus ook, "https://pv.domein.nl/foo?bar" wordt "http://192.168.178.24:4000/d/abcs/pv/foo?bar".

Zoals Traefik namelijk zelf stelt:

The AddPrefix middleware updates the path of a request before forwarding it.

[ Voor 5% gewijzigd door mithras op 16-02-2021 10:04 ]

[GAEvakYD]

Deze week ben ik begonnen met Traefik te spelen. Het concept vind ik super cool.

Ik heb dit stappenplan gebruikt:
https://medium.com/@conta...y-step-guide-e0be0c17cfa5

De basis kreeg ik al snel werkend. Incl LetEncrypt certificaten, HTTP challenge en portainer als server erachter. Het viel mij op dat het dashboard van traefik niet werkte. Ik heb nu een dag heel veel websites gelezen en verschillende configs bekeken, maar ik kom er niet uit.

Dit is mijn Docker-compose file:

code:

version: '3.6'

services:
  traefik:
    image: traefik:v2.0
    container_name: traefik
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    networks:
      - proxy
    ports:
      - 80:80
      - 443:443
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/traefik.yml:/traefik.yml:ro
#      - ./user-credentials:/user-credentials:ro
      - ./data/acme.json:/acme.json
      - ./log:/log
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.entrypoints=http"
      - "traefik.http.routers.traefik.rule=Host(`thuis.banaan.com`)"
      - "traefik.http.middlewares.traefik-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.traefik.middlewares=traefik-https-redirect"
      - "traefik.http.routers.traefik-secure.entrypoints=https"
      - "traefik.http.routers.traefik-secure.rule=Host(`thuis.banaan.com`)"
      - "traefik.http.routers.traefik-secure.tls=true"
      - "traefik.http.routers.traefik-secure.tls.certresolver=letsencrypt"
      - "traefik.http.routers.traefik-secure.service=api@internal"
#      - "traefik.http.routers.traefik-secure.middlewares=traefik-auth"
      - "traefik.http.middlewares.traefik-auth.basicauth.users=XXXX:YYYY". //XXX en YYY is dummy voor GOT post

networks:
  proxy:
    external: true

en mijn traefik.yml

code:

api:
  dashboard: true

entryPoints:
  http:
    address: ":80"
  https:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

certificatesResolvers:
  letsencrypt:
    acme:
      email: "[e-mail]"
      storage: acme.json
      httpChallenge:
        entryPoint: http

log:
  filePath: "log/traefik.log"
  level: WARN

accessLog:
  filePath: "log/access.log"
  bufferingSize: 100

Als ik regel

code:

      - "traefik.http.routers.traefik-secure.middlewares=traefik-auth"

Als commentaar zet, dan werkt het dashboard. Maar dan is er geen authenticatie. Als ik die regel weer aanzet dan laad het dashboard niet en ik zie ook niets in de logging voorbij komen. Ook niet bij een LOG_LEVEL debug.

Wel vreemd want die "traefik-auth" middlewares staat erboven goed gedefineerd volgens mij. Ik heb al geprobeerd om deze regel onder of boven de definitie van de middleware te zetten.

Na een dag pielen ben ik echt door de opties heen. Hebben jullie een suggestie?

[jvwou123]

GAEvakYD schreef op vrijdag 19 februari 2021 @ 21:07:
# - "traefik.http.routers.traefik-secure.middlewares=traefik-auth"
- "traefik.http.middlewares.traefik-auth.basicauth.users=XXXX:YYYY". //XXX en YYY is dummy voor GOT post

Staat er een punt achter de username:password?

[GAEvakYD]

jvwou123 schreef op zaterdag 20 februari 2021 @ 09:01:
[...]


Staat er een punt achter de username:password?

Nope. Dat is denk ik gekomen toen ik mijn user/pass veranderde door XXX en YYY.

De regel ziet er ongeveer zo uit in het echt.

code:

"traefik.http.middlewares.traefik-auth.basicauth.users=banaan:$$apr1$$DXORKT34$$qTRY0US47yI.ty0DDvdwn3"

[GAEvakYD]

Hmmm twee nieuwe observaties. Ik kan het niet loslaten. Vermoedelijk iets het namelijk iets heel kleins.

De middlemwares rule voor de https redirect werkt goed. http word goed geredirect naar https.

code:

      - "traefik.http.routers.traefik.middlewares=traefik-https-redirect"

Ik heb de redirect eens uitgezet en auth op http aangezet. Dus op router traefik ipv traefik-secure

code:

      - "traefik.http.routers.traefik.middlewares=traefik-auth"

Nu komt er geen redirect meer en netjes een http basic auth panel waar ik kan inloggen. Echter werkt de redirect dan niet meer en als je handmatig naar https gaat dan zit daar geen auth op. Conclusie. Die auth werkt wel maar er dus iets raar waarom het dashboard boem doet als ik die auth activeer op https.

Deze config heb ik nu staan daarmee het dashboard dus niet wil laden.

code:

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik_proxy"
      - "traefik.http.routers.traefik.entrypoints=http"
      - "traefik.http.routers.traefik.rule=Host(`thuis.banaan.org`)"

      - "traefik.http.routers.traefik-secure.entrypoints=https"
      - "traefik.http.routers.traefik-secure.rule=Host(`thuis.banaan.org `)"
      - "traefik.http.routers.traefik-secure.tls=true"
      - "traefik.http.routers.traefik-secure.tls.certresolver=letsencrypt"
      - "traefik.http.routers.traefik-secure.service=api@internal"
      - "traefik.http.routers.traefik-secure.middlewares=traefik-auth"
#      - "traefik.http.routers.traefik.middlewares=traefik-auth"
      - "traefik.http.routers.traefik.middlewares=traefik-https-redirect" 

      - "traefik.http.middlewares.traefik-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.middlewares.traefik-auth.basicauth.users=banaan:$$apr1$$snZhW2Oo$$739dDwdUfkl8gf4De5al1"

Als ik de regel commentaar uit zet en de regel erboven in comment zet dan heb ik dus een werkende maar open dashboard op https en een werkende basicauth op http.

[ Voor 255% gewijzigd door GAEvakYD op 20-02-2021 16:31 ]

[JBS]

mithras schreef op dinsdag 16 februari 2021 @ 10:03:
[...]

De middleware zorgt toch dat een incoming request intern een prefix krijgt in het pad zodat het request richting de service de prefix bevat Dus dat zou toch moeten lukken?

• Middleware: prefix met /d/abcs/pv
• Router: pv gekoppeld aan service pv en met middleware van hierboven
• Service: pv met loadbalancing URL "http://192.168.178.24:4000"

Als het goed lees van de docs (niet zelf getest) heb je nu een extern punt voor Traefik "https://pv.domein.nl" dat intern (via middleware en de service) wordt doorgestuurd naar "http://192.168.178.24:4000/d/abcs/pv". En dus ook, "https://pv.domein.nl/foo?bar" wordt "http://192.168.178.24:4000/d/abcs/pv/foo?bar".

Zoals Traefik namelijk zelf stelt:

[...]

Ik geloof dat ik het toch niet helemaal begrijp, hoewel het vast logisch klinkt voor de meer ervaren Traefik gebruikers. Zou je me alsnog op weg willen helpen op basis van onderstaande rule bestand?
Aangezien pv.domein.nl me nog niet naar http://192.168.178.24:4000/d/abcd/pv brengt maar naar het standaard Grafana dashboard, doe ik ongetwijfeld iets niet goed.

YAML:

[http]
 [http.middlewares]
   [http.middlewares.pv-redirect.redirectScheme]
       scheme = "https"
   [http.middlewares.add-pv.addPrefix]
       prefix = "/d/abcd/pv"
       
 [http.routers.pv-redirect]
   entrypoints = ["web"]
   rule = "Host(`pv.domein.nl`)"
   middlewares = ["pv-redirect"]
   service = "pv"

 [http.routers.pv]
   entrypoints = ["websecure"]
   rule = "Host(`pv.domein.nl`)"
   service = "pv"
   [http.routers.pv.tls]
       certResolver = "letsencrypt"

 [http.services]
   [http.services.pv.loadbalancer]
     [[http.services.pv.loadBalancer.servers]]
       url = "http://192.168.178.24:4000"

[RobertMe]

JBS schreef op zaterdag 20 februari 2021 @ 20:40:
[...]

Ik geloof dat ik het toch niet helemaal begrijp, hoewel het vast logisch klinkt voor de meer ervaren Traefik gebruikers. Zou je me alsnog op weg willen helpen op basis van onderstaande rule bestand?
Aangezien pv.domein.nl me nog niet naar http://192.168.178.24:4000/d/abcd/pv brengt maar naar het standaard Grafana dashboard, doe ik ongetwijfeld iets niet goed.

YAML:

[http]
 [http.middlewares]
   [http.middlewares.pv-redirect.redirectScheme]
       scheme = "https"
   [http.middlewares.add-pv.addPrefix]
       prefix = "/d/abcd/pv"
       
 [http.routers.pv-redirect]
   entrypoints = ["web"]
   rule = "Host(`pv.domein.nl`)"
   middlewares = ["pv-redirect"]
   service = "pv"

 [http.routers.pv]
   entrypoints = ["websecure"]
   rule = "Host(`pv.domein.nl`)"
   service = "pv"
   [http.routers.pv.tls]
       certResolver = "letsencrypt"

 [http.services]
   [http.services.pv.loadbalancer]
     [[http.services.pv.loadBalancer.servers]]
       url = "http://192.168.178.24:4000"

Je past de add-pv middleware nu nergens toe? Lijkt mij toch dat je die moet toepassen op de pv route.

[JBS]

RobertMe schreef op zaterdag 20 februari 2021 @ 20:52:
[...]

Je past de add-pv middleware nu nergens toe? Lijkt mij toch dat je die moet toepassen op de pv route.

Dank voor de hint, met die toevoeging kom ik inderdaad bij Grafana uit, maar wel met een error melding:



Heb het voor nu maar even anders opgelost: In Grafana het PV dashboard het standaard dashboard gemaakt.

[CH4OS]

Ik ben nu ook bezig om mijn webserver VM overbodig te maken en alles in een mooie Traefik contrainer te klappen. Daarbij wil ik graag wildcard certificaten via TransIP hebben.

Nu krijg ik daarbij echter een foutmelding:

cannot get ACME client transip: some credentials information are missing: TRANSIP_ACCOUNT_NAME,TRANSIP_PRIVATE_KEY_PATH"

.

Dan zou je zeggen: Noob, defineer die environment variabelen in jouw docker-compose.yml file.
Maar om het leuker te maken, het relevante deel van mijn docker-compose.yml is echter als volgt:

    traefik:
         image: traefik:2.4
         container_name: traefik
         security_opt:
           - no-new-privileges:true
         ports:
           - 80:80
           - 443:443
           - 8083:8080
         volumes:
           - /var/run/docker.sock:/var/run/docker.sock:ro
           - ./traefik/traefik.yml:/traefik.yml:ro
           - ./traefik/logs:/logs
           - ./traefik/certs:/certs
           - ./traefik/rules:/rules:ro
         restart: unless-stopped
         environment:
           - TZ:${TZ}
           - TRANSIP_ACCOUNT_NAME:${TRANSIP_ACCOUNT_NAME}
           - TRANSIP_PRIVATE_KEY_PATH:${TRANSIP_PRIVATE_KEY_PATH}

Met in de .env file mijn account_name en de key_path. Maar wat ik ook probeer, zelfs hardcoded, wordt Traefik er niet van overtuigt om de juiste username te gebruiken of de keyfile.

EDIT:
Ik had de = moeten gebruiken als scheidingsteken in plaats van :.

[ Voor 3% gewijzigd door CH4OS op 09-08-2021 01:06 ]

[timosmit]

CH4OS schreef op maandag 9 augustus 2021 @ 00:51:
Ik ben nu ook bezig om mijn webserver VM overbodig te maken en alles in een mooie Traefik contrainer te klappen. Daarbij wil ik graag wildcard certificaten via TransIP hebben.

Als ik je een tip mag geven, dan zou ik ook even kijken naar de manier waarop je je Docker-socket beschikbaar stelt aan Traefik. De manier waarop je het nu doet, heeft nogal wat consequenties op het gebied van beveiliging.

Ik heb hier in een ander topic (VPS-onderhoud) wat uitleg over gegeven.

[CH4OS]

timosmit schreef op maandag 9 augustus 2021 @ 11:30:
[...]

Als ik je een tip mag geven, dan zou ik ook even kijken naar de manier waarop je je Docker-socket beschikbaar stelt aan Traefik. De manier waarop je het nu doet, heeft nogal wat consequenties op het gebied van beveiliging.

Ik heb hier in een ander topic (VPS-onderhoud) wat uitleg over gegeven.

Ik zie niet helemaal hoe dat per se veiliger is. Als iemand al toegang heeft tot de container, ziet diegene dat er iets anders is en is het dus vervolgens een kwestie van overstappen naar de juiste container... Links of rechtsom zul je dus toch wel de Docker socket moeten mounten / doorgeven aan een container.

Ik zou dan eerder opteren om via SSH de toegang te verlenen, dan heb je de toegang in de hand middels de pubkeys. Dan gebruik je een unprivileged user, die wel toegang heeft tot de Docker commando's.

Tecnativa heeft immers ook gewoon de socket nodig en in die documentatie wordt hij zelfs niet eens als read-only gemount. Ik betwijfel in hoeverre dit veiliger is ten op zichte van dit er tussen, anders dan dat je naar deze container moet voor de toegang ten op zichte van een container dat deze socket direct gemount heeft. Ik zou dan echt eerder de SSH way gebruiken. Maar gelukkig is mijn thuisserver niet zo interessant.

EDIT:
Mooiste zou zijn als je Docker gewoon root-less draait en dat kan gewoon (die ook weer wat nadelen kent, zie het kopje 'Known limitations'), zoals Podman dat doet. Als alternatief kun je dan de toegang tot Docker via SSH ontsluiten, gebruikmakend van een non-root user, zie ook het kopje 'Using SSH' in de documentatie.

[ Voor 41% gewijzigd door CH4OS op 09-08-2021 12:17 ]

[RobertMe]

CH4OS schreef op maandag 9 augustus 2021 @ 11:50:
[...]
Ik zie niet helemaal hoe dat per se veiliger is. Als iemand al toegang heeft tot de container, ziet diegene dat er iets anders is en is het dus vervolgens een kwestie van overstappen naar de juiste container... Links of rechtsom zul je dus toch wel de Docker socket moeten mounten / doorgeven aan een container.

Ik zou dan eerder opteren om via SSH de toegang te verlenen, dan heb je de toegang in de hand middels de pubkeys. Dan gebruik je een unprivileged user, die wel toegang heeft tot de Docker commando's.

Tecnativa heeft immers ook gewoon de socket nodig en in die documentatie wordt hij zelfs niet eens als read-only gemount. Ik betwijfel in hoeverre dit veiliger is ten op zichte van dit er tussen, anders dan dat je naar deze container moet voor de toegang ten op zichte van een container dat deze socket direct gemount heeft. Ik zou dan echt eerder de SSH way gebruiken. Maar gelukkig is mijn thuisserver niet zo interessant.

EDIT:
Mooiste zou zijn als je Docker gewoon root-less draait en dat kan gewoon (die ook weer wat nadelen kent, zie het kopje 'Known limitations'), zoals Podman dat doet.

Het verschil is dat Traefik beschikbaar is vanaf het netwerk / internet. Als er dus een lek in Traefik zit waardoor containers gestart kunnen worden wat remote te exploiten is via HTTP heb je dus een probleem als Traefik rechtstreeks met de Docker daemon connect. Met die extra tussenlaag voorkom je dus dat er "extra" dingen worden gedaan met de Docker daemon (als in: het onmogelijk maken om containers te starten, stoppen, ...).
Het gaat dus niet om of je Traefik vertrouwd, maar dat Traefik lek kan zijn.

V.w.b. de socket beschikbaar stellen als read-only of niet. Dat maakt natuurlijk niks uit. Read-only in deze betekent dat je de socket file niet kunt overschrijven. Maar communiceren via een socket file is gewoon tweewegs.

Edit:
En v.w.b. rootless docker, dat beperkt het probleem ook maar voor een deel. Want ook dat zou (een lekke) Traefik gewoon andere containers kunnen starten. Alleen kan die gestarte container dan niet als root draaien. Maar bv / in die nieuwe container mounten zal nog steeds mogelijk zijn. En alle files die world readable zijn (dus file permissie xx4 / xx6 / xx7, oftewel alle bestanden die niet xx0 hebben) kan die container dan ook nog steeds lezen. Of om maar een zijstraat te noemen, edn container starten die bitcoins doet minen, of spam versturen, of, ....

[ Voor 12% gewijzigd door RobertMe op 09-08-2021 12:20 ]

[CH4OS]

RobertMe schreef op maandag 9 augustus 2021 @ 12:17:
[...]

Het verschil is dat Traefik beschikbaar is vanaf het netwerk / internet. Als er dus een lek in Traefik zit waardoor containers gestart kunnen worden wat remote te exploiten is via HTTP heb je dus een probleem als Traefik rechtstreeks met de Docker daemon connect. Met die extra tussenlaag voorkom je dus dat er "extra" dingen worden gedaan met de Docker daemon (als in: het onmogelijk maken om containers te starten, stoppen, ...).
Het gaat dus niet om of je Traefik vertrouwd, maar dat Traefik lek kan zijn.

V.w.b. de socket beschikbaar stellen als read-only of niet. Dat maakt natuurlijk niks uit. Read-only in deze betekent dat je de socket file niet kunt overschrijven. Maar communiceren via een socket file is gewoon tweewegs.

Dat weet ik, maar door een laag er tussen te zetten los je het probleem niet op, je contained het alleen naar die specifieke container. Voor de rest hou je dus gewoon het security issue (je houdt immers dat je ergens een mount hebt naar de socket terwijl dat slechte beveiliging is. ). Dan lijkt rootless Docker mij verstandiger (eventueel met een user dat alleen de Docker commandos kan doen).

Al met al blijven het pleisters voor een structureel Docker probleem.

[ Voor 7% gewijzigd door CH4OS op 09-08-2021 12:23 ]

[RobertMe]

CH4OS schreef op maandag 9 augustus 2021 @ 12:19:
[...]
Dat weet ik, maar door een laag er tussen te zetten los je het probleem niet op, je contained het alleen naar die specifieke container. Voor de rest hou je dus gewoon het security issue (je houdt immers dat je ergens een mount hebt naar de socket terwijl dat slechte beveiliging is. ). Dan lijkt rootless Docker mij verstandiger.

Die tussenlaag voegt zeker wel extra beveiliging toe. Immers kan een aanvaller niet zomaar die tussenliggende container exploiten. Een request naar Traefik die via een exploit een container start kan dat niet met die tussenliggende container. Want die denied gewoon toegang tot dat deel van de API. Dan moet de aanvaller dat tussenliggende stuk software dus ook zien te exploiten, over de Traefik hop heen ook nog eens.
En die tussenlaag is dus puur om ACL toe te voegen op de originele Docker daemon. Niet om andere beveilingsmiddelen te bieden. De Docker daemon staat gewoon alle operaties toe voor iedereen. Met dit laagje zorg je ervoor dat Traefik alleen kan zien welke containers er draaien (+ luisteren voor nieiw gestarte containers en gestopte containers etc).

V.w.b. rootless: zie de edit van mijn vorige post. Rootless docker voegt ook maar voor een deel beveiliging toe. En in de context van Traefik toegang geven tot de Docker socker vind ik API restricties belangrijker dan Docker rootless draaien (maar uiteindelijk is het natuurlijk een én én verhaal).

[CH4OS]

RobertMe schreef op maandag 9 augustus 2021 @ 12:26:
[...]

Die tussenlaag voegt zeker wel extra beveiliging toe. Immers kan een aanvaller niet zomaar die tussenliggende container exploiten. Een request naar Traefik die via een exploit een container start kan dat niet met die tussenliggende container. Want die denied gewoon toegang tot dat deel van de API. Dan moet de aanvaller dat tussenliggende stuk software dus ook zien te exploiten, over de Traefik hop heen ook nog eens.
En die tussenlaag is dus puur om ACL toe te voegen op de originele Docker daemon. Niet om andere beveilingsmiddelen te bieden. De Docker daemon staat gewoon alle operaties toe voor iedereen. Met dit laagje zorg je ervoor dat Traefik alleen kan zien welke containers er draaien (+ luisteren voor nieiw gestarte containers en gestopte containers etc).

V.w.b. rootless: zie de edit van mijn vorige post. Rootless docker voegt ook maar voor een deel beveiliging toe. En in de context van Traefik toegang geven tot de Docker socker vind ik API restricties belangrijker dan Docker rootless draaien (maar uiteindelijk is het natuurlijk een én én verhaal).

Al met al blijven de opties pleisters voor een algemeen Docker probleem.

[timosmit]

CH4OS schreef op maandag 9 augustus 2021 @ 11:50:
[...]
Ik zie niet helemaal hoe dat per se veiliger is. Als iemand al toegang heeft tot de container, ziet diegene dat er iets anders is en is het dus vervolgens een kwestie van overstappen naar de juiste container... Links of rechtsom zul je dus toch wel de Docker socket moeten mounten / doorgeven aan een container.

Tecnativa heeft immers ook gewoon de socket nodig en in die documentatie wordt hij zelfs niet eens als read-only gemount. Ik betwijfel in hoeverre dit veiliger is ten op zichte van dit er tussen, anders dan dat je naar deze container moet voor de toegang ten op zichte van een container dat deze socket direct gemount heeft. Ik zou dan echt eerder de SSH way gebruiken. Maar gelukkig is mijn thuisserver niet zo interessant.

Uiteraard zal er een container moeten zijn om de Docker-socket beschikbaar te moeten stellen. Echter, zoals ik in mijn andere bericht ook al benoemde, is dit een extra schil om de socket heen. Dat houdt dus in dat een potentiële aanvaller niet meer direct bij de socket kan, zodra deze in de Traefik-container is gekomen. Daarbij komt dat een aanvaller slechts de operaties op de socket mag uitvoeren, die de Tecnativa-image je toestaat te gebruiken. Dat is daardoor meteen een stuk veiliger dan dat je alles op de Docker-socket mag doen wat je wilt.

Ad. ik zie nu de berichten boven me waarin hetzelfde ongeveer wordt uitgelegd. Deze had ik even over het hoofd gezien.

[ Voor 4% gewijzigd door timosmit op 09-08-2021 12:56 ]

[Kabouterplop01]

Ik ben benieuwd naar de soorten load balancing en de nabije toekomst. Ik zit net de documentatie te lezen en zie jammer genoeg dat er alleen round robin wordt ondersteunt.
En het geen wat daarbij hoort; het monitoring gedeelte van serverfarms als je session based loadbalanced dan monitort de LB de servers op de beschikbaarheid van de service en zal als de probe faalt de server uit de farm houden, totdat deze weer beschikbaar is.
Ik zie ook niets over SSL offloading.

[FireDrunk]

Elke server waarvan de healthcheck faalt in Docker of Kubernetes wordt automatisch uit de 'pool' van servers uit een service gehaald. Traefik kent geen custom healthcheck op een server nee. Het is een containers first Load Balancer, daar is het voor gemaakt.

En voor de rest:
https://doc.traefik.io/tr...ces/#weighted-round-robin
https://doc.traefik.io/traefik/routing/entrypoints/#tls

Traefik kan gewoon beide?

Daarnaast is er ook nog een API, waarmee je het zelf zou kunnen bouwen.

[ Voor 7% gewijzigd door FireDrunk op 10-08-2021 08:28 ]

[JorisV]

Voor bepaalde functies van lokale websites heb ik https nodig en overzichtelijke naamgeving lijkt me ook handig. Dus als noob ben ik traefik aan het proberen, maar het wil niet opschieten. Ik heb geen domein (en wil er ook geen) maar heb op mijn router home.arpa ingesteld. Lokaal kan ik mijn server nu bereiken met http://rpi4. Voor traefik heb ik een docker-compose container met:

YAML:

version: '3'
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    labels:
     - traefik.enable=true
     - traefik.http.routers.traefik=true
     - traefik.http.routers.traefik.tls=true
     - traefik.http.services.traefik.loadbalancer.server.port=8080
    ports:
      - 80:80
      - 443:443
      - 8080:8080
    volumes:
     - ${USERDIR}/traefik/traefik.yml:/etc/traefik/traefik.yml:ro
     - ${USERDIR}/traefik/config.yml:/etc/traefik/config.yml:ro
     - ${USERDIR}/traefik/certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    ports:
      - 80
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.tls=true
      #- traefik.http.routers.whoami.rule=Host("myapi.rpi4.home.arpa")
      #- traefik.http.routers.whoami.rule=Host("whoami.localhost")
      #- traefik.http.routers.whoami.rule=PathPrefix(`/whoami{regex:$$|/.*}`)
      - traefik.http.routers.whoami.rule=Path(`/whoami`)

en voor de config.yml:

YAML:

http:
  routers:
    traefik:
      rule: Host(`traefik.localhost`)
      #rule: Host(`traefik.docker.localhost`)
      #rule: Path(`/traefik`)
      service: api@internal
      tls:
        domains:
          - main: docker.localhost
            sans:
              - "*.docker.localhost"
          - main: domain.local
            sans:
              - "*.domain.local"

tls:
  certificates:
    - certFile: /etc/certs/local-cert.pem
      keyFile: /etc/certs/local-key.pem

De certificaten heb ik gemaakt met mkcert voor localhost rpi4 192.168.1.207 127.0.0.1 ::1 home.arpa "*.home.arpa" domain.local "*.domain.local"

De regels die ik uitgecomment heb werken niet, vandaar.
Wat werkt is https://rpi4/whoami maar met een niet geldig certificaat:


Kan iemand me helpen met het volgende:
-Hoe kom ik bij de traefik configuratie site?
-Hoe krijg ik subdomains werkend (dus https://whoami.rpi4)
-Hoe maak ik het certificaat geldig?

[Faifz]

Je certificaat is getekend voor root@rpi4 wat natuurlijk geen URL of een IP-adres is. Een certificaat gaan tekenen voor 127.0.0.1 (of ::1) is niet echt nuttig. Je browser zal altijd de melding geven dat het certificaat niet vertrouwd is tenzij je de CA certificaat in je root store installeert.

Behalve voor de traefik container zelf, expose je geen poorten want je laadt traefik in de container door 'traefik.enable=true' te gebruiken. Je kan een poort maar maximaal eenmaal binden aan een IP-adres en jij probeert het 2x.

Wat is je domeinnaam nu precies home.arpa of rpi4.home.arpa? Hou het simpel en blijf bij home.arpa als je enkele DNS zone. Ik zal er vanuit gaan dat traefik-dashboard de volgende FQDN heeft: traefik.home.arpa en je wil whoami.home.arpa voor whoami.

code:

version: '3'
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    command:
      # Traefik-dashboard settings
      - "--log.level=DEBUG"
      - "--api.dashboard=true"
      - "--api.insecure=false"
      # Docker als provider
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      # Entrypoint -> is a front-end named "web" on HTTP Port 80
      - "--entrypoints.web.address=:80"
      # Entrypoint -> is a front-end named "web-secure" on HTTPS Port 443
      - "--entrypoints.web-secure.address=:443"
    labels:
     ### Traefik dashboard stuff ###
     - traefik.enable=true
     - traefik.http.routers.traefik-secure.tls=true
     - traefik.http.routers.traefik-secure.entrypoints=web-secure
     - traefik.http.routers.traefik-secure.rule=Host(`traefik.home.arpa`)
     - traefik.http.routers.traefik-secure.service=api@internal
    ports:
      - 80:80
      - 443:443
    volumes:
     - ${USERDIR}/traefik/config.yml:/etc/traefik/dynamic/config.yml:ro
     - ${USERDIR}/traefik/certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami-secure.entrypoints=web-secure
      - traefik.http.routers.whoami-secure.tls=true
      - traefik.http.routers.whoami-secure.rule=Host("whoami.home.arpa")

config.yml:

code:

tls:
  certificates:
    - certFile: /etc/certs/local-cert.pem
      keyFile: /etc/certs/local-key.pem

Traefik dashboard is optioneel en is vrijwel nutteloos vind ik. Dus die settings kan je beter weglaten als je het niet nodig hebt.

Edit: je kan beter een wildcard certificaat gaan maken voor *.home.arpa zodat je deze kunt gebruiken voor traefik.home.arpa en whoami.home.arpa

[JorisV]

Faifz schreef op zondag 26 december 2021 @ 15:00:
Je certificaat is getekend voor root@rpi4 wat natuurlijk geen URL of een IP-adres is. Een certificaat gaan tekenen voor 127.0.0.1 (of ::1) is niet echt nuttig. Je browser zal altijd de melding geven dat het certificaat niet vertrouwd is tenzij je de CA certificaat in je root store installeert.

Behalve voor de traefik container zelf, expose je geen poorten want je laadt traefik in de container door 'traefik.enable=true' te gebruiken. Je kan een poort maar maximaal eenmaal binden aan een IP-adres en jij probeert het 2x.

Wat is je domeinnaam nu precies home.arpa of rpi4.home.arpa? Hou het simpel en blijf bij home.arpa als je enkele DNS zone. Ik zal er vanuit gaan dat traefik-dashboard de volgende FQDN heeft: traefik.home.arpa en je wil whoami.home.arpa voor whoami.

code:

version: '3'
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    command:
      # Traefik-dashboard settings
      - "--log.level=DEBUG"
      - "--api.dashboard=true"
      - "--api.insecure=false"
      # Docker als provider
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      # Entrypoint -> is a front-end named "web" on HTTP Port 80
      - "--entrypoints.web.address=:80"
      # Entrypoint -> is a front-end named "web-secure" on HTTPS Port 443
      - "--entrypoints.web-secure.address=:443"
    labels:
     ### Traefik dashboard stuff ###
     - traefik.enable=true
     - traefik.http.routers.traefik-secure.tls=true
     - traefik.http.routers.traefik-secure.entrypoints=web-secure
     - traefik.http.routers.traefik-secure.rule=Host(`traefik.home.arpa`)
     - traefik.http.routers.traefik-secure.service=api@internal
    ports:
      - 80:80
      - 443:443
    volumes:
     - ${USERDIR}/traefik/config.yml:/etc/traefik/dynamic/config.yml:ro
     - ${USERDIR}/traefik/certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami-secure.entrypoints=web-secure
      - traefik.http.routers.whoami-secure.tls=true
      - traefik.http.routers.whoami-secure.rule=Host("whoami.home.arpa")

config.yml:

code:

tls:
  certificates:
    - certFile: /etc/certs/local-cert.pem
      keyFile: /etc/certs/local-key.pem

Traefik dashboard is optioneel en is vrijwel nutteloos vind ik. Dus die settings kan je beter weglaten als je het niet nodig hebt.

Edit: je kan beter een wildcard certificaat gaan maken voor *.home.arpa zodat je deze kunt gebruiken voor traefik.home.arpa en whoami.home.arpa

Dank!
Ik krijg het niet helemaal voor elkaar, maar dat ligt aan mij. Domein/DNS en de certificaten is me een raadsel. Ik heb het traefik dashboard er uit gegooid en ik heb nu:

YAML:

version: '3'
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    command:
      - "--log.level=DEBUG"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web-secure.address=:443"
    ports:
      - 80:80
      - 443:443
    volumes:
     - ${USERDIR}/traefik/config.yml:/etc/traefik/dynamic/config.yml:ro
     - ${USERDIR}/traefik/certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami-secure.entrypoints=web-secure
      - traefik.http.routers.whoami-secure.tls=true
      - traefik.http.routers.whoami-secure.rule=Path("/whoami")

  esphome:
    image: esphome/esphome
    container_name: esphome2
    restart: unless-stopped
    volumes:
      - ${USERDIR}/esphome:/config:rw
      - /etc/localtime:/etc/localtime:ro
    labels:
      - traefik.enable=true
      - traefik.http.routers.esphome-secure.entrypoints=web-secure
      - traefik.http.routers.esphome-secure.tls=true
      - traefik.http.routers.esphome-secure.rule=Path("/esphome")
      - traefik.http.services.esphome-secure.loadbalancer.server.port=6052

Daarmee kan ik whoami bereiken op https://rpi4/whoami. Dat is prima. Iets anders (whoami.rpi4 of varianten lukt echt niet).
Ik heb geprobeerd in google chrome het certificaat te exporteren en te importeren, maar ik krijg nog steeds een waarschuwing van een niet geldig certificaat.
Ik probeer nu ook een andere container toe te voegen: EspHome. Die luistert naar poort 6052. Bij het starten van de container krijg ik: Starting dashboard web server on http://0.0.0.0:6052, maar bij https://rpi4/esphome komt er een: WARNING 404 GET /esphome (172.23.0.2)
Dus
-hoe krijg ik het goed certificaat geïmporteerd?
-hoe krijg ik esphome aan de gang?

[Faifz]

JorisV schreef op maandag 27 december 2021 @ 12:51:
[...]


Dank!
Ik krijg het niet helemaal voor elkaar, maar dat ligt aan mij. Domein/DNS en de certificaten is me een raadsel. Ik heb het traefik dashboard er uit gegooid en ik heb nu:

Daarmee kan ik whoami bereiken op https://rpi4/whoami. Dat is prima. Iets anders (whoami.rpi4 of varianten lukt echt niet).
Ik heb geprobeerd in google chrome het certificaat te exporteren en te importeren, maar ik krijg nog steeds een waarschuwing van een niet geldig certificaat.
Ik probeer nu ook een andere container toe te voegen: EspHome. Die luistert naar poort 6052. Bij het starten van de container krijg ik: Starting dashboard web server on http://0.0.0.0:6052, maar bij https://rpi4/esphome komt er een: WARNING 404 GET /esphome (172.23.0.2)
Dus
-hoe krijg ik het goed certificaat geïmporteerd?
-hoe krijg ik esphome aan de gang?

Maak je wel de A records aan op je DNS server? Die moeten allemaal verwijzen naar het IP-adres van traefik.

esphome.home.arpa - 192.168.1.100 (traefik IP)
whoami.home.arpa - 192.168.1.100

Je kan een self-signed certificaat aanmaken op je linux host met het volgende:

code:

openssl req -newkey rsa:4096 \
            -x509 \
            -sha256 \
            -days 3650 \
            -nodes \
            -out example.crt \
            -keyout example.key

Als je liever een tool online gebruikt ipv de CLI; https://www.selfsignedcertificate.com/

Je krijgt een prompt waar je gevraagd wordt om het land etc in te geven, maar het enige dat belangrijk is de common name. Als common name geef je gewoon *.home.arpa in. Dit certificaat is wel niet getekend voor gewoon 'https://rpi4'. Je kan meerdere SAN's toevoegen (CN), maar je certificaat vernieuwen omdat je een nieuwe back-end server toevoegt (deze keer is het esphome) is niet echt praktisch.

[JorisV]

Faifz schreef op maandag 27 december 2021 @ 13:35:
[...]


Maak je wel de A records aan op je DNS server? Die moeten allemaal verwijzen naar het IP-adres van traefik.

esphome.home.arpa - 192.168.1.100 (traefik IP)
whoami.home.arpa - 192.168.1.100

Je kan een self-signed certificaat aanmaken op je linux host met het volgende:

code:

openssl req -newkey rsa:4096 \
            -x509 \
            -sha256 \
            -days 3650 \
            -nodes \
            -out example.crt \
            -keyout example.key

Als je liever een tool online gebruikt ipv de CLI; https://www.selfsignedcertificate.com/

Je krijgt een prompt waar je gevraagd wordt om het land etc in te geven, maar het enige dat belangrijk is de common name. Als common name geef je gewoon *.home.arpa in. Dit certificaat is wel niet getekend voor gewoon 'https://rpi4'. Je kan meerdere SAN's toevoegen (CN), maar je certificaat vernieuwen omdat je een nieuwe back-end server toevoegt (deze keer is het esphome) is niet echt praktisch.

Ik ben weer een klein stapje verder! Ik moest het root certificaat installeren in windows en android en nu heb een geaccepteerde https://rpi4/whoami.
Mijn doel is uiteindelijk om home assistant in https te krijgen. Daarvoor heb ik nu:

YAML:

  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/raspberrypi4-homeassistant:stable"
    depends_on:
      - mosquitto
    volumes:
      - ${USERDIR}/hass:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=${TZ}
    restart: unless-stopped
    privileged: true
    network_mode: host
    labels:
      - traefik.enable=true
      - traefik.http.routers.homeassistant.rule=Path("/hass")
      - traefik.http.routers.homeassistant.tls=true
      - traefik.http.routers.homeassistant.entrypoints=web-secure
      - traefik.http.services.homeassistant.loadbalancer.server.port=8123

Maar bij https://rpi4/hass krijg ik nu '400: Bad Request'. Wat is het laatste duwtje om dat aan de gang te krijgen?

[Faifz]

JorisV schreef op dinsdag 28 december 2021 @ 23:12:
[...]


Ik ben weer een klein stapje verder! Ik moest het root certificaat installeren in windows en android en nu heb een geaccepteerde https://rpi4/whoami.
Mijn doel is uiteindelijk om home assistant in https te krijgen. Daarvoor heb ik nu:

Network_mode=host heb je niet nodig. Je containers zitten al achter een bridge network.

[FireDrunk]

Na een *hele* tijd kloten om mijn interne en externe netwerk netjes gescheiden te krijgen in Traefik, heb ik gister deze oplossing gemaakt, misschien vinden mensen hier dat ook wel handig:

Dynamic

YAML:

http:
  middlewares:
    internal-redirect:
      redirectRegex:
        regex: "^https://(?P<subdomain>.*).in.my.tld(?P<port>:8443)?(?P<path>.*)"
        replacement: "https://${subdomain}.in.my.tld:8443${path}"
        permanent: true

Static:

YAML:

## Static configuration
serversTransport:
  insecureSkipVerify: true

entryPoints:
  external:
    address: ":443"
    forwardedHeaders:
      trustedIPs:
      - "10.0.0.0/8"
      - "192.168.1.0/24"
    http:
      middlewares:
      - internal-redirect@file
      tls: {}

  internal:
    address: ":8443"
    forwardedHeaders:
      trustedIPs:
      - "10.0.0.0/8"
      - "192.168.1.0/24"
    http:
      tls: {}

  metrics:
    address: ":9090"

providers:
  kubernetesCRD:
    allowCrossNamespace: true
  file:
    watch: true
    filename: /etc/traefik/dynamic.yaml

log:
  level: WARN

ping: {}

metrics:
  prometheus:
    entryPoint: metrics
    addRoutersLabels: true

api:
  dashboard: true
  insecure: true

Traefik luistert dus op zowel poort 443 als 8443, beide met een SSL certificaat.
Enige verschil is dus dat 443 van buiten open staat, en 8443 niet.
Dit zorgt er voor dat als ik applicaties alleen intern beschikbaar wil hebben, ik ze alleen maar op *.in.my.tld hoef te laten luisteren.

Als iemand extern naar deze url gaat, zal Traefik een harde redirect doen naar poort 8443, waardoor de connectie voor iedereen die extern binnen komt, kapot zal gaan, maar intern (of via VPN), zal blijven werken.

[Hmmbob]

JorisV schreef op dinsdag 28 december 2021 @ 23:12:
Mijn doel is uiteindelijk om home assistant in https te krijgen. Daarvoor heb ik nu:

Sidenote: je weet dat dit alleen lokaal / op jouw devices zal werken zonder SSL errors, en je dus ook geen gebruik kan maken van bijvoorbeeld Google Assistant? Deze vereisen correcte SSL certificaten, geen self-signed certificaten.

Ik snap niet waarom je zoveel moeite doet met een self-signed certificaat, haal gewoon via Let's encrypt een certificaat op en je bent klaar

[Hmmbob]

Faifz schreef op woensdag 29 december 2021 @ 05:41:
[...]


Network_mode=host heb je niet nodig. Je containers zitten al achter een bridge network.

Dit komt uit de standaard Home Assistant documentatie, o.a. om discovery van devices (mDNS) mogelijk te maken.

Alternatief is om Avahi juist in te stellen op de host.

[Faifz]

JorisV schreef op dinsdag 28 december 2021 @ 23:12:

Ik ben weer een klein stapje verder! Ik moest het root certificaat installeren in windows en android en nu heb een geaccepteerde https://rpi4/whoami.
Mijn doel is uiteindelijk om home assistant in https te krijgen. Daarvoor heb ik nu:

Homeassistant krijg ik niet aan de gang, maar esphome wel. Ik raad je wel aan dat je de docker-compose files apart houdt. Dus eentje voor traefik zelf en voor bv esphome. Vergeet je DNS records niet of edit (C:\Windows\System32\drivers\etc\hosts) als je geen DNS server hebt.

Ten eerste had ik een certificaat gemaakt voor *.home.arpa. Had je dit eerder uitgelegd hoe je dit doet.

traefik's docker-compose.yml:

code:

version: '3.3'
networks:
  traefik:
    external: true
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    command:
      # Docker als provider
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      # Entrypoint -> is a front-end named "web" on HTTP Port 80
      - "--entrypoints.web.address=:80"
      # Entrypoint -> is a front-end named "web-secure" on HTTPS Port 443
      - "--entrypoints.web-secure.address=:443"
    ports:
      - 80:80
      - 443:443
    networks:
      - traefik
    restart: unless-stopped
    volumes:
     - ./dynamic-config.yml:/etc/traefik/dynamic/config.yml:ro
     - ./certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

dynamic-config.yml:

code:

tls:
  certificates:
    - certFile: /etc/certs/local-cert.pem
      keyFile: /etc/certs/local-key.pem

esphome's docker-compose.yml:

code:

version: "3"
  
networks:
  traefik:
    external: true
  esphomenetwork:

services:
  esphome:
    image: esphome/esphome
    container_name: esphome2
    volumes:
      - ./esphome-config:/config:rw
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    networks:
      - traefik
      - esphomenetwork
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"
      - "traefik.http.routers.esphome-secure.entrypoints=web-secure"
      - "traefik.http.routers.esphome-secure.rule=Host(`esphome.home.arpa`)"
      - "traefik.http.routers.esphome-secure.tls=true"
      - "traefik.http.services.esphome-secure.loadbalancer.server.port=6052"

[Koepert]

Goedemorgen,

Ik heb een vraag omtrent het gebruik van Traefik binnen een netwerk.

Ik heb een Proxmox Node (2 totaal) met daarin een LXC container waarop docker --> Traefik draait.

Wat zijn de mogelijkheden om een 2e node toe te voegen an traefik? (de lxc containers daarop dus)

Zit ik dan aan n docker swarm of cluster proxmox (of tweede instance Traefik) vast?

Of is er wel een optie om Docker containers van een andere node toe te voegen binnen Traefik?

[lolgast]

@Koepert Je kunt sowieso de 'file' functie van Traefik gebruiken natuurlijk

[Koepert]

lolgast schreef op donderdag 10 februari 2022 @ 09:52:
@Koepert Je kunt sowieso de 'file' functie van Traefik gebruiken natuurlijk

Daar ben ik nu al enige tijd mee aan t prutsen.. maar kom er niet uit (ligt vast aan mij)..

Vooral ook omdat ik diverse berichten tegenkom over wel of niet werkend (en welke labels wel of niet)..


- Node 1 met FireflyIII
- Node 2 met Traefik en Authelia

Werkt prima met Docker containers van node 2, werkt prima met entries uit de file. maar niet met Fireflyiii. Zeker niet in combi met Authelia. Wat juist volgens mij een mooie combinatie oplevert.


Voor de volledigheid:

In mijn .env

code:

TRUSTED_PROXIES=**
# It's also possible to change the way users are authenticated. You could use Authelia for example.
# Authentication via the REMOTE_USER header is supported. Change the value below to "remote_user_guard".
#
# This will also allow Windows SSO.
#
# If you do this please read the documentation for instructions and warnings:
# https://docs.firefly-iii.org/advanced-installation/authentication
#
# This function is available in Firefly III v5.3.0 and higher.
##AUTHENTICATION_GUARD=web
AUTHENTICATION_GUARD=remote_user_guard

# If the guard is changed, Firefly III uses the 'REMOTE_USER' header as per RFC 3875.
# You can also use another header, like AUTH_USER when using Windows SSO.
# Some systems use X-Auth headers. In that case, use HTTP_X_AUTH_USERNAME or HTTP_X_AUTH_EMAIL
# Depending on your system, REMOTE_USER may need to be changed to HTTP_REMOTE_USER
#
# Firefly III won't be able to send emails when the header you use isn't an email address.
#
AUTHENTICATION_GUARD_HEADER=HTTP_REMOTE_USER

in mijn firefly container:

code:

      - "traefik.enable=true"
      - "traefik.http.routers.firefly_iii.rule=Host(`myserver.com`)"
      - "traefik.http.routers.firefly_iii.entrypoints=https"
      - "traefik.http.routers.firefly_iii.middlewares=authelia@docker"
      - "traefik.http.routers.firefly_iii.tls=true"
      - "traefik.http.services.firefly_iii.loadbalancer.server.port=8080"

In Authelia

code:

      - "traefik.enable=true"
      - "traefik.http.routers.authelia.rule=Host(`login.myserver.com`)"
      - "traefik.http.routers.authelia.entrypoints=websecure"
      - "traefik.http.routers.authelia.tls=true"
      - "traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rd=https://login.myserver.com/"
      - "traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups"

Met uiteraard overal mn eigen/juiste domein.

Maar ik krijg dus OF een niet werkende pagina OF een "Fatal error: "The Remote-User (REMOTE_USER) header was unexpectedly empty.""

[ Voor 63% gewijzigd door Koepert op 10-02-2022 12:06 ]

[lolgast]

@Koepert Maar die Traefik draait dus in een andere Docker omgeving dan je Firefly? Want dan hebben labels geen zin Labels kunnen alleen uitgelezen worden van de Docker omgeving waar je Traefik mee verbind en ik gok even dat dat de standaar config is endpoint: "unix:///var/run/docker.sock"

Hoe ziet een file voorbeeld eruit van je? Want ik gebruik hier file voor o.a. de verbinding naar Home Assistant (draait op een andere VM) of services op andere LXC containers en dat werkt prima.

[Koepert]

lolgast schreef op donderdag 10 februari 2022 @ 20:33:
@Koepert Maar die Traefik draait dus in een andere Docker omgeving dan je Firefly? Want dan hebben labels geen zin Labels kunnen alleen uitgelezen worden van de Docker omgeving waar je Traefik mee verbind en ik gok even dat dat de standaar config is endpoint: "unix:///var/run/docker.sock"

Ja dat had ik ook wel verwacht idd Maar zonder werkte het OOK niet..

Hoe ziet een file voorbeeld eruit van je? Want ik gebruik hier file voor o.a. de verbinding naar Home Assistant (draait op een andere VM) of services op andere LXC containers en dat werkt prima.

Mijn traefik bestaat uit n docker-compose.yml uiteraard, een traefik.yml (met api etc settings) en een config.yml met daarin (oa)

YAML:

routers;
bla bla
blabla 
    firefly:
      entryPoints:
        - "https"
      rule: "Host(`firefly.domein.adres`)"
      middlewares:
        - default-headers
        - authelia
      tls: {}
      service: firefly 



services
bla
bla
    firefly:
      loadBalancer:
        servers:
          - url: "http://IPADRESZONDERPOORTEN"
        passHostHeader: true


middlewares
blabla
bla
    default-headers:
      headers:
        frameDeny: true
        sslRedirect: true
        browserXssFilter: true
        contentTypeNosniff: true
        forceSTSHeader: true
        stsIncludeSubdomains: true
        stsPreload: true
        stsSeconds: 15552000
        customFrameOptionsValue: SAMEORIGIN
        customRequestHeaders:
          X-Forwarded-Proto: https

    authelia:
      forwardAuth:
        address: blalbla url/domain.. 

Dat is t wel eigenlijk. Ik heb in die config.yml dus meerdere staan (proxmox, jellyfin en home assistant) en dat werkt allemaal van zowel host 1 als host 2.

[lolgast]

Ok, dus even op een rijtje voor mij:
Traefik op Node 2
Firefly op Node 1

Proxmox werkt via de file-config van Traefik?

Werkt Firefly wel als je die benaderd op zijn IP?

[Koepert]

lolgast schreef op donderdag 10 februari 2022 @ 20:55:
Ok, dus even op een rijtje voor mij:
Traefik op Node 2
Firefly op Node 1

Proxmox werkt via de file-config van Traefik?

Werkt Firefly wel als je die benaderd op zijn IP?

Heeel strikt genomen andersom

Node 1 = Proxmox host -> werkt met file-config van traefik (zowel intern als extern en zowel url als ip benaderbaar, traefik alleen op url) Werkt tevens met Authelia.

LXCcontainers:
- Pihole (werkt met traefik en authelia, als test)
- Traefik & Authelia op 1 container

VM:
- Home Assistant (werkt met Traefik, geen Authelia want 2FA in Home Assistant, via File config)

Node 2 = Proxmox2 host --> werkt met file-config van traefik (zowel intern als extern en zowel url als ip benaderbaar, traefik alleen op url) Werkt tevens met Authelia.

LXContainers:
- Pihole 2 (passive bu van 1, werkt met traefik en authelia, wederom als test)
- Jellyfin (werkt met Traefik, geen authelia toegevoegd wederom via file)
- Firefly (werkt NIET met Traefik NOCH Authelia) --> Benaderbaar via Intern DNS op firefly.domein en IP-adres. zodra HTTPS://firefly.domein probeer krijg ik OF site reageert niet (zonder alle labels ed) of Header = empty (authelia).

[lolgast]

@Koepert Het valt me nu op dat je de quotes van 'rule' in mijn ogen heel apart hebt, alsof je een SNI wilt gebruiken. Ik gebruik ze zo

rule: Host("proxmox.domain.nl")