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

[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

[Mars Warrior]

Nou, de crowdsec firewall doet zijn werk:

• 0 = crowdsec decisions/ban list
• 1 = CAPI list
• 2 = tor list
• 3 = handmatige decisions

En dat geeft voor IPv4 en IPv6 de volgende "efficiëntie" van deze blacklists:

Blacklist	Entries	Packets	Hits/IP	% of total
crowdsec-blacklists-0	163	20884	128.09	76.08
crowdsec-blacklists-1	14807	4886	0.33	17.81
crowdsec-blacklists-2	473	167	0.35	0.61
crowdsec-blacklists-3	17	1514	89.06	5.52
crowdsec6-blacklists-0	555	213	0.38	0.78
crowdsec6-blacklists-1	592	0	0.00	0.00
crowdsec6-blacklists-2	10	242	24.20	0.88
crowdsec6-blacklists-3	5	702	140.40	2.56
Total packets dropped		27451

Conclusies:

• De ban-list op basis van CrowdSec detecties is dus erg efficient: die houdt 76% van al het geblokkeerde verkeer tegen. En dat met enkel 163 IP adressen.
• De handmatige lijsten (-3) zijn ook erg efficient, zeker op IPv6! Ik heb dan ook de meest bekende ASNs qua spam/botjes volledig geblokkeerd (hostglobal, censys arin 1/2/3).
• Hele grote blocklists houden wel tegen, maar procentueel doen ze eigenlijk weinig.
• Helt lijstje van 5 IPv6 adressen heeft de hoogste hit ratio. Best wel leuk.

Aangezien dit zo goed werkt wil ik de CrowdSec decisions lijst gaan omzetten naar een permanente ipset ban lijst die ik met een scripje vul.

Op sommige dagen zijn de botjes plotseling vreselijjk actief en zie ik ook een flinke stijging in het aantal bans per dag op basis van unieke IP adressen. De piek naar 27 bans kwam overeen met de dag dat de iptables firewall ca 10.000 packets aan het droppen was.

Botjes zijn lijkt wel af en toe boos en/of wat creatief in het proberen van andere IP adressen.



Nog steeds blij dus met de Traefik, CrowdSec bouncer en CrowdSec Firewall bouncer containers!

Als ik nu terugkijk dan zou deze combi van containers eigenlijk standaard gereedschap moeten zijn voor elke Docker setup. Het is veiliger, maar ook zuiniger omdat heel wat CPU cycles niet meer nodig zijn dankzij het blokkeren van dit ongewenste verkeer.

[alex3305]

@Mars Warrior Mooi om te zien dat het goed z'n werk doet .

Ik mis denk ik iets, want hoezo heb jij nog extra blocklists? Ik heb de drie gratis blocklists een hele tijd terug toegevoegd, maar toen ik er 1 weghaalde of eigenlijk in wilde wisselen, heb ik dat slot niet meer teruggekregen .

Verder gebruik ik gewoon de standaard en heb ik er eigenlijk ook geen omkijken naar. Het lijkt allemaal z'n werk te doen. Dat is wel mooi .

offtopic:
Ik zou eigenlijk nog eens een Crowdsec bouncer willen combineren met Unifi. Wellicht dat ik daar nog eens aan begin.

[alex3305]

Ik ben niet snel van mijn stuk geslagen, maar recent ben ik gestart met de opzet van OpenCloud (OwnCloud Infinite Scale fork). Daar heeft men een Github repository voor, maar heel duidelijk vind ik het allemaal niet.

Mijn use-case lijkt enorm op de use-case die ik bij bijna al mijn hosted apps heb, namelijk dat de applicatie draait + een vorm van authenticatie gebruikt. Bij voorkeur OIDC / OAuth2 via Pocket ID, maar anders LDAP met LLDAP.

Door alle includes en verschillende compose bestanden (en omdat ik het wil omzetten naar mijn eigen Ansible format) is het allemaal niet super evident. De documentatie is ook wat karig op sommige punten. Ik vind het jammer dat er geen 'kant-en-klare' demo Compose is waar men dan verder op zou kunnen bouwen, zoals ik dat vaker bij andere projecten wel zie.

[Mars Warrior]

alex3305 schreef op woensdag 5 november 2025 @ 22:27:
@Mars Warrior Mooi om te zien dat het goed z'n werk doet .

Ik mis denk ik iets, want hoezo heb jij nog extra blocklists? Ik heb de drie gratis blocklists een hele tijd terug toegevoegd, maar toen ik er 1 weghaalde of eigenlijk in wilde wisselen, heb ik dat slot niet meer teruggekregen .

De cs-firewall-bouncer lijkt dus per blocklist, of bron/origin of scenario een blacklist set aan te maken. Ik doe daar niks mee. Gaat allemaal automatisch.

Verder gebruik ik gewoon de standaard en heb ik er eigenlijk ook geen omkijken naar. Het lijkt allemaal z'n werk te doen. Dat is wel mooi .

offtopic:
Ik zou eigenlijk nog eens een Crowdsec bouncer willen combineren met Unifi. Wellicht dat ik daar nog eens aan begin.

Zo zal het bij mij ook wel gaan functioneren, maar ik wil altijd beetje begrijpen hoe dingen werken. En die standaard ban tijd van 4u heeft dus helemaal geen zin. Pas vanaf 24 dagen gaat alles goed werken, en zie je dus ook dat ik op dit ogenblik dus bijna 82% blokkeer met wat handmatige acties + die 150 bans van CrowdSec zelf.

De invloed van die CAPI lijst en de TOR lijst is dus veel beperkter dan dat ik in eerste instantie dacht. Het gros valt buiten deze lijsten. Ik zie nu ook voornamelijk IP adressen die ik voor het eerst zie (aantal bans = 1), waar ik voorheen met een kortere bantijd heel veel herhalingen zag.

Ben benieuwd of dit zich doorzet. Met 10 unieke bans per dag ga je al naar de 3600 op jaarbasis.

[alex3305]

@Mars Warrior Ik heb mijn bantijden opgerekt naar 48 uur. Ik zag ook dat je de bantijden incrementeel kunt ophogen, maar dat was al teveel moeite voor me . Ik laat alleen verkeer via :443 binnen. En alleen via de IP's van Cloudflare. Dus mijn aanvalsvector is sowieso enorm klein.

[Mars Warrior]

alex3305 schreef op donderdag 6 november 2025 @ 10:52:
@Mars Warrior Ik heb mijn bantijden opgerekt naar 48 uur. Ik zag ook dat je de bantijden incrementeel kunt ophogen, maar dat was al teveel moeite voor me . Ik laat alleen verkeer via :443 binnen. En alleen via de IP's van Cloudflare. Dus mijn aanvalsvector is sowieso enorm klein.

Een paar commentaarregels weghalen en hoppa

Maar als je voorbij de 24 dagen komt gaat ipset klagen dat het interval te groot is. Geen idee of CrowdSec dat corrigeert, dus na die 24 dagen en nog wat de ban weer opnieuw in de ipset gooit.

Dus daarom heb ik nu een vaste bantijd van 24 dagen. Scheelt zoals je in de grafiek ziet enorm veel bans/dag.

[Mars Warrior]

alex3305 schreef op woensdag 5 november 2025 @ 22:30:
Ik ben niet snel van mijn stuk geslagen, maar recent ben ik gestart met de opzet van OpenCloud (OwnCloud Infinite Scale fork). Daar heeft men een Github repository voor, maar heel duidelijk vind ik het allemaal niet.

Mijn use-case lijkt enorm op de use-case die ik bij bijna al mijn hosted apps heb, namelijk dat de applicatie draait + een vorm van authenticatie gebruikt. Bij voorkeur OIDC / OAuth2 via Pocket ID, maar anders LDAP met LLDAP.

Door alle includes en verschillende compose bestanden (en omdat ik het wil omzetten naar mijn eigen Ansible format) is het allemaal niet super evident. De documentatie is ook wat karig op sommige punten. Ik vind het jammer dat er geen 'kant-en-klare' demo Compose is waar men dan verder op zou kunnen bouwen, zoals ik dat vaker bij andere projecten wel zie.

Ik dacht even dat de EU met iets bezig was, maar het is gewoon een commercieel bedrijf die -eu achter een domein heeft geplakt

Documentatie is voor mij helemaal onleesbaar. Lekker nergens zeggen hoe het samenwerkt. Overal kleine stukjes, geen samenhang, niks. Bij KeyCloak haak ik vaak al af. Een Waterhoofd dat onnodig complex is qua GUI en enorm veel resources gebruikt voor iets simpels als inloggen.

Maar waarom geen NextCloud AIO? Dat is gewoon draaien, toch?

[alex3305]

@Mars Warrior Volgens mij wordt het (deels) gefinancierd door de EU als alternatief tegenover de Amerikaanse reuzen. Niet slecht dunkt me.

Meestal lees ik wat (voorbeeld) code om eruit te komen voordat ik de documentatie induik. Maar allebei vind ik het onleesbaar. Ik vond wel dit blog die het e.e.a. uitlegt, maar die gozer doet security through obsecurity en daar krijg ik toch altijd een beetje de kriebels van.

Idem voor environment variabelen die je daarna include met iets andere namen. WAAROM?! Het zal mij een worst zijn of je nou:

YAML:

services:
  my-service:
    image: postgresql
    environment:
      POSTGRES_USER: ${DB_USER}

of

YAML:

services:
  my-service:
    image: postgresql
    env_file: [.env]

doet . Waarbij bij het eerste voorbeeld de variabele DB_USER en bij het tweede voorbeeld de variabele POSTGRES_USER in de env file staat.

En dan is dit een slecht voorbeeld, want voor 3, 4 of 8 variabelen vind ik het tot daaraan toe. Maar conform de repo heb ik een env file van 100+ regels. Wel met commentaar, maar na eenmalige configuratie kan me dat over het algemeen toch gestolen worden. Ook is de repo ook niet erg consistent in zaken zoals formatting. Dat stoort mij meer dan zou moeten .

Overigens lijk ik 90% te zijn, alleen de IdP integratie (Pocket ID) loopt enorm moeizaam. Ik verwacht simpelweg een Issuer URL, Client ID en Client Secret en dan gaan, maar blijkbaar denk ik dan te simpel. Volgens de Pocket ID documentatie zijn het PKCE clients zonder secret. Allemaal weer prima, alleen weer een extra afwijkende configuratie.

Maar waarom geen NextCloud AIO? Dat is gewoon draaien, toch?

Ik heb dat weleens geprobeerd. Ook de niet-AIO variant overigens. Maar ik vond dat een enorm log systeem en niet onderhoudbaar. Met mijn Renovate setup heb ik trouwens ook de spreekwoordelijke pleuris aan AIO deployments. Alhoewel het soms niet anders kan .

[Mars Warrior]

alex3305 schreef op donderdag 6 november 2025 @ 11:56:
@Mars Warrior Volgens mij wordt het (deels) gefinancierd door de EU als alternatief tegenover de Amerikaanse reuzen. Niet slecht dunkt me.

Zeker niet, maar de pot was leeg toen men aan de documentatie begon zodat gebruikers het ook gaan gebruiken. Ach ja, prioriteiten...

Meestal lees ik wat (voorbeeld) code om eruit te komen voordat ik de documentatie induik. Maar allebei vind ik het onleesbaar. Ik vond wel dit blog die het e.e.a. uitlegt, maar die gozer doet security through obsecurity en daar krijg ik toch altijd een beetje de kriebels van.

Idem voor environment variabelen die je daarna include met iets andere namen. WAAROM?! Het zal mij een worst zijn of je nou:

YAML:

services:
  my-service:
    image: postgresql
    environment:
      POSTGRES_USER: ${DB_USER}

of

YAML:

services:
  my-service:
    image: postgresql
    env_file: [.env]

doet . Waarbij bij het eerste voorbeeld de variabele DB_USER en bij het tweede voorbeeld de variabele POSTGRES_USER in de env file staat.

En dan is dit een slecht voorbeeld, want voor 3, 4 of 8 variabelen vind ik het tot daaraan toe. Maar conform de repo heb ik een env file van 100+ regels. Wel met commentaar, maar na eenmalige configuratie kan me dat over het algemeen toch gestolen worden. Ook is de repo ook niet erg consistent in zaken zoals formatting. Dat stoort mij meer dan zou moeten .

Overigens lijk ik 90% te zijn, alleen de IdP integratie (Pocket ID) loopt enorm moeizaam. Ik verwacht simpelweg een Issuer URL, Client ID en Client Secret en dan gaan, maar blijkbaar denk ik dan te simpel. Volgens de Pocket ID documentatie zijn het PKCE clients zonder secret. Allemaal weer prima, alleen weer een extra afwijkende configuratie.

Rare manier van werken. Laten we piet jan noemen, jan klaas, en klaas weer piet

Ik hou het wel ff bij Microsoft met OneDrive en online samenwerken. Dat doet het voor mijn behoefte.

Ik heb dat weleens geprobeerd. Ook de niet-AIO variant overigens. Maar ik vond dat een enorm log systeem en niet onderhoudbaar. Met mijn Renovate setup heb ik trouwens ook de spreekwoordelijke pleuris aan AIO deployments. Alhoewel het soms niet anders kan .

De ene gebruiker vindt het log, de andere heeft geen problemen. Bij mij was het bagger traag en teveel CPU belasting voor iets dat niks doet het gros van de tijd. En dat op een 13900K.

OpenCloud beweert dat het zelfs op een RPI nog goed draait. Dat zou dus wel een enorm verschil zijn. Wie weet zie ik ooit nog het nut om het eens te proberen!

[alex3305]

@Mars Warrior OCIS en OpenCloud zijn volledig opnieuw opgebouwd op basis van Go ipv PHP. Bij mij was Nextcloud en Owncloud ook enorm traag.

[Mars Warrior]

Ik ben nog aan het kijken naar een metrics setup, maar dan zonder de usual suspects als Grafana enzo.
Het moet zuinig en snel zijn, en daarnaast simpel (voor mij dan).

Een combi van Telegraf, CrateDB en Metabase ben ik nu aan het verkennen:

• Telegraf zou met docker labels kunnen werken. Dan kan ik via labels pad, poort en interval kunnen opgeven
• Ook zou een label de CrateDB tabel kunnen aangeven. Ik wil dan per service een aparte tabel. Mixen heeft voor mij geen nut.
• CrateDB kan key/value pairs opslaan en is één van de snelste databases die ik ken
• Metabase zou dan voor visualisatie zijn. Is simpel met SQL queries, dus ik kan ook custom queries maken die enkel CrateDB kent/snapt (key/value pairs)
• Aangezien CrateDB Postgres praat is koppelen aan andere systemen ook geen probleem. Al die custom rare niet-SQL ben ik beetje zat.

Zou dan zoiets worden in Telegraf (bedacht door ChatGPT, dus kan nog totale onzin zijn, of een mix van versies, of iets dat helemaal nooit heeft bestaan):

TOML:

[agent]
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  omit_hostname = true

[[inputs.prometheus]]
  ## Automatisch containers met metrics.enable=true scrapen
  [inputs.prometheus.discovery]
    docker_labels_include = ["metrics.enable", "metrics.port", "metrics.path", "metrics.job", "metrics.interval"]
    docker_label_filter = { "metrics.enable" = "true" }

  ## Interval-label uitlezen (ondersteund sinds 1.30)
  interval_label = "metrics.interval"

  ## Vorm van de URL op basis van labels
  url_label = "metrics.path"
  job_label = "metrics.job"
  port_label = "metrics.port"

  ## Extra tag (servernaam)
  [inputs.prometheus.tags]
    node = "$METRICS_NODE"

[[outputs.postgresql]]
  address = "host=cratedb port=5432 user=crate dbname=metrics sslmode=disable"
  table_template = "metrics_{{ .Tags.job }}"
  create_templates = true

Telegraf draait al, dus enkel extra config erbij. CrateDB draait al in andere context, dus dat wordt een minimale container erbij die makkelijk op 1 core kan lopen wat mij betreft als ik elke 15minuten een scrape doe.
Metabase heb ik ook al in gebruik, dus dat is enkel een extra Postgres interface/bron erbij.

Wie weet

[oohh]

RobertMe schreef op donderdag 9 oktober 2025 @ 17:32:
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).

