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

[begintmeta]

Klopt inderdaad, ik had inmiddels ook een reeks containers, bijvoorbeeld
/volume1/docker/navidrome
met daaronder dan een docker-compose-file en eventuele persistant bind-mount dirs (voor navidrome bijvoorbeeld /volume1/docker/navidrome/data... maar dat kunnen er ook meer zijn.
Eventueel ook nog een subdirectory met de source-dockerfile als ik een eigen container heb gemaakt.

Maar het is best een gedoe om precies uit te zoeken welke dingen in de container precies persistent moeten zijn. (cache meestal niet, spool directories wel... maar waar en welke... is altijd een uitzoekwerkje heb ik al gemerkt)

[orvintax]

Shadow771 schreef op maandag 13 februari 2023 @ 13:51:
[...]


Ja idd. thanks voor de verduidelijking .. Zo heb ik bijv:

/volume1/docker/AdGuard1
/volume1/docker/AdGuard2
/volume1/docker/qbittorrent
/volume1/docker/nordvpn1
/volume1/docker/nordvpn2
/volume1/docker/nordvpn3
/volume1/docker/privoxy1
/volume1/docker/privoxy2
/volume1/docker/privoxy3
/volume1/docker/nginx-proxy-manager
/volume1/docker/nextcloud
/volume1/docker/mariadb

Ik weet niet of dit een synology ding is. Maar normaliter maak je de volumes per container aan. Niet één volume voor al je containers.

[begintmeta]

Synology DSM doet in de eigen docker-interface alleen aan bind-mounts... volume1=de synology volume, docker=de docker-directory, qbittorrent is een gebind-mounte directory voor qbittorrent vermoed ik

Heb net gemerkt dat het ook best wel een gedoe is om al het verkeer tussen de containers te versleutelen (bijvoorbeeld tussen diverse containers en de postgresql-container). Maar dat lijkt me op zich wel beter om te doen, dus zal het ondanks wat extra gedoe maar doen.

[orvintax]

begintmeta schreef op maandag 13 februari 2023 @ 20:07:
Synology DSM doet in de eigen docker-interface alleen aan bind-mounts... volume1=de synology volume, docker=de docker-directory, qbittorrent is een gebind-mounte directory voor qbittorrent vermoed ik

Heb net gemerkt dat het ook best wel een gedoe is om al het verkeer tussen de containers te versleutelen (bijvoorbeeld tussen diverse containers en de postgresql-container). Maar dat lijkt me op zich wel beter om te doen, dus zal het ondanks wat extra gedoe maar doen.

Maar als je maar een enkele host hebt dan gaat het verkeer toch helemaal niet over het netwerk? Wat heb je dan aan die versleuteling?

[begintmeta]

orvintax schreef op maandag 13 februari 2023 @ 20:26:
[...]

Maar als je maar een enkele host hebt dan gaat het verkeer toch helemaal niet over het netwerk? Wat heb je dan aan die versleuteling?

Niet superbelangrijk in de praktijk (voor mij) denk ik maar: als de versleuteling er alvast zit, kost het geen moeite om containers naar verschillende hosts te verplaatsen (en dat kan damn wat sneller) en: verkeer tussen containers kan eventueel door een andere (gecompromiteerde) container gesnift worden vziw (afhankelijk van wat permissies en zo).

[Jazco2nd]

begintmeta schreef op maandag 13 februari 2023 @ 20:31:
[...]

Niet superbelangrijk in de praktijk (voor mij) denk ik maar: als de versleuteling er alvast zit, kost het geen moeite om containers naar verschillende hosts te verplaatsen (en dat kan damn wat sneller) en: verkeer tussen containers kan eventueel door een andere (gecompromiteerde) container gesnift worden vziw (afhankelijk van wat permissies en zo).

Ik snap dit niet. Op welk niveau verwacht je die versleuteling dan dat dit een dergelijke bescherming biedt?

[begintmeta]

Jazco2nd schreef op maandag 13 februari 2023 @ 21:00:
[...]

Ik snap dit niet. Op welk niveau verwacht je die versleuteling dan dat dit een dergelijke bescherming biedt?

stel dat ik een container met Postgresql heb en eenn container met app A en een container met app B. De app-containers maken gebruik van postgres. Ze zitten allemaal in hetzelfde docker-netwerk. Apps A en B openen een poort naar buiten, postgres alleen naar het docker-netwerkje.

Dan zou het volgens mij zo kunnen zijn dat container app A, indien gecompromitteerd, kan luisteren naar verkeer tussen container app B en postgres, tenzij dat is versleuteld (en mits bepaalde (vrij standaard) docker-permissies gegeven zijn).

Maar goed ik moet me er eerloijk gezegd nog wel beter in verdiepen, dus als het anders zit hoor ik dat natuurlijk graag.

[RobertMe]

begintmeta schreef op maandag 13 februari 2023 @ 22:44:
[...]

stel dat ik een container met Postgresql heb en eenn container met app A en een container met app B. De app-containers maken gebruik van postgres. Ze zitten allemaal in hetzelfde docker-netwerk. Apps A en B openen een poort naar buiten, postgres alleen naar het docker-netwerkje.

Dan zou het volgens mij zo kunnen zijn dat container app A, indien gecompromitteerd, kan luisteren naar verkeer tussen container app B en postgres, tenzij dat is versleuteld (en mits bepaalde (vrij standaard) docker-permissies gegeven zijn).

Maar goed ik moet me er eerloijk gezegd nog wel beter in verdiepen, dus als het anders zit hoor ik dat natuurlijk graag.

Containers communiceren met elkaar via een bridge. En ik mag toch aannemen dat een bridge werkt als een switch, en niet als een hub. Oftewel: dat verkeer alleen op die poort wordt gestuurd waarvan bekend is dat de bestemming zich daar bevindt, tegenover "gooi alle inkomende verkeer op alle poorten". Want dat laatste zou voor elke container een shitload aan extra verkeer opleveren dat vervolgens toch weer gefilterd wordt.
En in dat geval is het dus ook onmogelijk om (singlecast) verkeer tussen twee containers op dezelfde bridge (/docker netwerk) te sniffen. Immers zal de bridge het verkeer al niet naar de container sturen. En de compromised container heeft geen toegang tot de bridge omdat deze zich in een andere network namespace bevind.

[lolgast]

@begintmeta Het is trouwens ‘best-practise’ om elke app een eigen db-container te geven. Waarom zou je je db-container sharen

[Webgnome]

@lolgast waarom zou je het niet doen? Als je 3 containers hebt met maar 3 databases van een paar MB wat win je dan precies met het containeren van die 3 servers? Mocht een van de 3 database echt teveel gaan vragen dan kun je alsnog een extra nieuwe container opzetten voor die specifieke instance? En met fatsoenlijke rechten structuur kun je het gewoon goed afschermen

[Voor 10% gewijzigd door Webgnome op 14-02-2023 07:31]

[lolgast]

- Omdat je dan geen gedoe hebt met eventuele versie ondersteuning bij verschillende apps
- Omdat je dan geen gedoe hebt met eventuele vulnerabilities en het besmetten van meerdere databases
- Omdat (zolang de versies wél hetzelfde zijn) de extra footprint nagenoeg non-existent is
- Omdat als je een HA cluster gebruikt en je wellicht sommige software en databases altijd op dezelfde host wilt hebben en dat voor andere niet/minder belangrijk is
- Omdat het hele idee van Docker en het gebruiken van containers het opsplitsen van services is. Waarom zou je wel de moeite nemen om je app en database te scheiden, maar vervolgens wel alle databases op 1 hoop gooien?
- Omdat als je je database containers scheidt en elk een eigen bridge netwerk geeft met de corresponderende app je helemaal niet meer na hoeft te denken over rechten binnen de databases, dat doet Docker al voor je

Ik kan maar 1 reden bedenken om het níet te doen. "Gemak". En zelfs dat durf ik te betwisten.

[orvintax]

Webgnome schreef op dinsdag 14 februari 2023 @ 07:31:
@lolgast waarom zou je het niet doen? Als je 3 containers hebt met maar 3 databases van een paar MB wat win je dan precies met het containeren van die 3 servers? Mocht een van de 3 database echt teveel gaan vragen dan kun je alsnog een extra nieuwe container opzetten voor die specifieke instance? En met fatsoenlijke rechten structuur kun je het gewoon goed afschermen

Buiten dat ik hier geen voordeel in zie, gaat dit echt volledig tegen het principe van (Docker) containerisatie in. Het mooie is juist dat je alles per applicatie in die container/containers hebt zitten. Als je dan vervolgens de verschillende containers van de verschillende applicaties aan elkaar gaat knopen heb je dat niet meer, want ze zijn van elkaar afhankelijk. En dat word op den duur echt een zooitje.

[begintmeta]

Daar zit op zich wel wat in, ben er niet echt met een container-mentaliteit ingegaan (omdat ik gewoon ff snel mijn actuele server wil vervangen)....

Zal de boel tzt maar migreren naar wat meer bridge-netwerken en database-containers. Alleen de reverse-https-proxy en ik denk ook een ClamAV-service is uiteindelijk denk ik wel iets dat ik aan meerdere containers zal koppelen.

[Voor 4% gewijzigd door begintmeta op 14-02-2023 17:40]

[Shadow771]

lolgast schreef op dinsdag 14 februari 2023 @ 09:44:
- Omdat het hele idee van Docker en het gebruiken van containers het opsplitsen van services is. Waarom zou je wel de moeite nemen om je app en database te scheiden, maar vervolgens wel alle databases op 1 hoop gooien?

...

Ik kan maar 1 reden bedenken om het níet te doen. "Gemak".

orvintax schreef op dinsdag 14 februari 2023 @ 13:46:
[...]

Buiten dat ik hier geen voordeel in zie, gaat dit echt volledig tegen het principe van (Docker) containerisatie in. Het mooie is juist dat je alles per applicatie in die container/containers hebt zitten. Als je dan vervolgens de verschillende containers van de verschillende applicaties aan elkaar gaat knopen heb je dat niet meer, want ze zijn van elkaar afhankelijk. En dat word op den duur echt een zooitje.

Zeggen jullie dit ook bijv tegen de developers van MailCow?

[Voor 26% gewijzigd door Shadow771 op 14-02-2023 20:23]

[RobertMe]

Shadow771 schreef op dinsdag 14 februari 2023 @ 20:18:
[...]


[...]


Zeggen jullie dit ook bijv tegen de developers van MailCow?

Mailcow is uiteindelijk wel een ding.

Naar mijn idee gaat de discussie meer over "als je WordPress en MailCow op 1 server draait, gebruik je dan 1 database in totaal, of 1 database per "pakketje" en dus ,1 voor WordPress en 1 voor MailCow"". En mijn antwoord daarop zou ook zijn: twee database containers. Eentje binnen de WordPress stack en eentje binnen de MailCow stack.

[Mars Warrior]

RobertMe schreef op dinsdag 14 februari 2023 @ 20:35:
[...]
Mailcow is uiteindelijk wel een ding.

Naar mijn idee gaat de discussie meer over "als je WordPress en MailCow op 1 server draait, gebruik je dan 1 database in totaal, of 1 database per "pakketje" en dus ,1 voor WordPress en 1 voor MailCow"". En mijn antwoord daarop zou ook zijn: twee database containers. Eentje binnen de WordPress stack en eentje binnen de MailCow stack.

Mailcow is beetje overdone met 1 app per container. Mailcow kan makkelijk in 1 container draaien. Maakt het een stuk overzichtelijker

[RobertMe]

Mars Warrior schreef op dinsdag 14 februari 2023 @ 20:39:
[...]

Mailcow is beetje overdone met 1 app per container. Mailcow kan makkelijk in 1 container draaien. Maakt het een stuk overzichtelijker

Als je het in één container wilt draaien moet je geen Docker gebruiken. Het hele idee van Docker is juist dat je één proces per container draait.
Voor een pakket aan processen als zijnde totaal (besturings)systeem kun je beter naar LXC kijken.

[synoniem]

Één proces per container is overrated met justcontainers/s6-overlay kun je prima meer dan een bij elkaar horende processen draaien zonder allerlei extra containercommunicatie.
Maar het hangt uiteraard wel af van wat je wil je combineren bijvoorbeeld een initialisatie service en een long run service kan prima samen. Een database zou ik wel in een aparte container draaien bijvoorbeeld.

[Freee!!]

synoniem schreef op dinsdag 14 februari 2023 @ 21:47:
Één proces per container is overrated met justcontainers/s6-overlay kun je prima meer dan een bij elkaar horende processen draaien zonder allerlei extra containercommunicatie.
Maar het hangt uiteraard wel af van wat je wil je combineren bijvoorbeeld een initialisatie service en een long run service kan prima samen. Een database zou ik wel in een aparte container draaien bijvoorbeeld.

Een lichte database kan best in een container samen met de hoofdapplicatie draaien (Pi-Hole is daarvan een heel redelijk voorbeeld).

[RobertMe]

synoniem schreef op dinsdag 14 februari 2023 @ 21:47:
Één proces per container is overrated met justcontainers/s6-overlay kun je prima meer dan een bij elkaar horende processen draaien zonder allerlei extra containercommunicatie.
Maar het hangt uiteraard wel af van wat je wil je combineren bijvoorbeeld een initialisatie service en een long run service kan prima samen. Een database zou ik wel in een aparte container draaien bijvoorbeeld.

Dat iets kan betekent niet dat het de bedoeling is en altijd "correct" is. Letterlijk een proces maximaal is wellicht wat overdreven, maar maar alles in één container dumpen net zo. Met het voorbeeld van MailCow: Postfix en Dovecot bv zijn twee volledig zelfstandige software "pakketten" die met elkaar te integreren zijn, maar ook onafhankelijk van elkaar te gebruiken zijn, of waarbij ze uitwisselbaar zijn met alternatieven (Exim i.p.v. Postfix, maar wel combineren met Dovecot, en Dovecot zijn ook alternatieven voor waar Postfix mee kan samenwerken). Deze "pakketten" zijn dus zo los met elkaar gekoppeld dat ze niet bij elkaar horen. Hetzelfde als dat de koppeling tussen een software pakket en de database relatief los gekoppeld is (ondanks dat je niet MySQL een op een kunt uitwisselen voor Postgres etc).
Maar aan de andere kant heb je ook software zoals de door @Freee!! aangehaalde PiHole. Die wordt min of meer ontwikkeld en gereleased als monolith. Ontwikkeld door één team, gesynchroniseerde releases, de een kan niet zonder de ander. En ja, dan is er een stuk DNSMasq en een stuk admin panel / webserver. Maar die zijn zo hard aan elkaar gekoppeld dat het een logisch idee kan zijn om die in één container te proppen. Je gaat immers het PiHole admin panel niet draaien zonder de daadwerkelijke DNS server ((aangepaste) DNSMasq dus). En als je PiHoles DNS server wilt draaien zonder filtering dan kun je ook een container draaien met alleen DNSMasq en hoef je niet naar PiHole te kijken

[begintmeta]

Hoe zit het eigenlijk met netwerken, ik heb in principe samenwerkende containers in een bridgenetwerk zitten, en ik wil ook een reverse-proxy opzetten. maar ik heb gemerkt dat mijn bestaande configuraties overzetten de client IP niet netjes behoudt (in plaats van een netwerk-extern IP komt de gateway van het bridge-netwerk in de logs terecht...) Een quick fix is dan de proxy-server op het hostnetwerk of een macvlan gooien, in plaats van in een eigen bridge-netwerk, maar ik heb het idee dat dat wellicht eigenlijk ook niet de bedoeling kan zijn.

[lolgast]

@begintmeta Als het nodig is, je container in 2 netwerken zetten. De bridge voor communicatie tussen bijvoorbeeld frontend en backend, een netwerk voor de reverse proxy voor verkeer tussen de frontend en de reverse proxy. Dan is de frontend namelijk op containernaam benaderbaar vanuit de reverse proxy en kun je dus op naam verwijzen ipv ip-adres.

Als dat nergens op slaat heb ik je vraag niet begrepen denk ik

[RobertMe]

begintmeta schreef op woensdag 15 februari 2023 @ 19:43:
Hoe zit het eigenlijk met netwerken, ik heb in principe samenwerkende containers in een bridgenetwerk zitten, en ik wil ook een reverse-proxy opzetten. maar ik heb gemerkt dat mijn bestaande configuraties overzetten de client IP niet netjes behoudt (in plaats van een netwerk-extern IP komt de gateway van het bridge-netwerk in de logs terecht...) Een quick fix is dan de proxy-server op het hostnetwerk of een macvlan gooien, in plaats van in een eigen bridge-netwerk, maar ik heb het idee dat dat wellicht eigenlijk ook niet de bedoeling kan zijn.

Als je het gateway IP van de bridge ziet klopt er waarschijnlijk sowieso iets niet. Want er vanuit gaande dat je een server gebruikt en dus überhaupt vanaf extern benaderd zou dat gateway IP IIRC geen rol moete spelen in het totaal. De server doet DNAT (destination NAT) van bv poort 443 op de server naar poort 443 van de reverse proxy (dit is dus de port forward in Docker). Vervolgens zal de reverse proxy, die zijn eigen IP adres op de bridge heeft, een request doen naar de achterliggende service / container. Bij de service zou je dan dus het IP adres van de reverse proxy moeten zijn, niet de .1 (standaard gateway IP dus). De reverse proxy zal vervolgens een header toevoegen, X-FORWARDED-FOR of X-REAL-IP of een van de andere varianten. De meeste software herkent deze header en zal deze gebruiken als IP adres voor bv white/blacklisting of eigen logging.

Het gateway IP kan dus echt alleen voorkomen als je of volle bak zit te NATten waarbij de server / iptables / nftables daarop dus echt de pakketjes herschrijft zodat deze afkomstig zijn van de server en de server een tabel bijhoudt waar het origineel vandaan komt en het antwoord afkomstig van de bestemming (in dit geval de reverse proxy) ook weer herschrijft zodat deze terug gaat naar de originele bron. Waarbij de bestemming (/reverse proxy) zijn antwoord dus ook niet stuurt naar de originele bron, maar naar de server, en de server dus weer vertaald (/NAT) naar de originele server.

Daarnaast heeft Docker way back when ook een ingebakken proxy bevat die op de host luistert op die poort en vervolgens de TCP pakketjes een op een doorzet naar de bestemming. Dit om het gedrag van DNAT na te bootsen. Maar ik weet niet meer waarvoor dat toen gebruikt werd en of dat nu überhaupt nog wordt toegepast.

[RobertMe]

RobertMe schreef op maandag 16 januari 2023 @ 16:56:
Wellicht dat ik hier met mijn, wat meer high level, vraag terecht kan.

Momenteel heb ik een Proxmox machine met daarop enkele LXC containers waarin vervolgens Docker draait. De reden dat ik dit zo heb is omdat ik in mijn netwerk meerdere VLANs heb en daarmee cintainers in het juiste VLAN kan plaatsen. Zo heb ik bv een LXC "controller.iot" waar dan Docker in draait met bv Home Assistant, een SQL Database, DSMR Reader, .... Waarbij alles dus in het IoT VLAN zit en poorten die ik open zet ook alleen in het IoT VLAN bereikbaar zijn. En hetzelfde idee heb ik dan gedaan met meerdere zaken. Een LXC vanuit Proxmox waarbij de LXC aan één specifiek VLAN gekoppeld is en port forwards etc alleen vanuit dat VLAN bereikbaar zijn en het spul in de LXC / docker dus ook niet met andere VLANs kan communiceren.
An zich werkt dit prima, alleen valt dat extra laagje mij tegen. In principe heb ik nu niet één OS dat ik moet onderhouden (Proxmox / dat wat bare metal draait), maar een stuk of 10 (Proxmox + de LXCs). Waarbij dus elk geupdate moeten worden, ik soms 2 keer zaken moet mappen (Proxmox => LXC => Docker), etc. Qua onderhoud niet ideaal dus.

Intussen heb ik een nieuw mini PCtje gekocht en wil ik hier nog eens goed naar kijken. En dus of ik niet bv gewoon Debian kan draaien met Proxmox en alles overal juist in prop. Daarnaast wil ik ook "Docker Docker" evalueren of ik dat wil blijven gebruiken, of bv de overstap maken naar Podman (lees: een alternatieve OCI compliant runtime).
Voordeeltje wat ik daarbij zie bij Podman is dat dit een "pod" concept heeft, net zoals Kubernetes. Waarbij je meerdere containers in dezelfde namespace kunt plaatsen en bv zaken als networking gewoon "localhost" kunnen gebruiken binnen dezelfde pod (bv Home Assistant die via localhost met Mosquito verbind, omdat ze dezelfde netwerk namespace / netwerk interface delen). Alleen zie ik dus niet hoe ik bv een complete pod dan aan een eigen interface / VLAN kan koppelen. Maar bij Docker lijkt dit ook nogal complex te regelen te zijn (voorbeeld dat ik een tijdje terug gevonden heb zet volledige iptables / firewall management van Docker uit. Waardoor zelf de regels aangemaakt kunnen worden en dus ook SNAT toegepast kan worden om alle verkeer vanaf een Docker bridge uit te sturen / te NATen over een specifieke andere interface (/VLAN)).

Heeft iemand hier dus (toevallig) kennis van en/of ervaring met dit soort zaken? Dus in het kort "specifieke containers v.w.b. het netwerk specifieke VLANs laten gebruiken, zowel voor inkomende als uitgaande verbindingen".

De reden dat ik overigens wel in de "Docker" (/Podman / ...) hoek wil blijven is, uiteraard, het gemak. Gewoon een pull + "up" / recreate en de boel is bijgewerkt. Alternatief zou in principe LXC kunnen zijn, zonder Docker er in dan, maar dan heeft elk "programma" natuurlijk weer zijn eigen installatie & update methode, dependencies die allemaal moeten kloppen, etc.

Intussen heb ik hier een stapje in weten ze zetten en iets dat waarschijnlijk een oplossing is gevonden.
Note: intussen ben ik terug naar Docker nadat ik met Podman tegen wat issues aan liep en daarnaast een waarschijnlijk foute configuratie doodleuk het hele systeem deed nuken met een rm -rf achtige situatie die ik ook, uiteindelijk meermaals, na herinstallaties, in / heb uitgevoerd. Dus zeg maar rm -rf / en voordat ik het in de gaten had waren letterlijk alle bestanden foetsie.

In essentie is het idee / de werking eigenlijk vrij simpel. Een container die naar buiten gaat doet dit via de bridge en vervolgens doet Linux een gewone lookup in de routing tabel v.w.b. hoe het verkeer naar buiten gaat. Daarna wordt door de firewall in postrouting een masquarade regel toegepast zodat het verkeer afkomstig is/lijkt vanaf de uitgaande "fysieke" interface (door dus het source IP te veranderen naar dat van de uitgaande interface). De simpele fix is dus policy based routing inregelen waarbij verkeer vanaf de bridge(s) een andere routing tabel gebruikt met daarbij een andere default route het internet op.

Het inregelen van dit komt vervolgens wat ik zo zie altijd neer op 3 zaken:

1. De routing tabel aanmaken en vullen
2. Het verkeer vanaf de bridge (/verkeer dat je gebruik wilt laten maken van deze routing tabel) markeren, in de firewall
3. Een regel (in de routing) die ervoor zorgt dat het verkeer gemarkeerd met X wordt verwerkt door routing tabel Y

Echter lijkt mij dit ook te lukken in 2 stappen. Wellicht een recentere toevoeging. In ieder geval is het (tegenwoordig?) mogelijk om 3 te doen op basis van een interface.

Zelf maak ik gebruik van systemd-networkd voor het configureren van de interfaces, aanmaken van de VLANs, etc. En die kan dat allemaal voor mij inregelen zo blijkt.

Hierbij kom ik dan uit op onderstaande snippet in het reeds bestaande /etc/systemd/network/....network bestand:

INI:

[RoutingPolicyRule]
IncomingInterface=br-iot
Table=500

[Route]
Gateway=192.168.20.1
Table=500

[Route]
Gateway=_ipv6ra
Table=500

Te beginnen met de twee [Route] blokken. Deze voegen de regels toe aan de routing tabel en maken deze eventueel aan. Uiteraard opletten dat je geen ids gebruikt die al bestaan (default sowieso 255 voor local, 254 voor main en 253 voor broadcast). In dit geval geef ik dus hardcoded een (default) gateway op voor IPv4. En daarnaast wordt de gateway voor IPv6 ingesteld maar komt deze uit de router advertisement (ik gebruik geen statisch IPv6 adres, maar wel een statische "token" / suffix). Het resultaat hiervan kan worden gecontroleerd met ip route:

robert@server:~$ ip -4 route show table 500
default via 192.168.20.1 dev iot proto static
robert@server:~$ ip -6 route show table 500
default via fe80::822a:a8ff:fecd:c7e6 dev iot proto ra metric 1024 expires 1500sec pref high
robert@server:~$

Als uitleg: dev iot verwijst naar de netwerk interface die ik ook lan, prive, iot etc heb genoemd i.p.v. ethX of enpXsY. Het voorbeeld snippet staat dan ook in /etc/systemd/network/iot.network met een [Match] op Name=iot

Het [RoutingPolicyRule] blok zorgt er vervolgens voor dat deze routing tabel wordt toegepast op verkeer met als inkomende interface de br-iot interface. Dit is te controleren met ip rule:

robert@server:~$ ip rule
0:      from all lookup local
32762:  from all iif br-iot lookup 500 proto static
32766:  from all lookup main
32767:  from all lookup default

En dan hoor ik jullie denken "waar komt br-iot vandaan?". Dat is de naam van de bridge die Docker aanmaakt voor het aangemaakte netwerk, middels:

docker network create --opt com.docker.network.bridge.name=br-iot br-iot

Met de opt geef ik dus zelf een naam aan het netwerk zodat ik deze makkelijk kan herkennen en kan opnemen in configuraties. Dit i.p.v. de random naam die Docker gebruikt.

De inspiratie voor de oplossing komt uit deze blogpost: https://stewartadam.io/bl...ecific-outgoing-interface . Hoe het in systemd-networkd te regelen heb ik zelf uitgezocht op basis van de man pages.

Mocht dit niet werken omdat de IncomingInterface toch ander gedrag vertoont dan werken met een firewall mark kan ook dat. Dit simpelweg door FirewallMark= te gebruiken met dan het nummertje van de mark. Dit uiteraard gecombineerd met een firewall mark dat geset wordt door de kernel, in te stellen via iptables/firewalld/nftables. Om het mijzelf extea moeilijk te maken heb ik zelf iptables volledig uit gezet in Docker. Zodat ik vervolgens alles, met de hand, kan/moet doen in nftables..
Daarnaast kan elke Table= i.p.v. met een nummertje ook met een naam. Deze naam moet je echter wel in systemd-networkd instellen en werkt ook alleen daarbinnen. Dit kan door aan /etc/systemd/networkd.conf onder het [Network] blok een of meerdere RouteTable=<naam>:<nummer> regels toe te voegen, bv:

INI:

RouteTable=iot:500

CC @PuijkeN omdat ik hierover toentertijd ook wat in het zuinige server topic heb gepost en hij ook interesse had in een oplossing hiervoor.

[Mars Warrior]

Ik ben bezig om nieuwe server in te richten. Daarop komt oa Adguard als docker container die in host mode draait, dus de DNS poorten zijn direct beschikbaar.

Adguard is dus zowel DHCP naar andere systemen als DNS Server.
Echter deze DNS server is dus niet beschikbaar bij opstarten van de server. Pas als docker volledig is gestart met de containers werkt dit.

Ik vroeg me even af hoe anderen hiermee om zijn gegaan. Dacht dat @Jazco2nd ook zoiets heeft?

Ik gebruik Ubuntu 22.04.2, dus zal alles met Netplan moeten inrichten en mogelijk nog wat andere dingen moeten doen om de standaard DNS server van Ubuntu uit te schakelen.

Zie ook hier: Ubuntu 22.04 wijzigen DNS server

En deze: How to Deploy Adguard Home Docker in Ubuntu 20.04

[Voor 8% gewijzigd door Mars Warrior op 27-02-2023 17:04]

[Jazco2nd]

@Mars Warrior ik heb nooit de DHCP server gebruikt van AGH of PiHole. Zou het wel willen, maar ik wil zo min mogelijk disruptie voor 'basic internet', DHCP vind ik nogal essentieel, dus dat doet de router gewoon.
Als ik de server reboot of heb zitten kloten waardoor reboot niet lukt of de container een probleem heeft (noem maar wat) of mijn ssd ineens niet werkt is er eventjes geen internet in huis. Dat kan niet.

Voor jou: het idee is dus dat je dit pas omzet (van router naar server) als je helemaal klaar bent met het configureren van je server en hem gewoon continu laat draaien.

Het voordeel in jouw geval als je hiervoor kiest is dat je altijd per-client queries en stats kan zien en per client AGH kan in/uitschakelen.
In mijn router worden alle DNS verzoeken naar mijn server geforceert via firewall rules. Met als nadeel dat alle DNS verzoeken dus van mijn router naar AGH gaan en AGH dus geen clients kan onderscheiden. Dit accepteer ik, omdat ik liever partijen als Google dwarszit en alle DNS verzoeken door AGH (icm Unbound) pers.
_{De router draait ook een script: elke 30sec wordt gekeken of mijn server nog DNS kan resolven. Zo niet, worden de firewall regels uitgezet en een andere regel aangezet waardoor alle verzoeken geforceerd worden afgehandeld via in de router ingestelde publieke DNS servers. Zo heb ik altijd internet}


In het meest ideale geval brengt Mikrotik een ARM variant van hun routers uit. Sinds vorig jaar ondersteunen ze namelijk docker containers , waardoor je AdGuard Home op je router kan draaien. Dan zou mijn server dit niet meer hoeven te doen. Maar hun huidige routers gebruiken MIPS architectuur (ipv ARM of x86) en er zijn geen ARM based routers aangekondigd

<sub>Ik ben trouwens ook nog eens van Ubuntu afgestapt. Vond het teveel eigenaardigheden hebben en teveel geklooi vereisen. Ben over op Manjaro. Dat draait zo lekker (Arch based) en volledig automatisch (ook updates), sindsdien nauwelijks nog tijd aan mijn server besteed. Ook geen last van ingebouwde DNS resolver van Ubuntu. En een veel betere documentatie als je toch wil klooien (Arch Wiki).

Ik heb in 3. Network Configuration en 6. Services & Apps - Configuration van mijn Homeserver guide best veel info gezet, ook step-by-step voor zaken als Adguard Home, Wireguard Server en bijvoorbeeld local domain names voor unexposed services (http://agh.o/ om adguard te benaderen bijvoorbeeld), ook wanneer ik niet thuis ben via WG VPN. Mocht je daar wat aan hebben.</sub>

[Mars Warrior]

Jazco2nd schreef op maandag 27 februari 2023 @ 17:27:
@Mars Warrior ik heb nooit de DHCP server gebruikt van AGH of PiHole. Zou het wel willen, maar ik wil zo min mogelijk disruptie voor 'basic internet', DHCP vind ik nogal essentieel, dus dat doet de router gewoon.
Als ik de server reboot of heb zitten kloten waardoor reboot niet lukt of de container een probleem heeft (noem maar wat) of mijn ssd ineens niet werkt is er eventjes geen internet in huis. Dat kan niet.

Aha. Tjsa. Ik gebruik nu PiHole op een RPI 2 daarvoor omdat mijn oude KPN modem het niet toestaat om de DNS te wijzigen. Dus ik heb wat moeten trucken op dei KPN doos om effectief de DHCP uit te schakelen.

Als ik nu aardig ben tegen KPN en een KPN Box 12 krijg als vervanging, dan kan ik de DNS gewoon instellen op AGH, en werkt DHCP gewoon vanaf het modem met mogelijk een fallback DNS mocht mijn server het niet doen of ff uit staan...

Maar ik zie nu pas je punt hieronder waar het voordelig kan zijn om AGH te gebruiken als DHCP server, zoals ik nu doe.

Mogelijk ga ik een NUCje gebruiken als vervanging van de RPI (die doet het al tig jaar zonder problemen) waarop nog wat docker containers gaan draaien, zodat ik wat meer backup mogelijkheden heb. Dat ding zal ik - net als de RPI 2 - gewoon rustig laten draaien...

Voor jou: het idee is dus dat je dit pas omzet (van router naar server) als je helemaal klaar bent met het configureren van je server en hem gewoon continu laat draaien.

Goed punt. Ik heb nu zowel PiHole als AdGuard op een andere server draaien. Dus ik zit ff niet zonder DNS server...

Het voordeel in jouw geval als je hiervoor kiest is dat je altijd per-client queries en stats kan zien en per client AGH kan in/uitschakelen.
In mijn router worden alle DNS verzoeken naar mijn server geforceert via firewall rules. Met als nadeel dat alle DNS verzoeken dus van mijn router naar AGH gaan en AGH dus geen clients kan onderscheiden. Dit accepteer ik, omdat ik liever partijen als Google dwarszit en alle DNS verzoeken door AGH (icm Unbound) pers.

Ff voor de duidelijkheid: ligt dit nu aan DNS of DHCP: oftewel als ik DHCP via mijn router laat lopen en DNS over AGH, dak kan ik toch nog steeds per client in/uitschakelen, of ligt dat echt vast aan de DHCP functie?

[sub]Ik ben trouwens ook nog eens van Ubuntu afgestapt. Vond het teveel eigenaardigheden hebben en teveel geklooi vereisen. Ben over op Manjaro. Dat draait zo lekker (Arch based) en volledig automatisch (ook updates), sindsdien nauwelijks nog tijd aan mijn server besteed. Ook geen last van ingebouwde DNS resolver van Ubuntu. En een veel betere documentatie als je toch wil klooien (Arch Wiki).

Ik ben geen Linux expert, en kan net aan wat omgaan met Ubuntu Desktop/Server. Dat doe ik al vanaf versie 14.04, dus dat wil ik eigenlijk houden. De RPIs zijn Debian, dus dan hou ik die kennis wat hetzelfde.

Linux is voor mij vaak volstrekt onlogisch met al die cryptische commando's en totaal verschillende config bestandjes waarvan vaak technisch wordt uitgelegd wat elke parameter is, maar niet wat je ermee kunt!

Dus mijn vraag is bijv "Ik wil een eigen DNS server draaien, wat moet ik hiervoor doen?", en dan doodgegooid worden met tig services en bestandjes die allemaal iets doen, maar waar niet integraal ff van wordt aangegeen WAT je moet wijzigen om je DOEL te bereiken

Ik heb in 3. Network Configuration en 6. Services & Apps - Configuration van mijn Homeserver guide best veel info gezet, ook step-by-step voor zaken als Adguard Home, Wireguard Server en bijvoorbeeld local domain names voor unexposed services (http://agh.o/ om adguard te benaderen bijvoorbeeld), ook wanneer ik niet thuis ben via WG VPN. Mocht je daar wat aan hebben.[/sub]

Dat ga ik doornemen. Ik wil ook WG gebruiken als VPN (mogelijk wederom vanaf de NUC omdat daar verder niemand aan zit), dus die samenwerking met AGH is ook voor mij van belang.

De local domain names optie met ".o" ken ik niet. Is dat anders dan dat je agh.srv oid gebruikt?

[Jazco2nd]

@Mars Warrior

Ff voor de duidelijkheid: ligt dit nu aan DNS of DHCP: oftewel als ik DHCP via mijn router laat lopen en DNS over AGH, dak kan ik toch nog steeds per client in/uitschakelen, of ligt dat echt vast aan de DHCP functie

Je hebt 3 keuzes als je per cliënt alles wil kunnen zien:
1) Router DCHP gebruiken en als DNS server (onder DHCP instellingen) het IP adres van je server invullen --> nu zullen je clients het IP van je server krijgen als DNS adres. Dit kan je makkelijk checken op je telefoon of laptop.
Nadeel 1: moderne Android/Apple devices hebben soms hun eigen DNS server ingesteld. Die omzeilen dus je server, tenzij je dit handmatig uitzet (heet volgens mij Private DNS ofzoiets).
Nadeel 2: Apparaten die graag constant met de cloud praten en daarvoor hun eigen publieke (al dan niet hardcoded) DNS server hebben ingesteld zoals een Google Nest of Chromecast omzeilen je server. Ook smartTVs die voorheen regelmatig screenshots van je tv beeld naar oa SambaTV stuurden blokkeer je dan niet.
Nadeel 3: als jij je DNS server wijzigt onder DHCP settings, wordt dit niet aangepast bij reeds verbonden clients. Dit kan een probleem vormen als je van de ene naar de ander server wil switchen. Dit los je op met Optie 3.

2) DHCP server adres == DNS adres, dit is het geval wanneer je server beide afgehandeld.
Nadelen 1 en 2 blijven bestaan.

3) Router DHCP gebruiken maar onder DHCP settings als DNS het IP adres van je router zelf invullen (dus Gateway en DNS onder kopje DHCP zijn dan zelfde).
Vervolgens elders in je router onder DNS servers jouw server IP invullen.
Dit lijkt op optie (1) maar heeft als voordeel dat clients dus altijd je router IP als DNS hebben, en je in de router zelf altijd de werkelijke dns servers kan aanpassen.

