[Docker] [alle OS] Het grote Docker ervaringen en tips topic

[alex3305]

Mars Warrior schreef op dinsdag 7 oktober 2025 @ 18:19:
Thanx voor de "heads up".
Ik draai - zoals vaker - nog heel wat oude versies in mijn setup. Ik update niet zo vaak.
Als de L4 plugin nu kapot is, dan ga ik daar ook veel last van krijgen. Dat is niet de bedoeling. Nu kun je met Docker gewoon weer de oude container starten, maar ik zit niet te wachten op dit soort gezeik na een update.

Het is niet dat ik mensen vraag om mij te volgen, maar ik vind het wel leuk om mijn motieven hier te delen . De L4 plugin werkt of zal binnenkort wel weer werken, maar ik vind nogal gaar om in Forgejo Actions een compleet irrelevante stack trace voor m'n giechel te krijgen als ik net een component heb toegevoegd:

code:

 > [builder 2/2] RUN GOTOOLCHAIN=go1.24.1 xcaddy build     --with github.com/caddy-dns/cloudflare     --with github.com/greenpau/caddy-security     --with github.com/hslatman/caddy-crowdsec-bouncer/http     --with github.com/hslatman/caddy-crowdsec-bouncer/layer4     --with github.com/hslatman/caddy-crowdsec-bouncer/appsec     --with github.com/lucaslorentz/caddy-docker-proxy/v2     --with github.com/mholt/caddy-l4     --with github.com/mholt/caddy-dynamicdns     --with github.com/WeidiDeng/caddy-cloudflare-ip:
124.4 go: added github.com/joho/godotenv v1.5.1
124.4 go: added github.com/lucaslorentz/caddy-docker-proxy/v2 v2.10.0
124.4 2025/08/19 10:48:01 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -v github.com/mholt/caddy-l4 github.com/caddyserver/caddy/v2@v2.10.0 
124.5 go: downloading github.com/mholt/caddy-l4 v0.0.0-20250814163833-b0a5a508a938
124.8 go: accepting indirect upgrade from github.com/cloudflare/circl@v1.6.0 to v1.6.1
124.8 go: accepting indirect upgrade from github.com/quic-go/quic-go@v0.50.1 to v0.54.0
124.8 go: github.com/mholt/caddy-l4@v0.0.0-20250814163833-b0a5a508a938 requires
124.8   github.com/caddyserver/caddy/v2@v2.10.1-0.20250720214045-8ba7eefd0767, but v2.10.0 is requested
124.8 go: github.com/mholt/caddy-l4@upgrade (v0.0.0-20250814163833-b0a5a508a938) requires github.com/caddyserver/caddy/v2@v2.10.1-0.20250720214045-8ba7eefd0767, not github.com/caddyserver/caddy/v2@v2.10.0
124.8 2025/08/19 10:48:01 [FATAL] exit status 1

En dan heb ik net te weinig kaas gegeten van de moderne Go toolchain om daar chocola van te maken. Buiten dat ik ook gewoon geen zin heb in dit soort vage issues. Het versionen, en als dat maar met 0.0.1, vind ik dan een kleine moeite en voorkomt dit soort problemen.

Ik vond Traefik aan de praat krijgen best wel straight forward. Toegegeven ik ken geen grote of populaire reverse proxy waar ik geen (professionele) ervaring mee heb. Dus dat helpt wel enorm, maar kort door de bocht:

Docker Compose

YAML:

services:
  traefik:
    container_name: traefik
    image: traefik:v3.5.3
    restart: on-failure:10
    networks:
      ingress:
      ipvlan:
        ipv4_address: 192.168.1.4
        ipv6_address: aaaa:aaaa:aaaa:1:b00b::135
      monitoring:
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /opt/appdata/traefik/traefik.yaml:/traefik.yaml:ro
      - /opt/appdata/traefik/config:/configs:ro
      - /opt/appdata/traefik/certs/acme.json:/acme.json:rw
      - logs:/logs:rw
    security_opt:
      - no-new-privileges=true
    cpus: 1

networks:
  ingress:
    name: swarm-overlay
    external: true

  ipvlan:
    name: br0
    external: true

  monitoring:
    name: monitoring
    external: true

volumes:
  logs:
    name: traefik-logs

traefik.yaml

YAML:

api:
  dashboard: True
  insecure: True

entryPoints:
  web:
    address: ":80"

    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true

  websecure:
    address: ":443"
    asDefault: true
    http:
      tls:
        certResolver: letsEncrypt
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"

      middlewares:
        - traefik-real-ip@file
        - security-headers@file
        - rate-limit@file

    http3:
      advertisedPort: 443

    forwardedHeaders:
      trustedIPs:
        - 127.0.0.1/32
        - 192.168.0.0/16
        - 172.16.0.0/12
        - 10.0.0.0/8
        # Cloudflare IPs kunnen hier

  dns-over-tls:
      address: :853/tcp
  mqtt-over-tls:
      address: :8883/tcp
  smtp-over-tls:
      address: :465/tcp
  ssh:
      address: :22/tcp

providers:
  providersThrottleDuration: 15s

  file:
    directory: "/configs"

  docker:
    watch: true
    exposedByDefault: false
    network: "swarm-overlay"

certificatesResolvers:
  letsEncrypt:
    acme:
      email: [e-mail]
      storage: /acme.json
      dnsChallenge:
        # Provider credentials should be stored in environment variables.
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "1.0.0.1:53"

metrics:
  prometheus: {}

configs/middlewares.yaml

YAML:

http:
  middlewares:
    traefik-real-ip:
      plugin:
        traefik-real-ip: {}

    local-ips-allowed:
      ipAllowList:
        sourceRange:
          - 192.168.0.0/16
          - 172.16.0.0/12
          - 10.0.0.0/8

    security-headers:
      headers:
        customResponseHeaders:
          browserXssFilter: true
          contentTypeNosniff: true
          frameDeny: true

    rate-limit:
      rateLimit:
        average: 100
        period: 1
        burst: 100

Ik heb eerder / vaker met Treafik gespeeld en gewerkt, maar vind dat nog steeds een enorm waterhoofd.

Ik heb hier wat ik geknipt, maar mijn basis Caddyfile was ook gewoon 190 regels . Zoveel doet dit dus niet voor elkaar onder.

De reden dat ik aan het experimentern was/ben met Traefik voor thuis is dat ik geen Cloudflare heb (veel docker services hangen aan verschillende subdomeinen en toplevel domeinen, die vanzelfsprekend extern worden beheerd). Nu gebruik ik wel wat WAFjes, maar ik wil eigenlijk het gros van het botverkeer met Anubis en Crowdsec eruit filteren, eigenlijk dus volgens jouw plaatje.

Caddy heeft icm Anubis meerdere lagen/instanties nodig, terwijl Traefik dat netjes met middlewares kan afhandelen.

Yes. Dat zit er dus echt nét in . Met Caddy moest ik het e.e.a. doorverwijzen, terwijl ik het nu als middleware kan configureren. Ik ben daar echt blij mee. Ik gebruik dat voor mijn Forgejo instantie.

YAML:

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:12.0.4
    networks:
      internal:
      ingress:
      forgejo:
    labels:
      traefik.enable: true
      traefik.http.routers.forgejo.rule: "Host(`example.com`)"
      traefik.http.routers.forgejo.middlewares: "forgejo-anubis@docker"
      traefik.http.services.forgejo.loadbalancer.server.port: "80"
      traefik.tcp.routers.forgejo-ssh.entrypoints: "ssh"
      traefik.tcp.routers.forgejo-ssh.rule: "HostSNI(`*`)"
      traefik.tcp.services.forgejo-ssh.loadbalancer.server.port: "22"

  anubis:
    container_name: forgejo-anubis
    image: ghcr.io/techarohq/anubis:v1.22.0
    networks:
      internal:
      ingress:
    environment:
      BIND: ":8080"
      TARGET: " "
      COOKIE_DOMAIN: "example.com"
      SERVE_ROBOTS_TXT: "true"
      REDIRECT_DOMAINS: "example.com"
      PUBLIC_URL: "https://anubis.example.com"
    labels:
      traefik.enable: true
      traefik.http.routers.forgejo-anubis.rule: "Host(`anubis.example.com`)"
      traefik.http.services.forgejo-anubis.loadbalancer.server.port: "8080"
      traefik.http.middlewares.forgejo-anubis.forwardauth.address: "http://anubis:8080/.within.website/x/cmd/anubis/api/check"

networks:
  internal:
    name: forgejo-internal
    attachable: false

  forgejo:
    name: forgejo
    attachable: true
    driver: overlay

  ingress:
    name: swarm-overlay
    external: true

Crowdsec heb ik nog niet naar gekeken, maar zou ik dan ook willen toepassen.

Heb jij enig idee hoeveel verkeer jij met Anubis en Crowdsec blokkeert, ondanks dat je ook al Cloudflare gebruikt? Ik lees sterk varierende cijfers als je geen Cloudflare gebruikt: daar claimen mensen dat ze 70-90% van het verkeer kwijt zijn op hun backend services. Als ik zie wat Wordfence op Wordpress al blokkeert, dan wil ik dat best geloven.

Van Crowdsec wel, Anubis niet. Crowdsec en inmiddels ook AppSec gebruik ik voor al mijn HTTP diensten die allemaal aan het internet hangen. Ik heb een aantal regioblokkades via Cloudflare lopen en de Unifi firewall filtert ook het e.e.a.. Toch heb ik momenteel 9 actieve bans en volgens de Crowdsec Console zijn er de afgelopen 7 dagen 4800 requests geblokkeert. De afgelopen 30 dagen blijkbaar zo'n 140 bans. Dat vind ik best wel veel.

Mijn doel is overigens niet om Cloudflare-vrij te worden, maar wel om minder afhankelijk te worden. Crowdsec en Anubis zijn daar mooie stappen voor.

[orvintax]

alex3305 schreef op dinsdag 7 oktober 2025 @ 19:39:
[...]

• diensten zonder authenticatie beveiligen

Vooral die laatste use case vind ik enorm aantrekkelijk. Ik heb bijvoorbeeld mijn eigen gehoste shields instantie beveiligd door Forgejo als OAuth2 Server in te zetten. Deze dienst kan ik dus veilig ontsluiten naar het internet zonder dat er zonder toestemming gebruik van wordt gemaakt.

Misschien interpreteer ik dit nu te simpel, maar hier gebruik ik gewoon HTTP basic authentication met Caddy voor. Maar goed, mijn belangrijkste design punt voor mijn homelab is KISS

[ Voor 4% gewijzigd door orvintax op 07-10-2025 23:22 . Reden: Typo + link ]

[alex3305]

orvintax schreef op dinsdag 7 oktober 2025 @ 23:20:
Misschien interpreteer ik dit nu te simpel, maar hier gebruik ik gewoon HTTP basic authentication met Caddy voor.

Nu haal je mijn post uit context. Waarom zou ik een OAuth of OIDC laag opzetten om daarna de helft met Basic Auth te authenticeren ...

Daarnaast vind ik Basic Auth een beroerde manier om diensten te beschermen. In de eerste plaats omdat je met Basic Auth de credentials in 'plain text' opslaat, het lastig is om wachtwoorden te veranderen en het enorm lastig is om bijvoorbeeld te rate limitten.

Maar goed, mijn belangrijkste design punt voor mijn homelab is KISS

Ik dacht even dat ik op het Viva forum was beland, maar volgens mij zitten we hier op Tweakers . Daarbij wil ik ook aangeven dat ik Basic Auth geen KISS vindt, maar verleden tijd. Een Golf Mk1 is ook KISS en soms erg mooi, maar niet meer van deze tijd.

Pocket ID met Caddy Security opzetten is daarnaast niet het einde van de wereld. Het is ook aardig beheersbaar.

Docker Compose

YAML:

services:
  caddy:
    container_name: caddy
    image: alex3305/caddy:v2.10.0
    networks:
      ingress:
      ipvlan:
        ipv4_address: 192.168.1.10
    cap_add:
      - NET_ADMIN
    environment:
      CADDY_INGRESS_NETWORKS: swarm-overlay
    volumes:
      - /opt/appdata/caddy:/config
      - caddy-data:/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: ["docker-proxy", "--caddyfile-path", "/config/Caddyfile"]

  pocket_id:
    container_name: pocket-id
    image: ghcr.io/pocket-id/pocket-id:v1.13.1
    restart: on-failure:10
    networks:
      ingress:
    volumes:
      - pocket-id-data:/app/data
    labels:
      caddy: "*.example.com"
      [e-mail]: "id.example.com"
      caddy.handle: "@pocket-id"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 1411{{ '}}' }}"

networks:
  ingress:
    name: swarm-overlay
    external: true

  ipvlan:
    name: br0
    external: true

volumes:
  caddy-data:
  pocket-id-data:

Wel moet je hiervoor een eigen Caddy bouwen met bovenstaande plugin en Docker Proxy.

Caddyfile

code:

{
    order authenticate before respond
    order authorize before basicauth
    order authorize before reverse_proxy

    security {
        oauth identity provider pocket-id {
            realm pocket-id
            driver generic

            client_id CLIENT_ID_POCKET_ID
            client_secret CLIENT_SECRET_POCKET_ID
            scopes openid email profile groups
            extract all from userinfo

            base_auth_url https://id.example.com
            metadata_url https://id.example.com/.well-known/openid-configuration

            delay_start 3
        }

        authentication portal default-auth-portal {
            enable identity provider pocket-id

            crypto default token lifetime 86400
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            cookie domain example.com
            cookie insecure off

            cookie lifetime 172800

            ui {
                meta title "example.com Authentication Portal"
                meta author "example.com"
                meta description "Authentication portal for accessing homelab services"

                links {
                    "Apps" https://example.com/lovelace/apps icon "las la-sitemap"
                    "View Me" "/whoami" icon "las la-user"
                }
            }

            transform user {
                match role user
                action add role authp/user
            }

            transform user {
                match role admin
                action add role authp/admin

                ui link "User Management" https://users.example.com icon "las la-users"
                ui link "Whoami" https://whoami.example.com icon "las la-question-circle"
            }
        }

        authorization policy user_access {
            set auth url https://auth.example.com/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            allow roles user

            inject headers with claims
            inject header "X-Username" from "userinfo|preferred_username"
            inject header "X-Token-User-Picture" from picture

            validate bearer header
        }

        authorization policy admin_access {
            set auth url https://auth.example.com/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            allow roles admin

            inject headers with claims
            inject header "X-Username" from "userinfo|preferred_username"
            inject header "X-Token-User-Picture" from picture

            validate bearer header
        }
    }
}

Waarna diensten zeer eenvoudig beveiligd kunnen worden met authorization policies:

YAML:

services:
  my-service:
    labels:
      caddy: "*.example.com"
      [e-mail]: "service.example.com"
      caddy.handle: "@service"
      caddy.handle.authorize: "with user_access"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"

En door SSO hoef ik dus maar één keer in te loggen in plaats van n-aantal keer bij n-aantal diensten. Dat is pas simpel .

[orvintax]

alex3305 schreef op woensdag 8 oktober 2025 @ 10:15:
[...]

Nu haal je mijn post uit context. Waarom zou ik een OAuth of OIDC laag opzetten om daarna de helft met Basic Auth te authenticeren ...

Daarnaast vind ik Basic Auth een beroerde manier om diensten te beschermen. In de eerste plaats omdat je met Basic Auth de credentials in 'plain text' opslaat, het lastig is om wachtwoorden te veranderen en het enorm lastig is om bijvoorbeeld te rate limitten.


[...]

Ik dacht even dat ik op het Viva forum was beland, maar volgens mij zitten we hier op Tweakers . Daarbij wil ik ook aangeven dat ik Basic Auth geen KISS vindt, maar verleden tijd. Een Golf Mk1 is ook KISS en soms erg mooi, maar niet meer van deze tijd.

Pocket ID met Caddy Security opzetten is daarnaast niet het einde van de wereld. Het is ook aardig beheersbaar.

Docker Compose

YAML:

services:
  caddy:
    container_name: caddy
    image: alex3305/caddy:v2.10.0
    networks:
      ingress:
      ipvlan:
        ipv4_address: 192.168.1.10
    cap_add:
      - NET_ADMIN
    environment:
      CADDY_INGRESS_NETWORKS: swarm-overlay
    volumes:
      - /opt/appdata/caddy:/config
      - caddy-data:/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: ["docker-proxy", "--caddyfile-path", "/config/Caddyfile"]

  pocket_id:
    container_name: pocket-id
    image: ghcr.io/pocket-id/pocket-id:v1.13.1
    restart: on-failure:10
    networks:
      ingress:
    volumes:
      - pocket-id-data:/app/data
    labels:
      caddy: "*.example.com"
      [e-mail]: "id.example.com"
      caddy.handle: "@pocket-id"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 1411{{ '}}' }}"