Ik weet niet of je hier al verder mee bent gekomen maar probeer eens UserNs=keep-id, waarmee je de container draait als de user die de container start. Of mount de socket met selinux flag zoals “Z” of “z” indien meerdere containers toegang nodig hebben tot de socket.

[Mars Warrior]

Mars Warrior schreef op donderdag 6 november 2025 @ 12:29:

Zou dan zoiets worden in Telegraf (bedacht door ChatGPT, dus kan nog totale onzin zijn, of een mix van versies, of iets dat helemaal nooit heeft bestaan):

Wie weet

Afijn. ChatGPT zat weer duidelijk aan de paddo’s.

De hele setup is verzonnen. Niets kan op deze manier. Natuurlijk gaf ChatGPT als verweer dat die functionaliteit dan in de laatste versie is verwijderd.

Ach ja. Dat soort verweer ken ik inmiddels

Het is soms ongelofelijk hoeveel complete onzin er uit zo’n AI chatbot kan komen. Als werknemer zou je niet meer serieus worden genomen, maar als AI krijg je juist nog meer geld om nog meer onzin te verkondigen 😇

Helaas krijg ik VMAgent ook niet aan de praat. Dat is ook een gedrocht qua duidelijkheid en foutmeldingen.

Pech.

[ Voor 14% gewijzigd door Mars Warrior op 06-11-2025 19:42 ]

[alex3305]

@Mars Warrior Ik ben super tevreden over mijn Beszel setup. Die heeft sinds kort ook Docker container stats support:



Ik heb daar zelf een Ansible role voor ontwikkeld. Twee van mijn Docker nodes gebruiken dan de Beszel agent in Docker, de andere twee nodes gebruiken een native agent.

Het is bijzonder lichtgewicht en energiezuinig met alles erin. Waaronder notificaties, SSO en (live) grafiekjes. Updates zijn ook regelmatig met ook nieuwe functies.





Voor access logging gebruik nu weer GoAccess. Met Caddy was dat echt een resource vreter, maar dat lijkt met Traefik wel goed te gaan.

[Mars Warrior]

@alex3305 dan moet ik nodig updaten. Die overzichten zitten niet in mijn versie van Beszel.

Ik was ook niet van plan om docker stats met VMAgent te verzamelen. Enkel andere stats maar dat zit dus nog ff tegen.

