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

[alex3305]

orvintax schreef op woensdag 2 april 2025 @ 22:23:
Cool! Was verder ook geen kritiek, is meer mijn eigen mening/voorkeur.

Zo pakte ik het ook niet op . Maar ik weet van mezelf dat ik soms wat snel kan gaan. Vooral als ik enthousiast ben . Dan mis ik nogal eens wat details die wellicht voor mij voor de hand liggend zijn.

Ik kom er nu ook pas achter dat Watchtower een beetje dood lijkt te zijn qua maintainers. Verder vind ik het ook een goede dat je Renovate laat comitten met de Renovate Bot gegevens. Bij mij is dit nu nog gewoon mijn persoonlijke account. Maar nu zie ik er wel als heel actieve developer uit.

Op zichzelf hoeft het natuurlijk niet zo'n probleem te zijn als een project maar werkt. Maar ik vind het bij Watchtower toch wel een risico. Het is toch een container die (waarschijnlijk) toegang heeft tot de Docker socket en daarmee dus feitelijk ook beheerrechten heeft. Ik heb daar dan toch ook niet zo'n denderend gevoel over. Vooral niet als het project dan dood lijkt .

Om de Docker labels vanuit Caddy uit te lezen gebruik ik bijvoorbeeld ook Docker Socket Proxy zodat ik enerzijds het gevoel heb wat toegangscontrole toe te passen en anderzijds zodat ik de Docker socket van andere systemen zo eenvoudig kan benaderen. Een waarom een gevoel? Omdat het ook weer een extern stukje software is.

[alex3305]

Yarisken schreef op woensdag 2 april 2025 @ 23:51:
Bedankt voor de tip Alex.
Mijn dhcp begint vanaf 192.168.0.100 dus alles daaronder kan ik statisch gebruiken.
Ik ga er is mee testen.

Als je gaat testen heb je de poortmapping zoals @Airw0lf boven aangeeft dus ook niet meer nodig. Het is immers analoog aan een host network maar dan met een eigen ip.

Ik ga ook is kijken naar een reverse proxy. Nog nooit mee gespeeld.

Mooi om te starten is Nginx Proxy Manager als je graag een GUI wilt of Caddy als je wat meer comfortabel bent met configuratiebestanden.

Het prettige van een reverse proxy is dat je dan op één plek TLS termination kunt doen voor je domeinnaam, bijvoorbeeld met Let's Encrypt. Daarnaast kun je onder water aanpassingen maken aan de configuratie terwijl het endpoint gelijk blijft. Toen ik bijvoorbeeld van poort mapping in het bridge netwerk naar ipvlan migreerde, merkte ik daar niets van. Uiteindelijk bleef (bijvoorbeeld) de url nog steeds: home.example.com. In de reverse proxy ging echter de toewijzing van (pseudo-code):

Diff:

home.example.com {
-   reverse_proxy http://192.168.1.2:8084
+   reverse_proxy http://192.168.1.40:8123
}

En idem toen ik van ipvlan naar een intern Docker (Swarm) overlay netwerk ging:

Diff:

home.example.com {
-   reverse_proxy http://192.168.1.40:8123
+   reverse_proxy http://10.0.4.47:8123
}

Dat zorgt er ook voor dat je geen IP + poortmapping meer hoeft te onthouden, maar simpelweg naar een URL kunt surfen . Dat zorgt ook voor een stukje gemoedsrust. Vanuit daar kun je dan ook bouwen aan bijvoorbeeld authenticatie en autorisatie wanneer dat gewenst is.

[Zenyatta]

Heb op mijn NAS (DS920+) de instructies gevolgd van Mariushosting om Navidrome te installeren. Dat lijkt goed gegaan, behalve dan dat Navidrome geen muziek kan vinden. Hij lijkt niets te zoeken en dus ook geen muziek te kunnen inladen. Iemand een idee of ik dan verkeerd heb geinstalleerd, of dat ik ergens een obvious fout heb gemaakt? Ben niet heel goed thuis in de dockers etc. maar kom ook niet helemaal uit een ei.

Mijn doel is om via een andere muziekspeler dan DS Music mijn muziek te spelen, want DS Music is kortgezegd gewoon ruk. Loopt vaak vast en is niet werkbaar met Android Auto. Dus mijn muziek moet op een andere manier dan dat...

[alex3305]

@Zenyatta Ik denk dat het handig is als je ook even je configuratie deelt .

[Zenyatta]

@alex3305 , wat bedoel je precies?

Heb met de volgende code geinstalleerd:
services:
navidrome:
container_name: Navidrome
image: deluan/navidrome
mem_limit: 6g
cpu_shares: 1024
security_opt:
- no-new-privileges:true
restart: on-failure:5
ports:
- 4533:4533
volumes:
- /volume1/docker/navidrome:/data:rw
- /volume1/pad/naar/muziek:rw
environment:
PUID: 1024
PGID: 100
ND_ENABLEINSIGHTSCOLLECTOR: false

En eerder ook al via deze instructie maar met hetzelfde resultaat:

[Ghoulli]

Navidrome is eigenlijk niks anders dan een programma wat de muziek voor je af kan spelen. Als je al muziek op jouw server hebt staan hoef jij alleen de map van jouw muziek te mappen. Dit kan, volgens mij, Navidrome niet uit zichelf. Hier heb je wat andere, extra dingen voor nodig.

Zo als volgt:
Lidarr - De backbone van de gehele operatie. In Lidarr kun je zoeken naar verschillende artiesten en albums en deze toevoegen aan jouw library. Om de files om te downloaden te vinden heeft Lidarr een Indexer nodig. Deze Indexer, in mijn geval voor Usenet maar kan ook een torrent indexer zijn, moet toegevoegd worden in Lidarr.

Indexer - De Indexer is niks anders dan een groot telefoonboek waarin alle mensen staan die voor jou het album of de artiest hosten naar het internet.

Nadat de Indexer aan Lidarr is toegevoegd moet je een download client hebben. Dit kan NZBGet zijn voor Usenet of qBittorrent voor Torrents. Torrents zijn makkelijker, daar hoef je verder niks voor in te stellen. Bij Usenet (NZBGet) werkt het als volgt: Je hebt een News-server nodig. Deze News-Server vist voor jou de bestanden van het Usenet en plaatst deze in jouw download client, waardoor jij ze vervolgens ook kunt downloaden. Een News-server wordt ook wel een Provider genoemd.

Nadat de bestanden gedownload zijn van de Provider worden deze geplaatst in een map zoals aangegeven in Lidarr. Deze map koppel je aan Navidrome (/pad/naar/muziek) en dan kun je via Navidrome naar je muziek luisteren.

[gijpie]

- /volume1/pad/naar/muziek:rw

Heb je dit aangepast naar het daadwerkelijke pad naar je muziek? Buiten dat map je volgens mij naar niks in je docker container :rw geeft alleen aan read/write. Daar moet ook nog iets als een pad in de container staan.

Eigenlijk zou er iets als volgt moeten staan: /path/to/your/music/folder:/music:rw Waar alles voor de dubbele punt het pad naar je muziekfiles op de NAS moet zijn en alles na de dubbele punt het pad in de container.

Zoiets dus: - /volume1/docker/navidrome/mijn_muziek:/music:rw

Zet je muziek dan in de mijn_muziek map en bij de instellingen in Navidrome selecteer je als bestandslokatie /music

Voor Android kies je een subsonic client zoals bijvoorbeeld substreamer

[ Voor 20% gewijzigd door gijpie op 07-05-2025 00:28 . Reden: android client toegevoegd ]

[Zenyatta]

Ghoulli schreef op dinsdag 6 mei 2025 @ 22:54:
Navidrome is eigenlijk niks anders dan een programma wat de muziek voor je af kan spelen. Als je al muziek op jouw server hebt staan hoef jij alleen de map van jouw muziek te mappen. Dit kan, volgens mij, Navidrome niet uit zichelf. Hier heb je wat andere, extra dingen voor nodig.

Zo als volgt:
Lidarr - De backbone van de gehele operatie. In Lidarr kun je zoeken naar verschillende artiesten en albums en deze toevoegen aan jouw library. Om de files om te downloaden te vinden heeft Lidarr een Indexer nodig. Deze Indexer, in mijn geval voor Usenet maar kan ook een torrent indexer zijn, moet toegevoegd worden in Lidarr.

Indexer - De Indexer is niks anders dan een groot telefoonboek waarin alle mensen staan die voor jou het album of de artiest hosten naar het internet.

Nadat de Indexer aan Lidarr is toegevoegd moet je een download client hebben. Dit kan NZBGet zijn voor Usenet of qBittorrent voor Torrents. Torrents zijn makkelijker, daar hoef je verder niks voor in te stellen. Bij Usenet (NZBGet) werkt het als volgt: Je hebt een News-server nodig. Deze News-Server vist voor jou de bestanden van het Usenet en plaatst deze in jouw download client, waardoor jij ze vervolgens ook kunt downloaden. Een News-server wordt ook wel een Provider genoemd.

Nadat de bestanden gedownload zijn van de Provider worden deze geplaatst in een map zoals aangegeven in Lidarr. Deze map koppel je aan Navidrome (/pad/naar/muziek) en dan kun je via Navidrome naar je muziek luisteren.

Maar Navidrome hoeft alleen de map met muziek te lezen en vervolgens te zorgen dat ik die elders af kan spelen. Downloaden is niet nodig, want de muziek staat al op mijn server.

gijpie schreef op woensdag 7 mei 2025 @ 00:18:
[...]


Heb je dit aangepast naar het daadwerkelijke pad naar je muziek? Buiten dat map je volgens mij naar niks in je docker container :rw geeft alleen aan read/write. Daar moet ook nog iets als een pad in de container staan.

Eigenlijk zou er iets als volgt moeten staan: /path/to/your/music/folder:/music:rw Waar alles voor de dubbele punt het pad naar je muziekfiles op de NAS moet zijn en alles na de dubbele punt het pad in de container.

Zoiets dus: - /volume1/docker/navidrome/mijn_muziek:/music:rw

Zet je muziek dan in de mijn_muziek map en bij de instellingen in Navidrome selecteer je als bestandslokatie /music

Voor Android kies je een subsonic client zoals bijvoorbeeld substreamer

Het pad heb ik aangepast naar de map waar mijn muziek staat opgeslagen. Zal het thuis nog eens nalopen en indien nodig anders instellen.

Via de browser kan ik Navidrome benaderen, daar zou het muziek ook moeten kunnen afspelen. Daar wordt niets gevonden. Substreamer had ik inderdaad al gedownload maar die vind dus vooralsnog ook niets.

Wordt vervolgd.

[gijpie]

Ik heb net nog eens gekeken op https://www.navidrome.org/docs/installation/docker/ en zoals ik begrijp is het default container pad /music en is dit niet aanpasbaar. Als je dit dus (na de dubbele punt) hebt aangepast dan zal Navidrome je muziek collectie niet vinden. Niet aanpassen dus, tenzij je de environment variabele hiervoor aanpast. Laat die toevoeging :rw ook lekker weg. Is niet perse nodig.
Nu er nog voor zorgen dat alles voor de dubbele punt correct is en Navidrome zou gewoon je files moeten vinden. Net zoals Substreamer

Omdat je Navidrome zonder problemen kan benaderen vanuit je browser lijkt de installatie op zich in orde en zit het probleem echt in de mapping van je files.

[Zenyatta]

De clue zat inderdaad in het verwijzen naar mijn mappen. Werkt als een zonnetje nu, in ieder geval op mijn eigen netwerk. Nu nog kijken hoe het buiten mijn netwerk gaat.

[gijpie]

Perfect man.

Volgende stap dan het installeren van een volgende docker container.

Kijk eens naar wg-easy (Wireguard) om een vpn tunnel op te zetten naar je server en zo je bestanden op je lokale ip adres te benaderen. Probleem bij mij is dat Android auto niet echt met een vpn verbinding om kan gaan.

Anders een subdomein registreren op b.v. duckdns (icm b.v. linuxserver/duckdns) en dan een reverse proxy installeren op je Nas bijvoorbeeld nginx proxy manager. Je zal dan wel je poorten 80 en/of 443 open moeten zetten.

Met Wireguard zal je ook een poort moeten openen maar dat is dan udp terwijl nginx een open tcp poort moet hebben.

Leuk om verder te klooien

[FLA NL]

Heb je voor Wireguard geen client waar je alleen Android Auto buiten je vpn verbinding om kan laten gaan? Zo heb ik het voor OpenVPN gedaan.

[ Voor 12% gewijzigd door FLA NL op 08-05-2025 22:08 ]

[gijpie]

Nog niet geprobeerd. Ben in de playstore alleen de officiele WG app tegen gekomen.

Ik los dit nu op met een cloudflare tunnel naar mijn server. Maar ik zal eens kijken wat er verder nog mogelijk is.

Dank je wel.

[Mars Warrior]

Ik zit inmiddels op 47 containers

De laatste aanwinst is Dawarich dat net als Immich Duits is.

Visualize your location history, track your movements, and analyze your travel patterns with complete privacy and control.

Dawarich is ooit begonnen als vervanger van Google Timeline.

Het is net als Immich - hoewel nog jonger - een complete App en goed verzorgt qua instelmogelijkheden en documentatie. Er is ook een iOS app, waarmee je netjes ook automatiseringen kunt instellen zodat bijv. als je je huis verlaat dat de tracking automatisch start en als je thuis komt weer stopt. De Home Assistant App is ook bruikbaar als GPS logger.

Dawarich kan ook foto's uit Immich weergeven op een route. Dat werkt bij mij nog niet lekker. Lijkt erop dat ik een Album ofzo daarvoor moet samenstellen in Immich.

Reverse geo lookup werkt op basis van een Photon container. Ook dat werkt goed. Ik heb nu enkel nl geladen ipv de hele wereld. Die laatste schijnt ca 200GB diskruimte in te nemen. Je kunt op dit ogenblik maar één land kiezen, dus het is 1 of alles

Het zijn totaal 4 containers voor Dawarich en 1 container voor Photon. Het neemt bij mij nu 2GB RAM in volgens de container stats van Portainer.

[ahbart]

gijpie schreef op donderdag 8 mei 2025 @ 22:11:
Nog niet geprobeerd. Ben in de playstore alleen de officiele WG app tegen gekomen.

Ik los dit nu op met een cloudflare tunnel naar mijn server. Maar ik zal eens kijken wat er verder nog mogelijk is.

Dank je wel.

Wg tunnel app werkt heel prettig

[Arosa]

Door de prijs/hardware verhouding onlangs een UGREEN NAS in gebruik genomen, dit heeft zo zijn plus en min-punten. Voor enkele minpunten middels Docker een prima oplossing voor elkaar gekregen, maar nog zoekende naar een goede foto-bibliotheek.

Immich wordt veel aangeraden, maar ik loop vast met mijn foto collectie van de afgelopen 15 jaar. Deze zit in een mappenstructuur en dat ik ik graag zou houden, maar daar is Immich niet op ingericht (schrijft zelfs de ontwikkelaar). Bovendien wil ik deze collectie toegankelijk hebben voor minimaal 2 gebruikers, maar eenvoudig een shared folder toevoegen is er niet bij (lijkt het).