networks:
  ingress:
    name: swarm-overlay
    external: true

  ipvlan:
    name: br0
    external: true

volumes:
  caddy-data:
  pocket-id-data:

Wel moet je hiervoor een eigen Caddy bouwen met bovenstaande plugin en Docker Proxy.

Caddyfile

code:

{
    order authenticate before respond
    order authorize before basicauth
    order authorize before reverse_proxy

    security {
        oauth identity provider pocket-id {
            realm pocket-id
            driver generic

            client_id CLIENT_ID_POCKET_ID
            client_secret CLIENT_SECRET_POCKET_ID
            scopes openid email profile groups
            extract all from userinfo

            base_auth_url https://id.example.com
            metadata_url https://id.example.com/.well-known/openid-configuration

            delay_start 3
        }

        authentication portal default-auth-portal {
            enable identity provider pocket-id

            crypto default token lifetime 86400
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            cookie domain example.com
            cookie insecure off

            cookie lifetime 172800

            ui {
                meta title "example.com Authentication Portal"
                meta author "example.com"
                meta description "Authentication portal for accessing homelab services"

                links {
                    "Apps" https://example.com/lovelace/apps icon "las la-sitemap"
                    "View Me" "/whoami" icon "las la-user"
                }
            }

            transform user {
                match role user
                action add role authp/user
            }

            transform user {
                match role admin
                action add role authp/admin

                ui link "User Management" https://users.example.com icon "las la-users"
                ui link "Whoami" https://whoami.example.com icon "las la-question-circle"
            }
        }

        authorization policy user_access {
            set auth url https://auth.example.com/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            allow roles user

            inject headers with claims
            inject header "X-Username" from "userinfo|preferred_username"
            inject header "X-Token-User-Picture" from picture

            validate bearer header
        }

        authorization policy admin_access {
            set auth url https://auth.example.com/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 703576704369326f4f6e11b1eeaf189a07f5590dd7fc983d1473efb6dbca4f49

            allow roles admin

            inject headers with claims
            inject header "X-Username" from "userinfo|preferred_username"
            inject header "X-Token-User-Picture" from picture

            validate bearer header
        }
    }
}

Waarna diensten zeer eenvoudig beveiligd kunnen worden met authorization policies:

YAML:

services:
  my-service:
    labels:
      caddy: "*.example.com"
      [e-mail]: "service.example.com"
      caddy.handle: "@service"
      caddy.handle.authorize: "with user_access"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"

En door SSO hoef ik dus maar één keer in te loggen in plaats van n-aantal keer bij n-aantal diensten. Dat is pas simpel .

Voor de duidelijkheid ik zeg niet dat jouw opzet "fout" is. Ik was meer benieuwd of ik je op dat vlak goed had begrepen.

OAuth en OIDC in samenwerking met HTTP Basic authenticatie slaat nergens op nee. Maar mijn punt was dan ook dat je die lagen niet nodig hebt. Puur vanuit functioneel blik. Maar ik snap dat je het leuk vind om te doen

Dat HTTP Basic authenticatie niet meer van deze tijd is ben ik het absoluut niet mee eens. Het is oud, het werkt en het is simpel. Ik vind dat persoonlijk drie grote pluspunten. Ik ben zelf tegenwooridg best waakzaam met het introduceren van extra complexiteit. Zeker voor mijn HomeLab, die ik niet alleen gebruik om mee te spelen maar ook " persoonlijke productie" op draai.

Maar goed heel veel mensen vinden dat leuk, hip en spannend. Dat zie ik ook in de professionele wereld. Tevens vind ik het wel tof om te zien dat je het allemaal hebt draaien. Het is natuurlijk ook gewoon leuk, hip en spannend

Voor de goede orde, als je HTTP Basic authenticatie gebruikt met Caddy worden de wachtwoorden gehashed opgeslagen. Dus die staan nergens in plaintext.

[ Voor 1% gewijzigd door orvintax op 08-10-2025 12:20 . Reden: Nederlands is moeilijk ]

[Mars Warrior]

@alex3305 . Aangezien ik zowel http services als https services heb kan ik volgens mij geen automatische redirect configureren voor Traefik, en moet ik alle externe domeinen handmatig redirecten. Dat betekent dus dat 3 regels Caddy vertalen naar ca 10-12 regels Traefik...

YAML:

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.any-service-rt.rule=Host(`as.example.com`)"
  - "traefik.http.routers.any-service-rt.entrypoints=websecure"
  - "traefik.http.routers.any-service-rt.tls=true"
  - "traefik.http.routers.any-service-rt.middlewares=security-headers@file,rate-limit@file,gzip-compress@file"
  - "traefik.http.services.any-service-svc.loadbalancer.server.port=80"
  # HTTP → HTTPS redirect
  - "traefik.http.routers.any-service-http-rt.rule=Host(`as.example.com`)"
  - "traefik.http.routers.any-service-http-rt.entrypoints=web"
  - "traefik.http.middlewares.any-service-redirect-mw.redirectscheme.scheme=https"
  - "traefik.http.routers.any-service-http-rt.middlewares=any-service-redirect-mw"

Edit:
Het kan nog 1 regel korter door de middleware voor te definieren:

YAML:

      traefik.http.routers.any-service-http-rt.middlewares: redirect-to-https@file

ChatGPT blijkt goed in staat om een docker compose file van ruim 2.000 regels van Caddy naar Traefik om te zetten, waarbij ik de Caddy labels laat staan, en de Traefik lables toevoeg. Daarmee kan ik namelijk makkelijk switchen tussen die 2 om te testen of alles nog werkt.

De compose files worden dus tijdelijk een heel stuk groter. Ik hak mijn huidige compose file namelijk ook meteen in stukken: dat maakt het ook eenvoudiger om een service of cluster van services toe te voegen en/of te verwijderen (tijdelijk). Dan is het namelijk enkel de include toevoegen/verwijderen.
Maakt het geheel ook een stuk overzichtelijker.

Verder lijkt CrowdSec dus op alle domeinen te kunnen werken (onafhankelijk) en Anubis moet je dan per domein/subdomein koppelen, althans ik krijg daar geen hoogte van hoe je die ook tegelijkertijd op meerdere domeinen kan laten werken.

[ Voor 6% gewijzigd door Mars Warrior op 08-10-2025 14:05 ]

[alex3305]

@Mars Warrior Ik heb dus geen enkele HTTP dienst . Alles gaat bij mij via HTTPs. Het zou echter wel wat makkelijker kunnen:

YAML:

services:
  traefik:
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.https-redirectscheme.redirectscheme.scheme=https"
      - "traefik.http.middlewares.https-redirectscheme.redirectscheme.permanent=true"

  any-service:
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.any-service-rt.rule=Host(`as.example.com`)"
      - "traefik.http.routers.any-service-rt.middlewares=https-redirectscheme, security-headers@file, rate-limit@file, gzip-compress@file"

Waarbij je de HTTPS redirect uiteraard ook in een file kunt doen. Volgens de documentatie luisteren services namelijk standaard naar alle EntryPoints

If not specified, HTTP routers will accept requests from all EntryPoints in the list of default EntryPoints. If you want to limit the router scope to a set of entry points, set the entryPoints option.

En de middleware leidt alleen om naar https wanneer het schema verschilt:

The RedirectScheme middleware redirects the request if the request scheme is different from the configured scheme.

Mars Warrior schreef op woensdag 8 oktober 2025 @ 13:27:
De compose files worden dus tijdelijk een heel stuk groter. Ik hak mijn huidige compose file namelijk ook meteen in stukken: dat maakt het ook eenvoudiger om een service of cluster van services toe te voegen en/of te verwijderen (tijdelijk). Dan is het namelijk enkel de include toevoegen/verwijderen.
Maakt het geheel ook een stuk overzichtelijker.

Dat heb ik precies zo gedaan . Alleen heb ik al mijn Compose opgesplitst en template ik via Ansible.

Verder lijkt CrowdSec dus op alle domeinen te kunnen werken (onafhankelijk) en Anubis moet je dan per domein/subdomein koppelen, althans ik krijg daar geen hoogte van hoe je die ook tegelijkertijd op meerdere domeinen kan laten werken.

CrowdSec werkt op alle domeinen. Anubis kan werken per cookie domein. Ik gebruik dus example.com als cookie domein en dat werkt dan ook voor shields.example.com. Meerdere redirect domains zijn wel mogelijk en volgens de documentatie zou de optie COOKIE_DYNAMIC_DOMAIN zijn die jij zoekt. Wel krijg je met een ander domain dan wel een nieuwe challenge, maar dat lijkt mij logisch.

[Mars Warrior]

alex3305 schreef op woensdag 8 oktober 2025 @ 16:10:
@Mars Warrior Ik heb dus geen enkele HTTP dienst . Alles gaat bij mij via HTTPs. Het zou echter wel wat makkelijker kunnen:

Aha. Tsja, ik heb nog zitten denken als ik alles https doe, dan heb ik ook geen gezeik meer met browsers die vinden dat http onveilig is, of zelfs niet meer op http willen gaan zitten...

Als ik dan een ip-allow-list erbij gooi die enkel lokale addressen toestaat, dan kan ik volgens mij nog steeds Traefik certificaten (http/tls challenge) laten ophalen, maar kan niemand er van buitenaf bij
Geeft wel een hele buts aan certificaten extra, maar ik zag dat LE per domein rate-limiting doet van 50/week. Dat zou dan best goed uitkomen met 50 containers verspreid over een serie domeinen.

YAML:

services:
  traefik:
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.https-redirectscheme.redirectscheme.scheme=https"
      - "traefik.http.middlewares.https-redirectscheme.redirectscheme.permanent=true"

  any-service:
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.any-service-rt.rule=Host(`as.example.com`)"
      - "traefik.http.routers.any-service-rt.middlewares=https-redirectscheme, security-headers@file, rate-limit@file, gzip-compress@file"

Waarbij je de HTTPS redirect uiteraard ook in een file kunt doen. Volgens de documentatie luisteren services namelijk standaard naar alle EntryPoints

Aha. Dus al die instellingen zijn dan overbodig omdat de service toch al op beide poorten luistert. Dan is dat impliciet, en ChatGPT houdt regelmatig van expliciete definities heb ik gemerkt.

Dat heb ik precies zo gedaan . Alleen heb ik al mijn Compose opgesplitst en template ik via Ansible.

Ik template dus met ChatGPT. Ook best wel reproduceerbaar, maar niet te automatiseren nog. Maar met af en toe een extra container perfect te doen. Ik geef de compose definitie op (of laat ChatGPT zoeken), en geef aan wat ik erbij wil hebben.

De enige beperking is dat ChatGPT af en toe dement is, wel een file van 2.000 regels kan invoeren, maar die op geen enkele manier meer kan uitvoeren: dat moet in batches. Helaas lukt het me nog steeds niet om alle batches in één keer te laten doen: na elke batch moet ik "Ja" zeggen, doe ze allemaal maar, maar nee hoor, bij de volgende weer de vraag of dat ding verder moet

CrowdSec werkt op alle domeinen. Anubis kan werken per cookie domein. Ik gebruik dus example.com als cookie domein en dat werkt dan ook voor shields.example.com. Meerdere redirect domains zijn wel mogelijk en volgens de documentatie zou de optie COOKIE_DYNAMIC_DOMAIN zijn die jij zoekt. Wel krijg je met een ander domain dan wel een nieuwe challenge, maar dat lijkt mij logisch.

Aha. Nou eerst maar eens de basis leggen met Traefik werkende krijgen. Daarna volgt CrowdSec wel. Als ik dan al een hoop troep kwijt ben, ben ik al blij.

---

Verder klinken zowel Beszel (systeem en container monitoring) als VictoriaMetrics voor app performance metrics interessant. Beiden hebben dashboards zag ik. Die van Beszel zijn lekker ingebouwd en overzichtelijk. Meer heb ik toch niet nodig om af en toe te kijken hoe contaieners het doen, en wat het effect van wijzigingen is.

[RobertMe]

Mars Warrior schreef op woensdag 8 oktober 2025 @ 17:29:
[...]

Aha. Tsja, ik heb nog zitten denken als ik alles https doe, dan heb ik ook geen gezeik meer met browsers die vinden dat http onveilig is, of zelfs niet meer op http willen gaan zitten...

Als ik dan een ip-allow-list erbij gooi die enkel lokale addressen toestaat, dan kan ik volgens mij nog steeds Traefik certificaten (http/tls challenge) laten ophalen, maar kan niemand er van buitenaf bij
Geeft wel een hele buts aan certificaten extra, maar ik zag dat LE per domein rate-limiting doet van 50/week. Dat zou dan best goed uitkomen met 50 containers verspreid over een serie domeinen.


[...]

Aha. Dus al die instellingen zijn dan overbodig omdat de service toch al op beide poorten luistert. Dan is dat impliciet, en ChatGPT houdt regelmatig van expliciete definities heb ik gemerkt.

[...]

Ik template dus met ChatGPT. Ook best wel reproduceerbaar, maar niet te automatiseren nog. Maar met af en toe een extra container perfect te doen. Ik geef de compose definitie op (of laat ChatGPT zoeken), en geef aan wat ik erbij wil hebben.

De enige beperking is dat ChatGPT af en toe dement is, wel een file van 2.000 regels kan invoeren, maar die op geen enkele manier meer kan uitvoeren: dat moet in batches. Helaas lukt het me nog steeds niet om alle batches in één keer te laten doen: na elke batch moet ik "Ja" zeggen, doe ze allemaal maar, maar nee hoor, bij de volgende weer de vraag of dat ding verder moet


[...]

Aha. Nou eerst maar eens de basis leggen met Traefik werkende krijgen. Daarna volgt CrowdSec wel. Als ik dan al een hoop troep kwijt ben, ben ik al blij.

---

Verder klinken zowel Beszel (systeem en container monitoring) als VictoriaMetrics voor app performance metrics interessant. Beiden hebben dashboards zag ik. Die van Beszel zijn lekker ingebouwd en overzichtelijk. Meer heb ik toch niet nodig om af en toe te kijken hoe contaieners het doen, en wat het effect van wijzigingen is.

VictoriaMetrics moet je wel meer vergelijken met Prometheus & InfluxDB. Het is puur een time series database. Hoe je de data er in krijgt is aan jou (wat dus zowel via node-exporter en dergelijke kan, of via Telegraf, of via <whatever>). En dashboards is bij VM ook net zo basic als Prometheus (/volgens mij letterlijk hetzelfde?). Grafana dus aan te bevelen (en die kun je dus ook alleen starten als je er naar wilt kijken )

[Mars Warrior]

Nou, nou, dat Beszel is lichtgewicht en echt belachelijk eenvoudig met compose te installeren.
In de webinterface voeg je dan een systeem toe (je lokale agent), en je knipt/plakt ff de key en token in je compose file en je start de agent.

Klaar!

Dashboards zijn voorgedefinieerd en worden direct gevuld met informatie.

• Processorgebruik is gewoon van 0..100%. Geen gezeik met die maffe Linux percentages. Ik zie nu dat het gemiddelde verbruik 2% is
• Alles in NL
• Met een hover zie ik direct alle 50 containers van veel naar weinig resource verbruik
• Je kunt simpelweg filteren op container/service naam: ik heb overal de groepsnaam voor, dus ik kan nu wel vreselijk eenvoudig zien wat infra, of websites verbruiken

Je kunt alleen niet het Schijf I/O per docker container zien, enkel overall. Ik zie nu ca 250kB/sec gemiddeld, maar dus geen idee of dat Ubuntu is (journal, etc) of welke Docker container continue staat te schrijven.

En hoppa: ik zit nu op 1,52% CPU verbruik: een container die nu helemaal niet gebruikt wordt blijkt een health-check te hebben: dat pakt al bijna gemiddeld 0,5%.

Heel veel containers laten netjes 0,00% CPU verbruik zien: die doen het goed als ze niks te doen hebben...

Kiek: daar gaat mijn CPU verbruik lekker omlaag

[ Voor 61% gewijzigd door Mars Warrior op 08-10-2025 21:08 ]

[alex3305]

@Mars Warrior Certificaten worden onafhankelijk aangevraagd van eventuele IP allowlist. Zelf gebruik ik overigens een DNS Challenge zodat ik met wildcard certificaten kan werken. Dan komen specifieke apps eveneens niet voor in een eventuele transparency report.