Ik gebruik auto discovery. Die doet al raar maar het scrapen zelf geeft dus ook time-outs lijkt het. Er komt dus niks uit VMAgent.

VMAgent moet de data naar Telegraf doorzetten die zich voordoet als prometheus endpoint. En dan CrateDB in.

[ComTech]

Mocht iemand tegen deze foutmelding aanlopen bij het starten van een container

code:

Error response from daemon: failed to create task for container:
OCI runtime create failed: runc create failed: unable to start container process:
error during container init: open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied

Er zit blijkbaar een bug in Docker versie 28.5.2 en om precies te zijn in containerd v1.7.29 waardoor containers niet meer starten.
Oplossing is even downgraden van containerd.
Voor ubuntu 25.04 plucky:

code:

wget https://download.docker.com/linux/ubuntu/dists/plucky/pool/stable/amd64/containerd.io_1.7.28-1~ubuntu.25.04~plucky_amd64.deb
sudo dpkg -i containerd.io_1.7.28-1~ubuntu.25.04~plucky_amd64.deb

Heeft mij al een uur zoeken gekost

[Mich]

@Mars Warrior @alex3305

Hebben jullie ook ervaring met https://app.crowdsec.net/hub hier kan je crowdsec nog mee uitbreiden met verschillende dingen. Bijvoorbeeld door crowdsec in bepaalde log files te laten kijken en extra appsec rules. Ik heb zelf crowdsec draaien op opnsense. Zie in de firewall ook wel dat her en der wat geblokkeerd wordt maar moet me er nog wat meer in verdiepen. Ook welke gratis blocklists nu het beste zijn.

[Mars Warrior]

Mich schreef op donderdag 6 november 2025 @ 23:00:
@Mars Warrior @alex3305

Hebben jullie ook ervaring met https://app.crowdsec.net/hub hier kan je crowdsec nog mee uitbreiden met verschillende dingen. Bijvoorbeeld door crowdsec in bepaalde log files te laten kijken en extra appsec rules. Ik heb zelf crowdsec draaien op opnsense. Zie in de firewall ook wel dat her en der wat geblokkeerd wordt maar moet me er nog wat meer in verdiepen. Ook welke gratis blocklists nu het beste zijn.

Wij hebben beiden AppSec draaien ja. Die is bij mij voor het grootste deel verantwoordelijk voor alle decisions/bans, dus zeker doen. De Traefik logfile is natuurlijk de 1ste waar wat mee gedaan wordt. Daarmee kun je al veel met standaard configuratie tegenhouden.
AppSec controleert de URI tegen allerhande CVE's enzo. Hieronder zie je bij "Scenario" een aantal van die dingen.



Ik gebruik de CAPI lijst (15.000 adressen), de TOR lijst, en verder niet.
Zoals eerder aangegeven is 0 de CrowdSec bouncer, 1 de CAPI, 2 de TOR en 3 handmatig.
Data afgeleid uit iptables (via cs-firewall-bouncer container) om de efficientie van deze lijsten te bepalen.

Blacklist	Entries	Packets	Hits/IP	% of total
crowdsec-blacklists-0	185	22748	122,96	71,54
crowdsec-blacklists-1	14811	5459	0,37	17,17
crowdsec-blacklists-2	494	167	0,34	0,53
crowdsec6-blacklists-0	543	213	0,39	0,67
crowdsec6-blacklists-1	602	0	0,00	0,00
crowdsec6-blacklists-2	10	250	25,00	0,79
crowdsec-blacklists-3	17	2075	122,06	6,53
crowdsec6-blacklists-3	5	887	177,40	2,79

Total packets dropped: 31799

En het script dat - na 5 pogingen - door ChatGPT is gemaakt. Ik ben zelf niet bepaald goed in bash en al die rare Linux commando's en tooltjes. Beetje abacadabra...

Bash:

#!/bin/bash
# Toon overzicht van CrowdSec-ipsets met counters en efficiency (packets)

echo -e "Blacklist\tEntries\tPackets\tHits/IP\t% of total"

# 🧮 1. Verzamel alle match-set regels uit iptables en ip6tables
iptables_output=$(sudo iptables  -L CROWDSEC_CHAIN -v -n 2>/dev/null)
ip6tables_output=$(sudo ip6tables -L CROWDSEC_CHAIN -v -n 2>/dev/null)

# 🧮 2. Totaal aantal packets (alle regels samen)
total=$(
  echo "$iptables_output"$'\n'"$ip6tables_output" \
  | awk '/match-set/ {s+=$1} END{print s+0}'
)

# 🧮 3. Maak mapping ipset -> packets in één awk-run
declare -A pkts_map
while read -r name pkts; do
  [[ -n "$name" ]] && pkts_map["$name"]=$(( ${pkts_map["$name"]:-0} + pkts ))
done < <(
  echo "$iptables_output"$'\n'"$ip6tables_output" \
  | awk '/match-set/ {
      for (i=1; i<=NF; i++) if ($i=="match-set") print $(i+1), $1
    }'
)

# 🧮 4. Loop over alle ipsets
for set in $(sudo ipset list | awk '/Name: crowdsec/ {print $2}'); do
  entries=$(sudo ipset list "$set" | awk '/Number of entries/ {print $4}')
  pkts=${pkts_map["$set"]:-0}

  [[ "$entries" -gt 0 ]] && ratio=$(awk -v p="$pkts" -v e="$entries" 'BEGIN{printf "%.2f", p/e}') || ratio=0
  [[ "$total"   -gt 0 ]] && pct=$(awk -v p="$pkts" -v t="$total" 'BEGIN{printf "%.2f", (p/t)*100}') || pct=0

  printf "%-25s\t%10s\t%10s\t%10s\t%10s\n" "$set" "$entries" "$pkts" "$ratio" "$pct"
done | column -t

echo -e "\nTotal packets dropped: $total"

[ Voor 25% gewijzigd door Mars Warrior op 07-11-2025 10:11 ]

[alex3305]

@Mich Ik deploy al mijn (Docker) applicaties met Ansible. Ik voeg die collections dus toe aan mijn Ansible variables:

YAML:

# CrowdSec
traefik_crowdsec_api_key: "{{ vault_traefik_crowdsec_api_key }}"
traefik_crowdsec_collections:
  - crowdsecurity/appsec-generic-rules
  - crowdsecurity/appsec-virtual-patching
  - crowdsecurity/appsec-crs
  - crowdsecurity/appsec-crs-inband
  - crowdsecurity/base-http-scenarios
  - crowdsecurity/home-assistant
  - crowdsecurity/http-cve
  - crowdsecurity/http-dos
  - crowdsecurity/http-extended-context
  - gauth-fr/immich
  - andreasbrett/paperless-ngx
  - crowdsecurity/plex
  - crowdsecurity/traefik
  - Dominic-Wagner/vaultwarden
  - crowdsecurity/whitelist-good-actors

traefik_crowdsec_additional_log_volumes:
  - src: "{{ home_assistant_config_dir }}"
    dest: /var/log/home-assistant
  - src: "{{ paperless_ngx_log_dir }}"
    dest: /var/log/paperless
  - src: "{{ vaultwarden_log_dir }}"
    dest: /var/log/vaultwarden

In de Compose Jinja template worden deze variabelen dan gebruikt om de uiteindelijke Compose op te bouwen:

YAML:

#jinja2: lstrip_blocks: True, trim_blocks: True
---
{{ ansible_managed | comment }}

name: {{ _compose_stack_name }}

services:
  crowdsec:
    container_name: ${COMPOSE_PROJECT_NAME}-crowdsec
    image: ghcr.io/crowdsecurity/crowdsec:v1.7.3
    restart: on-failure:5
    environment:
      COLLECTIONS: "{{ traefik_crowdsec_collections | join(' ') }}"
    networks:
      internal:
      docker-socket:
    volumes:
      - {{ traefik_crowdsec_database_dir }}:/var/lib/crowdsec/data/
      - {{ traefik_crowdsec_config_dir }}:/etc/crowdsec/
      - logs:/var/log/traefik:ro
      {% if traefik_crowdsec_additional_log_volumes is defined %}
      {% for dir in traefik_crowdsec_additional_log_volumes %}
      - {{ dir.src }}:{{ dir.dest }}:ro
      {% endfor %}
      {% endif %}
    healthcheck:
      test: ["CMD", "cscli", "version"]

Ansible zet dit dan om tijdens de deployment naar de correcte waardes in yaml. Dat maakt het beheer bijzonder eenvoudig.

Deployments vinden overigens veelal automatisch plaats. Dit gebeurt wanneer Renovate merged naar main. Op mijn infra-repo is dat tussen doordeweeks tussen 9-20. En dan alleen van de componenten waarvan de bestanden zijn aangepast. Deze fail fast aanpak zorgt ervoor dat fouten snel worden gevonden. En door de strakke versioning van Renovate kan ik ook vrij snel vinden waar de fout is opgetreden en hoe ik eventueel terug moet.

Zoals ik eerder al zei kan ik maar twee blocklists gebruiken . Ik ben dus 1 slot kwijt, maar ik heb nog nergens gevonden waar ik dat kan melden.

[Mars Warrior]

@Mich , hier zie je ook nog een keer het effect van het combineren met de cs-firewall-bouncer waarmee bans in ip/nftables worden gezet, en Traefik en de CrowdSec bouncer die pakketjes niet meer zien.