Je zou dus optie 3 altijd boven optie 1 moeten preferen.

Let op dat de meeste routers je wel 2 of zelfs 3 DNS adressen laten instellen, maar vaak worden deze willekeurig benaderd. Dus het is dan niet zo dat als de eerste server niet reageert, het request opnieuw naar de 2e wordt verzonden..


Wireguard VPN:
Hiervoor kan je zolang je Docker Compose gebruikt prima mijn guide als referentie gebruiken ongeacht het OS
In mijn setup gaat DNS altijd via mijn server, doordat telefoons automatisch verbinden met Wireguard wanneer ze WiFi verliezen. Alleen DNS verzoeken gaan dan via Wireguard VPN, de rest van het internet verkeer gaat buiten de tunnel om.
Je hebt zo ook altijd toegang tot de services op je server die alleen lokaal draaien.
Dit kan jij met Ubuntu en 2 servers ook prima voor elkaar krijgen.

Lokale domeinnamen:
Zie uitleg hier:
https://github.com/zilexa...ces-in-your-local-network
Binnen de context van de 2 onderwerpen erboven.

[Voor 17% gewijzigd door Jazco2nd op 27-02-2023 19:41]

[Mars Warrior]

Jazco2nd schreef op maandag 27 februari 2023 @ 19:31:
@Mars Warrior
[...]
Je hebt 3 keuzes als je per cliënt alles wil kunnen zien:
1) Router DCHP gebruiken en als DNS server (onder DHCP instellingen) het IP adres van je server invullen --> nu zullen je clients het IP van je server krijgen als DNS adres. Dit kan je makkelijk checken op je telefoon of laptop.
Nadeel 1: moderne Android/Apple devices hebben soms hun eigen DNS server ingesteld. Die omzeilen dus je server, tenzij je dit handmatig uitzet (heet volgens mij Private DNS ofzoiets).
Nadeel 2: Apparaten die graag constant met de cloud praten en daarvoor hun eigen publieke (al dan niet hardcoded) DNS server hebben ingesteld zoals een Google Nest of Chromecast omzeilen je server. Ook smartTVs die voorheen regelmatig screenshots van je tv beeld naar oa SambaTV stuurden blokkeer je dan niet.
Nadeel 3: als jij je DNS server wijzigt onder DHCP settings, wordt dit niet aangepast bij reeds verbonden clients. Dit kan een probleem vormen als je van de ene naar de ander server wil switchen. Dit los je op met Optie 3.