Ik doe inmiddels al jaren alles op HTTPS met een split horizon DNS, waarbij de publieke DNS dus via Cloudflare loopt (zie flowchart boven) en intern of VPN verkeer dus direct via Traefik loopt. Ik heb hiervoor A-records toegevoegd in Unifi en AdGuard Home serveert ook nog eens een HTTPS record:

||example.com^$dnstype=HTTPS,dnsrewrite=NOERROR;HTTPS;1 . alpn=h3 ipv4hint=192.168.1.40

Hierdoor kan de browser direct via udp/443 HTTP/3 verbinden .

Aha. Dus al die instellingen zijn dan overbodig omdat de service toch al op beide poorten luistert. Dan is dat impliciet, en ChatGPT houdt regelmatig van expliciete definities heb ik gemerkt.

Yes. Ik heb geen enkele moeite met de documentatie en schrijf al mijn code met het handje . Ik ben daarmee wellicht ouderwets, maar het meeste heb ik toch getemplate met Ansible. Daarmee is een uitrol inmiddels triviaal.

Verder klinken zowel Beszel (systeem en container monitoring) als VictoriaMetrics voor app performance metrics interessant. Beiden hebben dashboards zag ik. Die van Beszel zijn lekker ingebouwd en overzichtelijk. Meer heb ik toch niet nodig om af en toe te kijken hoe contaieners het doen, en wat het effect van wijzigingen is.

Leuke ontwikkelaar van Beszel ook. Alerting is ook echt dik in orde. Alleen wil ik gewoon wat meer. Ik wil bijvoorbeeld ook logging kunnen analyseren. Ook access logging bijvoorbeeld. En dan is Beszel onvoldoende.

Inmiddels heb ik besloten nav. posts hier om naar de TIG Stack te gaan kijken. Met InfluxDB zou ik logging namelijk ook kunnen tacklen.

[Mars Warrior]

alex3305 schreef op woensdag 8 oktober 2025 @ 20:51:
@Mars Warrior Certificaten worden onafhankelijk aangevraagd van eventuele IP allowlist. Zelf gebruik ik overigens een DNS Challenge zodat ik met wildcard certificaten kan werken. Dan komen specifieke apps eveneens niet voor in een eventuele transparency report.

Mooi. Dan zou ik dus wel alles op https kunnen zetten, waarbij die sites enkel intern bereikbaar zijn

Ik doe inmiddels al jaren alles op HTTPS met een split horizon DNS, waarbij de publieke DNS dus via Cloudflare loopt (zie flowchart boven) en intern of VPN verkeer dus direct via Traefik loopt. Ik heb hiervoor A-records toegevoegd in Unifi en AdGuard Home serveert ook nog eens een HTTPS record:

||example.com^$dnstype=HTTPS,dnsrewrite=NOERROR;HTTPS;1 . alpn=h3 ipv4hint=192.168.1.40

Hierdoor kan de browser direct via udp/443 HTTP/3 verbinden .

Ik wist niet dat dat zo heette. Ik gebruik de DNS Rewrite van AdGuard om een lokale DNS te hebben die alles simpelweg doorzet naar het IP adres van de server.
Is die regel hierboven uit AdGuard dan? Dat zegt me niks namelijk

Yes. Ik heb geen enkele moeite met de documentatie en schrijf al mijn code met het handje . Ik ben daarmee wellicht ouderwets, maar het meeste heb ik toch getemplate met Ansible. Daarmee is een uitrol inmiddels triviaal.

Voor mij is veel documentatie onsamenhangend: leuk om elke optie apart uit te leggen, maar als ik iets integraals wil, dan wil ik de samenhang zien, en veel technische documentatie levert dat niet.

Ik kan dus best wel dingen lezen, maar vind vaak niet wat ik zoek. Een bot als ChatGPT is wel in staat om dingen integraal (als je dit wilt, dan heb je de volgende combinatie van instellingen nodig...) ff in een paar seconden neer te zetten. Dat scheelt gewoon bergen tijd.

Leuke ontwikkelaar van Beszel ook. Alerting is ook echt dik in orde. Alleen wil ik gewoon wat meer. Ik wil bijvoorbeeld ook logging kunnen analyseren. Ook access logging bijvoorbeeld. En dan is Beszel onvoldoende.

Yep. Ik zie Beszel enkel als systeem/docker monitoring. Dan heb je nog applicatie monitoring (metrics), en uiteindelijk logmonitoring voor de details.
Feitelijk dus 3 aparte systemen in mijn geval.

Inmiddels heb ik besloten nav. posts hier om naar de TIG Stack te gaan kijken. Met InfluxDB zou ik logging namelijk ook kunnen tacklen.

Ben benieuwd hoe dat bevalt!

[RobertMe]

alex3305 schreef op woensdag 8 oktober 2025 @ 20:51:
Ik doe inmiddels al jaren alles op HTTPS met een split horizon DNS, waarbij de publieke DNS dus via Cloudflare loopt (zie flowchart boven) en intern of VPN verkeer dus direct via Traefik loopt. Ik heb hiervoor A-records toegevoegd in Unifi en AdGuard Home serveert ook nog eens een HTTPS record:

||example.com^$dnstype=HTTPS,dnsrewrite=NOERROR;HTTPS;1 . alpn=h3 ipv4hint=192.168.1.40

Hierdoor kan de browser direct via udp/443 HTTP/3 verbinden .

Heb je hier meer uitleg over / linkje? Nog nooit gehoord dat je HTTP/3 ook via DNS kunt adverteren (Traefik adverteert hem wel bij mij).

Inmiddels heb ik besloten nav. posts hier om naar de TIG Stack te gaan kijken. Met InfluxDB zou ik logging namelijk ook kunnen tacklen.

VictoriaMetrics & VictoriaLogs?
Influx is bij mij een beetje afgedaan. Doe er eigenlijk vrijwel niks mee. Maar ze zijn niet heel "stabiel". In Influx v1 moest je data ophalen via SQL, vervolgens hebben ze hun eigen (query) taal bedacht, "flux". Toen kwam Influx 2 uit met alleen flux en geen SQL. En quess what? Influx 3 bevat weer alleen SQL . Als je dus "serieus" gebruik maakt van Influx mocht je de afgelopen jaren verplicht 3x de queries (her)schrijven.
En daarnaast is de OSS versie ook een onderschoven kindje meen ik. In de zin dat Influx 3 voor self hosting / open source lang op zich heeft laten wachten terwijl de cloud versie al lang beschikbaar was.

[alex3305]

@Mars Warrior Voor de goede orde, het documentatiepunt was geen kritiek hè . Ik snap niet dat mensen ChatGPT of iets vergelijkbaars eenvoudig vinden. Ik vind documentatie lezen dan vaak eenvoudiger .

@Mars Warrior @RobertMe HTTP/3 is een stuk complexer dan de voorgangers en gebruikt QUIC op basis van UDP voor bestandsoverdrachten. De 'standaardpoort' hiervoor is 443, maar dan moet een client - laten we zeggen een browser - dat wel weten. Een HTTPS record wordt daar dan als hint voor gebruikt. Er kan nog wel meer in, zoals ECH.

Cloudflare stuurt die hints al een tijdje standaard:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Door mijn split horizon DNS werkt dit dus niet (correct). Ik stuur dus vanuit AdGuard Home ook zo'n record mee. Alleen ondersteund AdGuard Home weer niet de hele subset/syntax. Althans niet op een eenvoudige manier.

Ik stuur die records al bijna een jaar mee zie ook mijn post in het AdGuard Home topic. Helaas zonder enige Henkjes



Blijkbaar ben ik dus de enige die hier tegenaan loopt

[alex3305]

RobertMe schreef op woensdag 8 oktober 2025 @ 21:06:
VictoriaMetrics & VictoriaLogs?
Influx is bij mij een beetje afgedaan. Doe er eigenlijk vrijwel niks mee. Maar ze zijn niet heel "stabiel". In Influx v1 moest je data ophalen via SQL, vervolgens hebben ze hun eigen (query) taal bedacht, "flux". Toen kwam Influx 2 uit met alleen flux en geen SQL. En quess what? Influx 3 bevat weer alleen SQL . Als je dus "serieus" gebruik maakt van Influx mocht je de afgelopen jaren verplicht 3x de queries (her)schrijven.
En daarnaast is de OSS versie ook een onderschoven kindje meen ik. In de zin dat Influx 3 voor self hosting / open source lang op zich heeft laten wachten terwijl de cloud versie al lang beschikbaar was.

Ik heb dezelfde afkeer tegen InfluxDB... Maar heb je een linkje voor mij hoe ik bijv. nodes / Docker kan monitoren? Of logs kan verzamelen? Of een startpunt?

[Mars Warrior]

Ik krijg alweer Déjà vu's...

code:

infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:29+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:30+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:31+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:32+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:34+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:36+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:40+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:27:47+02:00","message":"Command error"}
infra-traefik  | {"level":"error","error":"command traefik error: field not found, node: middleware","time":"2025-10-09T16:28:00+02:00","message":"Command error"}

Waar? Welk veld?

Ach ja. De ontwikkelaars van Treafik zijn in de loop der jaren geen steek veranderd

[RobertMe]

alex3305 schreef op woensdag 8 oktober 2025 @ 21:58:
[...]

Ik heb dezelfde afkeer tegen InfluxDB... Maar heb je een linkje voor mij hoe ik bijv. nodes / Docker kan monitoren? Of logs kan verzamelen? Of een startpunt?

Uhm...

Ik heb toen gewoon Influx in Docker gestart (en later VictoriaMetrics), en Telegraf via de apt repo geïnstalleerd. V.w.b. Telegraf => Influx denk ik wel de docs gebruikt? Verder gewoon zelf het sample config bestand nagelopen en gekeken welke input ik aan of uit wilde hebben. Met de switch naar VM even gepuzzeld v.w.b. de juiste output config (IIRC moet dat influx (v1) zijn en niet influx_v2) en dat was het zo'n beetje.
Vrij letterlijk ook, want Grafana heb ik vrijwel niks in staan (en dus ook geen "standaard" dashboard over genomen).
Ik ben er dus niet heel fanatiek mee.

En v.w.b. VictoriaLogs weet ik uberhaupt alleen van het bestaan af. Nooit naar gekeken verder en heb het dus ook niet draaien.
Maar zou ik eigenlijk wel moeten doen, met in totaal 5 server like systemen. VPS, router, servertje, "NAS" (/server), en OrangePi voor backups bij familie. Allemaal Debian (/ARMBian op OrangePi). Jip. Dat is incl router die plain Debian draait.

[RobertMe]

Overigens weet ik niet of ik nog welkom ben in dit topic?

Vorige maand de NAS / server opnieuw geïnstalleerd en Podman er op gezet. En vervolgens was ik een week later, terwijl dat nog niet eens goed en wel draaide, de router ook aan het over zetten naar Podman. Dus van de 4 systemen met een OCI runtime zijn er nu nog maar 2 met Docker, en 2 met Podman.

Waarom Docker / Podman op een router? Nouja, bv Unbound als DNS . Maar gezien het "servertje" 8GB gesoldeerd RAM heeft en vol zit, en de router SODIMM heeft, en ik begon met 1 8GB reepje van een oude 16GB set, en daarvan al veel vrij was, en intussen het andere reepje er ook in zit, draait er veel meer op de router. Waaonder intussen ook Forgejo & Renovate. En beide zijn dan mini PCtjes met een Intel N5105, dus gelijke performance. De nu NAS, met 3x 3,5" HDD en dus onzuinig, heeft wel meer paardenkrachtjes (i3-9100, 32GB RAM), maar die staat alleen on-demand aan. Zowel router als servertje zit een 4TB SSD in voor opslag die nodig is, en de Linux ISOs worden permanent op de NAS bewaard zeg maar

Enige "issue" waar ik nu met Podman tegenaan loop is dat Telegraf draaiende onder de telegraf user natuurlijk geen toegang heeft tot de Podman socket (Docker compatibiliteit) aangezien Podman alles doet onder de user die het commando uitvoert en dus geen "extra" toegang geeft (zoals bij Docker zelf dus iedereen in de "docker" user group toegang heeft tot de socket).

[alex3305]

RobertMe schreef op donderdag 9 oktober 2025 @ 17:32:
Overigens weet ik niet of ik nog welkom ben in dit topic?

Misschien is een topic naamswijziging wel op z'n plaats? Ik blijf OCI containers uit gewoonte nog toch steeds Docker containers noemen. Of die dan aangestuurd worden door de Docker of Podman runtime vind ik om het even. Ook heb ik uit gewoonte ook altijd een alias ingesteld op machines met podman.

Ik ben zelf al enige tijd aan het spelen met rootless containers. Ook in Docker. Zie bijvoorbeeld mijn Forgejo Runner + DIND image. Maar dat werkt niet optimaal. Ik krijg regelmatig vage foutmeldingen en VPNKit - die gebruikt wordt voor netwerktoegang - gebruikt soms achterlijk veel CPU. Ik heb dus ook al overwogen om dat om te bouwen naar Podman. En eventueel op termijn twee releases cq. Dockerfile's bij te houden.

[Mars Warrior]

RobertMe schreef op donderdag 9 oktober 2025 @ 17:32:
Overigens weet ik niet of ik nog welkom ben in dit topic?

Alleen dit topic 🥴🤣 ?

[Mars Warrior]

Nou. Na 4 uur kloten met Traefik en 50 containers draait het op de belangrijkste containers.

Wat een ongelofelijk fout gevoelig en irritant pakket om sommige vlakken. Caddy draaide na een paar minuten en heeft geen moeite met bijv niet-healthy containers om maar iets te noemen.

Traefik slaat ze gewoon over. Dus geen toegang, geen certificaat, niks nakkes nada. Ook niks zichtbaar op de webgui. Waar bemoeit dat pakket zich mee 🧐

Ben er ff helemaal klaar mee.

[RobertMe]

Mars Warrior schreef op donderdag 9 oktober 2025 @ 21:42:
Wat een ongelofelijk fout gevoelig en irritant pakket om sommige vlakken. Caddy draaide na een paar minuten en heeft geen moeite met bijv niet-healthy containers om maar iets te noemen.

Traefik slaat ze gewoon over. Dus geen toegang, geen certificaat, niks nakkes nada. Ook niks zichtbaar op de webgui. Waar bemoeit dat pakket zich mee 🧐

De container is unhealthy, dus...? Wat zou die er dan mee moeten doen? Daadwerkelijk requests uitvoeren kan die toch niet.

En ja, wellicht dat die iets er mee kan. Maar blijkbaar is de implementatie dat die de hele service/route pas toevoegt als die healthy/started is en verwijderd als dat niet meer de status is. An zich best iets voor te zeggen IMO.

En uiteraard kun je de services / routes ook op een andere manier vastleggen (in een file bv), dan bestaan ze wel altijd.

Overigens niet alles gevolgd, maar waarom ben je nu, zo ontzettend tegen je zin in, alsnog de overstap aan het maken? Je geeft uhm, al jaren op Traefik af en vind Caddy geweldig.

Edit:
Owja, trouwens is er ook [Traefik - Proxy/Loadbalancer] Ervaringen & Discussie Daar is het onderwerp Traefik veel meer ontopic

[ Voor 6% gewijzigd door RobertMe op 09-10-2025 22:03 ]

[alex3305]

RobertMe schreef op donderdag 9 oktober 2025 @ 21:50:
Overigens niet alles gevolgd, maar waarom ben je nu, zo ontzettend tegen je zin in, alsnog de overstap aan het maken? Je geeft uhm, al jaren op Traefik af en vind Caddy geweldig.

Die snap ik ook niet helemaal eigenlijk. Misschien toch lichtelijke FOMO voor @Mars Warrior ? Dat zou mij namelijk ook kunnen gebeuren .

Ik begrijp alleen niet zo goed waarom @Mars Warrior unhealthy containers heeft eigenlijk. Ik heb geen enkele unhealthy container, maar ik heb wel een boel containers zonder health check. Meestal omdat ik niet de moeite heb genomen om de health check in te stellen in Compose . Het is overigens wel mogelijk om de health check uit te zetten als je er 'last van hebt':

compose.yaml

YAML:

services:
  # Oudere Docker Compose
  your-service:
    healthcheck:
      test: ["NONE"]

  # Moderne Docker Compose, waarschijnlijk wil je deze
  your-service:
    healthcheck:
      disable: true

Als ik het me goed kan herinneren scheelt dit ook (een aantal) CPU cycles .

Eveneens lijkt het mogelijk om Traefik Docker health checks te laten negeren met de optie allowEmptyServices:

traefik.yaml

YAML:

providers:
  providersThrottleDuration: 15s

  docker:
    watch: true
    exposedByDefault: false
    allowEmptyServices: true
    network: "swarm-overlay"