Zo rond 27/28 oktober heb ik de firewall container acief gemaakt. Je ziet een enorme daling in het aantal events dat door CrowdSec wordt geregistreerd. Ik heb met de installatie van de firewall container ook de bantijd verhoogd naar 24 dagen / 576 uur.

Tegelijkertijd zie je ook een flinke daling in het aantal unieke bans per dag. Het zal nooit 0 worden, daarvoor zijn er teveel botjes en cloud centra die die botjes hosten. Ik zie ook in mijn dashboards nu voornamelijk FTO's (First Time Offenders).

Door die standaard bantijd van 24 dagen is de CrowdSec blacklist dus ook meteen de meest effectieve van alle blacklists die ik gebruik. Ze leren hier namelijk niks van en komen gewoon weer terug als de ban is opgeheven. Vandaar wil ik naar een permanente block in de firewall van alle ip adressen die door CrowdSec geblokkeerd zijn. Dan zie ik ze ook nooit meer terug.

Sinds activeren firewall (en geen reboots, want dan start de teller weer op 0) dus zo'n 32.000 packets dropped. Zeg 11 dagen, dus gemiddeld 2.900 per dag. En dat op een gewoon consumenten lijntje van de KPN.

[Airw0lf]

@Mars Warrior - maar het gebruik van IP adressen is redelijk vloeibaar - enerzijds door de handel in IPv4 adressen en anderzijds door VPN-achtigen. Waardoor een "eeuwige" ban op enige termijn ook tegen je kan werken. Hoe zie jij dat? Wat als je die ban op 3 of 6 maanden zou zetten?

[Mars Warrior]

Airw0lf schreef op vrijdag 7 november 2025 @ 14:09:
@Mars Warrior - maar het gebruik van IP adressen is redelijk vloeibaar - enerzijds door de handel in IPv4 adressen en anderzijds door VPN-achtigen. Waardoor een "eeuwige" ban op enige termijn ook tegen je kan werken. Hoe zie jij dat? Wat als je die ban op 3 of 6 maanden zou zetten?

Lastig. IPv4 adressen willen nog wel eens doorgeschoven worden, verhandeld of hergebruikt. Dus ja, dan kan het zijn dat een ip adres van een spammer plotseling bij een normale partij komt. Dan zou een permanente ban onterecht zijn.

Ik zit nu op die 24 dagen vanwege de maximale timeout van ipset.

Voorheen gebruikte ik Fail2Ban, en elke overtreder (na tig overtredingen) kreeg een permanente ban. Daar heb ik op zich nooit last van gehad.

Optie 1 met CrowdSec:

• Na 24 dagen de ban gewoon laten verlopen, en als het ip adres weer komt, gewoon weer een ban van 24 dagen. Dus dan ga je wat cycli zien denk ik in de CrowdSec statistieken.

Optie 2 met CrowdSec:

• Tracken van recidiven (deed ik al met een 24h ban) en dan bijv. de ban in stappen van 24 dagen verlengen naar zeg max 6-12 maanden.

Optie 3 CrowdSec combineren met bekende blocklists:

HIerbij kun je gebruik kunnen maken van de uceprotect lijsten (1, 2 of 3). Die worden dynamisch bepaald, en zijn dus actueel.

• Als het ip adres in die lijst zit, de ban op voorhand verlengen of in stand houden
• Als het ip adres niet meer in die lijst zit, de ban netjes laten verlopen

De uceprotect lijsten zijn wat speciaal in de zin dat zij complete ASN's kunnen blokkeren als er bijv binnen een /24 bereik meer dan 50 adressen zijn die spam/bot gedrag vertonen (lijst 3).

Iets speciaals doen bovenop standaard CrowdSec gedrag is natuurlijk allemaal extra werk. Als optie 1 toch blijkt te werken (24 dagen ban, na 24 dagen weer bannen als ip terugkomt), dan kan het zijn dat ik het daarbij houd.

Besef dat ik de grote spammers/botnetwerken al handmatig in een ban heb staan. Dat scheelt al bergen alerts en bans. Deze ASNs staan er overigens gewoon om bekend botnetwerken te hosten. Hostglobal staat in veel lijsten op #1. En Censys Arin is ook gewoon een bekend bot/scan netwerk.

[Mars Warrior]

@alex3305 . Leuk die nieuwe Beszel. Was alleen vergeten de Agent ook te pullen. Had dus lege docker stats.

Al mijn huidige metrics containers. Beszel zit strak op 0,00% CPU.

De vmagent die nog niks richting storage krijgt doet het ook aardig, al is het maar met 1 container.
Dat wat wel al met Telegraf wordt binnengehaald gaat zowel naar InfluxDB als naar CrateDB. De laatste is duidelijk een stuk zuiniger om die data te verwerken.

[alex3305]

@Mars Warrior Ik heb ondanks advies eerder in dit topic afgezien van een Influx stack. Hoe mooi het misschien ook is. Met name omdat ik nog steeds een soort van PTSS heb van de InfluxDB 1 naar 2 overgang.

Grafana Loki en Prometheus werken prima, maar ik kan niet gewend raken aan Grafana. Hoe vaak ik het ook probleer. Ik vind dashboarding functionaliteit of LogQL / PromQL nou niet echt voor de hand liggend. Dat is overigens wel aardig een 'mijn probleem'. En cAdvisor ZUIPT stroom. Dat wil ik niet.

Netdata had ik ook nog even bekeken, maar dat belde nogal naar huis en dat mot ik niet. En de 1337-UI staat me niet aan. Bij andere concurrenten overigens ook. Dat komt mede omdat ik maar voor 20% zicht heb en dan zijn die kleine lettertjes of pictogrammen niet handig. Dan kun je wel weer zoomen, maar volgens ga ik dan het doel dashboard voorbij.

Met Beszel kun je overigens ook Docker logs zien en de container configuratie (Docker Inspect) als je een container aanklikt. Super handig .

[Airw0lf]

Mars Warrior schreef op vrijdag 7 november 2025 @ 13:54:
@Mich , hier zie je ook nog een keer het effect van het combineren met de cs-firewall-bouncer waarmee bans in ip/nftables worden gezet, en Traefik en de CrowdSec bouncer die pakketjes niet meer zien.

Zo rond 27/28 oktober heb ik de firewall container acief gemaakt. Je ziet een enorme daling in het aantal events dat door CrowdSec wordt geregistreerd. Ik heb met de installatie van de firewall container ook de bantijd verhoogd naar 24 dagen / 576 uur.

Tegelijkertijd zie je ook een flinke daling in het aantal unieke bans per dag. Het zal nooit 0 worden, daarvoor zijn er teveel botjes en cloud centra die die botjes hosten. Ik zie ook in mijn dashboards nu voornamelijk FTO's (First Time Offenders).

Door die standaard bantijd van 24 dagen is de CrowdSec blacklist dus ook meteen de meest effectieve van alle blacklists die ik gebruik. Ze leren hier namelijk niks van en komen gewoon weer terug als de ban is opgeheven. Vandaar wil ik naar een permanente block in de firewall van alle ip adressen die door CrowdSec geblokkeerd zijn. Dan zie ik ze ook nooit meer terug.

Sinds activeren firewall (en geen reboots, want dan start de teller weer op 0) dus zo'n 32.000 packets dropped. Zeg 11 dagen, dus gemiddeld 2.900 per dag. En dat op een gewoon consumenten lijntje van de KPN.

[Afbeelding]

[Afbeelding]

Waar komt dit plaatje vandaan?

Ik gebruik zelf Swag als proxy - daar is een CrowdStrike mod voor.
Fail2Ban zou ik dan willen vervangen door CrowdStrike.
Mijn zorg zit hem in de dashboard mod - gaat die nog iets laten zien van de resultaten met CrowdStrike.

[Mars Warrior]

Airw0lf schreef op zondag 9 november 2025 @ 10:26:
[...]
Waar komt dit plaatje vandaan?

Eigen Metabase dashboard met Dark Reader plugin omdat de gratis versie van Metabase geen thema's toestaat

Ik gebruik zelf Swag als proxy - daar is een CrowdStrike mod voor.
Fail2Ban zou ik dan willen vervangen door CrowdStrike.
Mijn zorg zit hem in de dashboard mod - gaat die nog iets laten zien van de resultaten met CrowdStrike.

Geen idee. Ik ken SWAG niet, dus ook het dashboard niet. Verwacht niet zomaar dat die de CrowdSec database kan uitlezen en verwerken, laat staan dat die toont wat jij wilt zien.

CrowdSec console kent wel wat dashboards, maar ook die zijn primitief en beperkt / expres kreupel gemaakt omdat ze je graag een betaalde versie willen aansmeren. Voorheen (2020 ofzo) leverde CrowdSec gewoon een Metabase container mee met dashboarding.

Ik maak dus liever mijn eigen dashboards. De SQL queries laat ik lekker door ChatGPT maken.



De SQL Query voor het onderste dashbaord ziet er als volgt uit. Of het helemaal optimaal is weet ik niet. Dat laat ik dus aan ChatGPT over. Een view of metabase model zou zo'n query sterk kunnen vereenvoudigen omdat ik nu alle berekeningen ook in de query doe.

SQL:

WITH latest_per_ip AS (
    SELECT
        value AS ip,
        MAX(created_at) AS last_created
    FROM decisions
    WHERE until > datetime('now')
      AND origin = 'crowdsec'
    GROUP BY value
)
SELECT
    datetime(d.created_at, 'localtime') AS "Tijdstip",

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

    -- Hoe lang nog actief
    CASE
        WHEN CAST((julianday(d.until) - julianday('now')) * 24 * 60 AS INT) < 60
            THEN printf('%d minuten',
                CAST(((julianday(d.until) - julianday('now')) * 24 * 60) % 60 AS INT)
            )
        WHEN CAST((julianday(d.until) - julianday('now')) AS INT) = 0
            THEN printf('%d uur',
                CAST(((julianday(d.until) - julianday('now')) * 24) % 24 AS INT)
            )
        WHEN CAST((julianday(d.until) - julianday('now')) AS INT) = 1
            THEN
                CASE
                    WHEN CAST(((julianday(d.until) - julianday('now')) * 24) % 24 AS INT) = 0
                        THEN '1 dag'
                    ELSE printf('1 dag, %d uur',
                        CAST(((julianday(d.until) - julianday('now')) * 24) % 24 AS INT)
                    )
                END
        ELSE
            CASE
                WHEN CAST(((julianday(d.until) - julianday('now')) * 24) % 24 AS INT) = 0
                    THEN printf('%d dagen',
                        CAST((julianday(d.until) - julianday('now')) AS INT)
                    )
                ELSE printf('%d dagen, %d uur',
                    CAST((julianday(d.until) - julianday('now')) AS INT),
                    CAST(((julianday(d.until) - julianday('now')) * 24) % 24 AS INT)
                )
            END
    END AS "Ban Resterend",

    printf('%s - %s', a.source_country, IFNULL(a.source_as_name, 'Onbekend'))  AS "ASN",
    concat('https://flags.example.com/hatscripts/circle-flags/', lower(a.source_country), '.svg') AS "Land",

    d.value AS "IP Adres",
    d.scenario AS "Scenario",
    a.events_count AS "Events",
    
    -- ✅ som van alle events over dit IP
    (
        SELECT SUM(a2.events_count)
        FROM alerts AS a2
        JOIN decisions AS d2
          ON a2.id = d2.alert_decisions
        WHERE d2.value = d.value
    ) AS "Totaal Events",
    
    printf(
        '%d / %d',
        (SELECT COUNT(*) FROM decisions d2 WHERE d2.value = d.value AND d2.until > datetime('now')),
        (SELECT COUNT(*) FROM decisions d3 WHERE d3.value = d.value)
    ) AS "Bans (act/tot)"

FROM decisions AS d
LEFT JOIN alerts AS a
  ON d.alert_decisions = a.id
JOIN latest_per_ip AS l
  ON d.value = l.ip AND d.created_at = l.last_created
WHERE d.until > datetime('now')
  AND d.origin = 'crowdsec'
ORDER BY d.created_at DESC;

Ik wilde bijv. ook weten hoeveel van de aanvallen op domeinen is, en hoeveel louter op IP adres.
Dat is wel even wat query en rekenwerk, want CrowdSec meldt niet overal netjes het domein bij, dus ik heb uit de Traefik log de router moeten halen om dit te vertalen naar een domein, maar het resultaat is dus dat ca 75% op IP adres is, dus ongevaarlijk, want dat komt dus op een 404 uit van Traefik zelf.



Allemaal dingen die geen enkel standaard CrowdSec dashboard je gaat vertellen. Die hebben het liefst dat alles gevaarlijk is, want dat verkoopt beter. Ze raden ook een maximale bantijd van 3 dagen / 72 uur aan om allerhande redenen. Één van de redenen is mij wel duidelijk: des te meer alerts, des te hoger het abbo dat je nodig hebt om op hun console dashboards alle alerts te tonen

Het is open source, dus ze zullen net als elk open source project toch ergens hun geld mee moeten verdienen. Ik heb echter op deze manier weinig tot niets aan hun dashboards, dus gebruik mijn eigen spullen. Dan kan ik ook drill-downs doen en alarmen zetten.

Ook dit soort cijfers komen nergens in CrowdSec voor. Het is nu een shell script, maar ik wil nog kijken of de metrics die CrowdSec levert ook dit soort info van af te leiden valt.

De handmatige blocks (de -3 namen), 17 IPv4 en 5 IPv6 adressen blijken dus vreselijk effectief te zijn

Bash:

Blacklist             Entries Packets Hits/IP % of total
crowdsec-blacklists-0   212    26592  125,43  72,11
crowdsec-blacklists-1   14632  5979   0,41    16,21
crowdsec-blacklists-2   470    167    0,36    0,45
crowdsec6-blacklists-0  543    213    0,39    0,58
crowdsec6-blacklists-1  567    0      0,00    0,00
crowdsec6-blacklists-2  11     257    23,36   0,70
crowdsec-blacklists-3   17     2699   158,76  7,32
crowdsec6-blacklists-3  5      972    194,40  2,64

Total packets dropped: 36879

Het zijn weer 3 extra containers (CrowdSec bouncer, CrowdSec firewall en Metabase), maar ik ben er blij mee

[Mars Warrior]

Om toch nog even door te gaan op de vraag die ik mezelf stelde, maar ook de vraag van @Airw0lf wat de kans is dat je een permantente block op een IP adres zet wat onterecht is, heb ik dus alle crowdsec decisions in mijn lijst (ca 230 nu) eens laten matchen (op DNS basis) met de Uceprotect 1, 2 en 3 lijsten.

TL;DR;
Als je de drie UCE lijsten combineerd dan komt 40% van de bans voor in deze lijsten. Je zou dus op voorhand van deze IP adressen de bantijd kunnen verlengen elke week zolang deze in één van de UCE lijsten voorkomt. Anders laten vervallen.

Aan de andere kant zie ik de laatste tijd voornamelijk First Time Offenders, en zou je gewoon CrowdSec zijn werk moeten laten doen omdat het verlengen van de bantijd geen enkele invloed heeft op deze nieuwe IP adressen.

Wat is de betekenis van die UCE lijsten?

• UCE Level 1: op IP adres, dus nauwkeurig, en kleine kans op false positives
• UCE Level 2: op subnet, dus grotere kans op missers
• UCE Level 3: op ASN niveau, de meest grove block die UCE kent

En mijn matches op elk level?

• UCE-L1 --> 30, 13%
• UCE-L2 --> 49, 21%
• UCE-L3 --> 75, 32%

Alle levels bij elkaar zijn 92 regels (40%) van de 230 die op één of meer van de levels matchen.
Enkel L1 en L2 zijn volgens Metabase 58 regels, dus 25% dekking.

Het geheel is volledig te automatiseren, dus vanaf de cscli decisions list tot aan het matchen en opvragen van ip adressen/ranges:

• UCE L1 is dus een match op ip adres
• UCE L2 geeft bij de details het subnet weer dat je zou moeten blokkeren
• UCE L3 geeft in de basis de ASN, waarvan je de ip ranges bijv. bij whosi.radb.net kunt opvragen

Ik heb de hele CSV ff in Metabase geupload om te bekijken, en dan zie je in ieder geval de usual suspects terug, maar ook heel wat bans die in de UCE lijsten niet voorkomen.



En wat kun je hiermee?
Op zich is het dus mogelijk om een strategie in elkaar te flansen die bepaalde bans blijft uitbreiden afhankelijk in welk level ze voorkomen. Level 1 bijv 3 weken, level 2 2 weken en level 3 1 week. Als je dat elke week doet dan zorgen wijzigingen in deze lijsten ook dat ip adressen/ranges ook weer af kunnen vallen.

Zou het helpen om een flinke reductie in alerts/bans te krijgen?
Met de meest zekere lijst wordt in slechts 13% van de gevallen de ban op voorhand verlengd. Dat is niet echt schokkend. Je kunt ook de ban laten verlopen, en dan CrowdSec gewoon weer een ban laten uitdelen als dat ip adres weer langskomt.

Kijk je enkel of een IP in één van de lijsten zit, dan zou je de ban van ca 40% van de IP adressen verlengen. Dus niet een subnet of ASN blokkeren, maar puur het handhaven van het eerder geblokkeerde IP ares.

Sommige lijsten op internet bevatten ettelijke miljoenen ip adressen, dus dat geeft al aan hoeveel je zou moeten blokkeren op voorhand om een echte flinke reductie te krijgen. Zelfs de CAPI lijst van 15.000 adressen doet de laatste week maar 10% van de 230 bans die nu actief zijn.

Containertje erbij?
Ik heb er wel weer een Postgres container bij en zit nu op 60 containers. De Postgres database is nodig om de uploads in op te slaan. Zo werkt Metabase: een upload moet je aan een database toewijzen om deze te kunnen gebruiken

[ Voor 14% gewijzigd door Mars Warrior op 10-11-2025 18:06 ]

[Webgnome]

Heeft iemand wel eens het volgende gehad?
Vanmorgen wilde ik mijn development omgeving starten. We maken gebruik van Traefick ( latest ) en diverse andere containers die via labels zich kenbaar maken aan Traefick. Dat heeft altijd gewerkt als een tierelier. Nu draai ik elke ochtend een apt update etc en daarna werkte traefik discovery ineens niet meer lekker.

Na wat gerommel kwam ik dit tegen in de logs

1.24 is too old. Minimum supported API version is 1.44

Wat ik echter gek vind