In de ideale wereld wil ik 4 gebruikers hun Android-telefoon laten synchroniseren naar de nas, hier hoeft geen complexe mappenstructuur, in principe is een tijdlijn weergave ala Google Foto's of Immich prima. In principe is ook 1-richtingsverkeer prima, dus als een foto op de telefoon verwijderd wordt, is het prima dat deze op de nas blijft staan. Voor dat verkeer zijn er volgens mij prima apps, zoals Foldersync, daar verwacht ik wel uit te komen.

Maar welke Docker App is nu geschikt om een gedeelde foto bibliotheek (met foto's van de fotocamera) te hebben + een persoonlijke bibliotheek (met telefoonfoto's). En eventueel als bonus nog de optie om gezamenlijke albums te maken, van bijvoorbeeld alle vakantiefoto's?

Ik ken PhotoPrism, PiGallery2, Lychee, Plex Photo's, ... maar welke moet ik nu echt proberen? Of zijn er tips om Immich wel in te richten op de mijn wijze?

[Mars Warrior]

@Arosa je kunt Immich een externe foto bibliotheek laten gebruiken.

Doe ik ook. Dat zijn dus gewoon mappen met jaartallen en daaronder mappen met vakanties enzo.

Werkt gewoon.

[Arosa]

@Mars Warrior :

Kan je een hint geven wat ik verkeerd doe? Best al wat uurtjes gezocht op het internet, maar ik kom niet verder dan dit:

De shared folder krijg ik niet zichtbaar in Immich.

Heb jij ook meerdere gebruikers?

[Mars Warrior]

Arosa schreef op maandag 19 mei 2025 @ 22:48:
@Mars Warrior :

Kan je een hint geven wat ik verkeerd doe? Best al wat uurtjes gezocht op het internet, maar ik kom niet verder dan dit:
[Afbeelding] [Afbeelding] [Afbeelding] [Afbeelding]
De shared folder krijg ik niet zichtbaar in Immich.

Heb jij ook meerdere gebruikers?

Je moet het externe archief definieren.

Dit staat in mijn .env file:

code:

# Read only location of existing archive
EXTERNAL_ARCHIVE=/mnt/pool/Afbeeldingen/Archief

# The location where your uploaded files are stored
UPLOAD_LOCATION=/mnt/pool/Afbeeldingen/Upload

En in mijn compose file voor Immich:

code:

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    cpuset: $CPUSET_E_CORES_ALL
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - ${EXTERNAL_ARCHIVE}:/usr/src/app/archive
      - /etc/localtime:/etc/localtime:ro

En daarmee ziet Immich je bestaande archief

[Arosa]

Ik heb het voor elkaar gekregen, maar wel op een iets andere wijze:

code:

  volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - ${EXTERNAL_ARCHIVE}:/usr/src/app/archive
      - /volume1/Photos/Archief:/volume1/Photos/Archief:ro
      - /etc/localtime:/etc/localtime:ro

Nog meer verschillende websites geraadpleegd, verschillende oplossingen voorbij zien komen, na meerdere trail&errors tot deze werkende oplossing gekomen.

Ik denk wel dat ik de camera foto's een eigen account ga geven, zodat ik deze wat eenvoudiger aan en uit kan zetten en niet altijd tussen de tijdlijn staan.

[Arosa]

Vanwege de wat beperkte software van Ugreen, was Docker de beste optie om toch alles te kunnen doen.

Ik heb ondertussen de volgende Containers draaien:

• Duplicati
  Gemakkelijk in gebruik te nemen, nu nog een keer testen om zelf te ondervinden hoe betrouwbaar het is.
• Emby
  Net zo makkelijk en werkt prima om een bescheiden dvd-collectie voortaan digitaal te benaderen
• Immich
  Wat problemen gehad om de externe bibliotheek bereikbaar te krijgen, maar ondertussen ook bijna mijn complete collectie mobiele telefoonfoto's 'online'.
• Nginx
  Wat een hoop slechte en onvolledige instructies staan er op internet, dit heeft mij heel wat uurtjes en proberen gekost, maar uiteindelijk met de uitleg van MariusHosting het nu voor elkaar mijn Immich ook buiten de deur te bereiken.

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

[Mars Warrior]

Arosa schreef op zondag 25 mei 2025 @ 08:54:
Vanwege de wat beperkte software van Ugreen, was Docker de beste optie om toch alles te kunnen doen.

Ik heb ondertussen de volgende Containers draaien:

• Duplicati
  Gemakkelijk in gebruik te nemen, nu nog een keer testen om zelf te ondervinden hoe betrouwbaar het is.
• Emby
  Net zo makkelijk en werkt prima om een bescheiden dvd-collectie voortaan digitaal te benaderen
• Immich
  Wat problemen gehad om de externe bibliotheek bereikbaar te krijgen, maar ondertussen ook bijna mijn complete collectie mobiele telefoonfoto's 'online'.
• Nginx
  Wat een hoop slechte en onvolledige instructies staan er op internet, dit heeft mij heel wat uurtjes en proberen gekost, maar uiteindelijk met de uitleg van MariusHosting het nu voor elkaar mijn Immich ook buiten de deur te bereiken.

Nginx is ook niet bepaald het meest moderne programma om makkelijk websites te ontsluiten.
Dan is Caddy met de Caddy docker plugin factoren eenvoudiger. Niks geen moeilijke config, geen portmappings nodig en default alles SSL.

Voorbeeld ontsluiten Immich op zijn standaard poort 2283 in de docker compose file:

code:

   labels:
      caddy: immich.mijndomein.nl
      caddy.reverse_proxy: "{{upstreams 2283}}"

Dat is alles om Immich op https://immich.mijndomien.nl te kunnen bereiken

(Vanzelfsprekend moeten de poorten wel opengezet/geforward worden, maar dat is altijd nodig voor IPv4. Voor IPv6 dan weer niet: daar kun je gewoon een IPv6 adres icm poorten gebruiken die je firewall doorlaat)

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

Dat klinkt als een min-of-meer standaard Backup programma? Er zal zeker een Docker container voor zijn.

[Airw0lf]

Arosa schreef op zondag 25 mei 2025 @ 08:54:

[...]

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

Een cp -R in een cronjob?

[Airw0lf]

dubbele post => verwijderd

[ Voor 130% gewijzigd door Airw0lf op 25-05-2025 10:53 ]

[RobertMe]

Mars Warrior schreef op zondag 25 mei 2025 @ 10:05:
(Vanzelfsprekend moeten de poorten wel opengezet/geforward worden, maar dat is altijd nodig voor IPv4. Voor IPv6 dan weer niet: daar kun je gewoon een IPv6 adres icm poorten gebruiken die je firewall doorlaat)

Hoe noem je dat? Als het blijkbaar niet "open zetten" is? Bij IPv6 is het juist alleen open zetten, bij IPv4 open zetten + een DNAT (destination NAT) regel aanmaken. Maar de meeste consumenten routers zal het gewoon 1 actie zijn. (Als die consumenten router dit al ondersteund bij IPv6. In ieder geval schijnen er nogal wat provider modem/routers te zijn waarbij de firewall gebrekkige IPv6 support heeft en een poort openen/toestaan niet mogelijk is. Terwijl IPv4 port forwards prima mogelijk zijn).

[Mars Warrior]

RobertMe schreef op zondag 25 mei 2025 @ 10:28:
[...]
Hoe noem je dat? Als het blijkbaar niet "open zetten" is? Bij IPv6 is het juist alleen open zetten, bij IPv4 open zetten + een DNAT (destination NAT) regel aanmaken. Maar de meeste consumenten routers zal het gewoon 1 actie zijn. (Als die consumenten router dit al ondersteund bij IPv6. In ieder geval schijnen er nogal wat provider modem/routers te zijn waarbij de firewall gebrekkige IPv6 support heeft en een poort openen/toestaan niet mogelijk is. Terwijl IPv4 port forwards prima mogelijk zijn).

Veel modems noemen het nog steeds "Port Forwarding" om het voor de consument makkelijk te houden.
En qua support: zelfs de stokoude Experia V10 van de KPN ondersteunt dit: gewoon het poortnummer of de service (HTTP, HTTPS, etc) invoeren en je lokale device (drop-down lijst die op je netwerk kijkt voor het bijbehorende IPv6 adres bij dat device/server) selecteren en klaar ben je.

Vanzelfsprekend heb ik vaste IPv6 adressen toegekend aan mijn servers. Ik heb zo'n groot subnet van de KPN dat ik miljoenen servers/devices op mijn adres kan hebben. Vraag me niet waarom KPN zo'n groot subnet (64 bits) uitdeelt, maar goed.

[RobertMe]

Mars Warrior schreef op zondag 25 mei 2025 @ 11:01:
Vanzelfsprekend heb ik vaste IPv6 adressen toegekend aan mijn servers. Ik heb zo'n groot subnet van de KPN dat ik miljoenen servers/devices op mijn adres kan hebben. Vraag me niet waarom KPN zo'n groot subnet (64 bits) uitdeelt, maar goed.

offtopic:
Een /64 is niet groot. Het is maar de helft. En daarnaast is het de verplichte minimale subnet grote. Omdat er binnen IPv6 wat "formules" zijn om een willekeurige suffix te bepalen (op basis van het MAC adres) en dat dus uit gaat van 64 beschikbare bits.

En van KPN krijg je nog meer, je krijgt een /48. En je kunt vervolgens dus nog 16 bits gebruiken om eigen /64 subnets te maken (oftewel 65.536 subnets van /64). Bij Ziggo en veel andere ISPs krijg je dan maar weer een /56, en kun je dus "maar" 256 subnets van /64 groot maken.
Waarbij ook weer is vastgelegd dat /56 de minimale grote moet zijn voor (vaste) aansluitingen. (Op mobiel krijg je normaliter maar een /64, en kun je dus niet subnetten daar onder aanmaken, of in ieder geval als je wilt voldoen aan /64 als minimale subnet grote).

En uiteraard zijn vaste IPv6 adressen op een consumenten lijntje vaak niet echt vast. Immers heb je een dynamische prefix en als die wijzigt heb je een probleem.
Daarom gebruik ik naast de GUA (Globally Unique Address), een link local address ook nog ULA (Unique Local Address, fc00::/7 uit mijn hoofd meen ik dat daarvoor gereserveerd is). Dus bv VLAN 1 gebruikt fd00:1::/64 en VLAN 2 fd00:2::/64 etc. En waar nodig hebben apparaten daar dus echt een statistisch IP adres, onafhankelijk van of Ziggo mij een andere prefix, voor de GUA, geeft.

IPv6 en Docker is echter AFAIK nog steeds wel een dingetje dat wat aandacht verdiend. Zo zou ondersteuning voor DHCPv6-PD zeer welkom zijn. Zodat elke bridge / netwerk ook een pefix kan opvragen bij de DHCP server van de ISP die die dan gebruikt voor het subnet van de bridge (het algoritme om een suffix te genereren om basis van het MAC adres ondersteund die wel. Alleen moet je dus zelf bij het aanmaken van het netwerk ook meteen het subnet (/"prefix") vast leggen, en geeft de ISP je dan een nieuwe prefix moet je dus alle netwerken opnieuw aanmaken .

[Mars Warrior]

Om nog even in te gaan op IPv6 icm Docker en toegang tot containers die het "remote_ip" bepalen

Uitgangssitutatie:

• Al mijn apparaten hebben een vast IPv4 adres. Dat is al jaaaaaaaaaaaaaaaaaaaaaaaaaaaaren zo.
• Verder krijgen ze van de router (ik vermoed via SLAAC / Router Announcements) een IPv6 adres .

Ik heb mij namelijk suf zitten zoeken waarom:

• Sommige containers netjes het externe of lokale IP (altijd IPv4) vastleggen
• Anderen het IPv4 adres van de Docker Gateway van mijn Ingress Netwerk als "remote_ip" bepaalt.
• (meerdere).

Aan die laatste heb ik niks icm Fail2Ban natuurlijk. Besef dat ik Docker nog als IPv4 netwerk draai. IPv6 staat nog niet geenabled/geconfigureerd voor het Ingress Netwerk.

Op het internet is hier veel over te vinden icm Caddy en Docker. Ook ChatGPT vind er wat van, maar behalve een leuke uitleg over IPv6 en hoe je deze in Docker kunt aanzetten, wat ook in de Docker documentatie staat natuurlijk, komt er weinig zinnigs uit. Volgens ChatGPT kan ik namelijk IPv4 en IPv6 mixen

Verder zou Caddy - wederom volgens het almachtige orakel - enkel in "network=host" mode in staat zijn om correct het "X-Forwarded-For" veld in de header te vullen. Caddy zou ik dan achter een proxy moeten zetten zoals HAproxy en dan met het PROXY protocol moeten kletsen om het externe IP door te geven.

Afijn: mogelijk dat dat vroeger zo was met een oude Caddy/Docker versie, maar met de huidige in ieder geval niet, immers een aardig aantal containers krijgt wel degelijk het externe IP adres door van Caddy.
Mogelijk dat dit voor IPv6 wel is (nog niet getest), maar voor IPv4 aantoonbaar niet.

Maar ChatGPT bleef dat mantra volhouden, ondanks dat de feiten anders zijn. Ik denk daarom dat ChatGPT een vrouw is, maar dat terzijde.

Wat is nu het geval (TLDR):

• Als de externe DNS IPv4 only is, dan gaat het altijd goed!
• Als de externe DNS IPv4 én IPv6 adressen geeft, dan gaat het eigenlijk altijd fout: ik krijg het Docker Gateway adres als "remote_ip"

Ik vermoed dat als zowel IPv4 als IPv6 aanwezig is, dat het "moderne internet" voorgaat: er wordt dus gebruik gemaakt van een IPv6 adres.

Het lijkt er dus op dat Docker een "IPv6 -> IPv4 vertaling" doet ofzo en daarmee het gateway adres als "remote_ip" doorgeeft en/of vervangt.

Ik kon dat alleen niet in de documentatie vinden tot nu toe. En het grote boze internet inclusief het orakel ook niet, anders was ik er snel uitgeweest natuurlijk.

Het wordt dus nu testen met IPv6 om te achterhalen of het dan wel goed gaat

[RobertMe]

@Mars Warrior, ik heb geen idee wat nu precies het probleem is / wat je bedoelt?

Maar als ik je goed begrijp (externe IP in services achter Caddy zien een IPv4 adres van de Docker host / gateway van de Docker bridge?) dan lijkt de kans mij zeer groot dat de "docker proxy" (?) op de host draait die luistert op de exposed poort(en) voor IPv6 verkeer (of zelfs alle) en dat verkeer dan 1 op 1 door zet naar het container IP. Waardoor de container dus altijd een verbinding ziet vanaf de Docker host omdat de proxy de verbinding op zet en je dus een TCP verbinding tussen proxy op de host en de software in de container hebt.
Dit is een "techniek" die Docker al eeuwen altijd heeft gehad, als fallback voor als die de firewall niet kan beheren. Dan start die (per port mapping die je gedefinieerd hebt) gewoon een proxy die luistert op de externe poort (+ opgegeven IP als dat het geval is) en stuurt at verkeer 1 op 1 door naar de container (die die exposed port heeft).

En gezien IPv6 bij Docker nogal awkward is, en je bij IPv6 eigenlijk niks met DNAT (/port forwards / destination NAT) wilt doen, zal dit wel de enige optie zijn? Of in ieder geval is dit per definitie de enige optie als je enerzijds extern wilt luisteren op IPv6 en de container alleen IPv4 doet. Immers zijn IPv6 en IPv4 incompatible met elkaar. Je kunt niet een pakketje "herschrijven" naar een "andere bestemming" (DNAT dus) terwijl er een totaal andere IP versie gebruikt wordt. DNAT kan gewoon een veldje in de header aanpassen en klaar. Maar IPv6 en IPv4 zijn incompatible met elkaar, dus kom je uit op "software" die puur de data over zet (een TCP proxy dus).

Wat ik zelf echter doe is...:

1. Überhaupt Docker van mijn firewall af laten blijven (ik gebruik nftable, de iptables opvolger, en Docker kan alleen overweg met iptables of firewalld).
2. Geen exposed ports gebruiken (want anders start die de proxies, en dat wil ik niet)
3. Alle containers krijgen een static IP, waardoor ik dus zelf in de firewall de regels kan aanmaken
4. Alle containers krijgen een IPv6 adres (ook statisch) dat routeerbaar is (in mijn LAN is dat een ULA adres, op mijn VPS is dat een GUA adres)
5. Voor containers die via IPv4 bereikbaar moeten zijn maak ik in de firewall met de hand een DNAT regel aan (bv dus poort 80 binnenkomend op het WAN IP herschrijven naar poort 80 van de Traefik container).
6. Voor containers die via IPv6 bereikbaar moeten zijn maak ik in de firewall een (accept) forward regel aan, direct met "als destination het IP van de Traefik container is en de poort is 80 (of 443) dan accept").