[alex3305]

Om nog even terug te komen op mijn monitoring vraag. Ik ben vandaag toch weer teruggegaan naar Beszel. Ik heb geen zin om Grafana te leren. Hoe zeer mijn FOMO dan opspeelt . Daarbovenop komt dan ook nog dat Docker stats - wat voor mij een basiscomponent is - lastig energiezuinig én betrouwbaar in Prometheus te krijgen zijn. Het zal allicht allemaal aan mij en mijn setup liggen, maar tegen het eenvoudige karakter van Beszel kan dit dan gewoon niet op.

Wel heb ik met Ansible de disk mounts toegevoegd aan de agent container(s). Die miste ik wel echt in Beszel en was ook een van de redenen dat ik over wilde gaan. Ik heb hiermee nog twee punten openstaan:

• Reverse Proxy statistieken en access logging (Traefik en...? maar hier OT)
• Uitval van statistieken bij hoge load (maar hier ook enigszins OT)

Waarbij dat laatste door Unraid en mijn Docker setup lijkt te komen.

Maar goed, ik ben blij met het resultaat, inclusief Intel GPU monitoring en dus de afzonderlijke disks:

[RobertMe]

alex3305 schreef op donderdag 9 oktober 2025 @ 22:09:
Ik begrijp alleen niet zo goed waarom @Mars Warrior unhealthy containers heeft eigenlijk. Ik heb geen enkele unhealthy container, maar ik heb wel een boel containers zonder health check. Meestal omdat ik niet de moeite heb genomen om de health check in te stellen in Compose . Het is overigens wel mogelijk om de health check uit te zetten als je er 'last van hebt':

compose.yaml

YAML:

services:
  # Oudere Docker Compose
  your-service:
    healthcheck:
      test: ["NONE"]

  # Moderne Docker Compose, waarschijnlijk wil je deze
  your-service:
    healthcheck:
      disable: true

Als ik het me goed kan herinneren scheelt dit ook (een aantal) CPU cycles .

Ik denk dat @Mars Warrior daar bekend mee is. Want in het zuinige server topic begon die juist over een hoger stroomverbruik (of in ieder geval package power usage) door een container die "stiekem" een health check had geïntroduceerd

Bedoel je trouwens niet "Docker Compose" i.p.v. "oudere Docker Compose" en "Compose" i.p.v. "moderne Docker Compose" De "nieuwe" is immers een semi onafhankelijke standaard.

Eveneens lijkt het mogelijk om Traefik Docker health checks te laten negeren met de optie allowEmptyServices:

traefik.yaml

YAML:

providers:
  providersThrottleDuration: 15s

  docker:
    watch: true
    exposedByDefault: false
    allowEmptyServices: true
    network: "swarm-overlay"

Cool. Gevalletje RTFM dus . Ik had wel even snel gezocht (/DuckDuckGo). En eerste hit was een issue met een "gaan we niet doen" reply en closed. Blijkbaar later dus alsnog toegevoegd.

[Mars Warrior]

RobertMe schreef op donderdag 9 oktober 2025 @ 21:50:
[...]
De container is unhealthy, dus...? Wat zou die er dan mee moeten doen? Daadwerkelijk requests uitvoeren kan die toch niet.

Als de health-check faalt wil dat niet per definitie zeggen dat er ook maar iets aan de container mankeert. Sommige containers hebben een manke health-check namelijk. Al mijn unhealthy containers werken gewoon, al jaaaaaaaaaaaaaaaaaaaaaren.

Het gedrag van Traefik in dit geval staat ook nergens uitgelegd als intro. Het is dat ik logging=DEBUG heb aangezet, dat ik die melding voorbij zag komen.

En ja, ook ik heb er op gezocht. Maar een naam als allowEmptyServices klinkt nu niet echt logisch, of wel?

De documentatie laat ook hier nogal wat steken vallen: https://doc.traefik.io/tr...providersThrottleDuration beschrijft geen defaults, laat staan of het ms/sec/uren zijn. Typische technische documentatie die voor mij zo ongeveer onbruikbaar is.

Overigens niet alles gevolgd, maar waarom ben je nu, zo ontzettend tegen je zin in, alsnog de overstap aan het maken? Je geeft uhm, al jaren op Traefik af en vind Caddy geweldig.

Ik vind de eenvoud van Caddy geweldig samen met de docker proxy plugin. 3 regels labels en gaan

Maar als je wat meer wilt, bijv met L4 of andere dingen, dan loop je tegen allerhande syntax problemen aan omdat de syntax soms conflicteerd met YAML maps, en dus ben ik veel tijd kwijt. Ook het niet kunnen mixen van een algemene config en de label config is soms een show stopper.

Verder heb ik steeds meer last van bots en andere irritante (AI) scrapers die robots.txt negeren en daarmee mijn back ends onnodig belasten: alles wordt wel tegengehouden dankzij WAFjes in de containers zelf, maar ik wil dat liever aan de voorkant allemaal om zeep helpen. Ik heb nu totaal richting de 2.000 (!!!) actieve lock-outs in de diverse containers.

Vandaar was ik al aan het inlezen over CrowdSec en Anubis, en stomtoevalig kwam @alex3305 vervolgens met wat voorbeelden op de proppen en liet dus zien hoeveel er - ondanks Cloudflare - toch wordt tegengehouden. En Traefik kan in deze een betere/makkelijkere integratie bieden dan Caddy, zeker als je het met de docker proxy plugin wilt regelen: dat is bijna geen doen

En verder heb je tegenwoordig ChatGPT die de omzetting van Caddy labels naar Treafik labels stukken eenvoudiger maakt. Oké, dat ding verzint af en toe labels en functionaliteit die helemaal niet bestaan, maar dan crashed Traefik gewoon

En op mijn vraag waarom ChatGPT niet bestaande velden gebruikt...

💯 Hele terechte (en terechte felle 😉) vraag — en je hebt gelijk om dat scherp te stellen.
Laat me dat even goed uitleggen, want dit gaat over een grens tussen conceptuele uitleg en echte YAML-syntax bij Traefik.

🧩 1️⃣ Wat er precies gebeurde

Toen ik die snippet eerder schreef met:

regex: ".*(xx\\.com|yy\\.nl|zz\\.com).*"

… was dat bedoeld als commentaar / illustratief concept,
niet als geldige Traefik-config — maar ik heb dat niet duidelijk genoeg gemarkeerd.
In Caddy kun je soortgelijke domein-filters wél rechtstreeks doen in de global config,
en ik probeerde te laten zien hoe dat idee er in Traefik uit zou zien,
maar dat was fout geplaatst: het leek alsof dat veld echt bestond.

Kortom: mijn fout ✅ — dat hoort niet thuis in een echte traefik.yaml.

Dus ik was er al even mee bezig. Het is niet dat ik spontaan ff denk: ach laat ik ff voor de gein dingen gaan omzetten voor 50 containers die ook nog eens veel extern gebruikt worden

Ik heb nu weer een werkende config: ik zie wel dat Traefik ca 30ms trager is dan Caddy, maar dat is dan maar zo. Ik heb nog niet naar optimalisaties gekeken, of dat Redis oid nog kan helpen.

Ik ga ervan uit dat dankzij die enkele access.log van Traefik (ipv per domein/site) en de efficientie van CrowdSec, dat dit sowieso sneller is dan de PHP WAFjes op de backends.

Ook lijkt het minder werk dan alles met Fail2Ban trachten te regelen, zeker als ik ook de CrowdSec firewall gebruik die alles meteen op OS niveau blokkeert (iptables/nftables).

Dus er komen weer een paar leuke docker containers bij

[Mars Warrior]

Zo!

alex3305 schreef op woensdag 8 oktober 2025 @ 21:57:
@Mars Warrior Voor de goede orde, het documentatiepunt was geen kritiek hè . Ik snap niet dat mensen ChatGPT of iets vergelijkbaars eenvoudig vinden. Ik vind documentatie lezen dan vaak eenvoudiger .

Mijn neurodiverse brein ziet liever plaatjes en samenhang. Die ontbreekt vaak, dus ik heb vaak moeite met tig pagina's documentatie lezen terwijl ik niet weet wat ik zoek

Als ik ChatGPT de link geef van de actuele documentatie, dan is die vaak goed in staat om dingen te zoeken en samen te vatten. Scheelt me gewoon veel tijd.

Het is wel zo dat je altijd kennis moet hebben van de materie, want ChatGPT verzint nogal eens wat, of claimt dat iets kan wat helemaal niet kan. Dus je zult moeten blijven vragen, zo van "Ken je dit pakket". "Welke versies ken je", etc. om te weten wat de referentie voor de antwoorden is.

Maar heb je eenmaal wat dingen op orde met ChatGPT dan kan deze dus heel goed labels vertalen in dit geval van Caddy naar Traefik, maar ook vertaalbestanden aanmaken voor Wordpress. Er zit vaak wel een beperking in de output qua regels, oftewel je zult dingen zelf moeten ophakken, of ChatGPT in batches laten werken, maar het gaat alsnog factoren sneller dan ik ooit zelf zou kunnen doen.

Met CrowdSec (zie hieronder voor metrics) had ik ook ff problemen met ChatGPT die de oude parameters in eerste instantie nam...

code:

| Situatie                    | Te gebruiken parameters                          |
| --------------------------- | ------------------------------------------------ |
| Oudere plugin (≤ 1.2)       | `api_url`, `api_key`, `log_level`                |
| Nieuwe plugin (≥ 1.3 / 1.4) | `CrowdsecLapiUrl`, `CrowdsecLapiKey`, `LogLevel` |
| Jouw foutmelding?           | Gebruik **de nieuwe** namen                      |

Maar dat eenmaal duidelijk kwamen alle definities voor crowdsec zelf en Traefik eruit rollen. Die heb ik in de betreffende yaml bestanden gezet, en gaan met die banaan...

Ik laat dit voorlopig ff draaien om te zien wat CrowdSec oppikt. AppSec komt dan later wel.
Ik zag wel dat de GUI niet meer wordt meegeleverd, en dat je nu moet koppelen met een gratis account in de cloud.

code:

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Acquisition Metrics                                                                                                        │
├──────────────────────────────────┬────────────┬──────────────┬────────────────┬────────────────────────┬───────────────────┤
│ Source                           │ Lines read │ Lines parsed │ Lines unparsed │ Lines poured to bucket │ Lines whitelisted │
├──────────────────────────────────┼────────────┼──────────────┼────────────────┼────────────────────────┼───────────────────┤
│ file:/var/log/traefik/access.log │ 467        │ 467          │ -              │ 12                     │ 457               │
╰──────────────────────────────────┴────────────┴──────────────┴────────────────┴────────────────────────┴───────────────────╯
╭─────────────────────────────────────────────────╮
│ Local API Decisions                             │
├───────────────────────┬────────┬────────┬───────┤
│ Reason                │ Origin │ Action │ Count │
├───────────────────────┼────────┼────────┼───────┤
│ ssh:exploit           │ CAPI   │ ban    │ 516   │
│ vm-management:exploit │ CAPI   │ ban    │ 35    │
│ generic:scan          │ CAPI   │ ban    │ 1185  │
│ http:bruteforce       │ CAPI   │ ban    │ 6384  │
│ http:crawl            │ CAPI   │ ban    │ 18    │
│ http:exploit          │ CAPI   │ ban    │ 16    │
│ http:scan             │ CAPI   │ ban    │ 4446  │
│ ssh:bruteforce        │ CAPI   │ ban    │ 2394  │
╰───────────────────────┴────────┴────────┴───────╯
╭────────────────────────────────────╮
│ Local API Metrics                  │
├────────────────────┬────────┬──────┤
│ Route              │ Method │ Hits │
├────────────────────┼────────┼──────┤
│ /v1/alerts         │ GET    │ 3    │
│ /v1/heartbeat      │ GET    │ 20   │
│ /v1/usage-metrics  │ POST   │ 1    │
│ /v1/watchers/login │ POST   │ 4    │
╰────────────────────┴────────┴──────╯
╭───────────────────────────────────────────╮
│ Local API Machines Metrics                │
├───────────┬───────────────┬────────┬──────┤
│ Machine   │ Route         │ Method │ Hits │
├───────────┼───────────────┼────────┼──────┤
│ localhost │ /v1/alerts    │ GET    │ 3    │
│ localhost │ /v1/heartbeat │ GET    │ 20   │
╰───────────┴───────────────┴────────┴──────╯
╭────────────────────────────────────────────────────────────────╮
│ Parser Metrics                                                 │
├────────────────────────────────────┬───────┬────────┬──────────┤
│ Parsers                            │ Hits  │ Parsed │ Unparsed │
├────────────────────────────────────┼───────┼────────┼──────────┤
│ child-crowdsecurity/http-logs      │ 1.40k │ 1.09k  │ 316      │
│ child-crowdsecurity/traefik-logs   │ 467   │ 467    │ -        │
│ crowdsecurity/dateparse-enrich     │ 467   │ 467    │ -        │
│ crowdsecurity/geoip-enrich         │ 10    │ 10     │ -        │
│ crowdsecurity/http-logs            │ 467   │ 467    │ -        │
│ crowdsecurity/non-syslog           │ 467   │ 467    │ -        │
│ crowdsecurity/public-dns-allowlist │ 467   │ 467    │ -        │
│ crowdsecurity/traefik-logs         │ 467   │ 467    │ -        │
│ crowdsecurity/whitelists           │ 467   │ 467    │ -        │
╰────────────────────────────────────┴───────┴────────┴──────────╯
╭────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Scenario Metrics                                                                                   │
├──────────────────────────────────────┬───────────────┬───────────┬──────────────┬────────┬─────────┤
│ Scenario                             │ Current Count │ Overflows │ Instantiated │ Poured │ Expired │
├──────────────────────────────────────┼───────────────┼───────────┼──────────────┼────────┼─────────┤
│ crowdsecurity/http-crawl-non_statics │ -             │ -         │ 9            │ 9      │ 9       │
│ crowdsecurity/http-probing           │ -             │ -         │ 3            │ 3      │ 3       │
╰──────────────────────────────────────┴───────────────┴───────────┴──────────────┴────────┴─────────╯
╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Whitelist Metrics                                                                     │
├────────────────────────────────────┬─────────────────────────────┬──────┬─────────────┤
│ Whitelist                          │ Reason                      │ Hits │ Whitelisted │
├────────────────────────────────────┼─────────────────────────────┼──────┼─────────────┤
│ crowdsecurity/public-dns-allowlist │ public DNS server           │ 467  │ -           │
│ crowdsecurity/whitelists           │ private ipv4/ipv6 ip/ranges │ 467  │ 457         │
╰────────────────────────────────────┴─────────────────────────────┴──────┴─────────────╯

Edit:
Gratis account aangemaakt, en de eerste bans zijn inmiddels uitgedeeld

[Mars Warrior]

Nou. Crowdsec loopt lekker. Het aantal Alerts stijgt ook!

Maar wat me opvalt: Alle IP adressen van deze alerts staan ook in de lijst van https://threathive.net/
Deze IP lijst bevat iets van 120.000 IPv4 adressen van bekende etterbakjes en wordt elke 15 minuten bijgewerkt.

Er is een leuk script op deze site die deze lijst ophaalt en geschikt maakt om te importeren in CrowdSec. Dus misschien leuk om te gebruiken

Je bent dan in ieder geval van grote bekende overlastgevers af.

[Mars Warrior]

@alex3305 , heb jij nog een voorbeeld van AppSec config?

Ik heb deze guide gevolgd: https://docs.crowdsec.net...ppsec/quickstart/traefik/

Ik kom niet uit de documentatie qua wat nu aan elkaar hangt. Bij mij is elke keer als ik AppSec actief maak dat alle websites geblokkeerd worden.

Maar ik zie talloze voorbeelden daarna met "bouncer", "crowdsec-bouncer" en meer. Dus hoe moet dat heten? Er wordt ook een bouncer "TRAEFIK" aangemaakt zie ik via een environment var: die moet dan BOUNCER_KEY_TRAEFIK heten.

YAML:

  infra-crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: infra-crowdsec
    environment:
      # - COLLECTIONS=crowdsecurity/traefik
      ## Please note the spaces between the collections names (hence why the quotes are needed)
      - 'COLLECTIONS=crowdsecurity/traefik crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules'
      - TZ=Europe/Amsterdam
      - BOUNCER_KEY_TRAEFIK="KEY"

Met wat geklooi heb ik nu 3 bouncers, ieder met hun eigen API key

code:

------------------------------------------------------------------------------
 Name              IP Address  Valid  Last API pull  Type  Version  Auth Type