1. Ik heb traefik latest image (docker compose file )
2. Docker versies zijn up to date ( beide v29, zowel client als server )
3. Het setten van de api version naar 1.24 wat volgens sommige bronnen zou werken zorgt er alleen maar voor dat heel docker er mee stopt (wat ergens logisch is )

Iemand enig idee wat hier nu aan te doen anders dan downgraden?

blijkbaar meerdere mensen last van: https://community.traefik...ld-api-version-1-24/29019

[ Voor 6% gewijzigd door Webgnome op 11-11-2025 08:43 ]

[DjoeC]

@Webgnome Docker is verhoogd naar versie 29.0 en die vereist minimaal API 1.44 (al bijna 2 jaar beschikbaar, huidige versie 1.51). Er zijn meer container images die "last" hebben van dit requirement, ikzelf met Portainer. De momenteel "aanbevolen" oplossing is om docker naar de laatste 28.x versie voor jouw platform te downgraden.

Ik blijf bij de nieuwe Docker versie en ga langzaam afscheid nemen van Portainer, dit is de 2e keer dat ze niet goed op niveau zitten en de boel gewoon klapt.........

[ed1703]

Webgnome schreef op dinsdag 11 november 2025 @ 08:37:
Heeft iemand wel eens het volgende gehad?
Vanmorgen wilde ik mijn development omgeving starten. We maken gebruik van Traefick ( latest ) en diverse andere containers die via labels zich kenbaar maken aan Traefick. Dat heeft altijd gewerkt als een tierelier. Nu draai ik elke ochtend een apt update etc en daarna werkte traefik discovery ineens niet meer lekker.

Na wat gerommel kwam ik dit tegen in de logs

[...]


Wat ik echter gek vind

1. Ik heb traefik latest image (docker compose file )
2. Docker versies zijn up to date ( beide v29, zowel client als server )
3. Het setten van de api version naar 1.24 wat volgens sommige bronnen zou werken zorgt er alleen maar voor dat heel docker er mee stopt (wat ergens logisch is )

Iemand enig idee wat hier nu aan te doen anders dan downgraden?

blijkbaar meerdere mensen last van: https://community.traefik...ld-api-version-1-24/29019

Dit dus getest?

code:

systemctl edit docker.service
Add this part above the line ### Lines below this comment will be discarded:
[Service]
Environment=DOCKER_MIN_API_VERSION=1.24
Save the file and exit
systemctl restart docker

Zonder heel erg belerend over te willen komen: Ik zou een beetje oppassen met de laatste versie willen draaien als er BREAKING CHANGES en ook geen CVE's in de Release Notes staan. Watchtower van containrrr zou ik sowieso vervangen voor iets anders voor degenen die dat draaien: https://github.com/nicholas-fedor/watchtower is misschien een optie.

Ben benieuwd of github gaat overstromen met issues die hieraan gerelateerd zijn.

[Webgnome]

ed1703 schreef op dinsdag 11 november 2025 @ 11:32:
[...]

Dit dus getest?

code:

systemctl edit docker.service
Add this part above the line ### Lines below this comment will be discarded:
[Service]
Environment=DOCKER_MIN_API_VERSION=1.24
Save the file and exit
systemctl restart docker

Zonder heel erg belerend over te willen komen: Ik zou een beetje oppassen met de laatste versie willen draaien als er BREAKING CHANGES en ook geen CVE's in de Release Notes staan. Watchtower van containrrr zou ik sowieso vervangen voor iets anders voor degenen die dat draaien: https://github.com/nicholas-fedor/watchtower is misschien een optie.

Ben benieuwd of github gaat overstromen met issues die hieraan gerelateerd zijn.

Er zit in de code van traefik een constante die de versie van de api hard op 1.24 forceert. Env variabelen hebben er dus geen vat op. Daar zit het probleem. Gelukkig was de fix makkelijk. Even terug naar een veilige versie van docker en het werkt weer

Deze specifieke 'fix' had ik niet getest als zodanig. Echter had ik al snel gevonden dat het kwam door een issue in een forcering van de versie van de api die Traefik verwacht. Dus heb ik uiteindelijk een vorige versie van Docker geinstalleerd. Even afwachten wat Traefik gaat doen de komende uren/dagen.

[ Voor 13% gewijzigd door Webgnome op 11-11-2025 13:27 ]

[RobertMe]

Webgnome schreef op dinsdag 11 november 2025 @ 12:43:
[...]


Er zit in de code van traefik een constante die de versie van de api hard op 1.24 forceert. Env variabelen hebben er dus geen vat op. Daar zit het probleem. Gelukkig was de fix makkelijk. Even terug naar een veilige versie van docker en het werkt weer

Volgens mij heb je de suggestie niet gelezen? Die gaat namelijk over een "aanpassing" aan Docker (door een env var te zetten), en jij hebt het vervolgens over de code van Traefik.
En dat Traefik een specifieke API versie vraagt lijkt mij ook logisch. Dat is dan de API versie waarop hun implementatie gebaseerd is. Een andere versie werkt misschien, maar zal niet getest zijn. En als Docker meerdere versies ondersteund zou het gek zijn als de client ook weer met meerdere versies geschikt zou moeten kunnen zijn.

Overigens vind ik het ook bijzonder om op een ontwikkelomgeving elke dag de aller laatste (bleeding edge) versie te draaien. En vervolgens uren aan de baas zijn tijd weg te gooien hierdoor.

[orvintax]

Webgnome schreef op dinsdag 11 november 2025 @ 12:43:
[...]


Er zit in de code van traefik een constante die de versie van de api hard op 1.24 forceert. Env variabelen hebben er dus geen vat op. Daar zit het probleem. Gelukkig was de fix makkelijk. Even terug naar een veilige versie van docker en het werkt weer

Dit is tevens geen Traefik only probleem. Ik heb Docker op mijn dev machine ook (per ongeluk) bijgewerkt en nu kan Intellij ook niet meer verbinden met dezelfde error message.

[Webgnome]

@RobertMe ja klopt, sorry my bad. Ik had er te snel overeen gelezen. Heb uiteindelijk een vorige versie van Docker geinstalleerd ( de vorige ) waardoor het nu nog wel werkt.

Dat ze tegen een specifieke versie aan willen praten snap ik, echter is dat het probleem van Traefik, niet van docker. Immers als ik naar de versie kijk die ze ondersteunden ( Traefik ) dan is dat een heel oude versie. We zitten inmiddels op 1.4x ? Om dan 1.24 nog te ondersteunen lijkt mij een beetje in de categorie ' zo lang het werkt hebben we het er niet over ' vallen.

En over je offtopic, dat is niet relevant aangezien het echt zeer zelden fout gaat. En juist dit soort dingen wil ik ver van te voren aan zien komen. Het alternatief is omdat op staging/test te doen en daar uren kwijt te zijn. Die uren, die ben je toch kwijt.

[ Voor 19% gewijzigd door Webgnome op 11-11-2025 13:30 ]

[DjoeC]

Het is een probleem in veel container images MAAR dat maakt t nog geen Docker probleem. 1.44 (laagst ondersteunde API versie) was er al in januari 2024. Als ontwikkelaars moet je toch een beetje bij de tijd blijven lijkt me, 2 jaar oud is tegenwoordig een eeuwigheid met bijkomende risico's...... En als Docker ouwe meuk moet blijven ondersteunen zal dat vooruitgang en/of refactoring hinderen, nog los van alle extra testwerk op ouwe meuk.....

De vraag is alleen of containerbouwers "leren" danwel of ze liever met hun eigen nieuwe functionaliteiten bezig zijn. Een API upgrade is werk maar levert geen onmiddellijke zichtbare verbetreringen.

@Webgnome Huidige API versie is 1.51 of misschien bij Docker 29.0 1,52 maar dat zie ik niet in de documentatie .

[ Voor 8% gewijzigd door DjoeC op 11-11-2025 13:42 ]

[Mars Warrior]

Zit er in Docker 28.x een depricated logmelding t.a.v. de API versie?

Meestal is dat namelijk de harde waarschuwing over een aankomende breaking change.

[S1NN3D]

Ik had ook problemen met Docker 29 na de update daarnaartoe van mijn Ubuntu Server VM. De API 1.24 fix werkte deels. Mijn NextcloudAIO-containers werkten daarna nog altijd niet; bleef hangen omdat de OnlyOffice container niet meer startte. Voor nu alles opgelost door de backup van de VM terug te zetten.

[Freee!!]

DjoeC schreef op dinsdag 11 november 2025 @ 13:35:
Het is een probleem in veel container images MAAR dat maakt t nog geen Docker probleem.

Wat het wel een Docker probleem maakt voor mij is dat de melding

1.24 is too old. Minimum supported API version is 1.44

geen naam van een image en/of container geeft.

[Mars Warrior]

Freee!! schreef op woensdag 12 november 2025 @ 11:31:
[...]
Wat het wel een Docker probleem maakt voor mij is dat de melding
[...]
geen naam van een image en/of container geeft.

Je zult in de logging van de services moeten kijken of je daar een foutmelding ziet.

Overigens blijken heeeeeeeeeeeeeeeeeeeeeeeeeel veel apps de API versie gewoon hard gecodeerd te hebben (vaak 1.24) ipv via de AutoNegotiate functie te doen.

Traefik is er gelukkig mee bezig...om dit voor eens en altijd te fixen.

Als je overigens op internet zoekt naar dit soort problemen met API versies, dan is dit een rinse-and-repeat