2) DHCP server adres == DNS adres, dit is het geval wanneer je server beide afgehandeld.
Nadelen 1 en 2 blijven bestaan.

3) Router DHCP gebruiken maar onder DHCP settings als DNS het IP adres van je router zelf invullen (dus Gateway en DNS onder kopje DHCP zijn dan zelfde).
Vervolgens elders in je router onder DNS servers jouw server IP invullen.
Dit lijkt op optie (1) maar heeft als voordeel dat clients dus altijd je router IP als DNS hebben, en je in de router zelf altijd de werkelijke dns servers kan aanpassen.

Je zou dus optie 3 altijd boven optie 1 moeten preferen.

Let op dat de meeste routers je wel 2 of zelfs 3 DNS adressen laten instellen, maar vaak worden deze willekeurig benaderd. Dus het is dan niet zo dat als de eerste server niet reageert, het request opnieuw naar de 2e wordt verzonden..

Ok. Duidelijk verhaal. Optie 3 ken ik niet van de routers waarmee ik heb gewerkt. Daar krijg ik altijd via DHCP de ingestelde DNS Servers terug. Dus niet die van het modem/router, maar de ingevulde externe servers...

Wireguard VPN:
Hiervoor kan je zolang je Docker Compose gebruikt prima mijn guide als referentie gebruiken ongeacht het OS
In mijn setup gaat DNS altijd via mijn server, doordat telefoons automatisch verbinden met Wireguard wanneer ze WiFi verliezen. Alleen DNS verzoeken gaan dan via Wireguard VPN, de rest van het internet verkeer gaat buiten de tunnel om.
Je hebt zo ook altijd toegang tot de services op je server die alleen lokaal draaien.
Dit kan jij met Ubuntu en 2 servers ook prima voor elkaar krijgen.

Lokale domeinnamen:
Zie uitleg hier:
https://github.com/zilexa...ces-in-your-local-network
Binnen de context van de 2 onderwerpen erboven.

Dat is mooi! Ik gebruik natuurlijk ook docker compose (let op dat docker-compose "legacy" is inmiddels), dus dat zou bij mij dan ook moeten gaan werken.

Ubuntu heeft ook WG in de repository zitten, dus dat moet geen probleem zijn. Dan gebruik ik enkel de docker containers voor de GUI om WG te configureren.

WG staat al wel op mijn iPhone, dus ik zou dat kunnen testen. Heb nu geen VPN draaien namelijk. Dus als test moet ik dan bij het AGH dashboard moeten kunnen komen als alles correct is ingesteld.

Noot:
Ik moet alleen ff een alternatief voor de iptables vinden, want Ubuntu gebruikt nftables

Gaat hierover uit je .env file:
WGPOSTUP=iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE
WGPOSTDOWN=iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE

Ik hoop dat hier wat staat: https://www.procustodibus.../wg-quick-firewall-rules/
en hier: https://www.procustodibus.../wg-quick-firewall-rules/

Oftewel dat het wat automatisch gaat

[Voor 9% gewijzigd door Mars Warrior op 28-02-2023 11:15]

[Jazco2nd]

@Mars Warrior correct, $namen zijn de variabelen die in je .env file staan.
Voor thuisgebruik lijkt dit overdreven, maar zo houdt je je compose file generiek. Alle echte personalisatie staat dan dus in .env.

Inderdaad, wireguard zit in de linux kernel, wg-tools gewoon in de standaard repositories en ik heb een paar UIs getest, klein beetje gedoneerd aan deze en die is nu redelijk uitontwikkeld en gebruiksvriendelijk in gebruik.

In het AGH topic vind je meer over optie 3. Soms kan je DNS invullen onder je internet instellingen/WAN ipv onder DHCP. Of zoals bij Asus een vinkje zetten bij "advertise router IP instead of DNS.. to clients". Inderdaad sommige routers lijken die opties niet te hebben.

[Mars Warrior]

Jazco2nd schreef op dinsdag 28 februari 2023 @ 11:15:
@Mars Warrior correct, $namen zijn de variabelen die in je .env file staan.
Voor thuisgebruik lijkt dit overdreven, maar zo houdt je je compose file generiek. Alle echte personalisatie staat dan dus in .env.

Inderdaad, wireguard zit in de linux kernel, wg-tools gewoon in de standaard repositories en ik heb een paar UIs getest, klein beetje gedoneerd aan deze en die is nu redelijk uitontwikkeld en gebruiksvriendelijk in gebruik.

In het AGH topic vind je meer over optie 3. Soms kan je DNS invullen onder je internet instellingen/WAN ipv onder DHCP. Of zoals bij Asus een vinkje zetten bij "advertise router IP instead of DNS.. to clients". Inderdaad sommige routers lijken die opties niet te hebben.

Wat pogingen gedaan om WG aan de gang te krijgen, maar de DNS werkt niet en ik heb geen idee hoe dat te fixen eerlijk gezegd.

Ik heb nog geen AG container lokaal draaien, maar ik verwijs - als ip adres - naar de bestaande AG container. Maar niks, nakkes, nada. Ik zie in de wg-gui dat ik verbonden ben met mijn telefoon nadat ik die als client het toegevoegd, maar dat is het dan ook. Het meest belangrijke werkt niet.

Ik zie ook geen DNS entry in de wg0.conf verschijnen. Als ik die toevoeg werkt er ook niks.

Kan zijn dat ik alles moet weggooien in de docker map, en weer opnieuw ofzo... Lijkt wel alsof je dingen in de .env file kan wijzigen,maar dat werkt enkel de 1ste keer...

Het blijkt dat Ubuntu 22.04.2 nog steeds wel met iptables werkt, maar nftables als backend gebruikt. Dus ik heb alle up/down commando's er gewoon in laten zitten.

EDIT:
Werkt nu. Ik heb de WGUI_DEFAULT_CLIENT_ALLOWED_IPS op 0.0.0.0/0 gezet

Die stond in je .env file en wat voorbeelden op 10.x enzo. Maar de default bij de UI is die 0.x. Dus instelling aangepast daaraan, en nu werkt de VPN tunnel op mijn telefoon!



En Plugsy is leuk! Had ik nog nooit van gehoord.

[Voor 12% gewijzigd door Mars Warrior op 01-03-2023 16:52]

[Jazco2nd]

@Mars Warrior met 0000 etc zeg je dat alle verkeer door VPN moet. Door dat te veranderen in het adres bereik van je LAN zorg je ervoor dat alleen verzoeken naar jouw LAN via vpn gaan. Op die manier gaan dns verzoeken dus door vpn. Staat ergens in mijn guide

Plugsy ontwikkeling is gestopt. Het alternatief is iets meer werk. Heb ik geen tijd voor:
https://github.com/Lissy93/dashy

[Voor 19% gewijzigd door Jazco2nd op 01-03-2023 17:02]

[Mars Warrior]

Jazco2nd schreef op woensdag 1 maart 2023 @ 17:01:
@Mars Warrior met 0000 etc zeg je dat alle verkeer door VPN moet. Door dat te veranderen in het adres bereik van je LAN zorg je ervoor dat alleen verzoeken naar jouw LAN via vpn gaan. Op die manier gaan dns verzoeken dus door vpn. Staat ergens in mijn guide

Ik geloof dat ik dan iets ga begrijpen:

• Mijn server zit op 168.198.10.100, AGH draait op een andere server op 168.198.10.190
• Als ik dan 168.198.10.0/24 toevoeg bij ALLOWED, dan voeg ik ook mijn server toe: die is daarna namelijk NIET meer bereikbaar in mijn LAN. EN de DNS doet het dus niet als ik dat doe!

Ik ben niet zo goed in netwerken, dus ik gis ook maar wat

Plugsy ontwikkeling is gestopt. Het alternatief is iets meer werk. Heb ik geen tijd voor:
https://github.com/Lissy93/dashy

Aha. Was me nog niet opgevallen dat Plugsy is gestopt, maar ik zie nu dat eea 2jr oud is

Ik zie dat dashy weer een losse config file is? Die inline docker labels zijn stuk fijner...

[Mars Warrior]

@Jazco2nd Met het proberen kwam ik er achter dat er mogelijk nog een foutje in je .env en/of docker compose zit:

Je gebruikt zowel:
- WGLANRANGE=192.168.88.1/24 als
- LAN_ADDRESS_RANGES=192.168.88.0/24,10.0.0.0/24

Maar in de docker compose kom ik de variabele WGLANRANGE niet tegen, en gebruik je de variabele LAN_ADDRESS_RANGE zonder "S"

Dus ik weet eigenlijk niet wat het juiste is. Ik zie ook dingen als 0/24 en 1/24. Is dat hetzelfde, of toch anders?

[Arunia]

Na lange tijd eigenlijk weinig nieuws te hebben gedaan met Docker, ben ik nu uitgekomen op Anydesk vervangen voor Rustdesk. Dit werkte intern wel, maar extern niet. Kwam er vandaag achter dat in de docker-compose.yml een verwijzing stond naar example.org:41116. deze vervangen voor het externe ip-adres en toen de docker herstart. Werkte meteen. Zo stom dat ik dat niet heb gezien.

Zag ook dat de container voor mijn wordpress heel lelijk random is. Maar om dat veilig over te zetten heeft aardig wat voeten in aarde. Dus daar twijfel ik nog over. Hernoemen is jammer genoeg geen mogelijkheid blijkbaar.

Enige wat ik nog "eng" vind om alles in Docker te zetten is backuppen en opnieuw opbouwen bij problemen, heb al eens iets gesloopt door een update van het één of ander. Maar dat zal wel gewenning zijn.

Ik denk ook dat ik meer met zichtbare volumes moet werken voor de host. Dat scheelt ook weer wat stres.

[Voor 6% gewijzigd door Arunia op 13-03-2023 11:54]

[Arunia]

Langzaam steeds meer in Docker gooien. Maar denk dat ik eens mijn udemy cursusje moet gaan doen. Heb ik al enige tijd in bezit, maar nooit wat mee gedaan.

Ook wil ik eens intern domainnames gaan gebruiken voor ipadressen met poorten. Want dat laatste is echt niet handig.
Gewoon plex.home.net of plex.home scheen dan ook te werken. Maar dat is minder van docker dan van wat anders.

[ThinkPad]

@Arunia Gebruik je ook iets van een GUI zoals Portainer? Ik vond Docker in het begin ook eng/spannend, maar door een webinterface te hebben om het te beheren maakte het voor mij 10x makkelijker.

Interne domeinnamen is ook handig, onlangs ook ingericht. Eigenlijk is alleen .home.arpa toegestaan als domein (dus plex.home.arpa) volgens de standaard. Ik heb ook gelijk een self signed wildcard certificate + root certificate gemaakt en dat root certificate op m'n devices geimporteerd. Op die manier kun je intern ook die lelijke HTTPS-waarschuwingen fixen

[Voor 4% gewijzigd door ThinkPad op 21-03-2023 13:39]

[Mars Warrior]

Arunia schreef op dinsdag 21 maart 2023 @ 12:25:
Langzaam steeds meer in Docker gooien. Maar denk dat ik eens mijn udemy cursusje moet gaan doen. Heb ik al enige tijd in bezit, maar nooit wat mee gedaan.

Ook wil ik eens intern domainnames gaan gebruiken voor ipadressen met poorten. Want dat laatste is echt niet handig.
Gewoon plex.home.net of plex.home scheen dan ook te werken. Maar dat is minder van docker dan van wat anders.

Als je iets als AdGuard zou gebruiken voor reclame filtering, dan heb je meteen een (interne) DNS Server die je via een GUI kunt invullen.

Kun je voor AL je web-based docker containers een gewone naam gebruiken.

Als je dat eenmaal gebruikt wil je natuurlijk nooit meer wat anders.

Hoewel er officieel beperkingen gelden voor de TLD die je intern gebruikt, zul je niet veel problemen ondervinden als je alles thuis *.home, of *.local, of *.arunia noemt. Dat maakt de buitenwereld helemaal niks uit namelijk

Als je niet val veel typen houd dan neem je gewoon plex.a ofzo...

[Voor 3% gewijzigd door Mars Warrior op 21-03-2023 13:12]