------------------------------------------------------------------------------
 traefik-bouncer               ✔️                                   api-key
 TRAEFIK                       ✔️                                   api-key
 crowdsec-bouncer              ✔️                                   api-key
------------------------------------------------------------------------------

In traefik.yaml, conform voorbeelden:

YAML:

experimental:
  plugins:
    bouncer:
      moduleName: github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin
      version: v1.4.5

Ik heb in middlewares.yaml:

YAML:

    crowdsec:
      plugin:
        bouncer:
          crowdsecLapiUrl:  "http://infra-crowdsec:8080/"
          crowdsecLapiKey:  "KEY"
          LogLevel: DEBUG
          enabled: false
          crowdsecAppsecEnabled: false
          crowdsecAppsecHost: infra-crowdsec:7422
          crowdsecAppsecFailureBlock: false
          crowdsecAppsecUnreachableBlock: false

De AppSec yaml file, met volgens de documentatie 0.0.0.0 adres vanwege docker.

YAML:

appsec_config: crowdsecurity/appsec-default
labels:
    type: appsec
listen_addr: 0.0.0.0:7422
# listen_addr: 127.0.0.1:7422
source: appsec
name: myAppSecComponent

Maar wat ik ook invul onder "bouncer", alle sites gaan op 403 op het moment dat ik enabled op true zet

Enig idee wat ik nu weer fout doe?

[Mars Warrior]

Omdat @alex3305 zo aardig was om ff in het Traefik topic te helpen heb ik CrowdSec nu lekker draaien.

Ik krijg gemiddeld zo'n 100 alerts per dag. De gratis versie van de CrowdSec console toont enkel 500 alerts per maand: dat is voor mij dus na 5 dagen op
Gelukkig neemt dit aantal wel af doordat ik nu een dynamische bantijd gebruik: afhankelijk van het aantal voorgaande "decisions", wordt de bantijd nu verlengd!

Dus ik dacht ach: containertje erbij en hoppa: dan maak ik me eigen dashboards wel met Metabase:

• Container erbij (enkel Metabase met eigen database, Postgres wilde niet op de één of andere manier)
• Container erbij voor de ronde vlaggetjes (kon geen cdn vinden)
• CrowdSec database ff leesbaar maken qua rechten
• ChatGPT de queries laten maken nadat ik de tabel en veldnamen had doorgegeven. Dat ding snapt de queries voor SQLite zodat ik zonder zoekwerk die kolommen als "Geleden" en "Resterend" heb: dat zijn flinke CASE statements namelijk!

De Alerts, inclusief wat verdelingen naar land
Amerika en Japan zijn duidelijk de favoriteten, waarbij de ASN in heel veel gevallen of Amazon is, of Microsoft. Dus die cloud wordt goed gebruikt door de verschillende botjes



De "Geleden" kolom in de "Laatste 100 Alerts" tabel als voorbeeld die ChatGPT er in één keer werkend uitpoepte. Of het allemaal perfect geoptimaliseerd is weet ik niet. De query duurt 6ms, dus ik maak me daar niet druk om:

SQL:

SELECT
    id,
    datetime(created_at, 'localtime') AS "Tijdstip",

    CASE
        WHEN CAST((julianday('now') - julianday(created_at)) * 24 * 60 AS INT) < 60
            THEN printf('%d minuten geleden',
                CAST(((julianday('now') - julianday(created_at)) * 24 * 60) % 60 AS INT)
            )
        WHEN CAST((julianday('now') - julianday(created_at)) AS INT) = 0
            THEN printf('%d uur geleden',
                CAST(((julianday('now') - julianday(created_at)) * 24) % 24 AS INT)
            )
        WHEN CAST((julianday('now') - julianday(created_at)) AS INT) = 1
            THEN
                CASE
                    WHEN CAST(((julianday('now') - julianday(created_at)) * 24) % 24 AS INT) = 0
                        THEN '1 dag geleden'
                    ELSE printf('1 dag, %d uur geleden',
                        CAST(((julianday('now') - julianday(created_at)) * 24) % 24 AS INT)
                    )
                END
        ELSE
            CASE
                WHEN CAST(((julianday('now') - julianday(created_at)) * 24) % 24 AS INT) = 0
                    THEN printf('%d dagen geleden',
                        CAST((julianday('now') - julianday(created_at)) AS INT)
                    )
                ELSE printf('%d dagen, %d uur geleden',
                    CAST((julianday('now') - julianday(created_at)) AS INT),
                    CAST(((julianday('now') - julianday(created_at)) * 24) % 24 AS INT)
                )
            END
    END AS "Geleden",

    source_ip          AS "IP",
    source_country     AS "Land",
    source_as_name     AS "ASN naam",
    scenario           AS "Scenario",
    events_count       AS "Aantal events",
    CASE
        WHEN remediation = 1 THEN '✅'
        WHEN remediation = 0 THEN '❌'
        ELSE '❔'
    END AS "Remedie"

FROM alerts
WHERE source_scope = 'Ip'
ORDER BY created_at DESC
LIMIT 100;

De Decisions, inclusief wat verdelingen naar land
Je ziet hier duidelijk het resultaat van dynamische / progressieve bantijden: bij elke overtreding komt er een dag bij namelijk.
Er zijn nu dus 142 actieve bans! (let op: meerdere per IP, omdat CrowdSec zo werkt)



De WAFjes (Web Application Firewalls) op de backends hebben de laatste dagen steeds minder te doen, sommige melden al dagen helemaal niks meer. Een teken dat de CrowdSec + AppSec firewall in Traefik zijn/haar werk doet!

[ Voor 5% gewijzigd door Mars Warrior op 18-10-2025 19:09 . Reden: Nu met ronde vlaggetjes! ]

[StarWing]

Ik heb afgelopen weekend een aparte post gemaakt met een vraag, maar het lijkt me ondertussen beter dat ik deze hier stel.
Ik ben al een tijdje bezig met docker, en heb een aantal containers draaien. Ik ben verre van een expert, en er zitten geen ingewikkelde scripts achter, maar alles werkt
Enkel een directory \docker met elke container in een aparte submap en bijhorende docker-compose, en een watchtower die de boel up-to-date houd.
Deze docker host staat op een ESXi machine, maar ik wil hier op termijn van af. De bedoeling is van de resterende services die een aparte VM vereisen (oa Home Assistant) in een nieuwe docker container te gooien.
Echter zitten deze op een aparte IoT vlan. En da's waar ik een probleem heb. Ik snap het idee achter netwerken etc, maar heb totaal geen idee hoe ik dit moet configureren in docker. Laat staan zonder de huidige config te breken.
Ik heb me ondertussen ingelezen in dit topic, maar 100% zeker ben ik toch niet, en ik heb totaal geen zin om mijn bestaande docker host te slopen (zoals ik in het verleden wel eens gedaan heb).

In eerste instantie is het idee van op de ubuntu host een 2de netwerkkaart toe te voegen en aldaar een test container aan te hangen om te zien of mijn opzet werkt, cfr de eerdere post die ik gemaakt heb.
Naderhand wil ik in eerste instantie de resterende services migreren naar docker en nadien een nieuwe server bouwen, maar dan bare metal ipv met esxi.

Onderstaande is een tekening hoe ik het in gedachten heb, lijkt dit wat, of sla ik hier de bal mis met mijn beperkte kennis ? En vooral, hoe moet ik dit aanpakken qua docker configuratie en aanpassingen in de docker-compose bestanden?

[Airw0lf]

@StarWing - de werking op een host is niet anders dan in een VM.

Dit wil zeggen dat de ens160 van je Ubuntu host automagically in je management vlan komt te zitten - doorgaans vlan 1. In de host networking config voeg je daar een of meer virtuele interfaces toe - bijvoorbeeld ens160.10 en ens160.30 voor respectievelijk vlan 10 en 30 - elk met hun eigen subnet.

Als je de containers start met de host interface (i.p.v. de standaard bridge interface) dan zijn alle containers via alle interfaces bereikbaar. Als je de containers start met de bridge interface kan je het IP adres van een van de host interfaces toevoegen aan de poortnummers waardoor de container alleen via dat IP adres bereikbaar is.

Hoewel je in Ubuntu kunt werken met secondary IP adressen is het niet handig om op een interface meerdere IP adressen te hebben. Ik weet ook niet hoe Docker containers dat gaan zien - nooit geprobeerd.

Weet dat een HASS-VM functioneel niet gelijk is aan een Docker uitvoering - je gaat hiervoor waarschijnlijk meerdere Docker containers moeten starten.

Als je perse van ESX af wil ben je het beste af bent met de inzet van Proxmox. En via een Proxmox VM ga je dan de puzzel kunnen leggen om alles met Docker containers in te kleuren. Heb je dit in een VM allemaal draaien, dan kan je dan die config porten naar de host. Maar je gaat hoe dan ook een steile leercurve tegemoet met als mogelijk eindresultaat een Proxmox host met een of meer VM's en/of LXC containers. En daarbinnen een of meer Docker containers... bij mij heeft dat in ieder geval zo uitgepakt...

[alex3305]

@StarWing Docker containers in een eigen VLAN lijkt snel een enorme uitdaging, maar is vaak relatief eenvoudig . Kort door de bocht zul je één of meerdere bruggen moeten slaan tussen het netwerk in de container en de buitenwereld. Ongeacht of daar onder water 1, 2 of 20 NICs aan hangen. Zo draaien mijn machines in het beheernetwerk op 192.168.1.0/24, maar hebben de containers een eigen VLAN. Bijvoorbeeld op 192.168.12.0/24.

Er zijn in Docker twee manieren, of eigenlijk netwerkdrivers, om dit te bereiken: ipvlan en macvlan. Met de macvlan driver krijgen de containers een eigen MAC-adres en worden ze dus als apart device door de (switch of) router gezien. Bij ipvlan krijgen ze hetzelfde MAC-adres als de host, maar hebben de containers een eigen IP-adres. Zelf heb ik de voorkeur voor ipvlan, vooral omdat MAC-adressen nog weleens willen wijzigen na bijvoorbeeld een reboot.

Het opzetten van een ipvlan netwerk is kinderlijk eenvoudig:

docker network create -d ipvlan \
    --subnet=192.168.1.0/24 \
    --gateway=192.168.1.1 \
    -o parent=enp3s0 \
    br0

Waarmee je netwerk br0 maakt zonder vlan tagging. Wil je ipvlan maken voor een vlan, dan is het commando net ff anders:

docker network create -d ipvlan \
    --subnet=192.168.38.0/24 \
    --gateway=192.168.12.1 \
    -o parent=enp3s0.12 \
    br0.12

Docker maakt nu voor mij het br0.12 netwerk aan en creeërt eveneens een nieuwe networkinterface:

$ ip a
2423: enp3s0.12@enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

Docker containers kan ik vervolgens koppelen aan dit netwerk om te testen:

$ docker run --rm -it --network br0.12 alpine /bin/sh
/ # wget -O- tweakers.net
Resolving tweakers.net (tweakers.net)... 2.18.244.96, 2.18.244.78
Connecting to tweakers.net (tweakers.net)|2.18.244.96|:80... connected.
...

Wel opletten dat dit alleen werkt in een VLAN-aware omgeving. Met mijn oude ASUS router kreeg ik dit niet aan de praat. Op mijn Unifi spullen moet ik ook het 192.168.12.0/24 netwerk aangemaakt hebben om het werkend te krijgen. Zorg er dus voor dat je dit van te voren configureert!

Verder zie ik weinig brood in jouw opzet, maar dat komt omdat ik het groeperen niet helemaal begrijp. Maar goed, je moet het opzetten zoals jij het wilt. Ik heb bijvoorbeeld een reverse proxy die aan ipvlan netwerk zit en de rest gaat allemaal met overlay netwerken. Een enkele uitzondering nagelaten. Tegelijkertijd ben ik ook niet zo begonnen jaren geleden. Dat is allemaal natuurlijk gegroeid. D'r is geen goed of fout hè. Jij moet het beheren.

In Docker kun je overigens ook meerdere netwerken aan containers hangen. Ik snap dus niet helemaal wat @Airw0lf bedoelt. Er zijn containers bij mij bij die 3 of 4 IP-adressen hebben. Vooral intern. In totaal heb ik meer dan 25 netwerken met twee of meer containers. Zo vind ik het prettig.

Op mijn lijstje staat ook nog container isolatie binnen netwerken. Maar daar moet ik nog een keer uitgebreid voor gaan zitten.

[Airw0lf]

@alex3305 - misschien wat veel vragen tegelijk...

1. Wat bedoel je precies met "meerdere netwerken aan containers hangen"?
2. Wat is het idee achter "meer dan 25 netwerken met twee of meer containers"?
3. Hoe doe je dat? Dat met 3 of 4 (interne) IP adressen aan een container?

Alvast unne dikke mercie voor de moeite!

[ Voor 40% gewijzigd door Airw0lf op 20-10-2025 21:58 ]

[alex3305]

Airw0lf schreef op maandag 20 oktober 2025 @ 21:54:
@alex3305 - misschien wat veel vragen tegelijk...

Nee joh, natuurlijk niet. Daarvoor is toch dit topic? Ik zal ze stuk voor stuk beantwoorden.

1. Wat bedoel je precies met "meerdere netwerken aan containers hangen"?

Netwerken werken in Docker net zoals in Linux, maar dat wist je al . Echter kun je natuurlijk zoveel mogelijk netwerken aan een Docker container hangen als je wilt. Sterker nog, je kunt zelfs verschillende netwerktypes combineren voor soms wat bijzondere set-ups .

Ik heb dus setups (bijna allemaal ) waar ik meerdere netwerken aan één container heb hangen. Bijvoorbeeld mijn Traefik (reverse proxy) container:

YAML:

services:
  traefik:
    container_name: traefik
    image: traefik:v3.5.3
    networks:
      internal:
      ingress:
      ipvlan:
        ipv4_address: 192.168.10.10
        ipv6_address: 0123:4567:891a:1:b00b::135
      docker-socket:
      metrics:
    depends_on:
      - socket-proxy
      - valkey

  logrotate:
    container_name: traefik-logrotate
    image: ghcr.io/vegardit/traefik-logrotate:latest
    networks:
      docker-socket:
    depends_on:
      - traefik
      - socket-proxy
    volumes:
      - logs:/var/log/traefik:rw
    security_opt:
      - no-new-privileges=true

  socket-proxy:
    container_name: traefik-socket-proxy
    image: lscr.io/linuxserver/socket-proxy:latest
    restart: on-failure:5
    networks:
      docker-socket:
    environment:
      EVENTS: 1
      PING: 1
      VERSION: 1
      INFO: 1
      CONTAINERS: 1
      ALLOW_RESTARTS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:rw
    healthcheck:
      test: "wget --no-verbose --tries=1 --spider http://localhost:2375/info || exit 1"
    read_only: true
    tmpfs:
      - /run
    security_opt:
      - no-new-privileges=true

networks:
  internal:
    name: traefik-internal
    driver: overlay
    attachable: true

  ingress:
    name: swarm-overlay
    external: true

  ipvlan:
    name: br0.10
    external: true

  docker-socket:
    name: traefik-docker-socket
    attachable: false

  logging:
    name: logging-overlay
    external: true

  metrics:
    name: metrics-overlay
    external: true

Waarbij elk netwerk een eigen functie heeft:

• internal: is een intern Swarm overlay netwerk voor Traefik waar Traefik, Redis en op mijn andere host traefik-kop aan gekoppeld zitten. Zo kan traefik-kop verbinding maken met Redis en Traefik voor config changes.
• ingress: is het Docker Swarm overlay 'ingress' netwerk waar alle services aan zitten die naar buiten ontsloten worden.
• ipvlan: zorgt voor de koppeling naar buiten via een eigen IPv4 en IPv6 adres. Deze adressen heb ik hier 'vast' geconfigureerd
• docker-socket: koppelt aan een Docker Socket container die beperkte machtigingen heeft naar de Docker Socket onder water. Ook logrotate maakt hier gebruik van zodat logs veilig opgeruimd kunnen worden
• logging: zorgt ervoor dat Grafana Alloy (ook in de stack) de logs van Traefik naar Grafana Loki kan krijgen
• metrics: verzorgt de Prometheus metrics en zit dus gekoppeld aan... Prometheus .

Naast een vorm van veiligheid, zorgt deze segregatie er ook voor dat ik eenvoudig kan zien en bijhouden welke diensten waar gebruik van maken. Met docker network inspect logging kan ik bijvoorbeeld zien welke containers er überhaupt aan het logging netwerk hangen.