En dat betekend bv dat ik in de Matomo container / logging van een publieke site dus ook prima (mangled / obfuscated) IPv6 adressen van bezoekers zie.

---

Oh, en ja, IPv6 krijgt de voorkeur. Zoekterm: happy eyeballing

[Mars Warrior]

@RobertMe zijn dat soms de userland proxies? Daar wel eerder van gehoord, maar geen idee wat dat was/is.

Het gevolg voor remote_ip staat vziw nergens gedocumenteerd en wordt ook nergens uitgelegd.

Ik gebruik verder gewoon iptables. Dat werkt ootb. Ook fail2ban kan ik dan standaard gebruiken. Nftables vereist aanpassingen.

Ik hoop dat alles straks werkt als ik ipv6 heb aangezet. Afwachten nog. Alles moet daarvoor weer plat. Opstarten duurt ff met bijna 50 containers waaronder een aantal hele zware met meer dan 100 draaiende applicaties.

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 20:05:
@RobertMe zijn dat soms de userland proxies? Daar wel eerder van gehoord, maar geen idee wat dat was/is.

Ja, dat is een userland proxy. Zoals ik aangaf gewoon een programmaatje dat luistert op de host IP/port opgegeven bij de publish en vervolgens het binnenkomende verkeer 1-op-1 doorzet naar een (nieuwe) verbinding richting de container.

Het gevolg voor remote_ip staat vziw nergens gedocumenteerd en wordt ook nergens uitgelegd.

Wat bedoel je hier nu precies mee? remote_ip zoals je in PHP hebt? Maar dat werkt sowieso niet direct als je achter een Caddy reverse proxy zit. Dan moet je naar de X-FORWARDED-FOR header kijken die Caddy zal sturen. Maar okay, bij de proxy variant zal die net zo goed niet kloppen.

Ik gebruik verder gewoon iptables. Dat werkt ootb. Ook fail2ban kan ik dan standaard gebruiken. Nftables vereist aanpassingen.

De grap is dat de Linux kernel al jaaaren alleen maar nftables code bevat. Waarbij er vervolgens iptables (+ ipset + ...) implementatie is die aan de achterkant de nftables APIs van de kernel aanspreekt.

Ik hoop dat alles straks werkt als ik ipv6 heb aangezet.

Nee, gaat niet werken. Om IPv6 te ontvangen in de containers moeten de containers zelf IPv6 doen. En ik heb je niet zien schrijven dat je IPv6 op de Docker networks enabled hebt (docker network create --ipv6 .... IIRC). En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten. En dat gaat dus iets verder dan "aanzetten" en ik heb je nog niet lezen vloeken over dat je de ~50 containers moet verwijderen (en daarna opnieuw aanmaken), dus ik denk niet dat je al zo ver bent

Edit:
Of bedoel je met IPv6 activeren de IPv6 optie in de daemon.json van Docker? Ook dat zal niet veel helpen. Want die optie gaat om het default bridge network. Dat is zeg maar de --ipv6 van docker network create voor die ingebouwde bridge. Niet meer, niet minder. Hetzelfde als die optie voor het IPv6 subnet dat je op kunt geven in de daemon.json, ook die heeft alleen betrekking op het default bridge netwerk.

[ Voor 10% gewijzigd door RobertMe op 29-05-2025 21:32 ]

[Airw0lf]

@RobertMe:
En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten.

Dat klopt an sich wel - netwerken kun je niet bewerken.

Maar wat zou er gebeuren als je een nieuw (bridge) netwerk aanmaakt met IPv6 actief?
En vervolgens alle containers aan dit nieuwe netwerk knoopt?
Als alles goed werkt kan het oude non-IPv6 netwerk verwijderd worden?

Het zou nog steeds een hele klus zijn - maar minder ingrijpend dan alle containers verwijderen en opnieuw aanmaken.

Of heb ik hier nu een klok-en-klepel iets "geschreven"?

[ Voor 6% gewijzigd door Airw0lf op 29-05-2025 21:42 ]

[ed1703]

—

[ Voor 117% gewijzigd door ed1703 op 30-05-2025 01:10 ]

[RobertMe]

Airw0lf schreef op donderdag 29 mei 2025 @ 21:37:
[...]


Dat klopt an sich wel - netwerken kun je niet bewerken.

Maar wat zou er gebeuren als je een nieuw (bridge) netwerk aanmaakt met IPv6 actief?
En vervolgens alle containers aan dit nieuwe netwerk knoopt?
Als alles goed werkt kan het oude non-IPv6 netwerk verwijderd worden?

Het zou nog steeds een hele klus zijn - maar minder ingrijpend dan alle containers verwijderen en opnieuw aanmaken.

Of heb ik hier nu een klok-en-klepel iets "geschreven"?

Potayto potahto

Ja, je kunt gewoon een "ingress-met-ipv6" netwerk maken en bestaande containers een voor een aan het nieuwe netwerk hangen. Dan kun je mogelijk wel half up blijven (/zijn alleen de containers stuk voor stuk even down, i.p.v. dat ze eerst allemaal down moeten, en dan weer allemaal up). Maar uiteindelijk is het kinda net zoveel werk (je moet alle containers na gaan).

Edit:
Of..., dus alleen Caddy naar de buitenwereld toe in een IPv6 netwerk zetten en klaar. Het is niet dat Caddy ook met alle "backends" over IPv6 moet babbelen. Dat kan nog steeds prima via IPv4 (uiteraard met behoud van de juiste X-FORWARDED-FOR header die Caddy naar het backend stuurt).

[ Voor 13% gewijzigd door RobertMe op 29-05-2025 21:56 ]

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 21:15:
[...]
Ja, dat is een userland proxy. Zoals ik aangaf gewoon een programmaatje dat luistert op de host IP/port opgegeven bij de publish en vervolgens het binnenkomende verkeer 1-op-1 doorzet naar een (nieuwe) verbinding richting de container.

Ok. Helder. Ik zie dat ik die kan uitzetten, maar dan wordt inderdaad IPv6 aanvragen domweg geblokkeerd. Logisch eigenlijk.

[...]
Wat bedoel je hier nu precies mee? remote_ip zoals je in PHP hebt? Maar dat werkt sowieso niet direct als je achter een Caddy reverse proxy zit. Dan moet je naar de X-FORWARDED-FOR header kijken die Caddy zal sturen. Maar okay, bij de proxy variant zal die net zo goed niet kloppen.

Nope. Dat is Caddy
Caddy pleurt dingen behalve in de header ook in de logging, waarin je de remote_ip oa kunt zien. En met templates kun je bijv ook handmatig je "X-Real-IP" op {remote} of {remote_host} zetten als je wilt...

Een voorbeeldlog waarin de Docker gateway staat omdat de client IPv6 gebruikt:

JSON:

{
  "level": "info",
  "ts": 1748525274.9179876,
  "logger": "http.log.access.log2",
  "msg": "handled request",
  "request": {
    "remote_ip": "172.30.0.1",
    "remote_port": "48622",
    "client_ip": "172.30.0.1",
    "proto": "HTTP/2.0",
    "method": "GET",
    },
    "Server": [
      "Caddy",
      "Rocket"
    ],
  }
}

En een log waarin wel het juiste externe IP adres staat omdat de client IPv4 gebruikt doordat in de DNS enkel een A record is opgenomen:

JSON:

{
  "level": "info",
  "ts": 1748525327.5075016,
  "logger": "http.log.access.log2",
  "msg": "handled request",
  "request": {
    "remote_ip": "188.207.108.185",
    "remote_port": "26385",
    "client_ip": "188.207.108.185",
    "proto": "HTTP/2.0",
    "method": "GET",
    "Server": [
      "Caddy",
      "Rocket"
    ]
  }
}

[...]
De grap is dat de Linux kernel al jaaaren alleen maar nftables code bevat. Waarbij er vervolgens iptables (+ ipset + ...) implementatie is die aan de achterkant de nftables APIs van de kernel aanspreekt.

Volgens mij gebruik ik dan de compatibility laag. Iets van "legacy" ofzo in de naam. Kan het me vaag herinneren omat het 2,5 jaar geleden is dat ik docker op de server heb gezet

[...]
Nee, gaat niet werken. Om IPv6 te ontvangen in de containers moeten de containers zelf IPv6 doen. En ik heb je niet zien schrijven dat je IPv6 op de Docker networks enabled hebt (docker network create --ipv6 .... IIRC). En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten. En dat gaat dus iets verder dan "aanzetten" en ik heb je nog niet lezen vloeken over dat je de ~50 containers moet verwijderen (en daarna opnieuw aanmaken), dus ik denk niet dat je al zo ver bent

Dat bedoel ik met aanzetten ja
En Nee, daar ben ik nog niet aan begonnen

Ik zal het ingress netwerk van Caddy, waarin natuurlijk alle containers zitten die via Caddy benaderd kunnen worden (zowel via een lokale dns als vanaf extern) met IPv6 moeten uitrusten. Ik heb daar nu enkel een custom IPv4 netwerk in gedefinieerd zodat ik de addressen kan herkennen.

Dat zal ik dus ook voor IPv6 moeten doen, en ja dat betekent dat alle containers die in dat netwerk zitten down moeten en weer moeten worden aangemaakt. Ach...

Aan de andere kant kan ik het ook Docker lekker zelf laten uitzoeken: die maakt dan ULAs aan door enkel een "vinkje" te zetten:

Dynamic IPv6 subnet allocation

If you don't explicitly configure subnets for user-defined networks, using docker network create --subnet=<your-subnet>, those networks use the default address pools of the daemon as a fallback. This also applies to networks created from a Docker Compose file, with enable_ipv6 set to true.

Is dus ook nog een overweging. Ik had namelijk een zelf gedefinieerd IPv4 netwerk gedefinieerd eerder om voor Caddy eventueel nog een proxy te zetten. Dan is een vast adres voor Caddy wel erg handig.

Edit:
Of bedoel je met IPv6 activeren de IPv6 optie in de daemon.json van Docker? Ook dat zal niet veel helpen. Want die optie gaat om het default bridge network. Dat is zeg maar de --ipv6 van docker network create voor die ingebouwde bridge. Niet meer, niet minder. Hetzelfde als die optie voor het IPv6 subnet dat je op kunt geven in de daemon.json, ook die heeft alleen betrekking op het default bridge netwerk.

Nee. Ik gebuik het default bridge netwerk niet. Overal heb ik eigen netwerken opgegeven. De meeste apps eisen dit ook omdat die zelf meerdere containers starten, en dus ook in hun eigen netwerk willen zitten. Alleen de hoofd-app komt extra in het ingress netwerk van Caddy te hangen.

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 21:54:
[...]
Edit:
Of..., dus alleen Caddy naar de buitenwereld toe in een IPv6 netwerk zetten en klaar. Het is niet dat Caddy ook met alle "backends" over IPv6 moet babbelen. Dat kan nog steeds prima via IPv4 (uiteraard met behoud van de juiste X-FORWARDED-FOR header die Caddy naar het backend stuurt).

Alle Aardappelen op een stokje!

Kan dit denk je? Dus behalve het ingress-network waarin de rest van de containers hangen een extra netwerk, laten we zeggen caddy-extern die IPv6 ondersteund, Caddy een schop geven, en klaar?

Zou Caddy dan naar een IPv4 container toch een IPv6 adres meegeven in de header? En als dat om een onverlaat gaat die met admin wil inloggen, dat in de logging van die container het IPv6 adres staat, zodat Fail2Ban die onverlaat een ban kan geven?

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 22:27:
[...]

Ok. Helder. Ik zie dat ik die kan uitzetten, maar dan wordt inderdaad IPv6 aanvragen domweg geblokkeerd. Logisch eigenlijk.

Nouja, uitzetten kan prima, zolang er een andere manier is om de containers te bereiken. Als de containers zelf IPv6 doen is het dus een kwestie van een poort open zetten (als in: het doorsturen van verkeer toestaan. Daar waar je het bij IPv4 hebt over "toestaan van doorsturen" + DNAT om uberhaupt het destination IP (+ evt poort) aan te passen).

[...]

Volgens mij gebruik ik dan de compatibility laag. Iets van "legacy" ofzo in de naam. Kan het me vaag herinneren omat het 2,5 jaar geleden is dat ik docker op de server heb gezet

iptables-legacy lijkt mij juist dat die wel nog de legacy kernel API zou aanspreken, not sure though. Ik gebruik nftables dus houd me niet zo bezig met iptables

Aan de andere kant kan ik het ook Docker lekker zelf laten uitzoeken: die maakt dan ULAs aan door enkel een "vinkje" te zetten:

Het nadeel van ULAs is natuurlijk dat het ULAs zijn. Idealiter knoop je meteen GUAs in de container. Dan kun je gewoon in de externe DNS server dat IPv6 adres gebruiken en werkt dat net zo goed vanaf intern. Maar..., daarvoor is het uiteraard wel nogal belangrijk dat je ook een statische prefix hebt. En bv Ziggo garandeert die niet (/je moet DHCP-PD gebruiken om een prefix op te halen, en daarbij AFAIK geen absolute garantie dat die nooit veranderd. Zoals je bij zakelijke abo's dus wel een vast IP adres krijgt, of bij IPv6 dan een vaste prefix).
ULAs kan uiteraard wel, maar dan moet je dus alsnog DNAT gaan doen, dat niet echt des IPv6 is. Wat daarbij dan weer wel zou kunnen is dat je alsnog verschillende IPv6 adressen aan de host geeft en die 1 op 1 naar containers vertaald. Dus bv een ::80 op de host die ongeacht de destination port vertaald naar het IP van de Caddy container.
* RobertMe gebruikt intern zelfs masquarading . De containers hebben v.w.b. IPv6 alleen een ULA, waardoor de container dus denkt dat IPv6 werkt. Maar dat doet het natuurlijk niet, want met een ULA kan niet het internet op worden gegaan. Vandaar SNAT / masquarading om dus maar weer de afzender te herschrijven naar het (GUA) adres van de host. Op de VPS heb ik uiteraard wel een vast IPv6 subnet (/64). En dat subnet heb ik dan ook opgesplitst in /72 (dus mogelijkheid tot 256x een /72). En dus kan elk Docker netwerk een /72 gebaseerd IPv6 subnet krijgen en kunnen containers rechtstreeks IPv6 naar buiten babbelen en kan binnenkomend verkeer dus ook rechtstreeks worden toegestaan om doorgestuurd te worden.

[...]

Nee. Ik gebuik het default bridge netwerk niet. Overal heb ik eigen netwerken opgegeven. De meeste apps eisen dit ook omdat die zelf meerdere containers starten, en dus ook in hun eigen netwerk willen zitten. Alleen de hoofd-app komt extra in het ingress netwerk van Caddy te hangen.

Uiteraard. Ik bedoelde het meer als "vergis je niet in de betekenis van de IPv6 (+ subnet + ...) instellingen in de daemon.json. Die hebben voornamelijk betrekking op het default bridge netwerk, dat je (waarschijnlijk) niet gebruikt. * RobertMe gebruikt het ook niet, en kan zomaar zijn dat het daadwerkelijk uit staat, want je kunt het ook uit zetten in de daemon.json.

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 22:32:
[...]

Alle Aardappelen op een stokje!

Kan dit denk je? Dus behalve het ingress-network waarin de rest van de containers hangen een extra netwerk, laten we zeggen caddy-extern die IPv6 ondersteund, Caddy een schop geven, en klaar?

Zou Caddy dan naar een IPv4 container toch een IPv6 adres meegeven in de header? En als dat om een onverlaat gaat die met admin wil inloggen, dat in de logging van die container het IPv6 adres staat, zodat Fail2Ban die onverlaat een ban kan geven?

Ik kan mij niet indenken dat dat niet werkt inderdaad. Caddy zal gewoon het binnenkomende IPv6 adres zien en kan die dus ook prima in de logging / X-FORWARDED-FOR header / ... opnamen. En hoe Caddy met de backends babbelt is natuurlijk onafhankelijk van hoe de client met Caddy babbelt. Niet veel anders als de userland proxy van Docker Alleen doet Caddy (mogelijk/waarschijnlijk) HTTP verkeer proxyen, en doet die userland proxy van Docker TCP / UDP proxyen zonder enige verdere kennis van de hogere protocollen.

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 22:48:
[...]

Ik kan mij niet indenken dat dat niet werkt inderdaad. Caddy zal gewoon het binnenkomende IPv6 adres zien en kan die dus ook prima in de logging / X-FORWARDED-FOR header / ... opnamen. En hoe Caddy met de backends babbelt is natuurlijk onafhankelijk van hoe de client met Caddy babbelt. Niet veel anders als de userland proxy van Docker Alleen doet Caddy (mogelijk/waarschijnlijk) HTTP verkeer proxyen, en doet die userland proxy van Docker TCP / UDP proxyen zonder enige verdere kennis van de hogere protocollen.

Ik heb de externe DNS weer omgezet. TTL staat op 10 minuten, maar dat is soms een flink kwartiertje...

Echter het lijkt er nu heel sterk op dat ik nu altijd een IPv4 adres krijg. Ik zie in ieder geval geen Docker Gateway adres meer langskomen. Waar ik voorheen zowel via WiFi als 4G op mijn telefoon dat wel kreeg, krijg ik nu over WiFi het lokale IPv4 adres, en via 4G het externe IPv4 adres.

Dus ja het werkt, maar ook weer niet

Edit: My Bad

Ik had een LLA opgegeven ipv een ULA. Dan krijg je dus dat effect...

Met een ULA (fc00) werkt het nu wel. Ik zie nu IPv6 adressen in de log voorbij komen!

[ Voor 74% gewijzigd door Mars Warrior op 29-05-2025 23:15 ]

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 23:01:
[...]

Ik heb de externe DNS weer omgezet. TTL staat op 10 minuten, maar dat is soms een flink kwartiertje...

Waarom test je niet intern, desnoods door gewoon een regeltje met het IPv6 adres in de /etc/hosts file op te nemen? (en bij Windows nog iets met C:\Windows\... voor /etc/hosts te zetten). Waarbij bij IPv6 dus uberhaupt geen "intern" en "extern" bestaat. Hoogstens dus een globaal IP adres vs een private IP adres (/range, als in: ULA oftewel IPs die binnen fc00://7 vallen).

Zou Caddy nu, omdat de containers in het ingress netwerk enkel IPv4 babbelen de IPv6 aanvraag domweg afwijzen, waardoor er - dankzij die oogballen - altijd een IPv4 verbinding wordt opgezet?

Nee, voor Caddy zal dat irrelevant zijn. Zolang Caddy maar een IP adres (of hostname?) van de backend server weet en die daarmee kan verbinden is dat prima. Caddy doet immers niet veel meer dan gewoon een TCP (client) socket openen om te verbinden met een hostname/IP adres (van de backend server). Dat die dat toevallig doet in reactie op een nieuwe verbinding op een (luisterende) socket die ook nog eens een ander IP protocol gebruikt is irrelevant. En Caddy is natuurlijk een reverse proxy die meer doet. TLS termination / logging / extra headers toevoegen aan HTTP verkeer (/een volledig nieuwe HTTP request opbouwen die toevallig (een deel van) de (meta)data van de originele aanvraag over neemt).
Het is niet zoals bij een firewall met DNAT dat de TCP/IP pakketjes herschreven worden naar een ander bestemmings IP adres. Het is een volledig programma, dat TCP/IP pakketjes ontvangt, en die daadwerkelijk verwerkt, en (wellicht) toevallig in reactie daarop zelf een TCP/IP verbinding op zet met een ander programma. Ter vergelijking: bv dan een PHP server die via IP een request ontvangt kan toch ook prima over een unix socket met de database babbelen. Het is ook niet alsof die dan ineens ook via IP, en dezelfde IP versie, met de database moet babbelen.

[Mars Warrior]

@RobertMe Zie mijn vorige, gewijzigde post!

Het werkt nu, zowel lokaal via WiFi als via 4G: ik krijg netjes IPv6 adressen in de log te zien van een container die in het IPv4 ingress netwerk zit.

Net ff de logfile voor Fail2Ban bekeken, en daar zie ik bij een foute inlog het IPv6 adres. Dus Fail2Ban gaat dan het juiste adres blokkeren. Dan zal het IPv4 adres vervolgens wel weer komen, maar goed. Dat krijg je met zowel IPv4 als IPv6: twee wegen die naar dezelfde server leiden.

Het is wat!

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 23:23:
@RobertMe Zie mijn vorige, gewijzigde post!

Twee edits? Volgens mij had je al een kleine edit gedaan die ik zag in de quote (maar nog niet bij lezen reactie had gezien).
Maar dat je het link local address gebruikt had had ik niet gezien nee. En dan wordt het lastig. Een link local address is immers niet routeerbaar, en het link local address van de container moet wel gerouteerd worden vanaf je gewone LAN.

Net ff de logfile voor Fail2Ban bekeken, en daar zie ik bij een foute inlog het IPv6 adres. Dus Fail2Ban gaat dan het juiste adres blokkeren. Dan zal het IPv4 adres vervolgens wel weer komen, maar goed. Dat krijg je met zowel IPv4 als IPv6: twee wegen die naar dezelfde server leiden.

Ik hoop voor je dat fail2ban uberhaupt de volledige /64 blokkeert. Anders hebben ze sowieso 2^64 (oftewel: 1.8e19) adressen beschikbaar Dat zou dan ook weer een leuke attack vector (/DoS) zijn om fail2ban / de firewall over de zeik te krijgen door een enorme (ip)set op te bouwen met dus miljarden individuele adressen er in.

Edit:
@Mars Warrior, maar heb je nu de ULA in de DNS opgenomen? Dat kan toch sowieso nooit werken? Behalve op wifi dan. Immers is die ULA niet over het internet routeerbaar. In de (externe) DNS zal toch echt een GUA moeten staan. Die je al dan niet in je router, of op de Docker host (of een ander IPv6 capable systeem in je netwerk) DNAT naar de ULA. Of dus als je een gegarandeerd statische prefix hebt dus een GUA gebruiken voor het Docker netwerk, maar dat zou dan wel een GUA in een ander subnet zijn (binnen de /46 die je van KPN kreeg dan), waardoor je router alsnog moet weten dat dat specifieke subnet bereikbaar is (/gerouteerd moet worden) via de Docker host (die routing entry kan dan wel weer op basis van het link local address van de Docker host uiteraard).

[ Voor 25% gewijzigd door RobertMe op 29-05-2025 23:39 ]

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 23:30:
Ik hoop voor je dat fail2ban uberhaupt de volledige /64 blokkeert. Anders hebben ze sowieso 2^64 (oftewel: 1.8e19) adressen beschikbaar Dat zou dan ook weer een leuke attack vector (/DoS) zijn om fail2ban / de firewall over de zeik te krijgen door een enorme (ip)set op te bouwen met dus miljarden individuele adressen er in.

Geen idee hoe Fail2Ban met IPv6 blokkades omgaat. Dat moet ik gaan zien dan de komende tijd.
Er komt niet enorm veel binnen op die containers qua bots en andere zooi, maar wel ff iets om op te letten.

Ik zet voorlopig de ban-tijd niet te lang in ieder geval.

[alex3305]

Vandaag nog een leuke situatie meegemaakt die mij niet eerder bekend was. Ik gebruikte eerder een ipvlan voor al mijn containers, maar ben al een tijdje geleden geswitched naar Docker Swarm met een overlay network. Na de upgrade naar Unraid 7.1.2 had ik echter wat problemen met het ipvlan netwerk. Hierover had ik al wat geschreven in het Unraid topic, maar tl;dr containers in het ipvlan netwerk konden de host niet bereiken en vice-versa. Met macvlan werkte het wel. Wat mij betreft ook prima . In Unraid heet het toch allebei br0.

Nu viel mij in mijn router echter op dat sommige containers een nogal bijzonder netwerkverbruik hadden . Voornamelijk onverwacht. En dan heb ik het over grote(re) transfers. Toen ik echter een docker network inspect br0 deed zag ik o.a. dit:

Even wat geknipt om voornamelijk mijn voorbeeld te illustreren.

JSON:

{
    "Name": "br0",
    "Containers": {
        "37b264686080564a243ca86da90fee6add3a65f27cd760c52c483778ef9f26bf": {
            "Name": "kopia",
            "EndpointID": "9e9e68388dc92541653bb4c42dcb34f3530427554a79f9eee9981a05254d112c",
            "MacAddress": "02:42:c0:a8:01:29",
            "IPv4Address": "192.168.0.41/24",
            "IPv6Address": ""
        },
        "854a9dbb6001d75d9a6dddc005adc7f05febaf4b2c3e3de8c8dc625e8e4e5c8a": {
            "Name": "adguard-home",
            "EndpointID": "c3b35675e624f9dd46928b628a4ad7d23764da15691051f64a3754324953c20e",
            "MacAddress": "02:42:c0:a8:01:04",
            "IPv4Address": "192.168.0.4/24",
            "IPv6Address": ""
        }
        "c8e185d487858dcea0e7fa2060c3f64e7c72b752639975ee8e4c8ea614dbe6c1": {
            "Name": "home-assistant",
            "EndpointID": "448236dfb73cdde6ddf63e35ad798b5e02955aa86de180d1db77e905faf37ab9",
            "MacAddress": "02:42:c0:a8:01:03",
            "IPv4Address": "192.168.0.3/24",
            "IPv6Address": ""
        }
    }
}

Dat Adguard Home er in staat klopt. Immers wil ik mijn DNS server(s) direct kunnen bereiken. Home Assistant klopt ook. Het implementeren van een DNS reflector zoals @RobertMe in het Home Assistant topic beschreef staat naar zijn bericht inmiddels op mijn lijstje. Maar Kopia heb ik al een hele tijd achter mijn Caddy setup draaien . Ook in de Docker Compose vond ik geen enkele verwijzing meer naar br0.

Een volledige docker compose down (vanuit dockge omdat ik lui ben ) zorgde er dan ook voor dat deze netwerkverwijzing verdween .

Ik had eigenlijk verwacht dat een wijziging in de Docker Compose voldoende zou zijn om de netwerktoewijzing teniet te doen. Maar dat is dus wellicht onterecht. Het is ook niet het einde van de wereld, maar vond het vooral verwarrend.

[RobertMe]

alex3305 schreef op donderdag 5 juni 2025 @ 20:34:
Ik had eigenlijk verwacht dat een wijziging in de Docker Compose voldoende zou zijn om de netwerktoewijzing teniet te doen. Maar dat is dus wellicht onterecht. Het is ook niet het einde van de wereld, maar vond het vooral verwarrend.

Geen ervaring met swarm. Maar als je een up doet en de container (definitie) is gewijzigd dan zou die effectief ook gewoon een down + up moeten doen. Of in Docker termen dan een stop + rm + (create + start) (/run). Daarom dat je ook volume mappings of named volumes moet gebuiken. Anders is bij die up al de data in de oude container verdwenen door de rm etc.

Niet toevallig toentertijd wel de compose file gewijzigd, maar niet opgeslagen, vervolgens een up gedaan met nog de oide file en daarna pas opgeslagen?

[alex3305]

@RobertMe Ik weet dat het zo zou moeten lopen, vandaar dat ik zo verbaasd ben . Mijn gehele deployment verloopt geautomatiseerd vanaf mijn workstation met Git naar Forgejo waarbij Forgejo Runner een Workflow aftrapt met Ansible. Die template vervolgens en Compose file naar mijn server, die vervolgens een Docker Compose Up doet.

Deze workflow vind tevens geautomatiseerd plaats bij versie updates door middel van Renovate. En extra bestanden of handmatige aanpassingen worden dan weggehaald. Ook heb ik twee geleden alles nog een keer vers gedeployed.

De laatste keer dat mijn Kopia container het ipvlan / macvlan netwerk gebruikte was meer dan een half jaar geleden . Er waren overigens nog meer containers waarbij dit aan de hand was. Een volledige down en up zorgde er voor dat de toewijzing werd weggehaald.

[alex3305]

alex3305 schreef op donderdag 5 juni 2025 @ 20:34:
[...] Het implementeren van een DNS reflector zoals @RobertMe in het Home Assistant topic beschreef staat naar zijn bericht inmiddels op mijn lijstje. [...]

Ik quote mezelf even, maar ik ben de afgelopen week bezig geweest om dit te implementeren op basis van de blijkbaar enorm veelgebruikte code van Darell Tan. Alleen heb ik het geheel dus in een Docker container gegoten. Het uiteindelijke containertje is niet veel groter dan standaard Alpine. Eventueel zou ik nog naar Busybox kunnen wisselen of wellicht zelfs scratch aangezien alles toch statisch gecompileerd is.

Met de ESPHome werkte deze container echt meteen out-of-the-box toen ik de ipvlan/macvlan toewijzing verwijderde. Maar vreemd genoeg kreeg ik in Home Assistant geen enkel mDNS / Zeroconf record te zien toen ik daar hetzelfde deed. Ik ben enorm benieuwd wat het eigenlijke verschil is tussen deze twee applicaties, want het principe is hetzelfde.

[Mars Warrior]

Nog even terugkomen op mijn IPv4/IPv6 probleem waarbij het "remote address" van een client altijd de Docker gateway was als de client over IPv6 babbelt:

De oplossing om enkel Caddy in een IPv4/IPv6 netwerk te hangen, en de rest van de containers (die andere 48 ofzo) in een IPv4-only netwerk te laten zitten blijkt uitstekend te werken.

Ik krijg dus op een container die enkel IPv4 doet toch netjes de externe/client IPv6 adressen door.
Dat betekent dat een WAF (Web Application Firewall) of Fail2Ban ook de juiste client blokkeert.

Het blokkeren van IPv6 is wel altijd een /128 adres. Dus geen subnet van /64, /56 of /48 aangezien ik ook niet weet hoe groot het subnet aan de andere kant is.
Vooralsnog geen "flood" aan verschillende IPv6 adressen die pogingen doen om binnen te komen, en daarmee een mega lijst van IP adressen geeft voor Fail2Ban om te blokkeren.

Ik gebruik Wordfence als WAF voor Wordpress gerelateerde containers, en daar zie ik dat iha het "Wordfence beveiligingsnetwerk" al bijna al het mens/bot verkeer dat ongewenst is bij voorbaat blokkeert voordat deze op een pagina terechtkomt: die zijn niet eens in staat om een poging te doen om in te loggen

Afwachten of dit in de toekomst nog veranderd als er steeds meer gebruik gemaakt wordt van IPv6.

[RobertMe]

Mars Warrior schreef op zondag 15 juni 2025 @ 13:33:
Het blokkeren van IPv6 is wel altijd een /128 adres. Dus geen subnet van /64, /56 of /48 aangezien ik ook niet weet hoe groot het subnet aan de andere kant is.
Vooralsnog geen "flood" aan verschillende IPv6 adressen die pogingen doen om binnen te komen, en daarmee een mega lijst van IP adressen geeft voor Fail2Ban om te blokkeren.

Het kleinste "geaccepteerde" subnet is /64. Een /64 is namelijk vereist voor SLAAC dat op zichzelf weer dr defacto standaard is om een IPv6 te verkrijgen (door het zelf te genereren dus).
Kleiner dan dat kan "uiteraard" wel, maar zou op zijn minst onwenselijk zijn als niet leiden tot heel wat issies bij "normaal gebruik". En ook in de hosting wereld is het bij mijn weten dus de standaard dat een server (of wellicht een cluster) een /64 (of groter) krijgt.

Enige uitzondering die ik mij kan bedenken zijn VPNs. De VPN aanbieder die ik gebruik gaat per server ("natuurlijk") maar met 1 IPv6 adres het internet op. Mogelijk wellicht misschien dat zij vervolgens wel 1 subnet delen over meerdere (/alle?) servers. Maar ik acht dat eigenlijk ook onwaarschijnlijk (routing zou dan bv per /128 of iets dergelijks moeten, en geen idee of dat mogelijk is, of ze moeten het intern routeren wat mij weer een SPoF op lijkt te leveren).

Ergo: ik zou gewoon een /64 gebruiken. De kans dat je daarmee legitieme gebruikers onterecht blokkeert is zeer klein. En dat zal dan vast een gebruiker zijn die of het of zelf "opzoekt" (VPN gebruiken, altijd een risico dat anderen misbruik doen waardoor het IP geblokkeerd wordt) of meer eigenaardigheden zal hebben.

[Mars Warrior]

RobertMe schreef op zondag 15 juni 2025 @ 13:53:
[...]
Ergo: ik zou gewoon een /64 gebruiken. De kans dat je daarmee legitieme gebruikers onterecht blokkeert is zeer klein. En dat zal dan vast een gebruiker zijn die of het of zelf "opzoekt" (VPN gebruiken, altijd een risico dat anderen misbruik doen waardoor het IP geblokkeerd wordt) of meer eigenaardigheden zal hebben.

dan ga ik eens kijken wat fail2ban kan en doet. Dat is me nog onduidelijk op IPv6 vlak.

Met de implementatie van IPv6 en wat header aanpassingen in Caddy is het uiteindelijke resultaat voor mijn domeinen en subdomeinen inmiddels wel een 100% score op internet.nl 😋

De rest doet de provider allemaal.

Best wel stuitend af en toe als je ziet dat bekende sites een score van nog geen 60% halen. En dan thuis gewoon 100% scoren.

Vanzelfsprekend voel ik me zo veilig dat ik verder overal username/password gebruik om in te loggen 😳🤣

[ Voor 13% gewijzigd door Mars Warrior op 15-06-2025 18:11 ]

[Question Mark]

Ik heb een aantal reacties/vragen over Dawarich afgesplitst naar een eigen topic.

[Dawarich] Locatie onvoldoende nauwkeurig

[Dennis]

Hopelijk kan iemand hier mij een klein beetje in de goede richting duwen, twijfelde wel tussen dit topic en het Traefik topic.

Ik ben vandaag begonnen met Docker. Eerst de hele boel opgezet bij Hetzner met de Ubuntu-Docker app. Ging allemaal prima. Daarna ook Portainer succesvol geïnstalleerd en dat is netjes toegankelijk. De volgende stap was Authentik. Dat is op zich ook gelukt, maar nu zit ik even met een gewetensvraag.

Mijn doel is uiteindelijk om (nog een keer) Matrix te installeren. En ik wil kijken of ik Vaultwarden aan de praat kan krijgen. Ik ga ervan uit dat dat lukt trouwens .

Maar aannemend dat ik deze services uiteindelijk veilig wil exposen met Traefik en dan dus in combinatie met Authentik, wat is een logische manier om het op te bouwen? Gebruik ik één grote Stack in Portainer en daarin alle componenten en dus één Traefik, of is het logischer om een en ander te groeperen qua logische services en dan dus ook meerdere Traefiks te draaien? Elke service moet uiteindelijk een eigen subdomain krijgen, dus vault.xxx.nl, chat.xxx.nl, etc.

Ik heb al wat filmpjes gekeken en blogs gelezen maar het is voor mij een beetje een overload aan informatie met als toppunt de video's van simple ( ) homelabs. Benieuwd naar jullie best practices.

[RobertMe]

Dennis schreef op zaterdag 9 augustus 2025 @ 22:40:
Hopelijk kan iemand hier mij een klein beetje in de goede richting duwen, twijfelde wel tussen dit topic en het Traefik topic.

Ik ben vandaag begonnen met Docker. Eerst de hele boel opgezet bij Hetzner met de Ubuntu-Docker app. Ging allemaal prima. Daarna ook Portainer succesvol geïnstalleerd en dat is netjes toegankelijk. De volgende stap was Authentik. Dat is op zich ook gelukt, maar nu zit ik even met een gewetensvraag.

Mijn doel is uiteindelijk om (nog een keer) Matrix te installeren. En ik wil kijken of ik Vaultwarden aan de praat kan krijgen. Ik ga ervan uit dat dat lukt trouwens .

Maar aannemend dat ik deze services uiteindelijk veilig wil exposen met Traefik en dan dus in combinatie met Authentik, wat is een logische manier om het op te bouwen? Gebruik ik één grote Stack in Portainer en daarin alle componenten en dus één Traefik, of is het logischer om een en ander te groeperen qua logische services en dan dus ook meerdere Traefiks te draaien? Elke service moet uiteindelijk een eigen subdomain krijgen, dus vault.xxx.nl, chat.xxx.nl, etc.

Ik heb al wat filmpjes gekeken en blogs gelezen maar het is voor mij een beetje een overload aan informatie met als toppunt de video's van simple ( ) homelabs. Benieuwd naar jullie best practices.

Meerdere Traefik instances gaat het nut een beetje voorbij.

Of je maakt er een grote stack van, of je splitst de software per stack, Traefik wordt zijn eigen stack, en er is een "extern" netwerk dat zowel door Traefik gebruikt wordt als waar de containers die ge-exposed moeten worden in zitten. Zodat Traefik dus over dat netwerk met de containers kan babbelen.

Optioneel combineer je Traefik & Authentik in een stack afhankelijk van hoe het is ingeregeld. Heb er zelf geen ervaring mee, maar AFAIK kan Traefik ook als authenticatie middleware dienst doen waarbij bij elke request Traefik dus (mogelijk) aan Authentik (of soortgelijke service) vraagt van "mag deze request worden uitgevoerd?" waarna die service dus een ja/nee teruggeeft en op basis daarvan Traefik of de request doorzet of een error (401 / 403?) retourneerd. Als je Authentik puur inzet als authenticatie middleware zou je kunnen stellen dat het in dezelfde stack hoort. Zet je Authentik zelfstandig in gecombineerd met bv OIDC / OpenID Connect ingesteld op de services direct dan zou ik eerder voor een losse stack gaan.

[Dennis]

Dank @RobertMe, dat meerdere instances overbodig is vermoedde ik al een beetje.

Authentik ga ik zelfstandig inzetten, inderdaad met OIDC. Zag alleen dat Vaultwarden dat niet ondersteunt dus daar moet ik nog even over nadenken.

Ik vind de leercurve van Traefik heel hoog en ik heb het nog niet eens draaien. Ik begrijp dat je een deel van de configuratie al in de docker compose meegeeft. Ondertussen begrijp ik nog niet hoe een en ander in Docker werkt m.b.t. users en hoe je directorystructuren op de host netjes gebruikt. De combinatie met Portainer word ik ook niet gelukkig van, want in de compose voorbeelden van Traefik wordt er naar externe files verwezen, maar in Portainer kun je dat niet goed uitvoeren (daar moet je alles in één file plakken). Snap daar eerlijk gezegd niets van.

En ik begrijp nog niet waarom er zoveel losse containers zijn te downloaden en te draaien via Portainer (die via de Docker Hub beschikbaar zijn) terwijl je dat moeilijk in een stack kunt krijgen en daar nou juist de meerwaarde lijkt te zitten van Portainer. Dan valt de hele use case voor Portainer toch zo'n beetje weg?

Waarom ben ik hier eigenlijk ook alweer aan begonnen?

[Mars Warrior]

Dennis schreef op zondag 10 augustus 2025 @ 09:38:
Dank @RobertMe, dat meerdere instances overbodig is vermoedde ik al een beetje.

Authentik ga ik zelfstandig inzetten, inderdaad met OIDC. Zag alleen dat Vaultwarden dat niet ondersteunt dus daar moet ik nog even over nadenken.

Ik vind de leercurve van Traefik heel hoog en ik heb het nog niet eens draaien. Ik begrijp dat je een deel van de configuratie al in de docker compose meegeeft. Ondertussen begrijp ik nog niet hoe een en ander in Docker werkt m.b.t. users en hoe je directorystructuren op de host netjes gebruikt. De combinatie met Portainer word ik ook niet gelukkig van, want in de compose voorbeelden van Traefik wordt er naar externe files verwezen, maar in Portainer kun je dat niet goed uitvoeren (daar moet je alles in één file plakken). Snap daar eerlijk gezegd niets van.

En ik begrijp nog niet waarom er zoveel losse containers zijn te downloaden en te draaien via Portainer (die via de Docker Hub beschikbaar zijn) terwijl je dat moeilijk in een stack kunt krijgen en daar nou juist de meerwaarde lijkt te zitten van Portainer. Dan valt de hele use case voor Portainer toch zo'n beetje weg?

Waarom ben ik hier eigenlijk ook alweer aan begonnen?

Traefik zou altijd mijn allerlaatste keuze zijn. Waarom geen Caddy met de docker plug-in? Simpeler wordt het niet met twee regels labels om een site over HTTPS te ontsluiten.

[Tularis]

Tja, portainer is een tool om het gemakkelijker te maken om je stacks te beheren via een web interface. Dat het niet alles netjes ondersteunt dat docker compose aanbiedt is op zich wel logisch. Niet alles is even makkelijk via het web te ontsluiten zonder verregaande toegang tot je systeem en het daarmee verhoogde risico dat je loopt.

Multifile support doe je gewoon in de bestanden zelf. Effectief kopieert compose de inhoud van je include en plakt die ipv de include regel in je bestand. Waardoor effectief een groot bestand wordt gevormd.

Persoonlijk gebruik ik portainer meer als een tool om via het web gemakkelijk bij mijn docker instances te komen, niet om mijn stacks mee te beheren. Daar heb ik ssh en een text editor voor (of vs code over ssh, werkt ook best fijn).

[sjorsjuhmaniac]

@Dennis maak je stacks niet e groot.

Benader een stack als een service, en draai daar alleen de containers in die voor die service nodig zijn. Maak stacks per service, je kan er oneindig veel maken en kosten niets.
Soms heb je containers die overlappen, zoals een proxy of database. Dan wordt het een afweging of je ze in de betreffende stack houd of ze afsplitst.

Voor traefik is het beste om er maar 1 te draaien ivm je ssl challenges. Als je er meerdere draait moet je voor iedere instance een valide ssl challenge opzetten OF een instance alles laten doen en dan certs gaan exporteren. Allemaal te omslachtig imho.

Ik draai 1 stack die “proxy” heet. Daar zit traefik in. In jou setup zou ik daar autentik aan toevoegen.
Andere stacks hebben in hun netwerk het proxy netwerk staan (met

YAML:

existing: true

. Daarna bij de containers welke iets exposen naar de user nog het traefik netwerk toevoegen.

Er zijn een aantal dingen die je in de traefik config file moet zetten en niet met labels kunnen, bv de default headers voor de middleware.

Let bij de traefik labels goed op dat je de juiste service name gebruikt. Ik raad ten zeerste aan om het traefik dashboard te gebruiken om de resultaten van je configuratie te zien. Hier kan je realtime zien wat traefik aan het doen is. En zie je dus ook het effect van je config. Ja kan dus makkelijk het effect zien als je 1 dingetje veranderd.


Ik heb dus een draaiend traefik setup met meerdere stacks. Als je er echt niet uitkomt kan ik wel mijn configuratie delen maar dan moet ik tijd gaan steken dus alleen als je er echt niet uit komt

[RobertMe]

Mars Warrior schreef op zondag 10 augustus 2025 @ 10:08:
[...]

Traefik zou altijd mijn allerlaatste keuze zijn. Waarom geen Caddy met de docker plug-in? Simpeler wordt het niet met twee regels labels om een site over HTTPS te ontsluiten.

Als Traefik is opgezet kan die het ook met twee regels Twee labels om traefik te "enablen" voor de service en voor de domeinnaam er op te zetten (middels een host rule). Maar die laatste is dan weer niet perse het meest intuïtief traefik.http.routers.<naampje>.rule=Host(`...`) als ik mij niet vergis.[/]

[Mars Warrior]

RobertMe schreef op zondag 10 augustus 2025 @ 10:36:
[...]
Als Traefik is opgezet kan die het ook met twee regels Twee labels om traefik te "enablen" voor de service en voor de domeinnaam er op te zetten (middels een host rule). Maar die laatste is dan weer niet perse het meest intuïtief traefik.http.routers.<naampje>.rule=Host(`...`) als ik mij niet vergis.[/]

Zeker als je die andere 100 regels abracadabra vergeet

Ik heb met 50 containers in één docker compose file minder labels nodig dan Traefik voor één service

Maar goed. Ik weet niet of ChatGPT tegenwoordig al die abracadabra automatisch kan genereren…

[Webgnome]

welke abracadabra heb je het over @Mars Warrior ?

[RobertMe]

Mars Warrior schreef op zondag 10 augustus 2025 @ 11:07:
[...]

Zeker als je die andere 100 regels abracadabra vergeet

Ik heb met 50 containers in één docker compose file minder labels nodig dan Traefik voor één service

Maar goed. Ik weet niet of ChatGPT tegenwoordig al die abracadabra automatisch kan genereren…

Welke abracadabra? Een config file van ~20 regels of zo? Die van mij is 87 regels en dan heb ik 5 entrypoints en 2 ACME DNS providers, die uiteraard elk ook wat regels innemen. Als ik het strip naar 1 entrypoint 1 DNS provider etc valt dat vast binnen 10, 20 regels te krijgen. En dan heb je meer een standaard setup dan wat ik nu heb en nog steeds onder de "100 regels abracadabra" is

[Dennis]

Dank iedereen voor jullie overpeinzingen!

@Mars Warrior goeie vraag en dat vraag ik me nu ook af. Al zou Caddy niet mijn eerste keuze zijn, maar eerder nginx omdat ik dat relatief goed ken. En ik heb het gevoel (maar het is niet meer dan dat) dat Caddy iets te gesimplificeerd is. Ik wil ook bijvoorbeeld client certificate authentication uitvoeren en het lijkt wel of dat kan maar het ziet er geforceerd uit.

Ik weet ook nog niet of ik Authentik wil houden of toch liever Authelia wil gebruiken, bijvoorbeeld in combinatie met lldap. Dat zou ook een mooie stack zijn.

Ik ga eens kijken hoever ChatGPT kan komen met helpen, dat was een goede tip ook!

[Mars Warrior]

Dennis schreef op zondag 10 augustus 2025 @ 12:20:
Dank iedereen voor jullie overpeinzingen!

@Mars Warrior goeie vraag en dat vraag ik me nu ook af. Al zou Caddy niet mijn eerste keuze zijn, maar eerder nginx omdat ik dat relatief goed ken. En ik heb het gevoel (maar het is niet meer dan dat) dat Caddy iets te gesimplificeerd is. Ik wil ook bijvoorbeeld client certificate authentication uitvoeren en het lijkt wel of dat kan maar het ziet er geforceerd uit.

Nginx is beetje vorige eeuw als je Caddy gewend bent. Net als bij Apache moet je de meest simpele dingen elke keer instellen, waar Caddy standaard HTTPS doet en standaard 2 certificaat diensten ondersteund. Die hoef je ook niet in te stellen.

Caddy ondersteund gewoon mTLS. Dus als je je certificaten correct configureert dan moet dat goed gaan met een client_auth.

Ik weet ook nog niet of ik Authentik wil houden of toch liever Authelia wil gebruiken, bijvoorbeeld in combinatie met lldap. Dat zou ook een mooie stack zijn.

Beiden kunnen. En als je ze juist configureert dan werkt het goed.

Ik ga eens kijken hoever ChatGPT kan komen met helpen, dat was een goede tip ook!

Yep. Er komt vaak rommel uit ChatGPT, maar dit soort dingen gaan in het algemeen altijd goed bij mij.

Zelfs de abracadabra 😊😮

[alex3305]

Ga alsjeblieft voor authenticatie en autorisatie niet zomaar uit van antwoorden van een taalmodel. Authentik - en anderen - zijn echt geen projectjes die zonder voorkennis binnen een middagje (veilig) in elkaar klust. Daarmee wil ik niet zeggen dat het niet kan, maar het is niet voor niets een apart kennisgebied. Ik heb (professionele) ervaring met legio authenticatie oplossingen en Authentik staat om eerlijk te zijn ook niet bijster hoog op mijn lijstje. Ik vind ook de oplossing met outposts niet zo denderend en enorm complex voor een homelab.

Als je met SSO / OAuth2 / OpenID Connect wilt starten kan ik Pocket ID aanraden. Dat is zo ongeveer de meeste simpele oplossing. Combineer die dan met zoiets als TinyAuth, oauth2-proxy of Caddy Security mits je Caddy gebruikt. Want simpeler dan dat wordt het eigenlijk niet. Een snippet uit mijn Caddyfile om mee te starten:

code:

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

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

            client_id <pocket-id-client-id>
            client_secret <pocket-id-client-secret>
            scopes openid email profile groups

            base_auth_url https://id.my.domain
            metadata_url https://id.my.domain/.well-known/openid-configuration

            delay_start 3
        }

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

            crypto default token lifetime 86400
            crypto key sign-verify 383aca9a-1c39-4d7a-b4d8-67ba4718dd3f

            cookie domain my.domain
            cookie insecure off

            cookie lifetime 172800

            ui {
                meta title "My Authentication Portal"
                meta author "alex3305"
                meta description "Authentication portal my homelab"

                links {
                    "View Me" "/whoami" icon "las la-user"
                }
            }

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

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

        authorization policy user_access {
            set auth url https://auth.my.domain/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 383aca9a-1c39-4d7a-b4d8-67ba4718dd3f

            allow roles user
            inject headers with claims
            validate bearer header
        }

        authorization policy admin_access {
            set auth url https://auth.my.domain/oauth2/pocket-id/authorization-code-callback
            crypto key sign-verify 383aca9a-1c39-4d7a-b4d8-67ba4718dd3f

            allow roles admin
            inject headers with claims
            validate bearer header
        }
    }
}