[orvintax]

Mars Warrior schreef op dinsdag 21 maart 2023 @ 13:11:
[...]
Hoewel er officieel beperkingen gelden voor de TLD die je intern gebruikt, zul je niet veel problemen ondervinden als je alles thuis *.home, of *.local, of *.arunia noemt. Dat maakt de buitenwereld helemaal niks uit namelijk

Daar zou ik toch iets voorzichtiger mee zijn. Sommige stukjes software gaan daar namelijk vrij streng mee om waar door je in rare situaties terecht komt. Heb het zelf ook wel eens een paar keer meegemaakt. Maar goed, misschien valt dat risico wel te overzien.

[Kaspers]

Da's een beetje hoe het ook binnen Kubernetes is opgelost. Wanneer je een container (als onderdeel van een pod) intern wil exposen maak je daar een service van. Een service valt binnen het cluster / de host weer bereiken via <servicenaam>.<namespace>.svc.cluster.local.



En services die je van buiten je host / cluster wilt bereiken zet je open via een ingress route:



Ik heb een tijd geleden om onder meer deze redenen de stap gemaakt van docker naar kubernetes. In eerste instantie is 't wel wat een steile leercurve, maar uiteindelijk is het wel een hele stabiele oplossing en goed te beheren wanneer je bij de basis concepten blijft en niet al te veel afhankelijk wordt van 3rd party custom configuratie / integraties. Ik kan k3s dan ook erg aanbevelen. Meer k3s gebruikers hier?

[Mars Warrior]

Kaspers schreef op dinsdag 21 maart 2023 @ 13:26:
Ik kan k3s dan ook erg aanbevelen. Meer k3s gebruikers hier?

Nee. Te hoge CPU load, te hoge CPU load, te hoge CPU load en naar mijn mening "onnodig complex" vergeleken met een docker compose file.

Ik wil een zuinige server, en dat is met k*s niet mogelijk, die krijg je idle niet onder de 0.1% cpu load

Wil je het simpel houden (lokale DNS, extern via eigen domein) dan is docker compose met labels voor bijv. Caddy behoorlijk simpel en voorspelbaar.

Als je Caddy (de docker versie die labels snapt) vergelijkt met Traefik dan zie je hetzelfde verschil als tussen docker compose en k*s: je hebt een halve studie nodig om de meest basale dingen voor elkaar te krijgen.

En als je bezig bent om docker te begrijpen zou ik alles rondom k0s/k3s/k8s lekker links laten liggen

[Arunia]

@ThinkPad Ik heb Portainer wel draaien. Maar moet zeggen dat ik het vrij weinig gebruik.
Mijn manier van werken met Docker is sowieso met docker-compose. Vind het wel makkelijk om een file te hebben welke aangepast en weer gestart kan worden.

Oeh, dat moet ik inderdaad ook nog doen met certificates. Dat wordt de volgende stap absoluut!

@Mars Warrior Qua intern wil ik inderdaad zoiets gaan doen. Heb nog geen AdGuard draaien, maar staat ergens nog op mijn lijstje om in te richten.
Of het naar buiten toe netjes is qua namen maakt me niet zo heel veel uit. Heb wel wat namen die gewoon zouden kunnen. Qua typen is op zich wel te doen, beter dan gebruik te maken van ip en poort nummer.

@orvintax Ik heb niet zo een idee bij wat je bedoelt. Wellicht bekende namen gebruiken, dat dat een probleem oplevert. Maar de naam die ik wil gebruiken zal dat niet echt hebben. Maar wel een goede om in de gaten te houden mochten er rare problemen zijn.

[Mars Warrior]

orvintax schreef op dinsdag 21 maart 2023 @ 13:26:
[...]
Daar zou ik toch iets voorzichtiger mee zijn. Sommige stukjes software gaan daar namelijk vrij streng mee om waar door je in rare situaties terecht komt. Heb het zelf ook wel eens een paar keer meegemaakt. Maar goed, misschien valt dat risico wel te overzien.

Geen idee welke software zich druk maakt om het TLD. Ik gebruik dat soort containers blijkbaar niet

Een proxy (Caddy, NPM, Traefik) zorgt voor routeren (sub)domein en SSL.

Er draaien hier meerdere domeinen:

• verschillende externe domeinen die deels lokaal draaien (reverse DNS of hoe dat ook heet). Er draaien lokaal dus gewoon *.com en *.nl domeinen, die extern ook bestaan, maar niet noodzakelijkerwijs in mijn bezit zijn. De externe DNS wijst simpelweg naar mijn ip adres thuis.
• verschillende lokale domeinen die dus extern niet beschikbaar zijn. Maar daarom zijn ze ook lokaal...

Ik zit nu in een transitie naar een nieuwe 20-core server die veel zuiniger is dan mijn bestaande/oude 4-core servers. Met zuinig bedoel ik ca 4W idle uit het stopcontact (32GB RAM, 2TB SSD, 20-core CPU).

Ik ga ook van ca 100 containers terug naar 30 door consolidatie van servers (van 3 naar 1) en functionaliteit.

SFTPGo bijvoorbeeld kan bijv zowel SFTP, FTP, HTTP/S, FTP/S als Webdav aan, heeft een ingebouwde GUI, plugins om dingen uit te breiden en kan zelf weer gebruik maken van verschillende back-ends. Dus dat scheelt nogal wat containers, configuratiewerk en dus onderhoud.

Intern gebruik ik Gotify voor events en Pushtify om het door te zette naar Pushover op mijn telefoon.

Influxdb en Telegraf gebruik ik voor metrics zodat ik zowel het CPU verbruik (package) kan meten (is idle nu 850mW) en het gebruik van de diverse containers (proxy, sftp, webdav, etc).

In die context heb ik nu containers gekozen die zelf al deze metrics (hetzij direct in influxdb, hetzij via een /metrics endpoint die Telegraf gebruikt) leveren, waar ik voorheen containers nodig had die logfiles analyseerden. Dat scheelt dus zowel containers, als cpu verbruik als andere resources!

[Mars Warrior]

Arunia schreef op dinsdag 21 maart 2023 @ 14:06:
@ThinkPad Ik heb Portainer wel draaien. Maar moet zeggen dat ik het vrij weinig gebruik.
Mijn manier van werken met Docker is sowieso met docker-compose. Vind het wel makkelijk om een file te hebben welke aangepast en weer gestart kan worden.

Oeh, dat moet ik inderdaad ook nog doen met certificates. Dat wordt de volgende stap absoluut!

@Mars Warrior Qua intern wil ik inderdaad zoiets gaan doen. Heb nog geen AdGuard draaien, maar staat ergens nog op mijn lijstje om in te richten.
Of het naar buiten toe netjes is qua namen maakt me niet zo heel veel uit. Heb wel wat namen die gewoon zouden kunnen. Qua typen is op zich wel te doen, beter dan gebruik te maken van ip en poort nummer.

@orvintax Ik heb niet zo een idee bij wat je bedoelt. Wellicht bekende namen gebruiken, dat dat een probleem oplevert. Maar de naam die ik wil gebruiken zal dat niet echt hebben. Maar wel een goede om in de gaten te houden mochten er rare problemen zijn.

Je zou naar de docker compose file van @Jazco2nd kunnen kijken. Hij heeft dat op Github staan.

Je ziet hier bijna alle dingen in terug die tegenwoordig het leven wat eenvoudiger maken:

• Portainer
• AGH als DNS voor oa interne domein (hij gebruikt *.o. Houdt ook niet van typen denk ik)
• Caddy als web proxy (dus zowel http als https)
• Wireguard VPN
• Diverse andere containers

De 1ste vier gebruik ik ook als basis. De rest van de containers wijkt dan weer nogal af

[Arunia]

@Mars Warrior Dat klinkt echt heel uitgebreid wat je doet. Dacht dat ik al voor thuisgebruik best wat dingen had, maar dat valt best mee.
Moet alleen nog dingen als nzbget, qbittorrent, de geijkte sonarr, radarr enzovoorts nog eens in Docker zetten.
Maar dan moet ik toch eens zien te kijken hoe ik goed kan backuppen en als ik dus opnieuw moet beginnen, ik wel mijn data blijf behouden. Dat komt uiteindelijk wel als ik wat meer tijd heb.

[Mars Warrior]

Arunia schreef op dinsdag 21 maart 2023 @ 14:25:
@Mars Warrior Dat klinkt echt heel uitgebreid wat je doet. Dacht dat ik al voor thuisgebruik best wat dingen had, maar dat valt best mee.
Moet alleen nog dingen als nzbget, qbittorrent, de geijkte sonarr, radarr enzovoorts nog eens in Docker zetten.
Maar dan moet ik toch eens zien te kijken hoe ik goed kan backuppen en als ik dus opnieuw moet beginnen, ik wel mijn data blijf behouden. Dat komt uiteindelijk wel als ik wat meer tijd heb.

Kijk dan ff goed in die compose file van @Jazco2nd : daar staan de **arr dingen al in!

[Arunia]

@Mars Warrior Ah ok. Ik ga daar zeker naar kijken.

[Mars Warrior]

Arunia schreef op dinsdag 21 maart 2023 @ 14:52:
@Mars Warrior Ah ok. Ik ga daar zeker naar kijken.

YAML:

##____________________ Sonarr [MEDIA/PVR-TVshows]
  sonarr:
    container_name: sonarr
    image: cr.hotio.dev/hotio/sonarr
    networks: 
      - web-proxy
    depends_on:
      - prowlarr
      - qbittorrent
    restart: always
    environment:
      PUID: $PUID
      PGID: $PGID
      UMASK: 002
      TZ: $TZ
    volumes:
      - $DOCKERDIR/sonarr/config:/config
      - $DATAPOOL/media:/Media
    ports:
      - 8989:8989
    labels:
      caddy: http://sonarr.o
      caddy.reverse_proxy: "{{upstreams 8989}}"
      plugsy.name: Sonarr (series)
      plugsy.link: http://sonarr.o/
      plugsy.category: Media
      org.hotio.pullio.update: true

De environment variabelen ($DOCKERDIR, $DATAPOOL) staan in de .env file in de map waarin je docker-compose.yml file staat en waar je dus "docker compose up -d" doet!

Je ziet de caddy labels, en dus ook het lokale domein (sonarr.o in dit geval). Die is in AGH gedefinieerd.

[Mars Warrior]

Arunia schreef op dinsdag 21 maart 2023 @ 14:25:
@Mars Warrior Dat klinkt echt heel uitgebreid wat je doet. Dacht dat ik al voor thuisgebruik best wat dingen had, maar dat valt best mee.

Ik gebruik Docker al sinds 2017: toen heb ik dat op kosten van mijn werkgever allemaal mogen leren en implementeren als een Docker Swarm op het werk (was nog voordat k*s populair werd).

En in de loop van die jaren kom je wel eens wat dingen tegen die het leven makkelijker maken. Ik heb een hekel aan onderhoud, dus wil graag dat het lekker werkt. Dat vergt initieeel wat tijd en testen, maar als het eenmaal werkt dan draait het lekker door.

En nu met een nieuwe server (bestaande servers zijn uit 2012, 2012 en 2015) was het ook weer tijd om alles ff tegen het licht te houden en kom je erachter dat sommige dingen een stuk eenvoudiger en/of beter kunnen als je andere docker containers gebruikt.

Moet alleen nog dingen als nzbget, qbittorrent, de geijkte sonarr, radarr enzovoorts nog eens in Docker zetten.
Maar dan moet ik toch eens zien te kijken hoe ik goed kan backuppen en als ik dus opnieuw moet beginnen, ik wel mijn data blijf behouden. Dat komt uiteindelijk wel als ik wat meer tijd heb.

Als je nu bind mounts (mappen ergens op je server) gebruikt, dan zou je enkel je container naar de juiste map moeten laten wijzen, en dan zou het moeten werken als vanouds!

[orvintax]

Mars Warrior schreef op dinsdag 21 maart 2023 @ 14:09:
[...]

Geen idee welke software zich druk maakt om het TLD. Ik gebruik dat soort containers blijkbaar niet

Een proxy (Caddy, NPM, Traefik) zorgt voor routeren (sub)domein en SSL.

Er draaien hier meerdere domeinen:

• verschillende externe domeinen die deels lokaal draaien (reverse DNS of hoe dat ook heet). Er draaien lokaal dus gewoon *.com en *.nl domeinen, die extern ook bestaan, maar niet noodzakelijkerwijs in mijn bezit zijn. De externe DNS wijst simpelweg naar mijn ip adres thuis.
• verschillende lokale domeinen die dus extern niet beschikbaar zijn. Maar daarom zijn ze ook lokaal...

Ik zit nu in een transitie naar een nieuwe 20-core server die veel zuiniger is dan mijn bestaande/oude 4-core servers. Met zuinig bedoel ik ca 4W idle uit het stopcontact (32GB RAM, 2TB SSD, 20-core CPU).

Ik ga ook van ca 100 containers terug naar 30 door consolidatie van servers (van 3 naar 1) en functionaliteit.

SFTPGo bijvoorbeeld kan bijv zowel SFTP, FTP, HTTP/S, FTP/S als Webdav aan, heeft een ingebouwde GUI, plugins om dingen uit te breiden en kan zelf weer gebruik maken van verschillende back-ends. Dus dat scheelt nogal wat containers, configuratiewerk en dus onderhoud.

Intern gebruik ik Gotify voor events en Pushtify om het door te zette naar Pushover op mijn telefoon.

Influxdb en Telegraf gebruik ik voor metrics zodat ik zowel het CPU verbruik (package) kan meten (is idle nu 850mW) en het gebruik van de diverse containers (proxy, sftp, webdav, etc).

In die context heb ik nu containers gekozen die zelf al deze metrics (hetzij direct in influxdb, hetzij via een /metrics endpoint die Telegraf gebruikt) leveren, waar ik voorheen containers nodig had die logfiles analyseerden. Dat scheelt dus zowel containers, als cpu verbruik als andere resources!

En @Arunia. Is inmiddels een paar jaar geleden en denk niet dat dat met containers was Maar het leek me toch handig om te vermelden.

Verder, mag ik vragen om wat voor een server het gaat? Zulke specs en dan 4W idle klinkt fantastisch!

[Mars Warrior]

orvintax schreef op dinsdag 21 maart 2023 @ 15:20:
[...]

En @Arunia. Is inmiddels een paar jaar geleden en denk niet dat dat met containers was Maar het leek me toch handig om te vermelden.

Verder, mag ik vragen om wat voor een server het gaat? Zulke specs en dan 4W idle klinkt fantastisch!

De 4W is met de 2.5" schijven in sleep overigens. Indien alledrie actief dan komt er ca 3W bij.

Dit alles onder Ubuntu Desktop 22.04.2 LTS met kernel 5.19.

Neem ik een 6.1 kernel dan kom ik zelfs nog lager uit dan die 4W. Maar die versie geeft weer wat andere nadelen waardoor ik weer gewoon op de standaard 5.19 kernel zit.

Metingen met Kernel 6.1:



Kontron (voorheen Fujitsu) borden staan bekend om hun zuinigheid: daarop zijn ze gemaakt.
De ATX voeding van Corsair is op lage belasting de beste ATX voeding die er nu is en komt op ca 1W in de buurt van een goede PicoPSU met adapter.

De 12700K is verder per core beperkt op maximale frequentie zodat deze bij belasting maximaal efficient draait. Ik maak dus niet volledig gebruik van de maximale performance van deze CPU.

Reden:

• de P-cores van de 12700K worden vanaf 4.0Ghz erg inefficiënt, ca 80% meer verbruik
• de E-cores van de 12700K worden vanaf 3.2Ghz erg inefficiënt, ca 50% meer verbruik

Ik lever dus graag wat performance in, voor een stuk minder verbruik. Voor de meeste taken maakt het niet uit of iets nu 2 of 1.8 seconde duurt namelijk.

De 20 cores is wat Linux weergeeft: 8P cores + HT + 4E cores is totaal 20 cores.



En bij elke container kijk ik wat de impact is op het idle verbruik en kijk ik of ik daar iets aan kan doen. Het is namelijk tegenwoordig "hip" om de container een healtcheck te laten doen. Komt van k*s af waar dat "normaal" is.

Door die healtcheck uit te zetten, of slechts elke minuut te doen daalt het verbruik zoals je in onderstaand screenshot van influxdb kunt zien rond 16:15:00:



En tenslotte mijn inventaris:

#	Category	Product	Prijs	Subtotaal
1	Processors	Intel Core i7-12700K Boxed	€ 324,36	€ 324,36
1	Moederborden	Kontron K3843-B	€ 0,-	€ 0,-
1	Behuizingen	Inter-Tech IM-1 Pocket	€ 64,86	€ 64,86
3	Externe harde schijven	Seagate Expansion+ Portable Drive 4TB Zwart	€ 0,-	€ 0,-
1	Processorkoeling	Scythe Kotetsu Mark II Rev.B	€ 44,90	€ 44,90
1	Geheugen intern	Corsair Vengeance CMK64GX5M2B5200C40	€ 234,-	€ 234,-
1	Voedingen	Corsair RM550x (2021) Zwart	€ 139,35	€ 139,35
1	Solid state drives	Solidigm 670p 2TB	€ 103,25	€ 103,25
Bekijk collectie Importeer producten			Totaal	€ 910,72