Elk netwerk heeft dus ook eigen permissies en eventuele afhankelijkheden. Mijn stack deploy ik met Ansible, waar ik dit ingeregeld heb. Daar heb ik ook variabelen voor deze netwerknamen. En als die missen zal het netwerk simpelweg niet gekoppeld worden . Op die manier kan ik ook heel eenvoudig modulair onderdelen toevoegen of weghalen als ik ze niet meer wil gebruiken, zonder dat ik heel mijn stack om moet gooien.

2. Wat is het idee achter "meer dan 25 netwerken met twee of meer containers"?

Naast bovenstaand voorbeeld, vind ik Forgejo ook nog een mooi voorbeeld om dit mee te illustreren. De Forgejo Docker Compose stack maakt een netwerk aan bij de deployment. Dit interne Forgejo netwerk gebruik ik vervolgens voor o.a. de Forgejo Runner(s) en communicatie. Hierdoor kan een gedeelte van de communicatie binnendoor lopen en hoeft het niet allemaal (onnodig) langs de reverse proxy.

3. Hoe doe je dat? Dat met 3 of 4 (interne) IP adressen aan een container?

Al deze netwerken hebben een eigen subnet, al dan niet door mij aangemaakt. Voor elk netwerk maakt Docker in de container een interface aan met een bijbehorend IP adres. Er is een prioriteit mogelijkheid, maar die werkt niet. Ik heb daar eerder ook al iets over geschreven. In de praktijk is de prioriteit alfabetisch. Wel zou je per netwerk een hostname aan kunnen geven waarmee je dus specifiek per netwerk zou kunnen routeren.

Eerlijk gezegd heb ik hier nog nooit echt problemen mee gehad. Je kunt het natuurlijk zo eenvoudig of complex maken als je zelf wilt. Zoals ik in mijn vorige post al zei is het allemaal natuurlijk. Momenteel werkt dit voor mij prima en vind ik dit prettig, maar wellicht is dat over een tijdje weer anders.

Ik ben vooral te spreken over de overlay netwerken, aangezien ik Swarm en Compose gebruik. Daarmee is het heel erg eenvoudig om applicaties over meerdere nodes te deployen terwijl het verkeer toch nog op hostname / container name niveau kan gaan. Helaas blijft alleen de DNS nog weleens plakken waardoor je 'onbereikbare' applicaties krijgt zonder herstart. Een vast IPv6 of IPv4 zou dit oplossen, maar het komt zo sporadisch voor dat ik het nog niet heb opgepakt.

[RobertMe]

Airw0lf schreef op maandag 20 oktober 2025 @ 21:54:
Wat bedoel je precies met "meerdere netwerken aan containers hangen"?

Ik ben dan niet @alex3305, maar je kunt prima bij een container meerdere netwerken opgeven. Zo zit bv bij mij de Unbound container (ik gebruik rechtstreeks Unbound met blocklists, geen PiHole / ADG) ook in een stuk of 5 verschillende netwerken.

---

En mijn opzet is weer heel anders. Doe vrijwel niks met IPv4 intern / op Docker (noch Podman). Container netwerken zitten in hun eigen ::/64 subnet (IPv6 dus) en kunnen rechtstreeks gerouteerd worden (de Docker / Podman host publiceert zijn "eigen" router advertisements dat verkeer voor die ::/64 naar hem gestuurd moeten worden, gaat dus niet expliciet over de router (alhoewel mijn zelfbouw router wel een Podman host is )). Indelen in VLANs gaat voor inkomend verkeer kinda vanzelf uiteraard afhankelijk van aan welke netwerken (/bridges) de container is gekoppeld. Uitgaand verkeer doe ik op basis van ip rules. Dus Linux weet bv dat als verkeer over br-prive het systeem verlaat dat die daarvoor de "prive" routing tabel moet gebruiken, en die tabel stelt dus weer dat de default gateway over de "prive" interface gaat (jip, mijn netwerk interfaces hebben logische namen i.p.v. eth0, eth1 of enp0s1, enp1s1, ...). Terwijl de main routing table als default gateway dan (bv) de "lan" interface heeft.

[Airw0lf]

@alex3305 en @RobertMe - ja - die Docker overlay netwerken... ik vermoede al dat het die kant op zou gaan...

Dat maakt het geheel er niet makkelijker op - sterker nog - de beheer(s)baarheid neemt af en de administratieve (netwerk)lasten verdubbelen omdat je twee keer iets van een IPAM moet opzetten - een voor de vlans en een voor de overlays... tis te zeggen... voor zover ik het begrijp kun je die twee niet bij elkaar vegen via zoiets als pihole/dnsmasq - toch?

Want dat is wat ik op dit moment heb lopen - alles aan vlans, dns en dhcp loopt via pihole/dnsmasq - met een L3-switch als default gateway voor alle vlans en subnetten. Deze aanpak lijkt niet bruikbaar te zijn bij de inzet van een of meer overlay netwerken waardoor er een andere, aanvullende IPAM aanpak nodig is - zo is mijn inschatting tot nu toe.

De inzet van IPv6 lijkt hier niet zo heel veel aan te veranderen.

Dan nog even terug naar de vraag van @StarWing - mijn inschatting is dat zijn/haar leercurve exponentieel toe gaat nemen met de inzet van overlay netwerkjes en het daarmee samenhangende engineering en beheer(s) vraagstuk. Ik denk dat het voor de korte termijn beter is om het vraagstuk te beperken tot de inzet van vlans. En hoe dat te doen met Docker containers. Waarbij er imho maar twee opties zijn: het Docker bridge of host netwerk - ik gok dat die materie bij elkaar al een redelijk stijle leercurve voor hem/haar gaat zijn...

[RobertMe]

Airw0lf schreef op dinsdag 21 oktober 2025 @ 08:22:
@alex3305 en @RobertMe - ja - die Docker overlay netwerken... ik vermoede al dat het die kant op zou gaan...

Ik gebruik helemaal geen overlay netwerk

[Airw0lf]

RobertMe schreef op dinsdag 21 oktober 2025 @ 09:05:
[...]

Ik gebruik helemaal geen overlay netwerk

Klopt - jij lost alles op met IPv6 - komt op hetzelfde neer...

[RobertMe]

Airw0lf schreef op dinsdag 21 oktober 2025 @ 09:10:
[...]


Klopt - jij lost alles op met IPv6 - komt op hetzelfde neer...

Uhm, nee. Een overlay netwerk is toch echt een Docker specifieke feature (ok, K8s kan het ook). Slim het netwerk inrichten en Linux de juiste routing laten doen is niet afhankelijk van Docker. Noch dat ik het gebruik voor Docker. Containers op de verschillende hosts communiceren op exact dezelfde manier onderling als dat dat tussen PC/laptop en container gaat. (Syncthing op mijn laptop verbind ("hardcoded" / fixed address) met fd00:10:2::2:2000 (always on servertje) en fd00:10:3::2:2000 (on demand on NAS), en Syncthing op servertje verbindt (eveneens met fixed address) met fd00:10:3::2:2000 (NAS) en vise versa). En bv Home Assistant op het ene systeem verwijst ook op een soortgelijke manier naar Piper op het andere systeem. Ook voor die zaken die niet "publiekelijk" zijn maar wel over meerdere hosts draaien gebruik ik geen overlay.

Edit/aanvulling:
En exact hetzelfde kun je ook met IPv4 doen. Alleen is het makkelijker om met IPv6, via een router advertisement, een route naar een subnet te publiceren dan bij IPv4 (met DHCP?, geen idee of extra routes in een DHCP reply kunnen. In ieder geval kan het servertje nooit zijn eigen subnets bekend maken aangezien die geen DHCP server draait dus moet de router op de hoogte zijn van de routes die via het servertje moeten lopen).

[ Voor 17% gewijzigd door RobertMe op 21-10-2025 09:20 ]

[alex3305]

Airw0lf schreef op dinsdag 21 oktober 2025 @ 08:22:
Dat maakt het geheel er niet makkelijker op - sterker nog - de beheer(s)baarheid neemt af en de administratieve (netwerk)lasten verdubbelen omdat je twee keer iets van een IPAM moet opzetten - een voor de vlans en een voor de overlays... tis te zeggen... voor zover ik het begrijp kun je die twee niet bij elkaar vegen via zoiets als pihole/dnsmasq - toch?

Daar ben ik het dus compleet mee oneens. Het is een keuze om de IPAM-config op te zetten en zelf in te regelen. Ik laat dat gewoon aan de daemon zelf over en dat gaat vooralsnog prima. Een kennis van mij klaagde een tijdje terug dat de Docker daemon z'n interne netwerk hetzelfde subnet gaf als een VLAN in Unifi waardoor er vage problemen ontstonden. Echter heb ik dat nog niet eerder gezien, en om eerlijk te zijn heeft hij wel vaker van dit soort 'onbekende' problemen .

Overigens begrijp ik niet helemaal waarom je containers überhaupt via DNS of via een eigen DHCP wilt beheren. Op interne netwerken zijn containers sowieso bereikbaar op container naam, of op de hostname-optie, of met aliassen. Een voorbeeld vanuit Compose:

YAML:

services:
  mosquitto:
    container_name: mosquitto
    image: eclipse-mosquitto:2.0.22
    hostname: mosquitto.docker.internal
    networks:
      ingress:
        aliases:
          - mqtt

En in principe hoef ik alleen maar vanuit mijn ingress netwerk / container bij de applicaties te kunnen. Want naast Traefik, is AdGuard Home zowat de enige applicatie die nog aan mijn bridge netwerk hangt. ik wil voor DNS namelijk niet afhankelijk zijn van de reverse proxy.

Hoe de containers onderling adressen toewijzen zal me verder een spreekwoordelijke Unox wezen.

Dan nog even terug naar de vraag van @StarWing - mijn inschatting is dat zijn/haar leercurve exponentieel toe gaat nemen met de inzet van overlay netwerkjes en het daarmee samenhangende engineering en beheer(s) vraagstuk. Ik denk dat het voor de korte termijn beter is om het vraagstuk te beperken tot de inzet van vlans. En hoe dat te doen met Docker containers. Waarbij er imho maar twee opties zijn: het Docker bridge of host netwerk - ik gok dat die materie bij elkaar al een redelijk stijle leercurve voor hem/haar gaat zijn...

Alhoewel ik zeker weet dat je het goed bedoelt, zie ik dat echt compleet anders. Overlay netwerken is misschien nog een brug te ver voor @StarWing, maar ik zou sterk adviseren om in ieder geval te starten met een ipvlan netwerk. Host netwerk is in 99% van de gevallen onnodig. Daarnaast kom je enorm vlug in de problemen met poorttoewijzingen. En het is enorm onveilig, omdat je de controle over poort mappings compleet uit handen geeft.

Het beste zou zijn om kennis over een reverse proxy - welke dan ook - op te gaan doen en op die manier containers te gaan ontsluiten. Dan maakt het uiteindelijk geen klap meer uit of het op een bridge, ipvlan of overlay netwerk draait. Simpelweg omdat je dat onderdeel niet meer naar buiten ontsluit.

[alex3305]

@RobertMe Jouw IPv6 aanpak klinkt enorm interessant. Doe jij de IPv6 configuratie in Compose? En dan met SLAAC?

Een tijdje terug heb ik wel getest om mijn complete Docker omgeving naar IPv6 om te zetten aangezien ik van KPN een /48 krijg, maar ik had niet per se het gevoel grip te hebben over de situatie. Vooral security maakte ik me wat zorgen over. Ik had ook best het e.e.a. alleen achter een IP whitelist hangen. En ja, ik had ook mijn IPv6 range toegevoegd, maar toch voelde het... niet lekker .

[RobertMe]

alex3305 schreef op dinsdag 21 oktober 2025 @ 12:43:
@RobertMe Jouw IPv6 aanpak klinkt enorm interessant. Doe jij de IPv6 configuratie in Compose? En dan met SLAAC?

Ik gebruik intern sowieso meerdere ULAs (fd00:<VLAN ID>::/64 met voor de Docker hosts na het VLAN ID het volgende blok een 1 / 2 / 3 voor resp. router / servertje / NAS). En vervolgens gewoon statistische adressering aan de containers.

SLAAC werkt AFAIK uberhaupt niet. Of nouja, als je MACVLAN gebruikt werkt SLAAC gewoon maar dat gaat natuurlijk buiten Docker om. Gebruik je gewoon het bridge network (zoals ik doe) dan heb je geen SLAAC.

Een tijdje terug heb ik wel getest om mijn complete Docker omgeving naar IPv6 om te zetten aangezien ik van KPN een /48 krijg, maar ik had niet per se het gevoel grip te hebben over de situatie.

Belangrijkste ding bij het gebruik van GUAs is dat je waarschijnlijk geen statische prefix hebt en je niet elke keer je Docker + container config overhoop wilt gooien als je een nieuwe prefix krijgt. Heb je wel een statische prefix dan kun je containers ook een statisch IP geven natuurlijk.
Daarom doe ik verkeer uit containers gewoon NATen naar buiten toe. Niet de 100% ideale situatie (IPv6 wil je natuurlijk niet NATen), maar goed genoeg.

[alex3305]

@RobertMe Ik heb blijkbaar net te weinig kaas gegeten van IPv6 , maar ik begin te begrijpen hoe jouw setup in elkaar zit.

Ik wilde echt puur en alleen met een GUA gaan werken omdat die van KPN zo goad als statisch is. Daarnaast rol ik alles uit met Ansible en is het wisselen van prefix dus ook niet bijster veel werk. Ik heb dat dan zo geconfigureerd:

YAML:

# Global Network configuration
local_ip_range: 192.168.0.0/16
ipv6_prefix: "{{ vault_ipv6_prefix }}" # format 'a13c:3305:1337'

# Secondary Host specific config
ipvlan_ipv6_subnet: "{{ ipv6_prefix }}:2::/64"

# AdGuard Home (primary)
adguard_home_ipvlan_ipv6_address: "{{ ipv6_prefix }}:1:b00b::ad"
# AdGuard Home (secondary)
adguard_home_ipvlan_ipv6_address: "{{ ipv6_prefix }}:2:b00b::ad"

# Pocket ID configuration
pocket_id_local_ipv6_ranges: "{{ ipv6_prefix }}::/48"

Per comment / header een afzonderlijk bestand die wordt toegepast waar het nodig is, maar even om mijn punt te illustreren.

Misschien binnenkort toch nog eens uitproberen. Want het werkte op zichzelf prima .

[Airw0lf]

alex3305 schreef op dinsdag 21 oktober 2025 @ 12:33:
[...]

Daar ben ik het dus compleet mee oneens. Het is een keuze om de IPAM-config op te zetten en zelf in te regelen. Ik laat dat gewoon aan de daemon zelf over en dat gaat vooralsnog prima.

Hoe werkt het dan met meerdere containers verdeeld over meerdere hosts? Waarbij alle containers bij elkaar in hetzelfde subnet moeten komen?

[...]

Alhoewel ik zeker weet dat je het goed bedoelt, zie ik dat echt compleet anders. Overlay netwerken is misschien nog een brug te ver voor @StarWing, maar ik zou sterk adviseren om in ieder geval te starten met een ipvlan netwerk. Host netwerk is in 99% van de gevallen onnodig. Daarnaast kom je enorm vlug in de problemen met poorttoewijzingen. En het is enorm onveilig, omdat je de controle over poort mappings compleet uit handen geeft.

Bij IP-VLAN heb je meerdere IP's op een MAC-adres zitten - dat kan ARP-alarmen triggeren van firewalls.
Hoe ga je daar dan mee om?

Mijn aanpak is alles met host network. En dan de firewall van de LXC-host gebruiken om alleen die poorten open te zetten die nodig zijn. Zit er een overlap in de TCP-poorten van twee containers, dan kijk ik of er via een env-var een aanpassing mogelijk is. Is die er niet, dan start ik een nieuwe LXC-host, voeg daar de nieuwe container toe met zijn firewall rules.

Wat is hier niet veilig aan? En wat heeft hier een IP-VLAN nog voor meerwaarde?

[ Voor 5% gewijzigd door Airw0lf op 21-10-2025 14:27 ]

[alex3305]

Airw0lf schreef op dinsdag 21 oktober 2025 @ 14:22:
Hoe werkt het dan met meerdere containers verdeeld over meerdere hosts? Waarbij alle containers bij elkaar in hetzelfde subnet moeten komen?

Dat regelt het overlay netwerk vanuit Docker Swarm.

Bij IP-VLAN heb je meerdere IP's op een MAC-adres zitten - dat kan ARP-alarmen triggeren van firewalls.
Hoe ga je daar dan mee om?

Niet, want hier heb ik nog nooit last van gehad.