*.my.domain {
        @auth {
                host auth.my.domain
        }
        @pocket-id {
                host id.my.domain
        }

        handle @auth {
                authenticate with default-auth-portal
        }
        handle @pocket-id {
                @admin {
                        not remote_ip 192.168.0.0/16
                        path /settings/audit-log* /settings/admin*
                }
                handle @admin {
                        redir https://my.domain
                }

                reverse_proxy 10.0.1.33:1411
        }

        handle @adguard-home {
                authorize with admin_access
                reverse_proxy 10.0.1.29:3000
        }
}

In Pocket ID heb ik dan de groepen admin en user en die heb ik dus toegewezen aan een authorization policy. En heb ik dus Caddy als client toegevoegd:


Applicaties die zelf SSO ondersteunen hebben geen authorization policy nodig en zijn dus apart ingeregeld:


Mapping doe ik net zoals @Mars Warrior met Caddy en Caddy Docker Proxy en dat werkt prima.

[alex3305]

Tularis schreef op zondag 10 augustus 2025 @ 10:15:
Tja, portainer is een tool om het gemakkelijker te maken om je stacks te beheren via een web interface. Dat het niet alles netjes ondersteunt dat docker compose aanbiedt is op zich wel logisch. Niet alles is even makkelijk via het web te ontsluiten zonder verregaande toegang tot je systeem en het daarmee verhoogde risico dat je loopt.