[Kaspers]

Mars Warrior schreef op dinsdag 21 maart 2023 @ 13:45:
[...]

Nee. Te hoge CPU load, te hoge CPU load, te hoge CPU load en naar mijn mening "onnodig complex" vergeleken met een docker compose file.

Ik wil een zuinige server, en dat is met k*s niet mogelijk, die krijg je idle niet onder de 0.1% cpu load

Wil je het simpel houden (lokale DNS, extern via eigen domein) dan is docker compose met labels voor bijv. Caddy behoorlijk simpel en voorspelbaar.

Als je Caddy (de docker versie die labels snapt) vergelijkt met Traefik dan zie je hetzelfde verschil als tussen docker compose en k*s: je hebt een halve studie nodig om de meest basale dingen voor elkaar te krijgen.

En als je bezig bent om docker te begrijpen zou ik alles rondom k0s/k3s/k8s lekker links laten liggen

Mwoah, een hogere CPU load wil ik nog wel gaan bediscussiëren
Deze host draait meer dan 100 containers:



Ik vind die load niet noemenswaardig hoog.

[Mars Warrior]

Kaspers schreef op dinsdag 21 maart 2023 @ 19:06:
[...]
Mwoah, een hogere CPU load wil ik nog wel gaan bediscussiëren
Deze host draait meer dan 100 containers:

[Afbeelding]

Ik vind die load niet noemenswaardig hoog.

Die ca 10% load per core die je ziet is gewoon k3s hoor, alles daarboven zijn pas je containers

Overall natuurlijk niet slecht met zoveel containers, maar dat is lastig vergelijken: mijn 100 containers zaten rond de 1% cpu namelijk onder docker swarm.

Maar als je ff kijkt in de documentatie van k3s zelf:



Hetgeen door zeer veel mensen wordt bevestigd in dit issue.

[Jazco2nd]

@Mars Warrior dit is niet het Het grote zuinige server topic - deel 3 hé?

@Arunia
Mijn guide is bedoeld voor de beginner en geeft alle info die ik nodig heb mocht ik helemaal opnieuw moeten beginnen. Het bevat ook een guide die uitlegt hoe je met docker compose omgaat, zie Stap 5: https://github.com/zilexa...ation-and-personalisation

En ook hoe je beste je mappenstructuur kunt maken voor *arr apps. Je netwerk configuratie icm lokale domeinen en een publiek domein, Adguard, Wireguard VPN.
En ook uitleg per service met link naar de officiële documentatie (indien beschikbaar). Compleet naslagwerk dus.

Het is volgens mij nog best up to date en ik heb afgelopen dagen nog een hoop geupdate (compose file en de maintenance scripts Nightly en Monthly). Changelog gebruik ik een issue voor op GitHub zodat je makkelijk op kunt subscriben voor updates.. daar zie je dan ook of er voor jou nuttige updates zijn.

Middels het Changelog probeer ik mijn motivatie voor bepaalde keuzes of wijzigingen toe te lichten. Ik ben nog aardig wat dingen tegengekomen de laatste tijd, met name mbt FileRun en Docker.

Het draait hier als een tierelier zonder dat ik een dashboard hoef te monitoren. Als het goed is krijg ik met de laatste wijziging netjes maandelijks een melding wanneer de server een reboot wil (bijv omdat een container dat wil of omdat het OS is geupdate en dat vereist) en een status rapport over resterende vrije ruimte + per user gebruikte opslag

[Mars Warrior]

Jazco2nd schreef op woensdag 22 maart 2023 @ 13:43:
@Mars Warrior dit is niet het Het grote zuinige server topic - deel 3 hé?

Een zuinige server is natuurlijk niet enkel de hardware hè

Ik heb door healtchecks te wijzigen of helemaal af te zetten en door de Crashplan container op de E-cores te zetten denk ik toch al wel €10 bespaart op jaarbasis. Dat wordt zeker eerder stoppen met werken

Op dit ogenblik is SnapRaid een uurtje of 6 bezig om te syncen, dus kan ik ff wat anders doen.

Ik heb bijna 1 server uitgefaseerd. En moet nog een tweede doen.
Op die server draait nu (alles Docker overigens) NPM (Nginx Proxy Manager) die alle lokale webservices doet, maar ook alles over HTTPS dat van buiten komt.

NPM zet dit als proxy door naar verschillende servers.

Nu wil ik overal Caddy Docker Proxy gaan gebruiken. Die kijkt normaliter naar labels in de docker compose file. Dat werkt goed voor 1 server.

Caddy moet echter ook wat dingen naar andere servers doorzetten.

Heeft iemand hier ervaring mee? Is het mogelijk om op de Caddy container zelf bijv. deze proxies naar andere servers te definieren, inclusief de LetsEncrypt dingen?

[RobertMe]

Mars Warrior schreef op zaterdag 25 maart 2023 @ 16:19:
Nu wil ik overal Caddy Docker Proxy gaan gebruiken. Die kijkt normaliter naar labels in de docker compose file. Dat werkt goed voor 1 server.

Caddy moet echter ook wat dingen naar andere servers doorzetten.

Heeft iemand hier ervaring mee? Is het mogelijk om op de Caddy container zelf bijv. deze proxies naar andere servers te definieren, inclusief de LetsEncrypt dingen?

Hoe hard ben je met Caddy getrouwd? Traefik heeft meerdere methodes om de "backends" te bepalen. Op basis van Docker labels, maar op basis van files kan ook. Verwijzen naar services op een andere server kun je dan via files doen en wat op dezelfde server draait via Docker labels.

Maar eerlijk is eerlijk, met de docker compose files die je laatst plaatste (meen in zuinige server topic) was ik wel jaloers hoe simpel de Caddy labels zijn

[Mars Warrior]

RobertMe schreef op zaterdag 25 maart 2023 @ 16:25:
[...]

Hoe hard ben je met Caddy getrouwd?

Ik ken 'haar' pas 2 maanden, dus we zijn nog niet getrouwd. We zitten nog in de kennismakings fase

Maar eerlijk is eerlijk, met de docker compose files die je laatst plaatste (meen in zuinige server topic) was ik wel jaloers hoe simpel de Caddy labels zijn

Ze is inderdaad erg makkelijk in de omgang. Wel een beetje een pietje precies: ik had eerder een inieminie typefoutje gemaakt, en hoppa, alles kapot!

Traefik heeft meerdere methodes om de "backends" te bepalen. Op basis van Docker labels, maar op basis van files kan ook. Verwijzen naar services op een andere server kun je dan via files doen en wat op dezelfde server draait via Docker labels.

Caddy heeft welgeteld 2 regels nodig voor een proxy. En als op die poort ook nog de websockets zitten, dan gaat ook dat automatisch. Hoef je geen regel extra voor te typen. Vergelijk dat eens met NGINX of Traefik!

Traefik blijft voor mij een waterhoofd. Wel met enorm veel mogelijkheden, maar ook vreselijk complex. Ik krijg elke keer Kubernetes-merries (ipv nachtmerries) als ik een config van Treafik bekijk.

Pak bijv http vs https: als ik voor een domein dat ik wil proxien https zet, dan vraagt Caddy een certificaat aan, en met http ervoor niet. Hoe veel simpeler kun je het maken voor een eindgebruiker!

Als het ff kan wil ik Traefik dus vermijden. Ook die heeft liever geen externe services, want ze hebben die info over externe bestanden een beetje lopen verstoppen vind ik.

Het enige dat ik nog niet duidelijk heb is of Caddy probleemloos met HTTPS icm Safari kan werken. NGINX heeft daarvoor extra instellingen nodig in de proxy om dat te laten werken namelijk.

[RobertMe]

Mars Warrior schreef op zaterdag 25 maart 2023 @ 16:42:
[...]

Caddy heeft welgeteld 2 regels nodig voor een proxy. En als op die poort ook nog de websockets zitten, dan gaat ook dat automatisch. Hoef je geen regel extra voor te typen. Vergelijk dat eens met NGINX of Traefik!

Huh? Websockets lopen toch gewoon over http(s)? Daarvoor heb je bij Traefik op zichzelf geen extra config nodig.

Traefik blijft voor mij een waterhoofd. Wel met enorm veel mogelijkheden, maar ook vreselijk complex. Ik krijg elke keer Kubernetes-merries (ipv nachtmerries) als ik een config van Treafik bekijk.

Wellicht ook door legacy? Bij Traefik 1 zat je dan met toml files te werken (wie heeft dat format bedacht?!), bij 2 kan YAML ook, scheelt IMO al een berg. Daarnaast heeft Traefik 2 sowieso allemaal nieuwe trucjes geleerd.

Pak bijv http vs https: als ik voor een domein dat ik wil proxien https zet, dan vraagt Caddy een certificaat aan, en met http ervoor niet. Hoe veel simpeler kun je het maken voor een eindgebruiker!

Ja, je moet bij Traefik natuurlijk expliciet zijn in het definiëren van de entrypoints. Maar in v2 kun je wel al op "het entrypoint met poort 443" aangeven welke certificate resolver gebruikt moet worden. En die wordt dan ook automatisch toegepast op alle "routers". Dus je hoeft niet meer per "router" (in v1 was het nog frontend?) aan te geven dat je iets met certificaten wilt doen. Daarnaast worden IIRC alle entrypoints standaard toegepast (of kon je dat eenmalig definiëren? Welke entrypoints standaard toegepast moeten worden). En je kunt op een entrypoint ook al standaard middlewares vastleggen (bv redirect naar https vanaf http of HSTS inschakelen). In ieder geval heb ik aan 2 labels voldoende om een container via Traefik beschikbaar te maken. En dat is dan 1x traefik.enable omdat ik uit heb gezet dat die standaard alle containers moet pogen te exposen. En de ander dan om aan te geven "deze service / container moet bereikbaar zijn onder hostname...".

Als het ff kan wil ik Traefik dus vermijden. Ook die heeft liever geen externe services, want ze hebben die info over externe bestanden een beetje lopen verstoppen vind ik.

AFAIK staat de files provider niet verder weg gestopt dan de Docker provider?

Het enige dat ik nog niet duidelijk heb is of Caddy probleemloos met HTTPS icm Safari kan werken. NGINX heeft daarvoor extra instellingen nodig in de proxy om dat te laten werken namelijk.

Neem aan dat het dan puur gaat over welke TLS versies aan & uit staan? Of gewoon geen Safari gebruiken

[Mars Warrior]

RobertMe schreef op zaterdag 25 maart 2023 @ 17:23:
[...]
Ja, je moet bij Traefik natuurlijk expliciet zijn in het definiëren van de entrypoints. Maar in v2 kun je wel al op "het entrypoint met poort 443" aangeven welke certificate resolver gebruikt moet worden. En die wordt dan ook automatisch toegepast op alle "routers". Dus je hoeft niet meer per "router" (in v1 was het nog frontend?) aan te geven dat je iets met certificaten wilt doen. Daarnaast worden IIRC alle entrypoints standaard toegepast (of kon je dat eenmalig definiëren? Welke entrypoints standaard toegepast moeten worden). En je kunt op een entrypoint ook al standaard middlewares vastleggen (bv redirect naar https vanaf http of HSTS inschakelen). In ieder geval heb ik aan 2 labels voldoende om een container via Traefik beschikbaar te maken. En dat is dan 1x traefik.enable omdat ik uit heb gezet dat die standaard alle containers moet pogen te exposen. En de ander dan om aan te geven "deze service / container moet bereikbaar zijn onder hostname...".

Ik weet dat je een hoop dingen in Traefik default kunt instellen in een hele rij yaml files en/of in docker compose. Als je zoekt op internet kom je echter tig variaties tegen die allemaal anders zijn.

YAML:

version: '2.1'

services:
  homeassistant:
    restart: always
    image: homeassistant/raspberrypi3-homeassistant
    expose:
      - 8123
    ports:
      - "8123:8123"
    devices:
      - /dev/ttyACM0
    volumes:
      - ./config:/config
    network_mode: host
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.hahttp.rule=Host(`MY_DOMAIN`)"
      - "traefik.http.routers.ha.rule=Host(`MY_DOMAIN`)"
      - "traefik.http.routers.ha.tls=true"
      - "traefik.http.routers.ha.tls.certresolver=le"
      - "traefik.http.routers.ha.tls.domains[0].main=MY_DOMAIN"
      - "traefik.http.services.homeassistant.loadbalancer.server.port=8123"

  traefik:
    restart: always
    image: traefik:v2.2
    command: 
      - "--api.dashboard=true"
      - "--api.insecure=true"
      - "--accesslog=true"
      - "--providers.docker"
      - "--providers.docker.exposedbydefault=false"
      - "--entryPoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "--certificatesresolvers.le.acme.email=MY_EMAIL"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - 80:80
      - 8080:8080
      - 443:443
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./letsencrypt:/letsencrypt"
    extra_hosts: 
      - host.docker.internal:172.17.0.1

Ik weet nooit welke klopt en dat moet ik dan toch elke keer weer uitzoeken...

Caddy aan de andere kant heeft een andere filosofie, namelijk alles is HTTPS by default!

• Dus geen instelling nodig voor https, want default
• Geen instelling nodig voor redirect http naar https, want default
• Geen certificaat instellingen nodig, want default Let's Encrypt of ZeroSSL
• Geen challenge instelling nodig, want default TLS (dus geen poort 80 nodig van buiten)

Door die default instellingen heb je dus werkelijk maar 2 regels per container nodig.

Voor http:

YAML:

    labels:
      caddy: http://whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

Voor https:

YAML:

    labels:
      caddy: whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

Klaar is kees!

Besef wel dat Caddy de INTERNE poorten gebruikt van de container, en niet de externe. Dat scheelt dus weer een paar regels "ports" yaml...

TL;DR:
Ik moet al voldoende leren / uitzoeken vanwege dat rare Linux (Ubuntu in dit geval) en hoe ik sommige containers functioneel moet configureren, dus zoek ik naar simpele oplossingen die - als het ff kan - zo logisch zijn, dat ik zo min mogelijk hoef te doen!

[RobertMe]

Mars Warrior schreef op maandag 27 maart 2023 @ 12:35:
Caddy aan de andere kant heeft een andere filosofie, namelijk alles is HTTPS by default!

• Dus geen instelling nodig voor https, want default
• Geen instelling nodig voor redirect http naar https, want default
• Geen certificaat instellingen nodig, want default Let's Encrypt of ZeroSSL
• Geen challenge instelling nodig, want default TLS (dus geen poort 80 nodig van buiten)

Dit soort zaken kun je bij Traefik dus ook in instellen, eenmalig. En v.w.b. "geen poort 80 naar buiten open", maar wel nog steeds 443, maakt dat het beter? Eigenlijk niet Zeker niet als je toch een http => https redirect hebt. En ik laat gewoon alles dicht en gebruik DNS challenge, en die vereist per definitie configuratie (van de DNS provider etc).

Door die default instellingen heb je dus werkelijk maar 2 regels per container nodig.

Voor http:

YAML:

    labels:
      caddy: http://whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

Voor https:

YAML:

    labels:
      caddy: whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

Klaar is kees!

En Traefik herkent de port automatisch, als de container maar een port exosed. Dan is Kees nog sneller klaar.

Besef wel dat Caddy de INTERNE poorten gebruikt van de container, en niet de externe. Dat scheelt dus weer een paar regels "ports" yaml...

Traefik doet exact hetzelfde. Maar jouw voorbeeld is gewoon super slecht / fout. Allemaal die port mappings & expose en weet ik wat zijn nergens voor nodig.

TL;DR:
Ik moet al voldoende leren / uitzoeken vanwege dat rare Linux (Ubuntu in dit geval) en hoe ik sommige containers functioneel moet configureren, dus zoek ik naar simpele oplossingen die - als het ff kan - zo logisch zijn, dat ik zo min mogelijk hoef te doen!

Dat is zeer zeker waar. En ik zal ook zeker niet zeggen dat Traefik makkelijker is op te zetten. Maar als je ee initiële setup gedaan hebt is het ook weer niet zoveel meer werk. Als in: je steekt een keer een of twee uurtjes in dat uitzoeken en daarna ben je met 1 of 2 labels per container klaar. En bij alle services die achter Traefik moeten moet je wellicht even kijken "hoe het ook alweer zat" maar dat is maar max 5 minuten per keer en zal niet veel langer / korter duren dan bij Caddy.

Edit:
Voor de volledigheid, dit is mijn volledige compose stukje voor HA:

YAML:

  homeassistant:
    image: ghcr.io/home-assistant/home-assistant
    container_name: homeassistant
    networks:
      homeassistant: ~
      traefik: ~
    volumes:
      - ./config/homeassistant/:/config
      - /etc/localtime:/etc/localtime:ro
    labels:
      - traefik.enable=true
      - traefik.http.routers.homeassistant.rule=Host(`ha.<knip>.nl`)
      - traefik.http.services.homeassistant.loadBalancer.server.port=8123
    depends_on:
      - postgresql
      - mosquitto
    restart: unless-stopped

Waarbij traefik.enable dus een keuze is. By default exposed Traefik AFAIK alle containers.

Edit2:
En dit mijn traefik.yaml:

YAML:

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

  websecure:
    address: ":443"
    http:
      tls:
        certResolver: leResolver
        domains:
          - main: "*.<knip>.nl"