[Mars Warrior]

In ander nieuws, je weet wel die CrowdSec containers enzo

Gedistribueerde aanvallen op al mijn domeinen:
Ik zie steed meer patronen: hieronder een massieve aanval op al mijn domeinen vanuit AMAZON 02, maar wel allemaal uit een ander land, en allemaal een "vpatch" actie van CrowdSec AppSec die inline gefixed wordt, en dus geen decision/ban geeft (Remedie is false). Deze kunnen op die manier dus terug blijven komen...



CIDRAM blocklist geeft 90-95% dekking op eigen banlijst:
Verder nog wat geexperimenteerd met bestaande blocklists. Ik heb nu de CIDRAM lijsten gevonden, en dan blijkt als ik een grepcidr doe met mijn eigen banlijst dat die CIDRAM lijsten 90-95% dekking geven: oftewel alles wat bij mij ongeveer langskomt zijn de "usual suspects".

Als ik dus de CIDRAM lijst(en) zou inladen - circa 60.000 ip adressen/ranges - dan zou ik nog max 5-10% van de alerts/decisions overhouden

Aan de andere kant: CrowdSec met een ban van 24 dagen doet het ook goed (242 bans and counting)
Nog even en de IP adressen zijn op van de botjes



En verder blij dat ik maar af en toe handmatig bijwerk nu ik de gevolgen zie van Docker v29, een versie waar ik wel naar uitkeek vanwege de native support van NFtables

[DjoeC]

Freee!! schreef op woensdag 12 november 2025 @ 11:31:
[...]

Wat het wel een Docker probleem maakt voor mij is dat de melding
[...]
geen naam van een image en/of container geeft.

Huh? Die melding staat bij mij in het log van de container die niet werkt.... Als jij daar meer images in hebt moet je toch effe zoeken.

[DjoeC]

Mars Warrior schreef op woensdag 12 november 2025 @ 12:01:
[...]
Als je overigens op internet zoekt naar dit soort problemen met API versies, dan is dit een rinse-and-repeat

Helaas zijn niet alle (opensource) bouwers mensen met een "been there, done that" ervaring. Na een aantal jaren weet je waar je je een keer flink aan gaat branden. En hard coderen is er 1 van, niet testen tegen de "RC's" van je basis (noem docker maar het OS) is een andere..... Maar, t scheelt wel veel tijd die je aan nieuwe features kunt besteden.... Geen betere tester dan je eindgebruiker

[Freee!!]

DjoeC schreef op woensdag 12 november 2025 @ 13:46:
[...]
Huh? Die melding staat bij mij in het log van de container die niet werkt.... Als jij daar meer images in hebt moet je toch effe zoeken.

Ik kreeg die melding in veelvoud in de mail

[DjoeC]

Freee!! schreef op woensdag 12 november 2025 @ 13:54:
[...]

Ik kreeg die melding in veelvoud in de mail

Gelukkig krijg ik (nog) geen mails van elke melding. Da's misschien een toekomstig traject..... Portainer wilde niet correct werken en dus keek ik mbv Dozzle effe snel in het container log.

[Freee!!]

DjoeC schreef op woensdag 12 november 2025 @ 13:57:
[...]
Gelukkig krijg ik (nog) geen mails van elke melding. Da's misschien een toekomstig traject..... Portainer wilde niet correct werken en dus keek ik mbv Dozzle effe snel in het container log.

Ik kijk niet elke dag in Portainer, mail komt automagisch binnen. Blijkbaar gebruikt de mailing-container dus wel de juiste versie.

[Mars Warrior]

DjoeC schreef op woensdag 12 november 2025 @ 13:51:
[...]
Helaas zijn niet alle (opensource) bouwers mensen met een "been there, done that" ervaring. Na een aantal jaren weet je waar je je een keer flink aan gaat branden. En hard coderen is er 1 van, niet testen tegen de "RC's" van je basis (noem docker maar het OS) is een andere..... Maar, t scheelt wel veel tijd die je aan nieuwe features kunt besteden.... Geen betere tester dan je eindgebruiker

Ik snap je punt, maar Traefik is geen hobby clubje in deze.

Verder had ik van Docker verwacht dat ze in v28 toch wel depricated meldingen zouden geven om mensen wakker te maken. Dat hoefrt dan niet de bouwer te zijn, maar een gebruiker kan daarop ook een bug report inschieten. Dan helpen we elkaar tenminste.

Nu lijkt dat niet gedaan te zijn, waardoor alles bij een simpele apt update of docker pull vastloopt.

[DjoeC]

Mars Warrior schreef op woensdag 12 november 2025 @ 14:07:
[...]

Ik snap je punt, maar Traefik is geen hobby clubje in deze.

Verder had ik van Docker verwacht dat ze in v28 toch wel depricated meldingen zouden geven om mensen wakker te maken. Dat hoefrt dan niet de bouwer te zijn, maar een gebruiker kan daarop ook een bug report inschieten. Dan helpen we elkaar tenminste.

Nu lijkt dat niet gedaan te zijn, waardoor alles bij een simpele apt update of docker pull vastloopt.

Eens, en ik beweer zeker niet dat projecten zoals Traefik door een "hobby" clubje gemaakt zijn..... Dezelfde issues doen zich voor in organisaties zoals het UVW (vergeten certificaat te vernieuwen??? ) of banken of wat dan ook. Al doende leert men door de neus te stoten.

Ja, Docker had wel wat duidelijker mogen zijn in de voorbereiding (en mogelijk is er op github wel iets te vinden) maar goed.... Dat je zoals portainer hard gecodeerd 1.41 gebruikt (introductie docker 20.10) terwijl 1.51 de cuurent is (docker 28.3) vind ik wel iets van, dan heb je het versie beheer op je componenten niet op orde.

[ed1703]

Mars Warrior schreef op woensdag 12 november 2025 @ 14:07:
[...]

Ik snap je punt, maar Traefik is geen hobby clubje in deze.

Verder had ik van Docker verwacht dat ze in v28 toch wel depricated meldingen zouden geven om mensen wakker te maken. Dat hoefrt dan niet de bouwer te zijn, maar een gebruiker kan daarop ook een bug report inschieten. Dan helpen we elkaar tenminste.

Nu lijkt dat niet gedaan te zijn, waardoor alles bij een simpele apt update of docker pull vastloopt.

Tja, als ontwikkelaar en beheerder hoor je bij zoiets belangrijks als moby->docker de release-notes te lezen voordat je een major-release gaat installeren. Ik ben het deels wel met je eens hoor, maar hoeveel keer en op hoeveel plekken moet men het dan wel niet neerzetten?

[Mars Warrior]

ed1703 schreef op woensdag 12 november 2025 @ 14:52:
[...]

Tja, als ontwikkelaar en beheerder hoor je bij zoiets belangrijks als moby->docker de release-notes te lezen voordat je een major-release gaat installeren. Ik ben het deels wel met je eens hoor, maar hoeveel keer en op hoeveel plekken moet men het dan wel niet neerzetten?

Het gaat er ook om dat je anderen ruim de tijd geeft om alvast een compatibele versie uit te brengen. Dat gaat vaak niet ff in een weekje ofzo.

Talen als PHP en Python geven vaak al 6 maanden van te voren depricated meldingen. En dat is ook niet voor niets. Home Assistent doet dat ook. En dat enkel om andere ontwikkelaars ruim de tijd te geven om hun software aan te passen.

Het is allemaal echt niet zo moeilijk om elkaar te informeren vanuit de container zelf.

Ook in bedrijfsomgevingen is het nodige omgevallen hoorde ik van collega’s. Ook die gingen ervan uit dat alle containers allang waren bijgewerkt op de wijzigingen in de API.

[ed1703]

Mars Warrior schreef op woensdag 12 november 2025 @ 15:16:
[...]

Het gaat er ook om dat je anderen ruim de tijd geeft om alvast een compatibele versie uit te brengen. Dat gaat vaak niet ff in een weekje ofzo.

Deprecate legacy API versions
Deprecated in release: v25.0

Target for removal in release: v26.0

The Docker daemon provides a versioned API for backward compatibility with old clients. Docker clients can perform API-version negotiation to select the most recent API version supported by the daemon (downgrading to and older version of the API when necessary). API version negotiation was introduced in Docker v1.12.0 (API 1.24), and clients before that used a fixed API version.

Use of old API versions is very rare, and support for legacy API versions involves significant complexity (Docker 1.0.0 having been released 10 years ago). Because of this, we'll start deprecating support for legacy API versions.

Eigenlijk had men dus al sinds januari 2024 kunnen weten dat men langzamerhand afscheid zou gaan nemen van legacy API versions. Geheel te wijten aan het niet lezen van Release Notes door het Traefik team

[synoniem]

ed1703 schreef op woensdag 12 november 2025 @ 16:04:
[...]


[...]

Eigenlijk had men dus al sinds januari 2024 kunnen weten dat men langzamerhand afscheid zou gaan nemen van legacy API versions. Geheel te wijten aan het niet lezen van Release Notes door het Traefik team

Of een gevalletje van een regression.

[DjoeC]

synoniem schreef op woensdag 12 november 2025 @ 16:21:
[...]

Of een gevalletje van een regression.