Ik vind het zelf voornamelijk irritant dat Portainer - historisch - eigen jargon is gaan gebruiken die dus compleet afwijkt van Docker jargon. Daarmee is het soms voor, met name nieuwelingen, erg verwarrend. Dat is ook de reden dat ik hiervoor Dockge gebruik. Wordt helaas niet bijster veel bijgehouden, maar heb ik in mijn setup ook niet echt nodig.

Persoonlijk gebruik ik portainer meer als een tool om via het web gemakkelijk bij mijn docker instances te komen, niet om mijn stacks mee te beheren. Daar heb ik ssh en een text editor voor (of vs code over ssh, werkt ook best fijn).

Geen versiebeheer ?

Ik ben echt blij dat ik dat in Forgejo heb staan en met Ansible uitrol. Ik maak sinds een tijdje van mijn infra repo ook wekelijkse releases met tags:


Daarnaast genereert de workflow dan ook release notes zodat ik direct inzichtelijk heb wat waar en wanneer is gebeurt:

[Airw0lf]

@alex3305 - ik ben voornemens om Authelia (2FA en evet. SSO) en Authentik (IdP) in te zetten.
Maar begrijp het goed dat je deze functies liever met resp. Pocket-ID en Caddy Security invult?

[alex3305]

Afgelopen weken heb ik met mijn Docker omgeving weer wat stappen gemaakt. Sowieso heb ik op allebei mijn nodes nu correct IPvlan op een eigen VLAN ingericht. Normaliter ontsluit ik alles via Caddy en Swarm, maar sommige containers wil ik toch direct ontsluiten. Bijvoorbeeld DNS met AdGuard Home.

Ook heb ik geprobeerd om Caddy HA uit te voeren, maar dat is wisselend . Ik heb Caddy Docker Proxy met één Controller draaien en dan twee Server's. Als Compose projecten en dus niet als Swarm services. So far, so good. Maar ik krijg het maar niet voor elkaar om op een stabiele manier de (certificaat) data te delen. NFS leek mij de makkelijkste aanpak, maar dat heeft toch meer voeten in de aarde dan ik had verwacht.

Ik heb nog nagedacht over GlusterFS in een container. Alhoewel dat project niet dood zou moeten zijn, heeft het ook niet bijster veel leven meer. Een replicerende Redis / Valkey of S3 met Garage zou ook nog een optie kunnen zijn, maar vond ik ook niet heel voor de hand liggend. Met name omdat ik het liefste alles in Docker containers wil draaien. Dus ook de storage .

Het zou allemaal wel moeten kunnen, maar voelt voornamelijk als net-niet. Hoe doen jullie dit of heb ik nog dingen gemist?

Voor de goede orde, k3s/k8s is geen antwoord

[RobertMe]

alex3305 schreef op zondag 10 augustus 2025 @ 14:48:
Ga alsjeblieft voor authenticatie en autorisatie niet zomaar uit van antwoorden van een taalmodel. Authentik - en anderen - zijn echt geen projectjes die zonder voorkennis binnen een middagje (veilig) in elkaar klust. Daarmee wil ik niet zeggen dat het niet kan, maar het is niet voor niets een apart kennisgebied. Ik heb (professionele) ervaring met legio authenticatie oplossingen en Authentik staat om eerlijk te zijn ook niet bijster hoog op mijn lijstje.

Het gaat er natuurlijk ook nogal om waarvoor je het in zet. Volgens mij zijn zowel Authentik als Authelia gemaakt door "hobbyisten" die SSO wilden hebben voor hun self hosted services. Vanuit dat oogpunt maakt "absolute veiligheid" misschien niet zo veel uit. Zolang de services niet vanaf het internet bereikbaar zijn etc etc. Als je bv Home Assistant, Zigbee2mqtt, ZWave JS UI, Radarr, Sonarr, qBittorrent, Syncthing, ... lokaal hebt draaien, je bent de enige die het gebruikt / toegang moet hebben, en je wilt alles met 1 login kunnen openen hoeft het niet perse heel veilig te zijn. Zolang je het maar niet aan het internet hangt (dus een, goed beveiligde, VPN voor buiten de deur, en geen poorten open zetten).

Maar voor een profi opzet, of uberhaupt services die wel direct aan het internet hangen, zou ik deze "hobby" tools idd niet snel inzetten. Maar voor thuisgebruik met een VPN voor buiten de deur zijn de risico's, lijkt mij, ook niet enorm groot. (Note: ik gebruik geen SSO. Met één Ctrl + Shift + L (Bitwarden auto fill) ben ik toch wel ingelogd als er al een login op zit).

[alex3305]

Airw0lf schreef op zondag 10 augustus 2025 @ 14:59:
@alex3305 - ik ben voornemens om Authelia (2FA en evet. SSO) en Authentik (IdP) in te zetten.
Maar begrijp het goed dat je deze functies liever met resp. Pocket-ID en Caddy Security invult?

Caddy Security is inderdaad mijn SP en Pocket ID mijn IdP. Overigens back ik Pocket ID ook nog met lldap voor user management. Die gebruik ik dan ook weer in Forgejo en als PAM op mijn server(s).

Caddy met forward auth en Authelia heb ik ook nog overwogen, maar ik weet niet meer precies waarom ik dat niet heb ingezet.

Authentik vond ik echt enorm complex. Vooral omdat je direct geconfronteerd wordt (of werd) met 101 knopjes. Verder was het niet heel erg energiezuinig en nam het voor wat het moest doen relatief veel resources in. Keycloak heb ik professioneel ervaring mee en stond daarmee dus ook op de shortlist. Mooi product, maar voor thuis met Let's Encrypt vond ik het - zowat verplichte - certificaatmanagement enorm irritant. JetBrains Hub heb ik eveneens professioneel ervaring mee en werkt enorm simpel. Maar was overkill voor mijn situatie en OAuth2 voelt daarin als een tweederangs burger.

Er zijn nog wel andere opties, maar ik vind deze oplossing vooral stralen door eenvoud. En inloggen met passkeys - vanuit Vaultwarden - is gewoon heel erg makkelijk.

Wel heb ik nog een tijdje Dex gebruikt als federated IdP voor Google IAM. Dat werkte prima, behalve dan dat ik afhankelijk was van Google voor auth.

[alex3305]

RobertMe schreef op zondag 10 augustus 2025 @ 15:00:
Het gaat er natuurlijk ook nogal om waarvoor je het in zet. Volgens mij zijn zowel Authentik als Authelia gemaakt door "hobbyisten" die SSO wilden hebben voor hun self hosted services. Vanuit dat oogpunt maakt "absolute veiligheid" misschien niet zo veel uit.

Sure, maar ik merk dan ook enorme scope-creep. Met name bij Authentik. Terwijl Caddy Security door iemand ontwikkeld wordt die het eveneens professioneel verkoopt - en dus ook dergelijke support levert. Dat boezemt me dan toch wat meer vertrouwen in.

Zolang de services niet vanaf het internet bereikbaar zijn etc etc. Als je bv Home Assistant, Zigbee2mqtt, ZWave JS UI, Radarr, Sonarr, qBittorrent, Syncthing, ... lokaal hebt draaien [...] Maar voor een profi opzet, of uberhaupt services die wel direct aan het internet hangen, zou ik deze "hobby" tools idd niet snel inzetten.

Nou ja, (bijna) al die diensten hangen bij mij dus direct aan het internet .

Maar zoals ik al zei, ik heb hier ook redelijk wat professionele ervaring mee. Dat scheelt misschien .

[Yarisken]

Bedankt voor de tip rond pocketid Alex !
Ik gebruik Caddy enkel om een lokale statische website te hosten en dus nog niet als reverse proxy. Blij dat ook authenticatie mee kan opgevangen worden.

[alex3305]