providers:
  docker:
    exposedByDefault: false
    network: traefik

certificatesResolvers:
  leResolver:
    acme:
      email: <knip>
      storage: /etc/traefik/acme.json
      dnsChallenge:
        provider: transip

Die dus TransIP gebruikt voor de DNS challenge (welk email adres gebruikt Caddy eigenlijk bij Lets encrypt? Want blijkbaar hoef je dat niet te configureren? En een waarschuwing als cert dreigt te vervallen vind ik wel fijn). En daarnaast dan dat die van http naar https redirect en in een keer een wildcard certificaat aanvraagt.

Edit3
Nog even verder gekeken v.w.b. exposedByDefault, en blijkbaar kun je tegenwoordig constraints opgeven op basis waarvan een container geexposed wordt. Dus dan zou een constraint kunnen om alleen containers met een traefik.http.routers.* label te exposen.

[Voor 27% gewijzigd door RobertMe op 27-03-2023 13:20]

[Mars Warrior]

RobertMe schreef op maandag 27 maart 2023 @ 13:03:
[...]
Dit soort zaken kun je bij Traefik dus ook in instellen, eenmalig.

Klopt, maar bij Caddy dus allemaal niet nodig!

En Traefik herkent de port automatisch, als de container maar een port exosed. Dan is Kees nog sneller klaar.

Traefik pakt de 1ste poort die exposed wordt. Heb je er maar 1, dan ben je inderdaad snel klaar...

Traefik doet exact hetzelfde. Maar jouw voorbeeld is gewoon super slecht / fout. Allemaal die port mappings & expose en weet ik wat zijn nergens voor nodig.

Ik denk dat je hier het pijnpunt van Traefik te pakken hebt: het is voor de meeste mensen zo onduidelijk dat iedereen maar wat probeert, en dat vervolgens weer van elkaar overneemt. En zo ontstaan natuurlijk configuraties die nergens meer op slaan, maar wel werken.

De User Guides zijn nog steeds zeer beperkt on incompleet omdat men de nadruk legt op de technische documentatie (wat allemaal kan) en niet hoe je vanuit een functionele wens eea moet configureren.

Zelfs in hun "basic" voorbeelden hebben ze 4 labels nodig om een HTTPS entry te definieren:

YAML:

  whoami:
    image: "traefik/whoami"
    container_name: "simple-service"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=myresolver"

Ik raak al beetje van slag van bovenstaande. Mijn brein ziet teveel vragen: Want is het toeval dat de .whoami. router net zo heet als de container, of niet? En als die toch hetzelfde moet zijn, waarom moet ik hem dan definieren? Dan kan dat toch automatisch? En wat zijn websecure en myresolver? Willekeurige namen, of standaard items, net als .tls. enzo ? En ik wil https, waarom staat er dan .http. bij de routers? Etc.......

Dat is zeer zeker waar. En ik zal ook zeker niet zeggen dat Traefik makkelijker is op te zetten. Maar als je ee initiële setup gedaan hebt is het ook weer niet zoveel meer werk. Als in: je steekt een keer een of twee uurtjes in dat uitzoeken en daarna ben je met 1 of 2 labels per container klaar. En bij alle services die achter Traefik moeten moet je wellicht even kijken "hoe het ook alweer zat" maar dat is maar max 5 minuten per keer en zal niet veel langer / korter duren dan bij Caddy.

Ik denk als Traefik dezelfde "quick starts" zou opnemen als Caddy, dat alles veel duidelijker en voorspelbaarder zou worden voor de gemiddelde gebruiker.

Ik heb - na welgeteld 1 voorbeeld van Caddy Docker Proxy (CDP) Github pagina - de hele documentatie van Caddy niet eens hoeven bekijken. Het was copy/paste en draaien voor de 1ste container, en daarna heb ik dat herhaald voor de andere containers die ik heb.

YAML:

  whoami:
    image: containous/whoami
    networks:
      - caddy
    labels:
      caddy: whoami.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"

Voor mijn manier van denken is Caddy dus "logisch" en Traefik "onlogisch en onduidelijk". En dat laatste kost dus veel energie en tijd. En die kan ik beter aan andere dingen besteden.

Maar anderen die graag door documentatie gaan en geen behoefte hebben aan plaatjes en verbanden die zullen met Traefik geen of minder problemen hebben.

Toevoeging:
Jouw voorbeelden zijn al een stuk simpeler dan de voorbeelden die ik heb kunnen vinden. Mijn dank daarvoor!

Zo'n opzet zou mooi staan bij de "User Guides" van Traefik

[RobertMe]

@Mars Warrior korte reactie zonder de specifieke stukjes te quoten De documentatie van Traefik laat (/liet? Al jaren niet meer echt gelezen) inderdaad wel te wensen over v.w.b. een aantal basis use cases uit te leggen / van een voorbeeld te voorzien.
Maar de vergelijking met Caddy gaat denk ik sowieso een beetje mank doordat Caddy denk ik volledig op de Docker use case gericht is van de simpele thuisgebruiker? Terwijl Traefik veel groter is en veel complexere zaken kan dan Caddy (denk ik) kan. Zoals dus een hele lijst aan providers waardoor je deze ook als proxy voor elke willekeurige HTTP service kunt zetten (met de file provider bv dus), de functionaliteit waar jij naar vraagt. Maar wat ik bv ook mis bij Caddy en denk ik niet kan is ondersteuning voor het proxyen van meerdere poorten in 1 container. Bv de Ubiquiti UniFi Controller heeft 1 poort (8443) voor de beheer omgeving en 1 poort (8843) voor de guest portal. In Traefik kun je dan 2 sets labels gebruiken met een andere router & service naam. Bij Caddy kan dat vermoed ik helemaal niet? Doordat je de vaste labels hebt. 2x "caddy" gebruiken met een andere hostname en 2x "caddy.reverse_proxy" met een andere poort zal niet ineens twee verschillende "virtual hosts" aanmaken waarbij die ook nog weet welk backend/welke upstream bij welke URL hoort.

TL;DR: de use cases van Caddy vs Traefik zijn denk ik gewoon nogal afwijkend. Ondanks dat voor simpel thuisgebruik ze wel hetzelfde kunnen. Alleen loop jevdan bij Traefik wat meer tegen de complexiteit aan, terwijl je anderzijds bij Caddy het risico hebt dat je net iets meer wilt dan deze kan uit zichzelf.

[Voor 10% gewijzigd door RobertMe op 27-03-2023 15:16]

[CH4OS]

RobertMe schreef op maandag 27 maart 2023 @ 13:03:
Waarbij traefik.enable dus een keuze is. By default exposed Traefik AFAIK alle containers.

Klopt: Documentatie. Het traefik.enable label is dus alleen voor containers wanneer exposedByDefault op false staat (lijkt me security technisch gezien sowieso al veiliger). Maar op deze manier heb je zelf ook wat meer controle over wat wel via Traefik bereikbaar is en wat niet. Soms kan iets explicieter zijn geen kwaad.

[Voor 36% gewijzigd door CH4OS op 27-03-2023 15:23]

[RobertMe]

CH4OS schreef op maandag 27 maart 2023 @ 15:21:
[...]
Klopt: Documentatie. Het traefik.enable label is dus alleen voor containers wanneer exposedByDefault op false staat (lijkt me security technisch gezien sowieso al veiliger). Maar op deze manier heb je zelf ook wat meer controle over wat wel via Traefik bereikbaar is en wat niet. Soms kan iets explicieter zijn geen kwaad.

Wat ik dan zelf wel ook flauw vind is dat het toevoegen van een van de traefik labels niet alsnog duidelijk genoeg is om het (by default) te laten exposen. Als ik een http.routers.<...>.rule er op zet is de kans wel heel erg groot dat ik het ding ook daadwerkelijk wil enablen.

[CH4OS]

Jazco2nd schreef op woensdag 22 maart 2023 @ 13:43:
En ook hoe je beste je mappenstructuur kunt maken voor *arr apps.

Voor deze instellingen en meer, kan je denk ik beter even kijken bij https://trash-guides.info/.

[Mars Warrior]

TL;DR: de use cases van Caddy vs Traefik zijn denk ik gewoon nogal afwijkend. Ondanks dat voor simpel thuisgebruik ze wel hetzelfde kunnen. Alleen loop jevdan bij Traefik wat meer tegen de complexiteit aan, terwijl je anderzijds bij Caddy het risico hebt dat je net iets meer wilt dan deze kan uit zichzelf.

Het klopt gedeeltelijk wat je zegt: Caddy en in dit geval CDP (Caddy Docker Proxy) is door zijn defaults veel simpeler voor recht-to-recht-aan proxy gebruik met https, wat inderdaad de meeste thuisgebruikers nodig hebben!

Maar Caddy blijft een full-spec proxy, zie hieronder...

RobertMe schreef op maandag 27 maart 2023 @ 15:14:
Terwijl Traefik veel groter is en veel complexere zaken kan dan Caddy (denk ik) kan. Zoals dus een hele lijst aan providers waardoor je deze ook als proxy voor elke willekeurige HTTP service kunt zetten (met de file provider bv dus), de functionaliteit waar jij naar vraagt. Maar wat ik bv ook mis bij Caddy en denk ik niet kan is ondersteuning voor het proxyen van meerdere poorten in 1 container. Bv de Ubiquiti UniFi Controller heeft 1 poort (8443) voor de beheer omgeving en 1 poort (8843) voor de guest portal. In Traefik kun je dan 2 sets labels gebruiken met een andere router & service naam. Bij Caddy kan dat vermoed ik helemaal niet? Doordat je de vaste labels hebt. 2x "caddy" gebruiken met een andere hostname en 2x "caddy.reverse_proxy" met een andere poort zal niet ineens twee verschillende "virtual hosts" aanmaken waarbij die ook nog weet welk backend/welke upstream bij welke URL hoort.

CDP maakt goed gebruik van YAML dingen om lijsten, arrays en records te maken. CDP is immers niets meer dan een vertaalslag van Docker Labels naar een volwaardige caddyfile!

Dus als je meer entries nodig hebt, dan voeg je een _x toe aan het einde bijv.
Ik gebruik dat voor wat containers die poort 80 gebruiken voor de webgui, en een andere poort voor het beheer.

YAML:

    labels:
      caddy.email: $EMAIL
      caddy_0: beheer.unify.com
      caddy_0.reverse_proxy: {{upstreams 8443}}
      caddy_1: guest.unify.com
      caddy_1.reverse_proxy: {{upstreams 8843}}

Caddy heeft standaard een eigen intern certificaat dat je kunt gebruiken:

YAML:

    labels:
      caddy: whoami2.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"
      caddy.tls: "internal"

Of een andere certificaat provider, de staging van Lets Encrypt in dit geval:

YAML:

      labels:
        caddy: whoami1.example.com
        caddy.reverse_proxy: "{{upstreams 80}}"
        caddy.tls.ca: https://acme-staging-v02.api.letsencrypt.org/directory

Wil je meer, dan ontkom je niet aan Traefik achtige praktijken , routes met named (@) matchers.
Je ziet hier dan weer dat om route volgordes te definieren, een 0_, 1_ etc wordt gebruikt om deze volgorde weer te geven...

YAML:

      labels:
        caddy: path.example.com
        [e-mail]: "/sourcepath /sourcepath/*"
        caddy.route: "@match"
        caddy.route.0_uri: "strip_prefix /sourcepath"
        caddy.route.1_rewrite: "* /targetpath{path}"
        caddy.route.2_reverse_proxy: "{{upstreams 80}}"

Lokale toegang van een site, maar wel MET https. Dus niet extern beschikbaar.
IP adressen worden via een named matcher (@local in dit geval) gematched met de proxy.

YAML:

    labels:
      caddy: local-only.example.com
      [e-mail]_ip: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
      caddy.reverse_proxy: "@local {{upstreams 80}}"

Voorbeeld van nextcloud zelf:

YAML:

    labels:
      caddy: nextcloud.example.com
      caddy.reverse_proxy: "{{upstreams 80}}"
      caddy.0_redir: "/.well-known/carddav /remote.php/dav 301"
      caddy.1_redir: "/.well-known/caldav /remote.php/dav 301"
      caddy.header: "Strict-Transport-Security max-age=15552000"

Wil je het nog complexer maken, dan kun je snippets definieren die je op andere plekken weer kunt hergebruiken, maar dan heb je de initiele eenvoud van CDP wel achter je gelaten moet ik zeggen...

Voor complexe(re) zaken zul je dus wel ff in de manual moeten gaan kijken en zal CDP/Caddy mogelijk niet veel afwijken van Traefik als het gaat om de tijd die je erin moet steken om te leren hoe dingen moeten.

Wie weet heeft iemand nog wat aan bovenstaande voorbeelden

[Mars Warrior]

Ik heb nog iets geks. (zie Update)

Elke keer als ik "docker compose up -d" doe, dan wordt o.a. de crashplan container opnieuw aangemaakt, ondanks dat ik niets heb gewijzigd aan deze container. De andere containers worden gewoon gestart.

Ik heb zitten zoeken in de Docker documentatie, maar kan geen reden vinden waarom deze container elke keer een "recreate" voor zijn kiezen krijgt...

YAML:

infra-crashplan:
    container_name: infra-crashplan
    image: jlesage/crashplan-pro
    restart: always
    # Use E-cores for crashplan.
    # Crashplan at 100% / 1 core @2.5Ghz uses 6W Package Power.
    cpuset: "16-19"
    networks:
      - web-proxy
      - infra
    volumes:
      # Store crashplan configuration
      - $DOCKERDIR/infra/crashplan-pro:/config:rw
      # Point storage to the MergerFS pool for backups
      - /mnt/pool:/storage:ro
    labels:
      caddy: http://crashplan.z
      caddy.reverse_proxy: "{{upstreams 5800}}"

Update - Update - Update...

Zie net dit issue nadat ik een update van dockerd.io voorbij zie komen.

Ik zit nog op Docker Compose version v2.16.0 en de fix zou in v2.17 moeten zitten

[Mars Warrior]

Mars Warrior schreef op zaterdag 25 maart 2023 @ 16:19:
Nu wil ik overal Caddy Docker Proxy gaan gebruiken. Die kijkt normaliter naar labels in de docker compose file. Dat werkt goed voor 1 server.

Caddy moet echter ook wat dingen naar andere servers doorzetten.

Heeft iemand hier ervaring mee? Is het mogelijk om op de Caddy container zelf bijv. deze proxies naar andere servers te definieren, inclusief de LetsEncrypt dingen?

Om mijzelf maar ff te herhalen.

Ik heb op de CDP container een extra proxy gezet die naar mijn NUC doorverwijst naar zowel Zigbee2Mqtt als de Home Assistant container. En dit werkt!

YAML:

    labels:
      caddy_0: http://z2mqtt-nuc.z
      caddy_0.reverse_proxy: domotica:8880
      caddy_1: http://homeassistant-nuc.z
      caddy_1.reverse_proxy: domotica:8123

Moest voor HA natuurlijk wel CDP als een trusted_proxy toevoegen, maar dat was dan ook alles.

Ik kan dus straks met Adguard als DNS en CDB als proxy bij elke lokale docker container en remote docker containers op andere servers komen.

Soms denk je onterecht dat iets afwijkt

[WheeleE]

Tot voor kort had ik op mijn Synology DS220 een docker stack draaien met een vpn-client en een aantal containers die via de vpn-container naar buiten gingen. Alles werkte uitstekend, de client-containers kwamen netjes met het vpn-ipadres naar buiten.
Nu heb ik deze week een deel gedupliceert naar een Raspberry Pi. Tot mijn verbazing komt de enige client-container (qbittorrent) die er op draait naar buiten met zowel het vpn-adres als het adres van mijn thuis-internet.
De ip-adressen heb ik in beide situaties elke keer via de interactive mode van de containers met wget -O - -q icanhazip.com gecontroleerd.

Het enige verschil tussen de 2 installaties is dat ik op de Pi een ander openvpnclient-image moest gebruiken. yacht7/openvpn-client op de Synology bleek niet geschikt voor ARM op de Pi, dus daar gebruik ik ghcr.io/wfg/openvpn-client.

Mijn netwerk/docker-kennis strekt niet ver genoeg om dit grondig te troubleshooten. Het zal waarschijnlijk in de vpn-container liggen maar hoe kom ik er achter wat er mis is en wat ik moet fixen?

[RobertMe]

WheeleE schreef op woensdag 29 maart 2023 @ 16:05:
Tot voor kort had ik op mijn Synology DS220 een docker stack draaien met een vpn-client en een aantal containers die via de vpn-container naar buiten gingen. Alles werkte uitstekend, de client-containers kwamen netjes met het vpn-ipadres naar buiten.
Nu heb ik deze week een deel gedupliceert naar een Raspberry Pi. Tot mijn verbazing komt de enige client-container (qbittorrent) die er op draait naar buiten met zowel het vpn-adres als het adres van mijn thuis-internet.
De ip-adressen heb ik in beide situaties elke keer via de interactive mode van de containers met wget -O - -q icanhazip.com gecontroleerd.

Het enige verschil tussen de 2 installaties is dat ik op de Pi een ander openvpnclient-image moest gebruiken. yacht7/openvpn-client op de Synology bleek niet geschikt voor ARM op de Pi, dus daar gebruik ik ghcr.io/wfg/openvpn-client.