Mwah, als je 10 of meer versies van de (een, welke dan ook) API achterloopt zie ik dat niet zomaar als regressie..... Ik ben gewend: Actueel + -1 wordt ondersteund, -2 gaat eruit zodra er een nieuwe beschikbaar is. MAAR niet meer dan 1 nieuwe API main versie per jaar. Doe je dit niet dan kom je nooit van ouwe meuk af. Maar, dit hoort meer in software ontwikkeling thuis

[Mars Warrior]

ed1703 schreef op woensdag 12 november 2025 @ 16:04:
[...]
[...]
Eigenlijk had men dus al sinds januari 2024 kunnen weten dat men langzamerhand afscheid zou gaan nemen van legacy API versions. Geheel te wijten aan het niet lezen van Release Notes door het Traefik team

Oja. Die aankondiging is al zo oud als de weg naar Rome.

Maar wat ik dan had verwacht in v25 zijn die deprecated meldingen bij elke keer verbinden of dingen opvragen. Nu lijkt er namelijk niks aan de hand.

Dat het slordig is van het Traefik team is zeker. Ze hadden al 2 jaar geleden op de version negotiation aanpak moeten zitten. Dan heb je geen gezeik meer.

Achteraf heel vreemd dat je één van je belangrijkste ecosystemen van je product niet in de gaten houdt.

[ Voor 7% gewijzigd door Mars Warrior op 12-11-2025 18:52 ]

[babbelbox]

Ik ben ook een actieve gebruiker van Docker, en zo ook o.a. van Traefik.
Toen ik de laatste berichten tegen kwam heb ik 1 van mijn test raspberries direct geüpdatet en (zoals verwacht) werkte Traefik niet meer.
D.m.v. de tip van ed1703 werkte eigenlijk alles weer.
Toch was ik nieuwsgierig naar hoe dit dan allemaal zit, in het verleden weinig aandacht aan besteed.
Naast Traefik en wat functionele containers draai ik ook de docker-socket-proxy container van Tecnativa.
Als ik daar door de beschrijving heen scroll staat redelijk onderaan een lijstje met supported API's.
Daar staat ook al geen 1.24 meer tussen.....
Terwijl het wel gewoon werkt.
Ik ben daarna eens in de logs van die docker socket proxy gedoken en daar zie ik 2 verschillende calls voorbijkomen. Vanaf m'n telegraf container zie ik allemaal /v1.51/ calls en vanaf Traefik zie ik allemaal /v1.24/ calls.
Toch handig dat die versie 1.24 wel werkt, ondanks dat die niet supported is in de docker socket proxy

[S1NN3D]

https://github.com/traefik/traefik/releases/tag/v3.6.1

Er is een nieuwe release van Traefik die de problemen met Docker 29 zouden moeten oplossen. Heb er nu ff zelf geen tijd voor dus in het weekend pas testen. Maar leek me handig om deze 3.6.1 hier ff te melden.

[Webgnome]

Morgen even testen. Thanks voor de update

[babbelbox]

Voor zover ik kan vinden is de docker image nog niet geüpdatet.
Die haalt nog steeds 3.6.0 binnen.

[RobertMe]

babbelbox schreef op donderdag 13 november 2025 @ 23:02:
Voor zover ik kan vinden is de docker image nog niet geüpdatet.
Die haalt nog steeds 3.6.0 binnen.

Staat intussen een minuutje op Docker Hub

[babbelbox]

Hier werkt het weer zonder de aanpassing aan de docker service

[RobertMe]

Wel "leuk" om image updates te laten doen door Renovate en deze ook te reviewen in bepaalde mate. Blijkt dat een image ineens gebuild wordt met daarin cups-libs. Like, best raar, waarom een container die iets op netwerk doet en een web interface exposed ineens libraries voor te printen binnen trekt. Even verder kijkende blijkt dat ook qt6-qtbase-x11 als package is toegevoegd. Wat ook meteen verklaard waarom een hele shitload aan andere packages is toegevoegd (wayland, libx...). Maar eens op Docker Hub kijken, en image size van vorige (patch) versie was 82MB, huidige image is 186MB. * oeps * (da's geen typo, maar daadwerkelijk een 100MB toename) Toch deze versie maar eens even over slaan. En uiteraard netjes een bug report aangemaakt.

[DjoeC]

Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

[Mars Warrior]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

Nope, doet wel wat met de API versie, maar niet dat...

• Docker image list now considers the NO_COLOR environment variable for choosing the colored output. docker/cli#6654
• docker images no longer truncates the name width when output is redirect (e.g. for grep). docker/cli#6656
• containerd image store: Fix a bug causing docker build to ignore the explicitly set unpack image exporter option. moby/moby#51514
• Fix a bug causing docker image list --all to not show untagged/dangling images. docker/cli#6657
• Fix build on i386. moby/moby#51528
• Fix explicit graphdriver configuration ("storage-driver") being treated as containerd snapshotter when prior graphdriver state exists. moby/moby#51516
• Fix output format of the ApiVersion and MinApiVersion fields in docker version --format=json to align with previous versions. docker/cli#6648

[babbelbox]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

Dat zou ik best bijzonder vinden. Er lijkt me genoeg tijd geweest voor ontwikkelaars om aanpassingen te maken in de containers die compatibel zijn met de nieuwere API version.
Zomaar een een obsolete versie weer herintroduceren is niet echt een te verwachten gebeurtenis.

[sjorsjuhmaniac]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

ipv op updates te wachten van de verschillende projects kan je de Min API versie kan je eenvoudig forceren in je daemon config, op debian-achtige systemen kan dat simpel via systemctl

Bash:

$ systemctl edit docker.service

paste dit in the juiste gedeelte bovenaan:

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

En restart de daemon

Bash:

$ systemctl restart docker

Ik liep er bv met portainer tegenaan.

[DjoeC]

sjorsjuhmaniac schreef op zondag 16 november 2025 @ 10:54:
[...]


ipv op updates te wachten van de verschillende projects kan je de Min API versie kan je eenvoudig forceren in je daemon config, op debian-achtige systemen kan dat simpel via systemctl

Bash:

$ systemctl edit docker.service

past dit in the juiste gedeelte bovenaan:

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

En restart de daemon

Bash:

$ systemctl restart docker

Die workaround had ik inmiddels al uitgevoerd, die werkt ook. Maar ik blijf het vreemd vinden dat zoveel projecten zo ontzettend veel api versies achterlopen....

[Mars Warrior]

Omdat mijn CrowdSec firewall projectje wel lekker draait - nog maar gemiddeld 8 bans per dag - en het nu telkens nieuwe IP adressen zijn, dus het-is-wat-het-is, had ik verder zitten neuzen naar wat leuks.

Ik kwam zodoende dockur tegen: een docker container gebaseerd op qemux, maar dan helemaal aangepast zodat deze geheel automagisch Windows kan downloaden/installeren/draaien alsof het een normale docker container is (dus volumes, environment, macvlan etc).

Wel grappig om te zien dat Windows XP maar 0,6GB is en Windows 11 iets van 7GB is.
Alle images worden dus legaal van Microsoft gedownload: je hebt dus ook gewoon een licentie nodig.

Vanzelfsprekend kun je ook alle Linux OSsen draaien.

Dus ook hiervoor heb je geen Proxmox meer nodig. Voor mij kan dit nog wel eens handig zijn als ik een VM toch niet helemaal lekker in een container gedraaid krijg, al loop je natuurlijk direct wel tegen typische VM zaken aan als reserveren van RAM enzo.

Je moet met Windows 11 wel ff geduld hebben, en vervolgens wel met RDP connecten, want de standaard browser interface is bietje traag en lage resolutie

[DjoeC]

Mars Warrior schreef op maandag 17 november 2025 @ 14:23:
Ik kwam zodoende dockur tegen: een docker container gebaseerd op qemux, maar dan helemaal aangepast zodat deze geheel automagisch Windows kan downloaden/installeren/draaien alsof het een normale docker container is (dus volumes, environment, macvlan etc).

Wel grappig om te zien dat Windows XP maar 0,6GB is en Windows 11 iets van 7GB is.
Alle images worden dus legaal van Microsoft gedownload: je hebt dus ook gewoon een licentie nodig.

Vanzelfsprekend kun je ook alle Linux OSsen draaien.

Je moet met Windows 11 wel ff geduld hebben, en vervolgens wel met RDP connecten, want de standaard browser interface is bietje traag en lage resolutie

Grappig, ik zie dat het ook op ARM64 (raspberry) zou kunnen werken.... Alleen denk ik dat een Pi-5 met 8GB dan wat klein wordt anders dan om te proberen.....

[Mars Warrior]

DjoeC schreef op maandag 17 november 2025 @ 15:11:
[...]
Grappig, ik zie dat het ook op ARM64 (raspberry) zou kunnen werken.... Alleen denk ik dat een Pi-5 met 8GB dan wat klein wordt anders dan om te proberen.....

Het zijn dan wel ARM images, dus geen idee of die kleiner zijn dan de x86 images.

[DjoeC]

Mars Warrior schreef op maandag 17 november 2025 @ 15:55:
[...]

Het zijn dan wel ARM images, dus geen idee of die kleiner zijn dan de x86 images.

Ik dacht meer aan de dan te installeren Windows en de performance daarvan. Dan denk ik dat een raspi desktop in Docker (in mijn geval...) een betere optie is. Ik draai OMV op de kale versie want OMV gaat niet samen met de raspi desktop maar OMV heeft voor mij als "minder deskundige" best een hoop voordelen.....