Yarisken schreef op zondag 10 augustus 2025 @ 17:41:
Ik gebruik Caddy enkel om een lokale statische website te hosten en dus nog niet als reverse proxy. Blij dat ook authenticatie mee kan opgevangen worden.

Ik doe met Caddy ontzettend veel, vandaar dat ik het dus graag HA zou willen uitvoeren. Al was het maar voor de -factor.

Momenteel gebruik ik Caddy als Docker Proxy en authenticatie, zoals benoemd, maar ook voor Layer4 diensten. Dat geeft echt enorm veel opties. Bijvoorbeeld AdGuard Home:

YAML:

services:
  adguard-home:
    container_name: adguard-home
    image: adguard/adguardhome:v0.107.64
    ...
    labels:
      ...
      caddy_3.layer4.udp/:53.route.proxy: "udp/{{upstreams 53}}"
      caddy_4.layer4.tcp/:[e-mail]: "sni dns.example.com"
      caddy_4.layer4.tcp/:53.route: "@dns-over-tls"
      caddy_4.layer4.tcp/:53.route.1_tls: ""
      caddy_4.layer4.tcp/:53.route.2_proxy: "{{upstreams 53}}"
      caddy_5.layer4.:[e-mail]: "sni dns.example.com"
      caddy_5.layer4.:853.route: "@dns-over-tls"
      caddy_5.layer4.:853.route.1_tls: ""
      caddy_5.layer4.:853.route.2_proxy: "{{upstreams 53}}"

Of Forgejo:

YAML:

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:12.0.1
    ...
    labels:
      caddy: "git.example.com"
      [e-mail]: "git.example.com"
      caddy.handle: "@forgejo"
      caddy.handle.reverse_proxy: "{{upstreams 3000}}"
      caddy.layer4.:[e-mail]: ""
      caddy.layer4.:[e-mail]_ip: "192.168.0.0/16"
      caddy.layer4.:22.route: "@forgejo-ssh"
      caddy.layer4.:22.route.proxy: "{{upstreams 22}}"

Bij lldap doe ik dan ook de TLS termination (met dus SNI) met Caddy, waardoor ik dus in Pocket ID en Forgejo een versleutelde ldap kan gebruiken mét geldige certificaten.

Recent heb hiermee ik zelfs sssd geconfigureerd voor PAM authenticatie. Dat werkt goed op een van mijn servers, maar op mijn Pi kreeg ik dat gek genoeg niet werkend. Daar moet ik nog even achterheen. Maar door de dynamische configuratie kan ik dan ook redelijk snel bijvoorbeeld testen met een unencrypted ldap. Zo kan ik dus ook het e.e.a. snel uitsluiten. Dat vind ik heel prettig.

[Ghoulli]

@alex3305 Hier heb je een mooie setup aan, ik had geen idee dat Caddy zo uitgebreid was (heb er ook niet zo in verdiept moet ik bekennen). Ik heb momenteel Caddy in gebruik om SSL certificaten uit te delen voor websites die ik via de browser ook buitenshuis wil bereiken (reverse proxy). De LLDAP integratie vind ik wel een interessante, vooral omdat ik het toch al heb draaien.

[RobertMe]

alex3305 schreef op maandag 11 augustus 2025 @ 11:27:

YAML:

services:
  adguard-home:
    container_name: adguard-home
    image: adguard/adguardhome:v0.107.64
    ...
    labels:
      ...
      caddy_3.layer4.udp/:53.route.proxy: "udp/{{upstreams 53}}"
      caddy_4.layer4.tcp/:[e-mail]: "sni dns.example.com"
      caddy_4.layer4.tcp/:53.route: "@dns-over-tls"
      caddy_4.layer4.tcp/:53.route.1_tls: ""
      caddy_4.layer4.tcp/:53.route.2_proxy: "{{upstreams 53}}"
      caddy_5.layer4.:[e-mail]: "sni dns.example.com"
      caddy_5.layer4.:853.route: "@dns-over-tls"
      caddy_5.layer4.:853.route.1_tls: ""
      caddy_5.layer4.:853.route.2_proxy: "{{upstreams 53}}"

Of Forgejo:

YAML:

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:12.0.1
    ...
    labels:
      caddy: "git.example.com"
      [e-mail]: "git.example.com"
      caddy.handle: "@forgejo"
      caddy.handle.reverse_proxy: "{{upstreams 3000}}"
      caddy.layer4.:[e-mail]: ""
      caddy.layer4.:[e-mail]_ip: "192.168.0.0/16"
      caddy.layer4.:22.route: "@forgejo-ssh"
      caddy.layer4.:22.route.proxy: "{{upstreams 22}}"

Ziet er wel uit als veel abracadabra, en niet als 2 regels.
Sorry @Mars Warrior, had to do it

Overigens kan Traefik bij mijn weten ook overweg met puur UDP & TLS (naast HTTP over TCP of UDP dan). Incl SNI achtige toestanden. Alleen bij protocollen met STARTTLS (SMTP en zo) kan die dat niet (altijd? Postgres meen ik ergens gezien te hebben van wel). Omdat in ieder geval SMTP & IMAP (& vermoed ook POP) ook moeten aangeven dat ze het ondersteunen. Waarbij in ieder geval SMTP IIRC weer eerst een HELO / EHLO heen en weer vereist voordat de server uberhaupt aangeeft welke features die ondersteund (waaronder dus STARTTLS). Daardoor zou Traefik dus een (zeer beperkte) subset van SMTP moeten ondersteunen puur om dit stukje flow te doorlopen.

[alex3305]

@RobertMe Ik ga niet tussen jou en @Mars Warrior inzitten hè . Mij zal het een spreekwoordelijke Unox worst wezen welke reverse proxy je gebruikt.

Caddy Docker Proxy is echt niet heilig. Voornamelijk niet wanneer je ook maar iets buiten de gebaande paden wil gaan. Layer4 wordt 'ondersteund', maar een mapping op IP-adres of hostname werkt niet mooi issue nummer trouwens . Ook vind ik de mapping, met name in lijsten, niet altijd voor de hand liggend. Er zijn namelijk prefix-nummers en suffix-nummers. En daarnaast moet je de nummering zelf doen en bijhouden. Dat vind ik behoorlijk brak.

Ook gebruik ik wildcard certificaten voor het ontsluiten van diensten. Dat werkt prima, totdat er een label ergens de mist in vliegt. Dan krijg ik in de terminal een minified JSON die ik dan maar moet ontleden om te debuggen. Dat is waardeloos.

Aan de andere kant is Traefik (let op: mening) enorm gericht op de grotere setups en enterprise en daardoor passen soms ook de blokjes niet echt lekker in mijn homelab. Ik heb meer dan een jaar Traefik naar volle tevredenheid gebruikt overigens. Ik ben toen gewisseld omdat ik X-Forwarded-For met Cloudflare IP's niet lekker werkend kreeg. Ik weet niet hoe het nu zit, maar ik moest dat destijds handmatig instellen. Dat vond ik nogal ruk. Voor Caddy is daar een plugin voor. Onder water natuurlijk hetzelfde, maar het gevoel is anders. Naderhand bleek dit overigens een Home Assistant probleem te zijn. En had dit met de volgorde van headers te maken. Uiteindelijk heb ik dus nog steeds handmatige configuratie .

De Caddy Layer4 integratie vind ik voornamelijk een erg interessante quick-win, zoals de door mij geïllustreerde Adguard Home. Tegelijkertijd vind ik de documentatie daarvan ook extreem summier en is het daardoor ook niet iets om mee te starten.

Mijn voorkeur zou uitgaan naar zoiets als Consul vanuit Docker labels voor service management. Ik heb daar wel over nagedacht en ook overwogen om zelf iets in elkaar te zetten, maar Consul vereist een 3 node cluster en dat heb ik al niet. Het is bij - zowel Caddy als Traefik - voornamelijk ellendig dat je van een formaat naar een ander formaat gaat, waarbij het allebei niet helemaal lekker past.

[alex3305]

@Ghoulli Wat ik eigenlijk had onderschat en uiteindelijk wel een super mooie quick win vond, was dat ik mijn SSH sleutel en groepenbeheer ook in de LDAP kan doen. Dit wordt dan - na sync - automatisch gebruikt in Forgejo en voor PAM-authenticatie. Het fijne is dat ik daar dan ook nauwelijks omkijken naar heb en was verrassend eenvoudig.

[Ghoulli]

alex3305 schreef op maandag 11 augustus 2025 @ 13:28:
@Ghoulli Wat ik eigenlijk had onderschat en uiteindelijk wel een super mooie quick win vond, was dat ik mijn SSH sleutel en groepenbeheer ook in de LDAP kan doen. Dit wordt dan - na sync - automatisch gebruikt in Forgejo en voor PAM-authenticatie. Het fijne is dat ik daar dan ook nauwelijks omkijken naar heb en was verrassend eenvoudig.

SSH Sleutel lekker in LDAP knallen is wel lekker, scheelt ook weer extra bijhoud werk. Denk dat ik me er vanavond eens in ga verdiepen, want ik zie alleen maar voordelen zo. Hopelijk niet te veel werk, maar krijg er wel jeukende handen van

[sjorsjuhmaniac]

@alex3305 wat is je probleem met caddy als proxy voor ha? Ha gewoon als http configureren en caddy als proxy ervoor zou gewoon moeten werken. Zo draai ik het hier al jaren, met nginx dan weliswaar

[alex3305]

@sjorsjuhmaniac Ik heb geen enkel probleem met Caddy of enig andere service te proxy'en. Maar ik denk dat je mijn post nogmaals eens begrijpend moet lezen :

alex3305 schreef op zondag 10 augustus 2025 @ 14:59:
Ook heb ik geprobeerd om Caddy HA uit te voeren [...]

Ik bedoel met HA hier natuurlijk niet Home Assistant, maar High Availability.

Ik wil namelijk mijn reverse proxy HA uitvoeren om o.a. config reloads te ondervangen. Het balancen of failover zou ik in kunnen regelen met een shared ip door middel van een ipvlan mapping met keepalived in een container. Dan heb ik ook maar één DNS entry nodig, omdat round robin DNS blijkbaar niet werkt vanuit Unifi. Echter moeten beide Caddy instanaties de certificaat data kunnen delen om geen dubbele aanvragen te doen. Dat kreeg ik over NFS niet correct werkend, vandaar dat ik op zoek ben naar een gedeelde (duplicerende) opslag voor Docker.

[Dennis]

Ghoulli schreef op maandag 11 augustus 2025 @ 11:36:
@alex3305 Hier heb je een mooie setup aan, ik had geen idee dat Caddy zo uitgebreid was (heb er ook niet zo in verdiept moet ik bekennen). Ik heb momenteel Caddy in gebruik om SSL certificaten uit te delen voor websites die ik via de browser ook buitenshuis wil bereiken (reverse proxy). De LLDAP integratie vind ik wel een interessante, vooral omdat ik het toch al heb draaien.

Wat doe je dan precies? Wie maakt die certificaten/hoe doe je dat? Ik gebruik zelf ejbca maar dat is geheel handmatig. Ik heb ook WPA2 enterprise wifi (moet nog overstappen naar WPA3) met certificaten voor mijn beveiligde netwerk.

[Ghoulli]

Dennis schreef op maandag 11 augustus 2025 @ 19:41:
[...]

Wat doe je dan precies? Wie maakt die certificaten/hoe doe je dat? Ik gebruik zelf ejbca maar dat is geheel handmatig. Ik heb ook WPA2 enterprise wifi (moet nog overstappen naar WPA3) met certificaten voor mijn beveiligde netwerk.

Ik heb in Caddy aangegeven via mijn Caddyfile welk (sub)domain name er aan welke port gekoppeld is. Ik heb een eigen domain name gekocht bij Cloudflare. Zie deze video voor een uitleg zoals ik het ook heb gedaan.

[ Voor 3% gewijzigd door Ghoulli op 12-08-2025 08:54 ]

[Dennis]

Ghoulli schreef op dinsdag 12 augustus 2025 @ 08:42:
Ik heb in Caddy aangegeven via mijn Caddyfile welk (sub)domain name er aan welke port gekoppeld is. Ik heb een eigen domain name gekocht bij Cloudflare. Zie deze video voor een uitleg zoals ik het ook heb gedaan.

Het ging me meer om hoe je de certificaten aanmaakt. Of je dat via ACME/Let's Encrypt doet of anderszins .

[sjorsjuhmaniac]

Dennis schreef op dinsdag 12 augustus 2025 @ 09:47:
[...]

Het ging me meer om hoe je de certificaten aanmaakt. Of je dat via ACME/Let's Encrypt doet of anderszins .

https://caddyserver.com/docs/automatic-https

Gewoon het standaard verhaal van ACME en LE. Andere providers zijn mogelijk.

[Ghoulli]

@Dennis zoals @sjorsjuhmaniac dit inderdaad al aangeeft, het standaard verhaal. Bij mij regelt LE het. Ik hoef echt verder niks te doen behalve de Caddyfile correct instellen, de rest word voor me geregeld (Lekker luxe hé )

[ Voor 37% gewijzigd door Ghoulli op 12-08-2025 10:17 ]

[Mars Warrior]

Je definieert in Caddy simpelweg een domein of subdomein en Caddy doet de rest via LE of ZeroSSL.

[alex3305]

Ik ben van mijn eerdere mening teruggekomen en ben inmiddels van Caddy naar Traefik gewisseld. Ik bleef maar kleine frustraties houden die groter en groter werden.

Ik gebruikte Caddy met de hier bekende Docker labels plugin met wildcard certificaten. Als er echter ergens een configuratiefout voorkwam, zorgde dat ervoor dat alle diensten onder die gebruik maakte van dat certificaat onbereikbaar waren. Dit komt door de opzet van Caddy:

code:

*.example.com {
    @adguard-home {
        host dns.example.com
    }

    ... andere domain matchers hier ...

    handle @adguard-home {
        reverse_proxy http://10.1.28.3:3000
    }

    ... andere reverse proxy configuratie hier ...
}

Want bij problemen wordt dan door Caddy of de Caddy Docker Proxy het hele *.example.com configuratie blok weggelaten. Tegelijkertijd kreeg ik dan deze configuratie als minified JSON in de terminal / Docker logs . Het debuggen daarvan was op z'n zachtst gezegd irritant.

Ook bleef ik vage kleine problemen houden. Websockets verbonden bijvoorbeeld niet altijd opnieuw bij connectieproblemen. Hier had ik last van als ik thuiskwam met Home Assistant. De Caddy container crashte soms zonder reden. En soms startte Caddy ook niet op. Wederom zonder foutmelding of informatie.

De druppel was voor mij dat de Caddy Layer4 plugin onlangs niet meer werkte en daar een GitHub discussie op volgde. De Caddy ontwikkelaars noemde de Layer4 plugin experimenteel en niet geschikt voor productie met als klap op de vuurpijl een sarcastische opmerking dat ik "niet goed, geld terug"-garantie zou hebben .

Inmiddels ben ik over naar Traefik en alles is weer koek en ei . De positieve punten:

• Docker labels worden out-of-the-box ondersteund
• Meerdere configuratiebronnen mogelijk
• Plug-ins gaan via configuratie, dus geen custom Docker image nodig
• Minder Docker labels nodig voor vergelijkbare configuratie