Mijn netwerk/docker-kennis strekt niet ver genoeg om dit grondig te troubleshooten. Het zal waarschijnlijk in de vpn-container liggen maar hoe kom ik er achter wat er mis is en wat ik moet fixen?

Kan het niet zijn dat eentje bv het IP adres lekt via DNS verkeer? Als die container nog steeds jouw eigen DNS server gebruikt kan via deze route het IP adres achterhaald worden. In ieder geval kan puur een HTTP(S) request niet over 2 adressen gebeuren. Maar een DNS based test is meestal wel een stuk complexer (/trager) en dat zie ik bij de door jou aangehaalde website niet terug. Vergelijk dat bv met een website als https://www.dnsleaktest.com/

[WheeleE]

RobertMe schreef op woensdag 29 maart 2023 @ 16:14:
[...]

Kan het niet zijn dat eentje bv het IP adres lekt via DNS verkeer? Als die container nog steeds jouw eigen DNS server gebruikt kan via deze route het IP adres achterhaald worden. In ieder geval kan puur een HTTP(S) request niet over 2 adressen gebeuren. Maar een DNS based test is meestal wel een stuk complexer (/trager) en dat zie ik bij de door jou aangehaalde website niet terug. Vergelijk dat bv met een website als https://www.dnsleaktest.com/

Die DNSleaktest heb ik zo even gauw niet binnen de containers kunnen testen.
Wat ik wel heb ontdekt is dat het aan de Raspberry ligt en niet aan de images of instellingen van de containers. De exact gelijke compose yml van de raspberry op de synology draaien geeft maar 1 extern ip, dat van de vpn.
Google geeft me wel wat hits over dns leaks op een raspberry dus daar ga ik maar eens in duiken,

Dank voor het duwtje de juiste richting op!

[rvk]

WheeleE schreef op woensdag 29 maart 2023 @ 17:08:
[...]
Wat ik wel heb ontdekt is dat het aan de Raspberry ligt en niet aan de images of instellingen van de containers. De exact gelijke compose yml van de raspberry op de synology draaien geeft maar 1 extern ip, dat van de vpn.

Ik draai een wireguard docker op de rpi.
Die icanhazip kijkt toch verder niet naar dns?

Deze geven op mijn wireguard docker gewoon de externe addressen.

code:

docker exec -it vpn curl ipinfo.io/json
docker exec -it vpn curl icanhazip.com

En mijn torrent docker kan alleen van de "network: service:vpn" gebruik maken.

Uiteraard moet je je vpn docker even goed controleren of die over het goede ip naar buiten gaat.

(Ik ben juist overgeschakeld van openvpn naar wireguard want bij openvpn kreeg ik maar 20Mbps en bij wireguard de volledige 350Mbps).

[WheeleE]

rvk schreef op woensdag 29 maart 2023 @ 17:42:
[...]

Ik draai een wireguard docker op de rpi.
Die icanhazip kijkt toch verder niet naar dns?

Deze geven op mijn wireguard docker gewoon de externe addressen.

code:

docker exec -it vpn curl ipinfo.io/json
docker exec -it vpn curl icanhazip.com

En mijn torrent docker kan alleen van de "network: service:vpn" gebruik maken.

Uiteraard moet je je vpn docker even goed controleren of die over het goede ip naar buiten gaat.

(Ik ben juist overgeschakeld van openvpn naar wireguard want bij openvpn kreeg ik maar 20Mbps en bij wireguard de volledige 350Mbps).

Curl doet het (nog) niet in m'n vpn-container helaas.
Aan de containers lijkt het niet te liggen. Die draaien op mijn Synology precies zoals het moet, zonder lek. Daaruit concludeer ik dat de instellingen en routering via de vpn-container correct is.
Welk image gebruik je voor wireguard? Ik heb geen specifieke reden om openvpn te gebruiken anders dan dat dat de makkelijkste leek om op te zetten.

[rvk]

WheeleE schreef op woensdag 29 maart 2023 @ 17:51:
[...]
Welk image gebruik je voor wireguard? Ik heb geen specifieke reden om openvpn te gebruiken anders dan dat dat de makkelijkste leek om op te zetten.

linuxserver/wireguard:latest en linuxserver/transmission:latest Op een raspberry pi 4 8GB.

Maar ik ben ook maar net voor dit weekend begonnen met docker

(Overigens zal de poort 9091 niet nodig zijn voor alleen uitgaand van wireguard.
Die is volgens mij meer voor binnenkomende vpn verkeer.)

code:

version: "3"
services:

  vpn:
    container_name: vpn
    image: linuxserver/wireguard:latest
    restart: unless-stopped
    network_mode: space11
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 9091:9091
    volumes:
      - ./wireguard:/config
      - /lib/modules:/lib/modules
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - LOG_CONFS=true
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.ip_forward=1

  transmission:
    container_name: transmission
    image: linuxserver/transmission:latest
    restart: unless-stopped
    network_mode: service:vpn
    depends_on:
      - vpn
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Eurpe/Amsterdam
      - USER=transmission
      - PASS=transmission
    volumes:
      - ./transmission:/config
      - /mnt/share:/mnt/share

# en nog wat meer containers :)

networks:
  space11:
    external: true

De wg0.conf van wireguard:

Ik ben ook niet helemaal zeker of die PostUp compleet nodig is, maar het werkt bij mij.
x.x.x.x en y.y.y.y dns zijn ook de eigen dns servers van mijn vpn provider.
z.z.z.z:51820 is de wireguard endpoint
en je moet bij je provider een key pair (private en public) genereren voor wireguard (ik gebruik wireshark).
Ik heb hem hier ook nog even als root draaien (0:0) maar eigenlijk zou dat 1000:1000 (pi:pi) moeten worden.
(maar aangezien ik op deze server, naar slecht gebruik, alleen nog even root gebruikte, heb ik het even zo gelaten )
Nu lopend als pi:pi

code:

[Interface]
Address = 10.14.0.2/16
PrivateKey = yourprivatekeyforwireguard
PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE;ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE;iptables -I OUTPUT -d $HOMENET -j ACCEPT;iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT;  iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
DNS = x.x.x.x, y.y.y.y

[Peer]
PublicKey = yourpublickeyforwireguard
AllowedIPs = 0.0.0.0/0
Endpoint = z.z.z.z:51820

Mijn raspberry pi zelf zit dus niet achter de vpn. Alleen de docker stack zit op de vpn van de docker stack.

Ps: Speedtestje draaien direct op je pi:

code:

docker run --rm robinmanuelthiel/speedtest:latest

En in de vpn docker:

code:

docker run --rm --network=container:vpn robinmanuelthiel/speedtest:latest

[Voor 3% gewijzigd door rvk op 29-03-2023 21:56]

[WheeleE]

rvk schreef op woensdag 29 maart 2023 @ 18:07:
[...]

linuxserver/wireguard:latest en linuxserver/transmission:latest Op een raspberry pi 4 8GB.

Maar ik ben ook maar net voor dit weekend begonnen met docker

(Overigens zal de poort 9091 niet nodig zijn voor alleen uitgaand van wireguard.
Die is volgens mij meer voor binnenkomende vpn verkeer.)

code:

version: "3"
services:

  vpn:
    container_name: vpn
    image: linuxserver/wireguard:latest
    restart: unless-stopped
    network_mode: space11
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 9091:9091
    volumes:
      - ./wireguard:/config
      - /lib/modules:/lib/modules
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - LOG_CONFS=true
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.ip_forward=1

  transmission:
    container_name: transmission
    image: linuxserver/transmission:latest
    restart: unless-stopped
    network_mode: service:vpn
    depends_on:
      - vpn
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Eurpe/Amsterdam
      - USER=transmission
      - PASS=transmission
    volumes:
      - ./transmission:/config
      - /mnt/share:/mnt/share

# en nog wat meer containers :)

networks:
  space11:
    external: true

De wg0.conf van wireguard:

Ik ben ook niet helemaal zeker of die PostUp compleet nodig is, maar het werkt bij mij.
x.x.x.x en y.y.y.y dns zijn ook de eigen dns servers van mijn vpn provider.
z.z.z.z:51820 is de wireguard endpoint
en je moet bij je provider een key pair (private en public) genereren voor wireguard (ik gebruik wireshark).
Ik heb hem hier ook nog even als root draaien (0:0) maar eigenlijk zou dat 1000:1000 (pi:pi) moeten worden.
(maar aangezien ik op deze server, naar slecht gebruik, alleen nog even root gebruikte, heb ik het even zo gelaten )
Nu lopend als pi:pi

code:

[Interface]
Address = 10.14.0.2/16
PrivateKey = yourprivatekeyforwireguard
PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE;ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE;iptables -I OUTPUT -d $HOMENET -j ACCEPT;iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT;  iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
DNS = x.x.x.x, y.y.y.y

[Peer]
PublicKey = yourpublickeyforwireguard
AllowedIPs = 0.0.0.0/0
Endpoint = z.z.z.z:51820

Mijn raspberry pi zelf zit dus niet achter de vpn. Alleen de docker stack zit op de vpn van de docker stack.

Ps: Speedtestje draaien direct op je pi:

code:

docker run --rm robinmanuelthiel/speedtest:latest

En in de vpn docker:

code:

docker run --rm --network=container:vpn robinmanuelthiel/speedtest:latest

Met dank aan jouw info bleek het opzetten van een wireguard-container simpel.

Deze geven beiden het verwachte externe vpn-adres aan

code:

docker exec -it vpn curl ipinfo.io/json
docker exec -it vpn curl icanhazip.com

Hetzelfde resultaat krijg ik als ik het in de qtorrent-container doe.

So far so good dus. Maar...bij de qtorrentwebinterface komen lukt nog even niet. Blijkbaar zit het netwerkstukje voor wireguard anders in elkaar dan met een openvpn-container.
To be continued!

code:

version: "2"

services:
  vpn:
    container_name: vpn
    image: linuxserver/wireguard:latest
    restart: unless-stopped
    network_mode: media
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 8083:8083
      - 6887:6887
      - 6887:6887/udp
    volumes:
      - /docker/vpn:/config
      - /lib/modules:/lib/modules
    environment:
      - TZ=Europe/Amsterdam
      - LOG_CONFS=true
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.ip_forward=1

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - TZ=Etc/UTC
      - WEBUI_PORT=8083
    volumes:
      - qbittorrent:/config
      - /download:/downloads
    network_mode: service:vpn
    depends_on:
      - mullvad
    restart: unless-stopped

volumes:
  qbittorrent:
  
networks:
  media:
    external: true

[Voor 11% gewijzigd door WheeleE op 30-03-2023 11:42]

[rvk]

WheeleE schreef op donderdag 30 maart 2023 @ 11:30:
[...]
So far so good dus. Maar...bij de qtorrentwebinterface komen lukt nog even niet. Blijkbaar zit het netwerkstukje voor wireguard anders in elkaar dan met een openvpn-container.
To be continued!

Ik heb jouw code hier ook even ingehangen (met qbittorrent) en ik kon de webgui van qbittorrent direct bereiken.

Als dat bij jou niet het geval is dan moet je misschien in de PostUp van de vpn (in die wg0.conf) de HOMENETWORK aanpassen. De server op mijn interne netwerk zit op 192.168.2.21. Dus die 192.168.0.0/16 omvat ook dat netwerk. Als jij niet op 192.168.x.x of 10.x.x.x zit, dan moet je dat dus misschien aanpassen.

Heb je nu overigens nog een lek in qbittorrent of gaat dat nu wel goed?
(ik weet niet welke torrent-service je daarvoor gebruikt om dat goed te controleren.)

[WheeleE]

rvk schreef op donderdag 30 maart 2023 @ 16:35:
[...]

Ik heb jouw code hier ook even ingehangen (met qbittorrent) en ik kon de webgui van qbittorrent direct bereiken.

Als dat bij jou niet het geval is dan moet je misschien in de PostUp van de vpn (in die wg0.conf) de HOMENETWORK aanpassen. De server op mijn interne netwerk zit op 192.168.2.21. Dus die 192.168.0.0/16 omvat ook dat netwerk. Als jij niet op 192.168.x.x of 10.x.x.x zit, dan moet je dat dus misschien aanpassen.

Heb je nu overigens nog een lek in qbittorrent of gaat dat nu wel goed?
(ik weet niet welke torrent-service je daarvoor gebruikt om dat goed te controleren.)

Om een eventueel lek te kunnen controleren met de wireguard-container moet ik eerst bij de qtorrent-interface kunnen komen om een torrent aan te zetten .

Ik ga vanavond of morgen eens in die PostUp duiken. De wg0.conf van mijn provider (mullvad) heeft daar wel e.e.a. in staan maar daar staat in z'n geheel geen homenetwork in vermeld.

code:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Voor 10% gewijzigd door WheeleE op 30-03-2023 19:50]

[Jazco2nd]

@WheeleE @rvk
Zie deze regel die ik bij jullie beide mis:
https://github.com/zilexa...r/docker-compose.yml#L423

Refereert naar:
https://github.com/zilexa...42204584e/docker/.env#L42
Ofwel je LAN IP adress range, je VPN IP address range.

Als je dit aanpast verwijder dan je containers + nonpersistent volumes + bijbehorende netwerken voordat je weer compose up doet.

Additioneel: die CAP_ADD dingen wil je zoveel mogelijk vermijden en zo min mogelijk van hebben..

[rvk]

Jazco2nd schreef op donderdag 30 maart 2023 @ 21:23:
@WheeleE @rvk
Zie deze regel die ik bij jullie beide mis:
https://github.com/zilexa...r/docker-compose.yml#L423

Refereert naar:
https://github.com/zilexa...42204584e/docker/.env#L42
Ofwel je LAN IP adress range, je VPN IP address range.

Ik denk dat die local_network alleen in de "wireguard with pia" docker image werkt. Niet in de standaard van wireguard zelf. Voor pia heb je overigens een abonnement nodig (dacht ik te zien).

In de standaard wireguard is die homenetwork in de postup nodig om een route aan te maken van je eigen interne netwerk naar docker (voor de webui). In die pia versie wordt dat dus waarschijnlijk met een environment variabele gedaan maar ik denk niet dat dat standaard bij wireguard docker ook zo werkt.

Je kunt natuurlijk wel de postup aanpassen in wg0.conf dat die wel gebruik maakt van die environment variabele. Maar ik heb hem in de postup hardcoded erin gezet. Ik zal later eens in de pia versie kijken wat daar in de wg0.conf staat.

Jazco2nd schreef op donderdag 30 maart 2023 @ 21:23:
Additioneel: die CAP_ADD dingen wil je zoveel mogelijk vermijden en zo min mogelijk van hebben..

Dat moet ik even onderzoeken. Ik dacht dat wireguard hem nodig had. Maar misschien is dat alleen voor binnenkomende vpn verbindingen.

Hier staat overigens de volledige uitleg voor de wireguard image.
https://github.com/linuxserver/docker-wireguard

When routing via Wireguard from another container using the service option in docker, you might lose access to the containers webUI locally. To avoid this, exclude the docker subnet from being routed via Wireguard by modifying your wg0.conf like so (modifying the subnets as you require):

code:

[Interface]
PrivateKey = <private key>
Address = 9.8.7.6/32
DNS = 8.8.8.8
PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE;ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE;iptables -I OUTPUT -d $HOMENET -j ACCEPT;iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT;  iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route del $HOMENET3 via $DROUTE;ip route del $HOMENET2 via $DROUTE; ip route del $HOMENET via $DROUTE; iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT; iptables -D OUTPUT -d $HOMENET -j ACCEPT; iptables -D OUTPUT -d $HOMENET2 -j ACCEPT; iptables -D OUTPUT -d $HOMENET3 -j ACCEPT

[Voor 30% gewijzigd door rvk op 30-03-2023 21:46]

[Jazco2nd]

@rvk excuus, ik las daar helemaal overheen!
Ik gebruik inderdaad PIA. Voor torrents was dat 2 of 3 jaar geleden de enige service die én port forwarding ondersteunde (vrij essentieel voor een torrent client) én een image beschikbaar was die automatisch snelste server zoekt + portforwarding (incl wijzigingen) automatisch configureert en update in je QBittorrent cliënt.

Vandaar dat deze image vrij populair werd.

Zo heb je helemaal geen ommekijk meer hiernaar.

[WheeleE]

Ik heb inmiddels iets voortgang: de wireguard-vpn op de Raspberry lekt geen onbedoelde ip-adressen, hoezee!
Via een workaround een torrent aangeslingerd en alleen het adres van de vpnserver is zichtbaar.

Vanavond duik ik in het homenet-avontuur.

[WheeleE]

rvk schreef op woensdag 29 maart 2023 @ 18:07:
[...]

code:

[Interface]
Address = 10.14.0.2/16
PrivateKey = yourprivatekeyforwireguard
PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE;ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE;iptables -I OUTPUT -d $HOMENET -j ACCEPT;iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT;  iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
DNS = x.x.x.x, y.y.y.y

[Peer]
PublicKey = yourpublickeyforwireguard
AllowedIPs = 0.0.0.0/0
Endpoint = z.z.z.z:51820

[..]

Helaas. Ik heb in mijn wg0.conf de PostUp en PreDownregels vervangen door deze bovenstaande ^^ maar zonder succes. (Mijn thuisnetwerk draait geheel in 192.169.x.x 192.168.x.x)
Er wordt wel netjes een vpnverbinding opgezet maar ik kan nog niet bij de webinterface van de app-container die door de vpn gaat.

