Recept: AdGuard Home of Pi-hole in een container

Het doel: AdGuard Home of Pi-hole draait op de router zelf, je clients krijgen die als DNS-server, en je hoeft er geen apparaat bij te zetten. Lees eerst de laatste paragraaf; die zegt wanneer je dit beter niet doet.

Wat je nodig hebt

• Een apparaat met ARM64 of x86. Het onderdeel Containers verschijnt alleen als de architectuur van je model dat toelaat; op een ander apparaat zegt de tool dat containers ARM64 of x86 vereisen en houdt het daar op.
• Externe opslag: een USB-stick, SSD of NVMe. De interne flash van een RouterBOARD is klein en slijt van schrijven.
• Het pakket container, dat je zelf bij MikroTik downloadt en op de router installeert.
• Fysieke toegang tot het apparaat, binnen vijf minuten na het plakken. Dit is het enige onderdeel van de configurator waarvoor je ernaast moet staan.

Stap 1: kijk of je apparaat dit echt kan

De architectuur is de enige controle die de tool doet, en die is niet genoeg. Waar het in de praktijk op aankomt is geheugen:

Dat gigabyte deel je met RouterOS zelf, met je verbindingstabel en met alles wat er verder draait. AdGuard Home gebruikt in rust ongeveer 100 tot 150 MB, en meer naarmate je meer lijsten laadt en meer queries logt. Op 1 GB past dat naast een gewone configuratie; onder een halve gigabyte begin je er niet aan.

Voor opslag geldt hetzelfde. De image, de lagen, de tijdelijke bestanden tijdens het ophalen en het querylog moeten ergens staan: reken op een paar honderd megabyte plus een log dat groeit, op een stick of SSD en niet op de interne flash.

Stap 2: de instellingen van het onderdeel

1. Opslag: de naam van de schijf, standaard disk1. Kijk met /disk print hoe die van jou heet; bij een USB-stick is het vaak usb1-part1. Staat hier de verkeerde naam, dan schrijft alles naar een pad dat niet bestaat.
2. Containernetwerk: het adres van de router in dat netwerk, standaard 172.17.0.1/24. Kies iets dat nergens anders in je netwerk voorkomt.
3. Registry URL: https://registry-1.docker.io, tenzij je een eigen mirror hebt.

Daaronder de container zelf. Voor AdGuard Home:

• Naam: adguard. Die naam komt terug als opmerking, als naam van de veth-interface en als map op je schijf.
• Image: adguard/adguardhome:latest. Zet er liever een versienummer achter dan latest, dan doet een herstart morgen hetzelfde als vandaag.
• IP in containernetwerk: 172.17.0.2, in hetzelfde subnet als het adres hierboven.
• Omgevingsvariabelen: bijvoorbeeld TZ=Europe/Amsterdam, één regel per variabele.
• Mounts: work:/opt/adguardhome/work en conf:/opt/adguardhome/conf, elk op een eigen regel. De tool maakt daar mappen van op je schijf, zodat je instellingen een herstart overleven.
• Poorten doorzetten vanaf het LAN: tcp:3000 voor de eerste installatie, daarna tcp:80 voor de webinterface.

De standaardrij in de tool is Pi-hole, met WEBPASSWORD=changeme als voorbeeld. Omgevingsvariabelen komen letterlijk in het script te staan. Zet je daar een wachtwoord in, dan staat dat wachtwoord in het script en in alles wat je daarvan deelt.

Stap 3: wat het script doet

• Als eerste regel /system device-mode update container=yes. Die vraagt om een fysieke bevestiging binnen vijf minuten: resetknop indrukken, of stroom eraf en erop. Sla je dat over, dan gebeurt er niets. In de praktijk plak je dus in twee rondes: script plakken, bevestigen, daarna het containerdeel opnieuw draaien. Het script zegt dat in een opmerking.
• Een bridge containers, het routeradres daarop, en een masquerade-regel zodat de container naar buiten kan.
• /container config met je registry en de mappen voor tijdelijke bestanden en lagen op je schijf.
• Een /interface veth met de naam veth-adguard, met jouw adres en de router als gateway, toegevoegd als poort aan die bridge. De veth is de kabel tussen RouterOS en de container: de container ziet hem als netwerkkaart, de router als interface in de bridge.
• Een dst-nat-regel per doorgezette poort, met in-interface-list=LAN en dst-address-type=local. Dat betekent dat je de container bereikt op het eigen adres van de router, op die poort. AdGuard op tcp:80 staat dus op het LAN-adres van je router, niet op 172.17.0.2.