Het nadeel is wel dat meerdere Docker hosts zonder Swarm deployments alleen werken met een third-party tool: Traefik-kop. Geen grote ramp omdat het e.e.a. best eenvoudig in opzet is, maar dat had wel even wat uitzoekwerk nodig.

Met name door standaard te definiëren configuratie heb ik een stuk minder labels nodig en dat vind ik enorm prettig. Ook hoef ik de labels niet meer te nummeren of zijn er rare edge-cases. Bijvoorbeeld dat punten in labels bijwerkingen kunnen hebben.

Voor en na voorbeelden...

Caddy labels

YAML:

services:
  adguard-home:
    container_name: adguard
    image: adguard/adguardhome:v0.107.67
    labels:
      caddy: "*.example.com"
      [e-mail]: "dns.example.com"
      caddy.handle: "@adguard-home"
      caddy.handle.crowdsec: ""
      caddy.handle.authorize: "with admin_access"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 3000{{ '}}' }}"
      caddy.layer4.udp/:53.route.proxy: "udp/{{ '{{' }}upstreams 53{{ '}}' }}"
      caddy.layer4.:[e-mail]: "sni dns.example.com"
      caddy.layer4.:853.route: "@dns-over-tls"
      caddy.layer4.:853.route.1_tls: ""
      caddy.layer4.:853.route.2_proxy: "{{ '{{' }}upstreams 53{{ '}}' }}"

  pocket_id:
    container_name: pocket_id
    image: ghcr.io/pocket-id/pocket-id:v1.13.1
    labels:
      caddy: "*.example.com"
      caddy.@pocket_id.host: "id.example.com"
      caddy.handle: "@pocket_id"
      caddy.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"

Traefik labels

YAML:

services:
  adguard-home:
    container_name: adguard
    image: adguard/adguardhome:v0.107.67
    labels:
      traefik.enable: true
      traefik.http.routers.adguard-home.rule: "Host(`dns.example.com`)"
      traefik.http.routers.adguard-home.middlewares: "crowdsec@file, oidc-auth@file"
      traefik.http.services.adguard-home.loadbalancer.server.port: 3000
      traefik.udp.routers.dns-router.entryPoints: dns
      traefik.udp.routers.dns-router.service: dns-service
      traefik.tcp.routers.dns-over-tls-router.tls: true
      traefik.tcp.routers.dns-over-tls-router.rule: "HostSNI(`dns.example.com`)"
      traefik.tcp.routers.dns-over-tls-router.entryPoints: dns-over-tls
      traefik.tcp.routers.dns-over-tls-router.service: dns-service
      traefik.tcp.services.dns-service.loadbalancer.server.port: 53

  pocket_id:
    container_name: pocket_id
    image: ghcr.io/pocket-id/pocket-id:v1.13.1
    labels:
      traefik.enable: true
      traefik.http.routers.pocket_id.rule: "Host(`id.example.com`)"

De leercurve van Traefik is wel redelijk steil. Bij Caddy is het starten een stuk makkelijker. Wel zijn de foutmeldingen (ergernis) bij Traefik kort, bondig en duidelijk. Ook bij third party plugins, zoals Traefik OIDC. Het dashboard en middlewares zijn eveneens een verademing. Dat geeft veel meer inzicht in hoe flows lopen.

Ik ben vooralsnog blij dat ik de switch heb gemaakt. Maar het zal vast over een tijdje wel weer gaan kriebelen .

[alex3305]

Naast Traefik ben ik ook bezig met observability van mijn platformen en Docker platformen. Ik heb al een tijdje Beszel draaien en alhoewel dat prima werkt, mis ik toch wat metrics. Het is soms simpelweg net iets te ver uitgekleed. Ik ben dus weer aan het kijken naar Prometheus + Grafana en heb dat daarom recent weer eens aangeslingerd.

Prometheus, Grafana en de node exporters lopen inmiddels prima. Maar ik wil toch wat Docker monitoring toevoegen. Normaal zou ik daar cAdvisor voor gebruiken, ware het niet dat ik daar elke keer problemen mee heb. Sowieso gebruikt die container soms ineens veel CPU of geheugen. Tegelijkertijd kloppen de metrics niet lijkt het . Gister had ik dat mijn Kopia (backup) tool een uurtje 20% CPU gebruikte, terwijl cAdvisor niet eens load leek te detecteren.

Ik had ook nog gekeken naar Docker Exporter, en die waardes lijken zinniger. Maar ik ben benieuwd of ik nu nog iets over het hoofd zie? Of dat ik iets anders kan proberen?

[DjoeC]

@alex3305 Wat doen Caddy / Traefik eigenlijk "beter" dan NPM?

Ik moet eerlijk zeggen dat ik met NPM prima uit de voeten kan, zowel met toevoegen van hosts, redirects, certificaten als access lists als - tja, ik heb nog niks gemist of gevonden dat niet werkt of echt complex is. Maar misschien doe ik alleen maar simpele dingen?

[alex3305]

@DjoeC Kort antwoord: niets. Maar dat is natuurlijk niet de hele waarheid .

Het heeft simpelweg met de hele use-case te maken. Ik wil geen tweede administratie hebben in NPM. Ik wil dat in code doen met bijvoorbeeld Docker labels. Aangezien ik mijn services deploy met Docker Compose, Ansible en Forgejo Actions is dat een stuk beter beheersbaar dan NPM. Ook gebruik ik Renovate voor gecontroleerd versiebeheer. Hierdoor is mijn hele setup transparant, reproduceerbaar en idempotent.

Tegelijkertijd zijn ACL's voor mij veel en veel te beperkt. Ik heb een aardig complete SSO setup waardoor ik nog maar heel af en toe filter op basis van IP's. Toegang wordt gegeven op basis van rollen vanuit LDAP die propageren naar Pocket ID zodat deze ook gebruikt kunnen worden in OIDC clients. Attributen worden eveneens gesynct. Waaronder naam, foto en publieke SSH sleutel. Waarbij ik die laatst ook gebruik in Forgejo.

Ik heb het even in een flowchart gezet om het e.e.a. duidelijk te maken .

[DjoeC]

@alex3305 Tja, jouw setup is wat anders van opzet..... Voorlopig zit ik ook nog niet aan "meerdere" gebruikers en dus rollen. Er is maar 1 rol: Ikke....

[Mars Warrior]

alex3305 schreef op dinsdag 7 oktober 2025 @ 15:02:
Naast Traefik ben ik ook bezig met observability van mijn platformen en Docker platformen. Ik heb al een tijdje Beszel draaien en alhoewel dat prima werkt, mis ik toch wat metrics. Het is soms simpelweg net iets te ver uitgekleed. Ik ben dus weer aan het kijken naar Prometheus + Grafana en heb dat daarom recent weer eens aangeslingerd.

Prometheus, Grafana en de node exporters lopen inmiddels prima. Maar ik wil toch wat Docker monitoring toevoegen. Normaal zou ik daar cAdvisor voor gebruiken, ware het niet dat ik daar elke keer problemen mee heb. Sowieso gebruikt die container soms ineens veel CPU of geheugen. Tegelijkertijd kloppen de metrics niet lijkt het . Gister had ik dat mijn Kopia (backup) tool een uurtje 20% CPU gebruikte, terwijl cAdvisor niet eens load leek te detecteren.

Ik had ook nog gekeken naar Docker Exporter, en die waardes lijken zinniger. Maar ik ben benieuwd of ik nu nog iets over het hoofd zie? Of dat ik iets anders kan proberen?

Ik monitor - heel simpel - enkel CPU en diskverbruik via Telegraf, die het in Influxdb ramt waar ik ook het dashboard van gebruik. Mijn eerdere ervaringen met tools die 50 docker containers monitoort is dat mijn zuinige server geen zuinige server meer is: de monitoring kost factoren meer CPU tijd dan 50 containers.

Nu heb ik DEX nog nooit gebruikt, maar Prometheus is voor mij altijd een no-go vanweg het absurde CPU en Disk gebruik. Voorheen kreeg Prometheus het voor elkaar om één enkele E-core 100% te belasten.

[Mars Warrior]

DjoeC schreef op dinsdag 7 oktober 2025 @ 17:33:
@alex3305 Tja, jouw setup is wat anders van opzet..... Voorlopig zit ik ook nog niet aan "meerdere" gebruikers en dus rollen. Er is maar 1 rol: Ikke....

Je kunt heel Treafik OIDC gewoon overslaan / niet gebruiken. Dan blijft de rest over voor een simpelere setup.

[Mars Warrior]

alex3305 schreef op dinsdag 7 oktober 2025 @ 14:57:
Ik ben van mijn eerdere mening teruggekomen en ben inmiddels van Caddy naar Traefik gewisseld. Ik bleef maar kleine frustraties houden die groter en groter werden.

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

Ik heb eerder / vaker met Treafik gespeeld en gewerkt, maar vind dat nog steeds een enorm waterhoofd. Dat zal ook nooit verbeteren dus anders worden: Traefik heeft wat meer "specificaties" nodig om zijn werk te doen dat natuurlijk komt door de vele routeer/filter mogelijkheden.

Gelukkig - voor mij - zijn er tegenwoordig chatbots waar ik gewoon een compose file met Caddy labels inpleur, en waar een - vaak in 1 keer werkende - Traefik versie uit komt rollen.
Natuurlijk moet je daarna ff kijken wat je in files gooit om alles eenduidig te houden, maar ook dat is zo'n chatbot wel wijs te maken.

Chatbots kunnen van bergen technische documentatie zonder ook maar enige samenhang tenminste iets samenhangends van maken. Lang leve die vooruitgang als techneuten dat nalaten

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

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

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

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

[RobertMe]

Mars Warrior schreef op dinsdag 7 oktober 2025 @ 17:50:
maar Prometheus is voor mij altijd een no-go vanweg het absurde CPU en Disk gebruik. Voorheen kreeg Prometheus het voor elkaar om één enkele E-core 100% te belasten.

VictoriaMetrics zou ook een optie kunnen zijn. Kan dezelfde metrics endpoints scrapen, heeft "push" support op basis van het Influx protocol, en kan gequeried worden op basis van "MetricQL", dat zoals de naam al doet vermoeden, gebaseerd is op PromQL, van Prometheus.

* RobertMe draait nu een tijd VM op "de" VPS en data (vanaf zelfbouw router, servertje, ...) gaat er naartoe op basis van Telegraf. Geen idee hoe het met CPU gebruik zit, want draait toch buiten de deur .

[alex3305]

DjoeC schreef op dinsdag 7 oktober 2025 @ 17:33:
@alex3305 Tja, jouw setup is wat anders van opzet..... Voorlopig zit ik ook nog niet aan "meerdere" gebruikers en dus rollen. Er is maar 1 rol: Ikke....

Er zitten wat meer voordelen aan mijn setup en aan de OIDC laag dan wellicht op eerste gezicht duidelijk is. Uiteindelijk heb ik twee gebruikers en de rollen zijn vooral voor de show. Maar ik kan nu wel...

• diensten met OAuth2 of OIDC ondersteuning afzonderlijk beveiligen
• diensten met Trusted Header / Forwarded Header beveiligen
• diensten zonder authenticatie beveiligen

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

Vergeet ook niet dat het ook om een hobby gaat. En dan mag er best wat tijd en moeite in zitten . Mocht je er mee willen spelen kan ik Pocket ID ten zeerste aanraden.

[alex3305]

Mars Warrior schreef op dinsdag 7 oktober 2025 @ 17:50:
[...]

Ik monitor - heel simpel - enkel CPU en diskverbruik via Telegraf, die het in Influxdb ramt waar ik ook het dashboard van gebruik. Mijn eerdere ervaringen met tools die 50 docker containers monitoort is dat mijn zuinige server geen zuinige server meer is: de monitoring kost factoren meer CPU tijd dan 50 containers.

Beszel doet dat wel goed. Is enorm zuinig in mijn ervaring.

Telegraf had ik nog niet aan gedacht. Goede tip. Ik heb lang InfluxDB gebruikt voor Home Assistant, maar vond het visualiseren altijd een beetje net-niet. Dat vind of vond ik van Grafana ook. Vooral omdat daar altijd de edit mode aanstond en omdat je er teveel in kunt. Soms is beperken de beste optie, maar daar zal niet iedereen het met me eens zijn.

Ook wilde ik wat logs naar een centraal punt brengen. Vandaar dat ik bij LGTM en dan nu Loki en Grafana uitkwam. Maar wat een enorm geklooi is dat om een beetje werkend en gevisualiseerd te krijgen. Vooral omdat nu promtail deprecated is en Grafana Alloy gebruikt dient te worden. Daar loop ik niet voor warm...

Nu heb ik DEX nog nooit gebruikt, maar Prometheus is voor mij altijd een no-go vanweg het absurde CPU en Disk gebruik. Voorheen kreeg Prometheus het voor elkaar om één enkele E-core 100% te belasten.

Prometheus heb ik op mijn secundaire J4105 machine staan en daar verbruikt het zeer weinig. Volgens Node Exporter 3% load in idle waarvan Prometheus 0.5% zou zijn. Dat is verwaarloosbaar.

cAdvisor gebruikte gisteren op mijn 13500 20% CPU . Dat gaat 'em, zoals in de business zeggen, niet worden .

[DjoeC]

alex3305 schreef op dinsdag 7 oktober 2025 @ 19:39:
[...]
Vergeet ook niet dat het ook om een hobby gaat. En dan mag er best wat tijd en moeite in zitten . Mocht je er mee willen spelen kan ik Pocket ID ten zeerste aanraden.

Eens, maar ik heb nog andere hobbies en ook nog wat verplichtingen die ook tijd vreten.....

Maar dank voor de tips!

[alex3305]

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

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

code:

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

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

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

Docker Compose

YAML:

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

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

  ipvlan:
    name: br0
    external: true

  monitoring:
    name: monitoring
    external: true

volumes:
  logs:
    name: traefik-logs

traefik.yaml

YAML:

api:
  dashboard: True
  insecure: True

entryPoints:
  web:
    address: ":80"

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

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

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

    http3:
      advertisedPort: 443

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

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

providers:
  providersThrottleDuration: 15s

  file:
    directory: "/configs"

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

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

metrics:
  prometheus: {}

configs/middlewares.yaml

YAML:

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

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

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

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

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

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

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

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

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

YAML:

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

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

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

  forgejo:
    name: forgejo
    attachable: true
    driver: overlay

  ingress:
    name: swarm-overlay
    external: true

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

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

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

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

[orvintax]

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

• diensten zonder authenticatie beveiligen

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

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

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

[alex3305]

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

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

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

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

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

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

Docker Compose

YAML:

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

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

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

  ipvlan:
    name: br0
    external: true

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

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

Caddyfile

code:

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

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

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

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

            delay_start 3
        }

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

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

            cookie domain example.com
            cookie insecure off

            cookie lifetime 172800

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

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

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

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

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

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

            allow roles user

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

            validate bearer header
        }

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

            allow roles admin

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

            validate bearer header
        }
    }
}

Waarna diensten zeer eenvoudig beveiligd kunnen worden met authorization policies:

YAML:

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

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