//edit: verduidelijking:
de wg0.conf van m'n vpnprovider zag er origineel zo uit:

code:

[Interface]
PrivateKey = <private key>
Address = <ip4 adres>,<ip6 adres>
DNS = <dns van vpn provider>
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = <public key>
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = <endpoint ip adres>:<poortnummer>

Het format van de postup/predown-regels was dus wel anders dan wat er nu in staat. Kan dat uitmaken?

[Voor 16% gewijzigd door WheeleE op 01-04-2023 19:58. Reden: verduidelijking wg0.conf]

[rvk]

WheeleE schreef op zaterdag 1 april 2023 @ 17:22:
[...]
(Mijn thuisnetwerk draait geheel in 192.169.x.x)

Bedoel je echt 192.169.x.x?
Want normaal is het 192.168.x.x.

Daar zit dan jouw probleem en dan moet je dus ook 192.169.0.0/16 gebruiken (ipv 192.168.0.0/16).

[WheeleE]

rvk schreef op zaterdag 1 april 2023 @ 19:48:
[...]

Bedoel je echt 192.169.x.x?
Want normaal is het 192.168.x.x.

Daar zit dan jouw probleem en dan moet je dus ook 192.169.0.0/16 gebruiken (ipv 192.168.0.0/16).

Dat was/is een tikfout, alles zit in 192.168.x.x
Ik had ook per ongeluk de gewijzigde wg0.conf geplakt in plaats van de originele wg0.conf van m'n provider. Bij deze ook aangepast.

[Voor 16% gewijzigd door WheeleE op 01-04-2023 19:59]

[rvk]

WheeleE schreef op zaterdag 1 april 2023 @ 19:57:
[...]
Dat was/is een tikfout, alles zit in 192.168.x.x

Wel handig dat er geen geen tikfouten zijn

Wat het interne netwerk van de docker stack?
Ergens in de 172.14 tot 172.24 o.i.d.

De default geeft geen toegang van buitenaf.
Deze aanpassing staat op de github pagina.

Ik zal straks ook ff kijken wat de route is in de von docker.

[ThinkPad]

Ik heb Docker draaien in Ubuntu Server. Toen ik er nog wat minder kennis van had ooit een tutorial gevolgd om Docker te installeren. Blijkbaar is dat toen via 'snap' gegaan. Is geen aanrader, ik heb regelmatig als ik bezig ben met wat containers aanmaken/verwijderen etc. de melding too many open files. Ook via Portainer komt dat wel eens terug.

Binnenkort maar een nieuwe VM bouwen om Docker in te draaien, maar dit keer lekker via de native methode. Het opbouwen van de VM is een mooie oefening om met Ansible te doen, onlangs training in gehad via het werk.

---

Verder lekker bezig: een self-signed wildcard certificaat gegenereerd zodat ik in het thuisnetwerk alles op HTTPS kan zetten zonder vervelende browserwaarschuwingen te hebben. Met NginxProxyManager de Docker containers voor zover mogelijk achter de reverse proxy gezet. Ideaal dat ik nu gewoon 'grafana.home.arpa' kan typen en dan bij Grafana uitkom, netjes met een HTTPS-slotje erop

Wel stom dat Portainer geen ondersteuning heeft voor de 'expose' functionaliteit van containers. Moet ik toch weer terugvallen op de cli in sommige gevallen Loopt al een issue over zag ik.

[Voor 36% gewijzigd door ThinkPad op 01-04-2023 20:34]

[rvk]

Even een klein weetje...
Niet alle docker containers hebben bash in zich.
Maar soms kom je er toch in met sh.
Dus als dit niet werkt

code:

docker exec -it container_name bash

kun je ook dit proberen

code:

docker exec -it container_name sh

Dan het probleem om de qbittorrent te benaderen:
Hier wat relevante commando's om de IPs en IPTABLES te bekijken:

op de host moet de IPTABLES dus doorgelust zijn naar de interne IP van de qbittorrent.
In de vpn docker moet dit ook in de IPTABLES toegestaan zijn voor je home network want anders werkt het niet. (mijn host space01 heeft ip 192.168.2.21 en qbittorrent 172.18.0.4)

code:

# IPTABLES heeft poort 8083 op de host doorgelust naar 172.18.0.4:8083
pi@space01:~ $ sudo iptables -L -n
Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.4           tcp dpt:8083

# start bash op de vpn docker
pi@space01:~ $ docker exec -it vpn bash

# bekijk het IP van vpn docker
root@e4b4ae10c171:/# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.4  netmask 255.255.0.0  broadcast 172.18.255.255
  
# IPTABLES dat 192.168.0.0/16 geaccepteerd word (al het andere wordt REJECTed)
root@e4b4ae10c171:/# iptables -L -n
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            192.168.0.0/16
ACCEPT     all  --  0.0.0.0/0            10.0.0.0/8
ACCEPT     all  --  0.0.0.0/0            172.16.0.0/12
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            mark match ! 0xca6c ADDRTYPE match dst-type !LOCAL reject-with icmp-port-unreachable

# de ROUTE
root@e4b4ae10c171:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.18.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        172.18.0.1      255.0.0.0       UG    0      0        0 eth0
10.14.0.0       0.0.0.0         255.255.0.0     U     0      0        0 wg0
172.16.0.0      172.18.0.1      255.240.0.0     UG    0      0        0 eth0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
192.168.0.0     172.18.0.1      255.255.0.0     UG    0      0        0 eth0

# EXIT
root@e4b4ae10c171:/# exit

# start bash op de qbittorrent docker
pi@space01:~/docker/prive $ docker exec -it qbittorrent sh

# bekijk het IP van qbittorrent docker
root@e4b4ae10c171:/# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 02:42:AC:12:00:04
          inet addr:172.18.0.4  Bcast:172.18.255.255  Mask:255.255.0.0
  
# EXIT
root@e4b4ae10c171:/# exit

[ravedek]

ThinkPad schreef op zaterdag 1 april 2023 @ 20:30:
Ik heb Docker draaien in Ubuntu Server. Toen ik er nog wat minder kennis van had ooit een tutorial gevolgd om Docker te installeren. Blijkbaar is dat toen via 'snap' gegaan. Is geen aanrader, ik heb regelmatig als ik bezig ben met wat containers aanmaken/verwijderen etc. de melding too many open files. Ook via Portainer komt dat wel eens terug.

Binnenkort maar een nieuwe VM bouwen om Docker in te draaien, maar dit keer lekker via de native methode. Het opbouwen van de VM is een mooie oefening om met Ansible te doen, onlangs training in gehad via het werk.

Als tijdelijke workaround kan je met ulimit het max. aantal open files verhogen.
Bij mij werd het probleem veroorzaakt door de InfluxDB container en bulk import van data. Dat heb ik opgelost door de container een extra parameter mee te geven:

code:

--ulimit nofile=32768:32768

Linkje.

Zelf ben ik bezig om over te stappen van Ubuntu met Docker (ook snap) naar NixOS met Podman, ook erg interessant

[RobertMe]

rvk schreef op zaterdag 1 april 2023 @ 20:33:
Even een klein weetje...
Niet alle docker containers hebben bash in zich.
Maar soms kom je er toch in met sh.
Dus als dit niet werkt

code:

docker exec -it container_name bash

kun je ook dit proberen

code:

docker exec -it container_name sh

Dat is niet zo gek, omdat niet alle Linux distributies met bash geleverd worden. Dan zit het waarschijnlijk dus ook niet in het Docker image (omdat het daar eigenlijk sowieso niks in te zoeken heeft, los van de basis distro). Maar de images waar het in ontbreekt zijn waarschijnlijk gebaseerd op Alpine Linux. Die gebruikt Busybox als basis (en musl libc i.p.v. GNU glibc), en daarin zit ash. sh is echt een antieke zeer basale shell. ash is een stuk vergelijkbaarder met bash.

Toevoeging:
Daarnaast zijn er ook images gebaseerd op ik meen het scratch image. Dat is gewoon letterlijk leeg. Traefik gebruikte die bij v1. Dat was gewoon een image met daarin de traefik executable en klaar. Geen libraries wat die nodig had, geen shell, niks.

[Voor 13% gewijzigd door RobertMe op 01-04-2023 21:16]

[ThinkPad]

ravedek schreef op zaterdag 1 april 2023 @ 21:04:
[...]


Als tijdelijke workaround kan je met ulimit het max. aantal open files verhogen.
Bij mij werd het probleem veroorzaakt door de InfluxDB container en bulk import van data. Dat heb ik opgelost door de container een extra parameter mee te geven:

code:

--ulimit nofile=32768:32768

Linkje.

Zelf ben ik bezig om over te stappen van Ubuntu met Docker (ook snap) naar NixOS met Podman, ook erg interessant

Ja in de hoek van ulimit ophogen zat ik ook al inderdaad. Ik heb wel InfluxDB draaien, maar was niet met die container bezig, dus de parameter aan de Influx container doorgeven weet ik niet of dat gaat helpen. Hoe kwam jij erachter welke container de schuldige was?

[ravedek]

ThinkPad schreef op zaterdag 1 april 2023 @ 22:42:
[...]

Ja in de hoek van ulimit ophogen zat ik ook al inderdaad. Ik heb wel InfluxDB draaien, maar was niet met die container bezig, dus de parameter aan de Influx container doorgeven weet ik niet of dat gaat helpen. Hoe kwam jij erachter welke container de schuldige was?

Waarschijnlijk zag ik dit destijds terug in de logs (docker logs influxdb). Maar ik had dan ook een stevig ETL proces lopen die dit veroorzaakte

[Arunia]

Ik ben al een tijd met firefly aan het stoeien. Maar ik kom nu iets geks tegen.
Als ik kijk naar mijn docker container ip-adressen, dan zijn dit andere nummers dan bijvoorbeeld firefly terug geeft met de data importer module.
Als ik ping op een ip-adres van de firefly container, dan komt er niets uit. Ping ik op dat andere ip-adres welke de importer geeft, dan krijg ik wel reactie. Voer ik deze als url in met bijbehorende poort, dan kom ik ook gewoon op die pagina.
Ik kom dat ip-adres ook totaal nergens tegen en snap er dus geen hout meer van hoe dat zit.

Iemand enig idee? Ik werk met Windows en gebruik hierin Linux containers.

[rvk]

Arunia schreef op maandag 3 april 2023 @ 11:44:
Ik kom dat ip-adres ook totaal nergens tegen en snap er dus geen hout meer van hoe dat zit.

Het hangt er helemaal vanaf hoe je je docker container netwerken in elkaar gezet hebt.

Normaal krijgt een container een 172.x.x.x adres (afhankelijk van je gekozen netwerk).
172.16.0.0/12 = 172.16.0.1 tot 172.31.255.254

Dus het is dan misschien handiger om wat echte snippets te geven van je docker-compose.yml.

(Uiteraard kun je ook met network_mode: host werken zodat de ip van je Windows box geshared wordt.)

[Arunia]

@rvk Qua wat je uitlegt snap ik wel. Bij mij komt het automatisch uit op /16. Heb overigens zelf niets ingesteld aan hoe dit ingeregeld is. Ofwel, docker installeren en via compose verschillende applicaties opzetten. De rest gaat automagisch zo lijkt het.
Maar begrijp niet helemaal waarom er een ip-adres ergens vandaan getoverd wordt welke niet te vinden is in docker zelf. Of ik kijk dan ergens overheen, wat natuurlijk prima kan.
Geen enkele docker-compose bevat dit ip-adres, ook geen enkele container bevat dat ip-adres of wat er uberhaupt op lijkt. Dat maakt het zo apart.

[rvk]

Arunia schreef op maandag 3 april 2023 @ 12:23:
Maar begrijp niet helemaal waarom er een ip-adres ergens vandaan getoverd wordt welke niet te vinden is in docker zelf. Of ik kijk dan ergens overheen, wat natuurlijk prima kan.

Over welk IP adres heb je het dan?
Zonder configuratie wordt er een standaard docker (bridged) netwerk gebruikt.

Arunia schreef op maandag 3 april 2023 @ 11:44:
Als ik ping op een ip-adres van de firefly container, dan komt er niets uit. Ping ik op dat andere ip-adres welke de importer geeft, dan krijg ik wel reactie. Voer ik deze als url in met bijbehorende poort, dan kom ik ook gewoon op die pagina.

Als je echt het ip adres van die container gebruikt dan zou het wel moeten werken (als je een standaard installatie gebruikt).

Met docker inspect container_name kun je wel het een en ander uitzoeken.

Maar zonder meer informatie kunnen wij je ook niet zoveel meer vertellen.

[Voor 3% gewijzigd door rvk op 03-04-2023 12:49]

[Arunia]

rvk schreef op maandag 3 april 2023 @ 12:47:
[...]

Over welk IP adres heb je het dan?


[...]

Als je echt het ip adres van die container gebruikt dan zou het wel moeten werken (als je een standaard installatie gebruikt).

Met docker inspect container_name kun je wel het een en ander uitzoeken.

Maar zonder meer informatie kunnen wij je ook niet zoveel meer vertellen.

Het gaat om het interne ip-adres van de container. Via portainer zou dat 172.21.0.1 moeten zijn. Echter als ik deze ping, komt er niets uit.
Kijk ik bij data importer voor Firefly III, dan zegt hij dat hij wel verbinding maakt met 172.20.0.1, maar dat dit actief geblokt wordt.
Als ik dit adres ping, dan krijg ik contact en als ik deze in de browser mik met het poortnummer erbij, dan kom ik op Firefly III uit.

Dat laatste ip-adres kom ik alleen nergens tegen.

docker inspect container_name (uiteraard de code/naam van die container). Komt alleen het ip-adres uit wat voor mij logisch is (172.21.x.x).

Ik probeer uit te vinden welke informatie handig is om te delen, omdat de inspect best groot is.
De docker-compose en de bijbehorende .env files zijn ook best groot qua tekst wat daar in staat.

En toen werkte het na weken ineens wel. Gewoon alle voor configuratie weggelaten en kreeg daarna ineens vragen te beantwoorden. Dit gedaan, 1 500 error en daarna werkte het ineens wel. >_<
Schiet mij maar lek.

[Voor 12% gewijzigd door Arunia op 03-04-2023 13:22]

[rvk]

Arunia schreef op maandag 3 april 2023 @ 12:54:
[...]
En toen werkte het na weken ineens wel. Gewoon alle voor configuratie weggelaten en kreeg daarna ineens vragen te beantwoorden. Dit gedaan, 1 500 error en daarna werkte het ineens wel. >_<
Schiet mij maar lek.

Op Linux zou ik verwachten dat het een restant in iptables het kunnen zijn (van na een crash). Van blijven oude verwijzingen staan naar oude ip adressen. Maar ik weet niet hoe dat in Windows zit met doorlussen van ip.

Maar platgooien (met docker compose down) en weer opnieuw opbouwen (docker compose up -d) werkt ook vaak wonderen 😁 (e.v. met een cleanup van iptables ertussen. (Voorstaand natuurlijk voor Linux, geen idee voor Windows.)

[Arunia]

rvk schreef op maandag 3 april 2023 @ 14:31:
[...]

Op Linux zou ik verwachten dat het een restant in iptables het kunnen zijn (van na een crash). Van blijven oude verwijzingen staan naar oude ip adressen. Maar ik weet niet hoe dat in Windows zit met doorlussen van ip.

Maar platgooien (met docker compose down) en weer opnieuw opbouwen (docker compose up -d) werkt ook vaak wonderen 😁 (e.v. met een cleanup van iptables ertussen. (Voorstaand natuurlijk voor Linux, geen idee voor Windows.)

Wat betreft ip-tables ook geen idee binnen Windows.
Uiteindelijk komen we er wel. Zijn nog wel meer dingen die nog niet meewerken met firefly en data importer, maar dat is voor het andere topic.
Staan wel nog wat Docker dingen die ik wil doen, maar dat komt ergens wel een keer als ik tijd en zin heb.

[WheeleE]

Na meerdere keren tevergeefs proberen de boel aan de praat gekregen ben ik vanaf nul begonnen en heb nu de wireguard en qtorrent containers aan de praat, via de vpn en zonder lekken.
Dank voor je hulp en geduld @rvk !

[Raven]

Jazco2nd schreef op donderdag 30 maart 2023 @ 21:47:
@rvk excuus, ik las daar helemaal overheen!
Ik gebruik inderdaad PIA. Voor torrents was dat 2 of 3 jaar geleden de enige service die én port forwarding ondersteunde (vrij essentieel voor een torrent client) én een image beschikbaar was die automatisch snelste server zoekt + portforwarding (incl wijzigingen) automatisch configureert en update in je QBittorrent cliënt.

Vandaar dat deze image vrij populair werd.

Zo heb je helemaal geen ommekijk meer hiernaar.

Deze? Overigens is

Private Internet Access supports port forwarding required for torrenting. Very few support this, without it your speeds will be slow.

niet helemaal waar. Ik heb pfSense als PIA-client en proxy in een VM waar uTorrent (waar helaas geen nog ondersteunde Docker-image voor bestaat ) verbinding mee maakt. Ondanks dat ik helemaal niets met portforwarding heb gedaan haal ik toch nog zo'n 5MBps, soms meer.