Het script start je container niet. De image moet eerst opgehaald worden, wat tijd kost en kan mislukken. De laatste regel van het onderdeel laat zien hoe je dat zelf doet:

/container start [find comment="adguard"]
/log print where topics~"container"

Stap 4: DHCP naar de container wijzen

Er zijn twee manieren, en ze hebben elk een prijs.

De router laten doorsturen (aanbevolen). Zet in DNS de Upstream DNS op Aangepast en vul 172.17.0.2 in. Laat Router als DNS-server voor het LAN aan staan. Je clients blijven de router gebruiken, de router vraagt het aan de container. Je hoeft poort 53 dan niet door te zetten, en het werkt vanzelf in elke VLAN, ook een geïsoleerde. De prijs: AdGuard ziet alleen de router als client, dus per-apparaat statistieken en regels per apparaat vervallen.

Clients rechtstreeks naar de container sturen. Zet in LAN & DHCP, of per VLAN in de VLAN-tabel, het veld DNS-server voor DHCP-clients op Aangepast en vul daar het adres in. Nu ziet AdGuard elk apparaat apart. De prijs: clients in een geïsoleerde VLAN komen niet bij het containernetwerk, dus daar moet je in de matrix een richting voor openzetten, en als de container stilstaat heeft niemand meer DNS.

In beide gevallen helpt LAN-clients dwingen de router te gebruiken in het DNS-onderdeel tegen apparaten met een ingebakken 8.8.8.8. Tegen DNS over HTTPS in een browser helpt het niet.

Testen

1. /system/device-mode/print: staat container: yes?
2. /container print: draait hij, en wat is de status?
3. /log print where topics~"container" bij twijfel. Hier zie je ook waarom een image niet binnenkomt.
4. Open de webinterface op het LAN-adres van je router, op de poort die je hebt doorgezet.
5. Doe vanaf een client een opzoekvraag naar een domein dat geblokkeerd hoort te zijn, en kijk of hij in het querylog van AdGuard verschijnt.
6. Herstart de router en kijk of de container vanzelf terugkomt. Dat hoort, want start-on-boot=yes staat aan.
7. /system resource print als het druk is: hoeveel geheugen is er over?

Wat de tool hier niet heeft

• Geen veld voor een geheugen- of CPU-limiet per container. Een container die geheugen opeet, doet dat ten koste van het routeren.
• Geen health check en geen herstartbeleid. Valt de container om, dan blijft hij liggen tot de volgende start.
• Geen automatische updates van images. Een nieuwe versie haal je zelf op.
• Geen tweede DNS-server als achtervang. Vul je er zelf een in naast de container, dan gaan clients daar ook naartoe en is je filtering een suggestie geworden.

Het eerlijke advies

Een container op de router is aantrekkelijk voor één klein ding op een apparaat met ruimte over. Voor DNS is dat meestal net niet het geval, en wel hierom: DNS is de dienst waar alles op wacht. Als je router herstart voor een update, gaat je DNS mee. Als je containerbestand corrupt raakt op een USB-stick die al drie jaar in de meterkast zit, staat het hele huis stil. En een RouterOS-upgrade kan device-mode opnieuw laten bevestigen, terwijl jij niet in de buurt bent.

Een los kastje, een Raspberry Pi of een kleine mini-pc, kost je een stopcontact en lost dat allemaal op: de router blijft een router, updates en herstarts zijn onafhankelijk, en je kunt er een tweede naast zetten. Doe het op de router als het apparaat toch al overgedimensioneerd is en de dienst niet kritiek is, niet om dat kastje uit te sparen.

Verder lezen: Containers op RouterOS, DNS en Je apparaat kiezen.