Mijn aanpak is alles met host network. En dan de firewall van de LXC-host gebruiken om alleen die poorten open te zetten die nodig zijn. Zit er een overlap in de TCP-poorten van twee containers, dan kijk ik of er via een env-var een aanpassing mogelijk is. Is die er niet, dan start ik een nieuwe LXC-host, voeg daar de nieuwe container toe met zijn firewall rules.

Wat is hier niet veilig aan? En wat heeft hier een IP-VLAN nog voor meerwaarde?

Ja, maar dit is geen Docker (LXD) hè. Dit is LXC.

Jij hebt het eerder over beheerbaarheid en beheersbaarheid, maar ik vind dit dus enorm veel aan de beheerbaarheid toevoegen. Immers heb je nu twee containerlagen boven op elkaar, die allebei (waarschijnlijk) nét anders werken. Ik kan verder geen uitspraken doen over de veiligheid van een dergelijke setup. Of meerwaarde van ipvlan, want die is er in jouw geval denk ik niet.

Echter vind ik Docker hosts met daarop Docker containers - of podman met containers - een stuk eenvoudiger dan verschillende LXC containers die ik dan nog met een (eventuele) firewall aan elkaar moet knopen.

Maar uiteindelijk zet ik nagenoeg nooit meer poorten open en ontsluit ik alles via een reverse proxy. Dan hoef ik niet aan te klooien met env-vars of firewalls. Ik hoef alleen maar een paar labels toe te voegen om een dienst werkend en bereikbaar te krijgen.

[Airw0lf]

alex3305 schreef op dinsdag 21 oktober 2025 @ 15:23:
[...]

Dat regelt het overlay netwerk vanuit Docker Swarm.

[...]

Zorgt die Docker Swarm dan ook dat IP-adressen niet dubbel uitgegeven worden over hosts en containers heen?

[...]

Ja, maar dit is geen Docker (LXD) hè. Dit is LXC.

Eens

Jij hebt het eerder over beheerbaarheid en beheersbaarheid, maar ik vind dit dus enorm veel aan de beheerbaarheid toevoegen. Immers heb je nu twee containerlagen boven op elkaar, die allebei (waarschijnlijk) nét anders werken. Ik kan verder geen uitspraken doen over de veiligheid van een dergelijke setup. Of meerwaarde van ipvlan, want die is er in jouw geval denk ik niet.

Echter vind ik Docker hosts met daarop Docker containers - of podman met containers - een stuk eenvoudiger dan verschillende LXC containers die ik dan nog met een (eventuele) firewall aan elkaar moet knopen.

Wat zijn in jouw geval de "Docker hosts"?

Een LXC gedraagt zich als een VM - of zo je wil - als een bare metal host - in ieder geval bezien vanuit de Docker containers.

Maar uiteindelijk zet ik nagenoeg nooit meer poorten open en ontsluit ik alles via een reverse proxy. Dan hoef ik niet aan te klooien met env-vars of firewalls. Ik hoef alleen maar een paar labels toe te voegen om een dienst werkend en bereikbaar te krijgen.

Kortom... ieder zijn ding @alex3305 - de beheer(s)aspecten lijken wat anders te liggen - tis maar net wat iemand ervaart als handig(er).

[ Voor 6% gewijzigd door Airw0lf op 21-10-2025 15:57 ]

[StarWing]

Test gedaan, bos, bomen, verdwaald
Even een nieuwe vm opgezet, kale ubuntu + docker met 2 netwerkkaarten.
Bridge aangemaakt via onderstaand commando:

code:

sudo docker network create -d ipvlan  --subnet=10.0.2.0/24 --gateway=10.0.2.254 -o parent=ens192 br_iot

code:

sudo docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
2ec0e2e687b7   br_iot    ipvlan    local
92770f7dfb59   bridge    bridge    local
80dd6a4467e3   host      host      local
684e8f327ad4   none      null      local

code:

sudo docker network inspect br_iot
[
    {
        "Name": "br_iot",
        "Id": "2ec0e2e687b750e2a8a5531e1ab53d5566d50528e04cc322a2060b7c93bbdeba",
        "Created": "2025-10-21T15:53:04.352792291Z",
        "Scope": "local",
        "Driver": "ipvlan",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "10.0.2.0/24",
                    "Gateway": "10.0.2.254"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "parent": "ens192"
        },
        "Labels": {}
    }
]

code:

test@test:/docker/portainer$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:0f:ff:c4 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 192.168.10.150/24 brd 192.168.10.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe0f:ffc4/64 scope link
       valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:0f:ff:ce brd ff:ff:ff:ff:ff:ff
    altname enp11s0
    inet 10.0.2.95/24 brd 10.0.2.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe0f:ffce/64 scope link
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 06:4e:8c:77:13:8c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

Ik kan pingen van mijn lan naar IOT:

code:

ping 10.0.2.95
Pinging 10.0.2.95 with 32 bytes of data:
Reply from 10.0.2.95: bytes=32 time<1ms TTL=64

Maar een test portainer container is niet bereikbaar:

code:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    environment:
      TZ: 'Europe/Brussels'
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /docker/portainer/data:/data
    ports:
      - '9000:9000'
    networks:
      - br0_IOT

networks:
  br0_IOT:
    external: true
    name: br_iot

Anderzijds, een ongewenst neveneffect. Op mijn bestaande dockerserver heb ik een extra netwerkkaart toegevoegd, en blijkbaar zijn de containers ook bereikbaar via deze netwerkkaart. Da's nu net niet de bedoeling. Waarschijnlijk simpel op te lossen, maar dat moet ik proberen uitzoeken.

//Edit:
Ik ben erachter gekomen dat de portainer-container blijkbaar een automagisch IP adress krijgt, en dit dus niet 10.0.2.95 is.
Toevoegen van:

code:

    networks:
       br0_IOT:
         ipv4_address: 10.0.2.100
networks:
  br0_IOT:
    name: br_iot
    external: true

En de container is bereikbaar op 10.0.2.100
Blijft de vraag of dit een correcte manier van werken is.
Indien ik nu een 2de container aanmaak, met 10.0.2.101, kunnen deze elkaar bereiken?

[ Voor 6% gewijzigd door StarWing op 21-10-2025 19:29 ]

[alex3305]

Airw0lf schreef op dinsdag 21 oktober 2025 @ 15:50:
Zorgt die Docker Swarm dan ook dat IP-adressen niet dubbel uitgegeven worden over hosts en containers heen?

Yes. Nogmaals, ik werk nagenoeg nooit meer met IP-adressen. Niet voor containers, maar ook niet voor machines. In principe probeer ik zoveel mogelijk op hostname niveau te doen waar mogelijk. Die abstractie zorgt ervoor dat ik me niet druk hoef te maken waar applicaties zich ergens op het netwerk bevinden. Hostnames worden toegewezen vanuit de router of vanuit Docker configuratie.

Wat zijn in jouw geval de "Docker hosts"?

Ik heb een viertal Docker hosts, waarvan er twee in een Swarm hangen. Die twee zijn mijn primaire en secundaire machines met elk eigen verantwoordelijkheden. De primaire machine is het krachtigste en fungeert eveneens als mijn NAS.

De derde machine is een Pi 3B die dienst doet als mijn digitale elektrische boiler thermometer en nog wat kleine verantwoordelijkheden, zoals uptime rapportage.

Tot slot is de vierde machine een VPS die ik (hopelijk) nooit nodig ga hebben. Die machine staat in Canada en fungeert als backup server.

Het grootste deel van de workload vindt dus plaats op machine 1 en 2. En ik voel niet per se de behoefte om nog VM's of LXC containers - hehe pleonasme - te maintainen.

Docker laat ik overigens door de package manager van het OS installeren. Op mijn primaire machine is dat unRAID en op de secundaire komt het uit Debian. Docker Compose en andere configuratie manage ik met Ansible. Die update o.a. Compose automatisch met Renovate en heb ik geen omkijken naar.

[alex3305]

StarWing schreef op dinsdag 21 oktober 2025 @ 18:08:
Test gedaan, bos, bomen, verdwaald

De rest van de post suggereert toch echt iets anders . Volgens mij lukt het best aardig, maar schort het nog aan wat kennis.

Anderzijds, een ongewenst neveneffect. Op mijn bestaande dockerserver heb ik een extra netwerkkaart toegevoegd, en blijkbaar zijn de containers ook bereikbaar via deze netwerkkaart. Da's nu net niet de bedoeling. Waarschijnlijk simpel op te lossen, maar dat moet ik proberen uitzoeken.

Het is voor mij niet helemaal duidelijk wat je hiermee bedoelt. Welke containers op welke machine zijn vanuit welke bron bereikbaar? En wat zou je dan willen afschermen?

//Edit:
Ik ben erachter gekomen dat de portainer-container blijkbaar een automagisch IP adress krijgt, en dit dus niet 10.0.2.95 is.

Ja, Docker pakt een IP-adres uit de pool die je op hebt gegeven. In jouw geval is dat dan 10.2.0.0-10.2.0.254. Dit kun je afkaderen door een strikter netmask op te geven. Het is op deze manier ook mogelijk IP conflicten te krijgen, aangezien je nu twee DHCP's in een zelfde vijver laat vissen.

En de container is bereikbaar op 10.0.2.100
Blijft de vraag of dit een correcte manier van werken is.
Indien ik nu een 2de container aanmaak, met 10.0.2.101, kunnen deze elkaar bereiken?

Ja die kunnen elkaar dan bereiken. En dit kan een correcte manier van werken zijn. Maar dat is afhankelijk wat je wilt. Mijn AdGuard Home wil ik bijvoorbeeld op een vast IP-adres hebben en heb ik dus geconfigureerd in Compose. Mijn Mosquitto broker daarentegen benader ik alleen op hostname en kan het mij dus een spreekwoordelijke worst wezen waar die zich bevindt.

Als je echt compleet gesegregeerde netwerken wilt is een ipvlan wellicht niet de beste keuze. Of je moet met een VLAN werken en deze beperken in de router. Je zou dan eventueel voor een overlay netwerk kunnen gaan. Echter moet je dan wel weer een manier hebben om het e.e.a. te ontsluiten.

[StarWing]

alex3305 schreef op dinsdag 21 oktober 2025 @ 19:59:
Het is voor mij niet helemaal duidelijk wat je hiermee bedoelt. Welke containers op welke machine zijn vanuit welke bron bereikbaar? En wat zou je dan willen afschermen?

Wel, als ik op mijn werkende docker host, welke een ip heeft van 192.168.10.155, een additionele netwerkkaart toevoeg via esxi, met ip 10.0.2.155, dan zijn alle dockers die ik heb, op beide ip's bereikbaar. Da's nu niet de bedoeling van een scheiding iot <> lan .

Maar dit kan ik waarschijnlijk correct oplossen door in de docker compose een ip te specifieren.

[Airw0lf]

StarWing schreef op woensdag 22 oktober 2025 @ 04:42:
[...]

Wel, als ik op mijn werkende docker host, welke een ip heeft van 192.168.10.155, een additionele netwerkkaart toevoeg via esxi, met ip 10.0.2.155, dan zijn alle dockers die ik heb, op beide ip's bereikbaar. Da's nu niet de bedoeling van een scheiding iot <> lan .

Maar dit kan ik waarschijnlijk correct oplossen door in de docker compose een ip te specifieren.

Klopt - en een standaard bridge netwerk werkt dan prima.

[ed1703]

StarWing schreef op woensdag 22 oktober 2025 @ 04:42:
[...]

Maar dit kan ik waarschijnlijk correct oplossen door in de docker compose een ip te specifieren.

Ja, door dit in je ports op te geven:

code:

ports:
      - "ipv4adres:9000:9000"
      - "[ipv6adres]:9000:9000"

Overigens heeft het opgeven van ports in containers die onderdeel zijn van ipvlan of macvlan niet veel nut, want die zal docker negeren.

Zelf prefereer ik reverseproxy met caddy, npm of traefik. Die proxycontainer prop je samen met de container die je wilt gebruiken in een eigen netwerk en die benader je op naam. Het maakt namelijk geen drol uit welk ipadres dat ding dan heeft. Dat zoekt de proxy met docker wel voor je uit.
Hangt er verder wel een beetje vanaf wat je gaat doen welke proxy software je perse nodig hebt.

[Webgnome]

Vraagje voor de kenners. Tijdje terug Docker Desktop geinstalleer op Linux, nu wil ik eigenlik weer terug naar alleen de engine. Weet iemand wat de beste manier is om dat te doen zonder verlies van containers, images etc ?

[alex3305]

StarWing schreef op woensdag 22 oktober 2025 @ 04:42:
Wel, als ik op mijn werkende docker host, welke een ip heeft van 192.168.10.155, een additionele netwerkkaart toevoeg via esxi, met ip 10.0.2.155, dan zijn alle dockerscontainers die ik heb, op beide ip's bereikbaar.

Maar hoe zie je dat anders voor je dan? Dat Docker weet welke NIC jij in gedachte hebt bij welke container? Dat kan natuurlijk niet hè. Onder water werkt Docker 'gewoon' met iptables-regels. Out of the box zitten die regels aan alle NICs gekoppeld in de machine.

Da's nu niet de bedoeling van een scheiding iot <> lan .

Ik begrijp nog steeds niet helemaal wat je nu wilt bereiken. Vooral niet omdat je in jouw spreadsheet voorbeelden geeft waarbij meerdere containers aan één /32 zitten. Waarom, geen idee... Containers zijn (heel kort door de bocht) gewoon lichte VM's. Daarvan wil je er ook niet meerdere aan één /32 hebben.

En of je de scheiding nu in /24, /16 of /8 maakt, maakt onder water vrij weinig uit. Jouw router routeert dat verkeer uiteindelijk toch. En eventuele blokkades zullen dan ook op dat niveau plaats moeten vinden.

ed1703 schreef op woensdag 22 oktober 2025 @ 08:48:
[...]

Zelf prefereer ik reverseproxy met caddy, npm of traefik. Die proxycontainer prop je samen met de container die je wilt gebruiken in een eigen netwerk en die benader je op naam. Het maakt namelijk geen drol uit welk ipadres dat ding dan heeft. Dat zoekt de proxy met docker wel voor je uit.
Hangt er verder wel een beetje vanaf wat je gaat doen welke proxy software je perse nodig hebt.

Maar uiteindelijk is dit het antwoord dus... Waarom aanklooien met NICs en IP-adressen? Laat dat onder water bestaan.

Geef elke container een eigen IP. Hoe je dat doet maakt geen klap uit. Het kan vanwege mDNS handig zijn dat bijvoorbeeld Home Assistant wel aan het netwerk hangt met bijvoorbeeld een host of ipvlan netwerk.

[Mars Warrior]

Gelukkig ben ik niet zo goed in netwerken en lost Docker eigenlijk alles op in mijn geval:

• Ik heb een "extern" netwerk met een vast IPv4 en IPv6 adres. De enige die in dat netwerk hangt is mijn proxy. Die is als enige bereikbaar over poort 80/443, ook extern. De rest van mijn docker netwerk is dus gewoon IPv4, maar dus via de proxy wel bereikbaar over IPv6
• Dan heb ik een "proxy" netwerk waarin alle containers hangen, inclusief de proxy, die met de proxy moeten praten
• En verder per set van applicaties die bij elkaar horen, of met elkaar moeten praten een eigen overlay netwerk. Apps praten dan via de service naam of alias.

Dit werkt gewoon. Behalve de proxy dus nergens port mappings of andere zaken. Om vanuit buiten bij een container te komen moet je voorbij de proxy weten te komen, oftewel je moet het domein (FQDN) weten.

In bovenstaand voorbeeld is het wel zo dat iedereen die in het "proxy" netwerk hangt elkaar ook kan bereiken. Als je dat niet wilt, dus dat een container enkel met de proxy kan praten, dan moet je dingen omkeren en moet je bijv. Traefik onderdeel maken van de overlay netwerken van de containers.

• Traefik kan dan wel verkeer routeren naar de verschillende containers doordat deze in alle overlay netwerken zit.
• Die containers kunnen enkel met Traefik en hun eigen containers praten, verder niet.

En als je Swarm gebruikt dan kun je ook "--internal" gebruiken voor je overlay netwerken. Dan heb je éénrichtingsverkeer, en kan een container gewoon niet naar buiten

Ik snap in deze het hele nut van vlans niet

alex3305 schreef op woensdag 22 oktober 2025 @ 11:59:
Geef elke container een eigen IP. Hoe je dat doet maakt geen klap uit. Het kan vanwege mDNS handig zijn dat bijvoorbeeld Home Assistant wel aan het netwerk hangt met bijvoorbeeld een host of ipvlan netwerk.

Of je gebruikt een mdns-repeater container. Die hangt natuurlijk wel aan je host netwerk, en gooit al die berichtjes door naar bijv. je docker bridge of het specifieke home assistant en/of jellyfin/plex overlay netwerk.

[ Voor 15% gewijzigd door Mars Warrior op 22-10-2025 12:15 ]

[Airw0lf]

Mars Warrior schreef op woensdag 22 oktober 2025 @ 12:00:
Gelukkig ben ik niet zo goed in netwerken en lost Docker eigenlijk alles op in mijn geval:

• Ik heb een "extern" netwerk met een vast IPv4 en IPv6 adres. De enige die in dat netwerk hangt is mijn proxy. Die is als enige bereikbaar over poort 80/443, ook extern. De rest van mijn docker netwerk is dus gewoon IPv4, maar dus via de proxy wel bereikbaar over IPv6
• Dan heb ik een "proxy" netwerk waarin alle containers hangen, inclusief de proxy, die met de proxy moeten praten
• En verder per set van applicaties die bij elkaar horen, of met elkaar moeten praten een eigen overlay netwerk. Apps praten dan via de service naam of alias.

Dit werkt gewoon. Behalve de proxy dus nergens port mappings of andere zaken. Om vanuit buiten bij een container te komen moet je voorbij de proxy weten te komen, oftewel je moet het domein (FQDN) weten.

In bovenstaand voorbeeld is het wel zo dat iedereen die in het "proxy" netwerk hangt elkaar ook kan bereiken. Als je dat niet wilt, dus dat een container enkel met de proxy kan praten, dan moet je dingen omkeren en moet je bijv. Traefik onderdeel maken van de overlay netwerken van de containers.

• Traefik kan dan wel verkeer routeren naar de verschillende containers doordat deze in alle overlay netwerken zit.
• Die containers kunnen enkel met Traefik en hun eigen containers praten, verder niet.

En als je Swarm gebruikt dan kun je ook "--internal" gebruiken voor je overlay netwerken. Dan heb je éénrichtingsverkeer, en kan een container gewoon niet naar buiten

Ik snap in deze het hele nut van vlans niet


[...]

Of je gebruikt een mdns-repeater container. Die hangt natuurlijk wel aan je host netwerk, en gooit al die berichtjes door naar bijv. je docker bridge of het specifieke home assistant en/of jellyfin/plex overlay netwerk.

Mja... wel bijzonder... je gebruikt de nodige overlays? Maar ziet vervolgens het nut van vlans niet? Wat denk je dat Docker gebruikt om dit allemaal te kunnen doen? Juist ja...

[Mars Warrior]

Airw0lf schreef op woensdag 22 oktober 2025 @ 12:32:
[...]
Mja... wel bijzonder... je gebruikt de nodige overlays? Maar ziet vervolgens het nut van vlans niet? Wat denk je dat Docker gebruikt om dit allemaal te kunnen doen? Juist ja...

Docker gebruikt VxLANs, het is maar één letter verschil, maar daarmee totaal niet te vergelijken met VLANs.

Dus als je al VxLANs gebruikt, dan ontgaat mij totaal het nut van VLANs nog: Slechte / foutgevoelige isolatie & beheer van switches/ids/trunks, geen encryptie, maar 4K Ids ipv 16M, geen IP overlap mogelijk (in VxLANs kun je tenminste gewoon dezelfde IP adressen gebruiken per VNI ), etc.

Maar goed. VxLANs zijn natuurlijk ook bedacht voor cloud / mult-tenant en multi-host toepassingen (Swarm/K*s), en VLANs zijn daar vziw nooit voor bedoeld.

Ik heb ooit - om te leren - 10 RPI's van mijn baas gekregen om een Docker Swarm cluster op te zetten en mee te spelen. Normaal is een cluster opzetten zonder netwerk kennis nogal een probleem, maar met een swarm was dat ook niet nodig. Elke ingress service krijgt automagisch een (gedistribueerde) VIP, zodat op welke van de RPI's ik ook kwam op poort 80 of 443, ik kwam altijd op de service proxy uit die op één of meerdere van de RPI's draaide. Alles dankzij load balancers en VxLANs!

Het was magisch

Op deze manier heb ik ooit ook die gevaarlijke Chinese camera's aan een macvlan gekoppeld: die konden dus enkel elkaar en die ene docker container zien. Meer niet. Beheer ging of via een WebSSH container in hetzelfde overlay netwerk, of via een WebGUI die enkel via een proxy beschikbaar was.

[Airw0lf]

@Mars Warrior - ok - maar een VXLAN heeft toch altijd een L3 transport mechanisme nodig? Wat - zeker in grotere bedrijven - is ingevuld met subnetten "verpakt" in vlans (d.w.z broadcast domains)?

Hier kom je pas vanaf als alle aangesloten apparaten native VXLAN kunnen - pas dan kun je uit de voeten met één plat netwerk - theoretisch dan toch. Dit lijkt me killing voor de verdienmodellen van de grote netwerk fabrikanten zoals Cisco, HP/Juniper, etc. Maar klinkt me als muziek in de oren... zeker als de intelligentie vergelijkbaar is met die van Docker containers in een Swarm/overlay netwerk...

Unne dikke mercie voor je tijd en uitleg - ook @alex3305 - top! Ik heb een hoop bijgeleerd en ben ook tot een paar andere inzichten gekomen!

[alex3305]

@Mars Warrior Het nut of onnut van VLANs komt bij de vraag van @StarWing vandaan. De vraag is niet per se duidelijk, heel erg eenvoudig of heeft een heel eenvoudig antwoord. ik zou hem adviseren om met een overlay netwerk en reverse proxy, of met een ipvlan netwerk te gaan werken. Dat laatste vond ik in ieder geval een veel eenvoudigere stap omdat applicaties dan ook nog via het netwerk routeerbaar zijn, waarna je eventueel een reverse proxy kunt toevoegen.

Mijn machines krijgen elk een /24 netwerk (VLAN) vanuit de router. Om de simpele reden dat ik op die manier eenvoudig containers kan scheiden per host en ik dus ook geen mogelijke IP collissions heb. Daarnaast heb ik er genoeg ruimte voor op mijn /16 netwerk. Dus waarom niet?

De communicatie tussen containers onderling vindt plaats via interne netwerken, dus VxLAN, of via de Traefik reverse proxy. Waarbij die laatste eveneens via een DNS toewijzing via het VLAN gaan. Elk Docker Compose project heeft, waar nodig, een eigen intern netwerk, waar ook geen andere container aan gekoppeld kan worden. Maar dit heb ik al eerder uitgebreid uitgelegd. Voor het ontsluiten zit het via een ingress overlay netwerk.

De mdns-repeater (waar ik overigens een eigen variant van heb ) werkt in sommige gevallen niet helemaal zoals ik verwacht. Ik merkte dat niet alle SSDP berichten doorkomen bij mijn Home Assistant container. Bijvoorbeeld die van mijn Sonos of Chromecast. Dat staat nog op mijn todo lijst om op te pakken.

Ik gebruik ook geen Swarm deployments, maar alleen Compose met Docker in Swarm mode. Met Swarm kan ik namelijk geen CPU-affiniteit opgeven wat voor mij enorm belangrijk is met mijn energiezuinige server. Voor load balancen van o.a. Traefik en eerder Caddy heb ik nog gekeken naar keepalived. Maar uiteindelijk nog geen zin en tijd gehad om moeite in te steken.

[Mars Warrior]

Airw0lf schreef op woensdag 22 oktober 2025 @ 15:21:
@Mars Warrior - ok - maar een VXLAN heeft toch altijd een L3 transport mechanisme nodig? Wat - zeker in grotere bedrijven - is ingevuld met subnetten "verpakt" in vlans (d.w.z broadcast domains)?

Hier kom je pas vanaf als alle aangesloten apparaten native VXLAN kunnen - pas dan kun je uit de voeten met één plat netwerk - theoretisch dan toch. Dit lijkt me killing voor de verdienmodellen van de grote netwerk fabrikanten zoals Cisco, HP/Juniper, etc. Maar klinkt me als muziek in de oren... zeker als de intelligentie vergelijkbaar is met die van Docker containers in een Swarm/overlay netwerk...

Haha. Yep. En vanzelfsprekend is daar over nagedacht, want hoe krijg je nu die communicatie voor elkaar in die grote data centers zodat L3 gewoon op de juiste plek terechtkomt? Nou, met EVPN (Ethernet VPN). Dat is een BGP-based control-plane die VxLAN netwerken kan routeren. Net als op het grote boze internet (waar BGP vandaan komt) kan er op die manier worden gerouteerd tussen VTEPs (VxLAN endpoints).

En daarvoor zijn vanzelfsprekend door de grote hardware partijen switches bedacht die een hoop van de VxLAN zaken lekker in hardware implementeren/offloaden. (Cisco Nexus, Arista, Juniper QFX).
Dus die doen nog steeds leuk centjes verdienen, ook zonder VLANs



Voor thuis is dat natuurlijk onzin: elke switch kan gewoon L3 routeren, alleen dat kost net wat meer CPU.

Unne dikke mercie voor je tijd en uitleg - ook @alex3305 - top! Ik heb een hoop bijgeleerd en ben ook tot een paar andere inzichten gekomen!

[RobertMe]

Mars Warrior schreef op woensdag 22 oktober 2025 @ 16:21:
Voor thuis is dat natuurlijk onzin: elke switch kan gewoon L3 routeren, alleen dat kost net wat meer CPU.

Routeren hoort dan wel bij L3, maar zeker niet veel consumer switches kunnen L3 routeren. Een "gewone" switch werkt op L2 (ethernet), niet op L3 (IP).

Tenzij je bv Uniquitis Pro / Enterprise switches hebt thuis, die doen wel L3. Maar de standaard TP-Link / ... switch zeker niet.

[StarWing]

alex3305 schreef op woensdag 22 oktober 2025 @ 16:05:
ik zou hem adviseren om met een overlay netwerk en reverse proxy, of met een ipvlan netwerk te gaan werken.

Ik heb het ondertussen werkend gekregen. Het ontbreken van kennis en de angst om wat te slopen zorgt ervoor dat ik niet simpelweg commando's ga beginnen inrammen.
Met de info van hier en wat hulp van ChatGPT heb ik een nieuwe brigde gemaakt "docker_lan" waaraan ik de containers koppel met een vast IP via docker-compose. Deze zijn dan enkel benaderbaar op mijn lan.
Via ipvlan een nieuw "vlan" netwerk gemaakt, welke ik dan ook correct kan benaderen, enkel op de vlan.

Volgende stap, maar dan eerder als test, is om een globale docker compose te maken met een .env, zodat alle variabelen op 1 plaats heb, mocht ik een migratie moeten doen.

[alex3305]

@StarWing Heel goed dat het e.e.a. werkt . Let op ChatGPT antwoorden aangezien die soms (wat) achterlopen.

Ben niet bang om dingen zomaar te slopen. Docker is daar precies voor bedoeld. Dat je eenvoudig herbruikbare omgevingen hebt. Eventueel die je op meerdere plekken kunt deployen. Zolang je netjes volume mounts gebruikt, kan er weinig misgaan. Sterker nog, ik undeploy ook nog weleens wat. Op mijn werk was dat zelfs een vereiste stap om te kijken of een herstel ook goed zou gaan .

Ik kan je nog wel een andere tip geven - althans dat doe ik altijd - zoek ook het tegenovergestelde commando op. Dus:

docker network create ... br-vlan
# docker network ls
# docker network inspect br-vlan
docker network rm br-vlan

En probeer die commando's ook uit. Dan leer je ook wat er 'achter de schermen' gebeurt en wordt het wellicht wat minder eng om dingen uit te proberen.

Anderzijds kun je ook gewoon een tweede VM opzetten en daar gaan spelen.

Ik zou je wel aanraden om meerdere Compose files te hebben, maar dat is mijn voorkeur. Ik manage die via Dockge omdat ik daarmee ook gewoon .env bestanden kan gebruiken. Met Portainer moeten die bestanden stack.env heten. Als je dat niet weet werkt het niet. Dat vond ik op z'n zachtst gezegd irritant.

[Webgnome]

Even tussendoor. Het is inmiddels gelukt om docker helemaal opnieuw te installeren via de docs.

Kleine tip nog, gebruik op Linux nooit docker Desktop. Het gebruikt een vm laag die het ontzettend langzaam maakt in tegenstelling tot default docker engine.

[Mars Warrior]

Ik heb inmiddels ook de CrowdSec firewall als docker container draaien
Omdat Docker officieel nog geen NFT tables ondersteund, draait de container netjes in iptables mode. Dat werkte in één keer goed.

De firewall van CrowdSec kan zowel in "managed" als in "set only" mode draaien. Ik heb hem gewoon in "managed" mode draaien.
In "managed" mode regelt CrowdSec alles, in "set only" mode moet je zelf die chains enzo aanmaken, en vult CrowdSec enkel wat er in moet of uit moet...

Verder heb ik logging aan staan, met prefix, zodat ik met journalctl (sudo journalctl -k | grep crowdsec) kan zien wat er geblokkeerd wordt.

De blocklists doen allemaal hun werk zie ik. Na 1 dag heb ik al 4.000 drops van de firewall. Ik zie dat sommige IP adressen wel 200x iets proberen met tussenpozen van 1 seconde.

De IPv4 en IPv6 logs na één dag, dus ca 4.000 blocks per dag op dit ogenblik:

• blacklist 0 = crowdsec
• blacklist 1 = community blocklist (15.000 adressen)
• blacklist 2 = tor exit nodes.

Output van sudo nft list ruleset | grep -i crowdsec -A3

Bash:

        chain CROWDSEC_CHAIN {
                # match-set crowdsec-blacklists-2 src  counter packets 0 bytes 0 jump CROWDSEC_LOG
                # match-set crowdsec-blacklists-1 src  counter packets 2655 bytes 158060 jump 
                # match-set crowdsec-blacklists-0 src  counter packets 1308 bytes 74858 jump 
        }
        chain CROWDSEC_CHAIN {
                # match-set crowdsec6-blacklists-2 src  counter packets 110 bytes 9913 jump CROWDSEC_LOG
                # match-set crowdsec6-blacklists-1 src  counter packets 0 bytes 0 jump CROWDSEC_LOG
                # match-set crowdsec6-blacklists-0 src  counter packets 27 bytes 2160 jump CROWDSEC_LOG
        }

Logischerwijs heb ik nu dus ook factoren minder events en alerts (20-40% over, dus factor 2-5 minder) en vanzelfsprekend ook andere decisions: dat zijn enkel nieuwe overtreders, want de oude worden immers door de firewall bouncer tegengehouden. Ik ben dan ook van plan om de default ban tijd naar 576 uur (max van ipset regels vziw) te verhogen.

De configuratie van de cs-firewall-bouncer:

YAML:

mode: iptables
update_frequency: 10s
log_mode: file
log_dir: /var/log/
log_level: info
log_compression: true
log_max_size: 100
log_max_backups: 3
log_max_age: 30
api_url: ${API_URL}
api_key: ${API_KEY}

## TLS Authentication
# cert_path: /etc/crowdsec/tls/cert.pem
# key_path: /etc/crowdsec/tls/key.pem
# ca_cert_path: /etc/crowdsec/tls/ca.crt
insecure_skip_verify: false
disable_ipv6: false
deny_action: DROP
#deny_log: false
deny_log: true

supported_decisions_types:
  - ban
#to change log prefix
deny_log_prefix: "crowdsec: "
#to change the blacklists name
blacklists_ipv4: crowdsec-blacklists
blacklists_ipv6: crowdsec6-blacklists
#type of ipset to use
ipset_type: nethash
#if present, insert rule in those chains
iptables_chains:
  - INPUT
#  - FORWARD
  - DOCKER-USER
iptables_add_rule_comments: true

## nftables
nftables:
  ipv4:
    enabled: false
    set-only: false
    table: crowdsec
    chain: crowdsec-chain
    priority: -10
  ipv6:
    enabled: false
    set-only: false
    table: crowdsec6
    chain: crowdsec6-chain
    priority: -10

nftables_hooks:
  - input
  - forward

# packet filter

En het docker compose gedeelte:

YAML:

  infra-cs-firewall-bouncer:
    image: ghcr.io/shgew/cs-firewall-bouncer-docker:latest
    container_name: infra-cs-firewall-bouncer
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    security_opt:
      - no-new-privileges:true
    volumes:
      - $DOCKERDIR/infra/cs-firewall-bouncer/config/crowdsec-firewall-bouncer.yaml:/config/crowdsec-firewall-bouncer.yaml:ro
      - $DOCKERDIR/infra/cs-firewall-bouncer/log:/var/log/
      - /etc/localtime:/etc/localtime:ro
    restart: always