MikroTik Dojo · prova di esistenza (OpenTimestamps)
Versione: 2
Registrato il: 2026-11-13T12:38:37+00:00
Verifica: ots verify mikrotikdojo-2661-v2.txt.ots (o su https://opentimestamps.org)

Indirizzo: https://mikrotikdojo.com/dojo/adguard-home-container-mikrotik/
ID: 2661 (post)
Titolo: AdGuard Home dentro il MikroTik: un DNS che blocca pubblicità, in un container
Pubblicato: 2026-11-12T06:30:00Z

Immagini (sha256 del file):
a1f8c4ee9258e28fceeb7536173a0b651180cb323bececf83157a160638ab919  https://mikrotikdojo.com/media/2026/10/2661.jpg

--- Contenuto (HTML originale, in italiano) ---
<p class="lead">Nel <a href="https://mikrotikdojo.com/dojo/container-mikrotik-cosa-vedono-del-kernel/">primo articolo sui container</a> abbiamo guardato <em>dentro</em> un container per capire cosa condivide con il router. Ora lo usiamo per qualcosa di utile: far girare <strong>AdGuard Home</strong>, un server DNS che blocca pubblicità e tracker per tutta la rete, <strong>dentro il router stesso</strong>. Niente Raspberry Pi acceso in un angolo: il filtro DNS vive nel router, in un container isolato. Lo montiamo in laboratorio, lo configuriamo, lo mettiamo alla prova (risolve, blocca) e lo chiudiamo come si deve.</p>

<h2>Passo 1: cos'è AdGuard Home, e perché in un container</h2>
<p><strong>AdGuard Home</strong> è un server DNS che fa da filtro per tutta la rete: ogni dispositivo gli chiede "a che indirizzo sta questo nome?", e lui risponde — tranne quando il nome è di un circuito pubblicitario o di un tracker, nel qual caso lo <em>blocca</em>. Un solo punto di controllo per telefoni, TV, computer, senza installare niente sui singoli dispositivi. In più ha una web UI con statistiche e log delle richieste.</p>
<p>Perché dentro il router? Perché il router è sempre acceso ed è già il cuore della rete: è il posto naturale per un DNS. E con i container non serve un apparato in più. Ricordando il <a href="https://mikrotikdojo.com/dojo/container-mikrotik-cosa-vedono-del-kernel/">primo articolo</a>: un container <strong>non è una macchina virtuale</strong>, condivide il kernel del router, ma porta con sé il suo userland (qui l'immagine di AdGuard Home). AdGuard gira nel suo spazio, con le sue librerie, e parla con la rete tramite una veth.</p>
<p class="kb">Prerequisito concettuale: <a href="https://mikrotikdojo.com/knowledge-base/device-mode-routeros-come-funziona/">Device-mode su RouterOS</a> — i container vanno prima sbloccati con <code>device-mode container=yes</code> e una conferma fisica.</p>

<h2>Passo 2: il collegamento di rete</h2>
<p>Come nel primo articolo, diamo al container un'interfaccia <strong>veth</strong> su un bridge dedicato, con il NAT verso l'esterno (ad AdGuard serve Internet per interrogare i DNS upstream):</p>
<pre><code>/interface veth add name=veth-adg address=172.17.0.4/24 gateway=172.17.0.1
/interface bridge add name=ctbr
/ip address add address=172.17.0.1/24 interface=ctbr
/interface bridge port add bridge=ctbr interface=veth-adg
/ip firewall nat add chain=srcnat src-address=172.17.0.0/24 action=masquerade</code></pre>
<p>Il container avrà l'indirizzo <code>172.17.0.4</code>; il router è <code>172.17.0.1</code> sullo stesso segmento.</p>

<h2>Passo 3: lo spazio dove AdGuard salva i suoi dati</h2>
<p>Un container, se lo cancelli e lo ricrei, riparte da zero. Ma AdGuard deve <strong>ricordare</strong> la sua configurazione e le statistiche. Per questo gli diamo due cartelle persistenti del router, <em>montate</em> dentro il container nei punti dove AdGuard si aspetta i suoi file:</p>
<pre><code>/container mounts add list=adg src=adg/conf dst=/opt/adguardhome/conf
/container mounts add list=adg src=adg/work dst=/opt/adguardhome/work</code></pre>
<p>Due cose da notare. <code>src</code> è una cartella sul router (percorso relativo, il router la crea da solo); <code>dst</code> è dove compare dentro il container. E le abbiamo messe nella stessa <strong>lista</strong> (<code>list=adg</code>), così il container le richiama tutte con un nome solo.</p>
<p>Qui torna il tema del <a href="https://mikrotikdojo.com/dojo/container-mikrotik-cosa-vedono-del-kernel/">primo articolo</a>: <strong>ogni mount è un accesso che concedi</strong>. Ma c'è una differenza importante. mikroscope montava <code>/proc</code> e <code>/sys</code> del router per spiarne lo stato; qui montiamo solo <strong>cartelle dati di AdGuard</strong> (<code>/opt/adguardhome/...</code>): non diamo al container nessuna finestra sul router. È il modo sano di usare i mount — solo ciò che serve al servizio, niente del sistema.</p>

<h2>Passo 4: creare e avviare il container</h2>
<p>Diciamo da dove scaricare le immagini e creiamo il container, agganciando la lista di mount. Nota: <strong>niente <code>privileged</code></strong>. AdGuard è un normale servizio di rete, non ha bisogno dei poteri di root sul router — e quindi non glieli diamo.</p>
<pre><code>/container config set registry-url=https://registry-1.docker.io tmpdir=tmp
/container add remote-image=adguard/adguardhome:latest interface=veth-adg \
    root-dir=ct/adguard mountlists=adg logging=yes name=adguard
/container start adguard</code></pre>
<p>Dopo lo scaricamento, il container gira. In laboratorio l'ingombro era contenuto:</p>
<pre><code>/container print
#   NAME     ROOT-DIR     INTERFACE   MEMORY-CURRENT  CONTAINER-SIZE
0 R adguard  /ct/adguard  veth-adg    56.1MiB         43.5MiB</code></pre>
<p>Circa <strong>56 MiB di RAM</strong> e <strong>43 MiB su disco</strong> per un DNS che serve tutta la casa. Controlla sempre RAM e spazio liberi del router prima: su un apparato piccolo è un conto da fare.</p>

<h2>Passo 5: la configurazione iniziale</h2>
<p>Al primo avvio AdGuard apre una <strong>procedura guidata sulla porta 3000</strong>. Dal browser, da un PC della LAN, vai su <code>http://172.17.0.4:3000</code> (se il container non è raggiungibile direttamente dalla tua LAN, vedi il Passo 6 per esporlo). La procedura chiede:</p>
<ul>
<li>su quale porta mettere la <strong>web UI</strong> (tipicamente la <code>80</code>);</li>
<li>su quale porta mettere il <strong>server DNS</strong> (la <code>53</code>, quella standard);</li>
<li><strong>utente e password</strong> di amministratore.</li>
</ul>
<p><strong>⚠️ Attenzione: scegli una password robusta.</strong> Questa web UI comanda il DNS di tutta la rete; con le credenziali in mano si decide cosa risolvono tutti.</p>
<p>Finita la procedura, AdGuard si riavvia sulle porte scelte: la <code>3000</code> si chiude, la web UI passa sulla <code>80</code> (ora protetta: senza login risponde <code>401</code>) e il <strong>DNS sulla 53 è attivo</strong>. Da qui in poi lo gestisci da <code>http://172.17.0.4/</code>.</p>

<h2>Passo 6: usarlo — e vederlo bloccare</h2>
<p>Perché AdGuard filtri davvero, i dispositivi devono usarlo come DNS. Due modi:</p>
<ul>
<li><strong>Tutta la rete:</strong> nel server DHCP del router, annuncia come DNS l'indirizzo del container. Così ogni dispositivo che prende l'indirizzo dal router usa AdGuard senza configurazioni manuali.</li>
<li><strong>Il router stesso:</strong> <code>/ip dns set servers=172.17.0.4</code> per far passare da AdGuard anche le richieste del router.</li>
</ul>
<p>Proviamo in laboratorio. Con il DNS puntato al container, un nome normale si risolve:</p>
<pre><code>/ip dns set servers=172.17.0.4
:put [:resolve "example.com"]
104.20.23.154</code></pre>
<p>Ora aggiungiamo una regola di blocco (dalla web UI, oppure via API) per un dominio pubblicitario e riproviamo:</p>
<pre><code>:put [:resolve "doubleclick.net"]
0.0.0.0</code></pre>
<p>AdGuard ha risposto <code>0.0.0.0</code>: il nome è <strong>bloccato</strong>, il browser non raggiungerà quel server. Nella web UI, alla voce statistiche, le due richieste compaiono subito — una passata, una bloccata:</p>
<pre><code>num_dns_queries:       2
num_blocked_filtering: 1</code></pre>
<p>E le liste di blocco, chi le mette? <strong>Non si compilano a mano.</strong> AdGuard Home arriva con un <strong>catalogo di liste pronte</strong>: la <em>AdGuard DNS filter</em> è <strong>già attiva</strong> appena finito il setup (in laboratorio, oltre 185.000 regole), e altre liste note (AdAway, OISD, le hagezi…) sono lì <strong>da accendere con un clic</strong> nella sezione <em>Filtri → Liste di blocco DNS</em>. Sono liste <strong>online</strong>: AdGuard le scarica da un URL e le <strong>aggiorna da sola</strong> a intervalli regolari (di default una volta al giorno), così restano al passo senza che tu faccia niente. Puoi aggiungerne altre incollando il loro URL, scrivere regole tue a mano, e nel log vedere chi ha chiesto cosa. Ma il meccanismo di base è quello che hai appena visto.</p>

<h2>In un clic: la versione «app» (il menu Apps di RouterOS)</h2>
<p>Tutto quello che abbiamo fatto a mano — immagine, veth, bridge, NAT, mount, porte — nelle versioni recenti di RouterOS si può chiedere in <strong>un comando solo</strong>. Si chiama <strong>Apps</strong> (<code>/app</code>): un livello che sta <em>sopra</em> i container e li orchestra a partire da un <strong>catalogo</strong>. Un'«app» è una <strong>ricetta</strong> in stile Docker-Compose (un file YAML) che descrive immagine, porte e volumi; RouterOS la legge e costruisce il container, la rete e persino un <strong>indirizzo HTTPS per la web UI</strong>, da solo.</p>
<p>Il senso didattico è proprio questo: <em>l'app fa sotto il cofano esattamente i Passi 2-4 che hai appena visto a mano</em>. Averli fatti a mano una volta ti fa capire cosa succede davvero quando premi «un clic».</p>
<p>Servono tre cose, una volta sola:</p>
<ul>
<li><strong>device-mode</strong> con <code>container</code> e <code>partitions</code> sbloccati (più la conferma fisica) — vedi la <a href="https://mikrotikdojo.com/knowledge-base/device-mode-routeros-come-funziona/">KB sul device-mode</a>.</li>
<li>un <strong>disco esterno veloce</strong> (USB o NVMe) formattato <code>ext4</code>: a differenza del container manuale, <code>/app</code> vuole uno <strong>storage vero</strong> (la documentazione parla di ≥100 MB/s), non la flash interna.</li>
<li>un passaggio di setup in cui dici ad <code>/app</code> quale disco, quale bridge della LAN e quale IP del router usare.</li>
</ul>
<pre><code># sblocca container + partizioni (richiede la conferma fisica sul dispositivo)
/system/device-mode/update container=yes partitions=yes

# dopo aver formattato il disco esterno in ext4 (menu Disks), indica disco/bridge/ip
/app settings set disk=&lt;disco-esterno&gt; lan-bridge=&lt;bridge-lan&gt; router-ip=&lt;ip-del-router&gt;

# installa AdGuard dal catalogo, in un comando
/app enable &lt;nome-app&gt;</code></pre>
<p>Da qui RouterOS scarica l'immagine (nella ricetta del Dojo la teniamo <strong>pinnata</strong> a una versione precisa, non <code>latest</code>), crea e avvia il container, e genera un indirizzo per la web UI del tipo <code>https://&lt;nome-app&gt;.&lt;seriale&gt;.routingthecloud.com</code>.</p>
<p><strong>Nota di sicurezza (verificata).</strong> Quel nome cloud è pubblico, ma <strong>risolve all'IP privato del router nella LAN</strong>: da Internet punta a un indirizzo non instradabile. In pratica la web UI di AdGuard resta raggiungibile <strong>solo dalla tua rete</strong> e <strong>non</strong> viene esposta su Internet dal cloud MikroTik. Vale comunque la regola del metodo manuale: non inoltrare quella porta verso la WAN.</p>
<p><strong>Dove funziona, e dove no — detto onestamente.</strong> Il deploy un-clic <strong>si completa su hardware reale</strong> (apparati arm64/x86 con un disco esterno veloce): immagine scaricata, container creato e avviato, UI che risponde. Sul <strong>CHR / in macchina virtuale con disco su file</strong>, invece, <code>/app enable</code> si <strong>ferma</strong> su «<code>wait for reverse proxy</code>» e <strong>non crea mai il container</strong>: a <code>/app</code> serve storage veloce vero, che un disco virtuale su file non garantisce. Su un CHR con un <em>disco reale</em> dedicato e veloce è plausibile che vada, ma <strong>non l'abbiamo ancora verificato</strong>. Il menu <code>/app</code> è una funzione recente e ancora in maturazione: confidiamo che MikroTik la renda solida su più configurazioni. E se nel frattempo il tuo deploy si pianta su «wait for reverse proxy», il <strong>metodo manuale qui sopra funziona ovunque, oggi, su ogni versione stabile</strong> e anche senza disco esterno.</p>

<h2>Passo 7: chiuderlo bene</h2>
<ul>
<li><strong>DNS solo verso la LAN, mai verso la WAN.</strong> Un server DNS aperto su Internet diventa un <em>open resolver</em>: viene sfruttato per <a href="https://mikrotikdojo.com/dojo/amplificazione-dns-mikrotik/">attacchi di amplificazione</a> contro altri. Con il firewall, la porta 53 del container non deve mai essere raggiungibile da fuori. Esponi alla LAN solo ciò che serve.</li>
<li><strong>La web UI protetta e non pubblica.</strong> Password robusta (Passo 5) e nessun inoltro della porta della web UI verso Internet.</li>
<li><strong>Niente <code>privileged</code>.</strong> AdGuard non ne ha bisogno: lasciandolo senza, un'eventuale falla nel servizio resta chiusa nel container e non tocca il router.</li>
<li><strong>Mount al minimo.</strong> Solo le due cartelle dati di AdGuard. Nessun motivo per montargli altro.</li>
<li><strong>Immagine aggiornata.</strong> Un DNS che sta in mezzo a tutto il traffico va tenuto aggiornato; rifai il <em>pull</em> dell'immagine quando esce una nuova versione.</li>
<li><strong>Limita le risorse</strong> con <code>memory-max</code>, così un problema del container non si mangia la RAM del router.</li>
</ul>

<section class="faq"><h2>Domande frequenti</h2>
<div class="faq-item"><h3>Serve device-mode anche per AdGuard?</h3><p>Sì: AdGuard gira in un container, e i container vanno sbloccati una volta con <code>device-mode container=yes</code> più la conferma fisica. Una volta fatto, vale per tutti i container.</p></div>
<div class="faq-item"><h3>Posso usarlo senza esporre il container alla LAN?</h3><p>Se vuoi che i dispositivi lo interroghino direttamente, il loro DNS deve poterlo raggiungere: o il container sta su un bridge della LAN, o il router inoltra la porta 53 verso il container solo dall'interno. In entrambi i casi la porta 53 non deve mai affacciarsi sulla WAN.</p></div>
<div class="faq-item"><h3>Se cancello il container perdo la configurazione?</h3><p>No, se hai fatto i mount del Passo 3: configurazione e statistiche stanno nelle cartelle del router (<code>src</code>), non dentro il container. Ricreando il container con gli stessi mount, AdGuard ritrova tutto.</p></div>
<div class="faq-item"><h3>Quanto pesa davvero sul router?</h3><p>In laboratorio circa 56 MiB di RAM e 43 MiB su disco, con CPU quasi a zero da fermo. Dipende da quante liste di blocco carichi e da quante richieste serve: più liste e più client, più RAM. Su un apparato piccolo, verifica prima.</p></div>
<div class="faq-item"><h3>AdGuard può vedere dentro il router, come mikroscope?</h3><p>No, ed è voluto. Qui non c'è <code>privileged</code> e non montiamo <code>/proc</code> o <code>/sys</code>: AdGuard vede solo il suo filesystem e le sue due cartelle dati. È un servizio ospite, non un osservatore del router.</p></div>
</section>

<p class="fonte">Provato in laboratorio su CHR RouterOS 7.25 (stable): pacchetto <code>container</code> e <code>device-mode container=yes</code>; container <code>adguard/adguardhome</code> su una veth con bridge dedicato e NAT, con due mount persistenti (<code>list=adg</code>, <code>/opt/adguardhome/conf</code> e <code>/opt/adguardhome/work</code>) e senza <code>privileged</code>; procedura guidata iniziale sulla porta 3000, poi web UI sulla 80 (protetta, risposta 401 senza credenziali) e DNS sulla 53; risoluzione di un nome attraverso il container (<code>example.com</code>) e blocco di un dominio pubblicitario (<code>doubleclick.net</code> → <code>0.0.0.0</code>) con conferma nelle statistiche (2 richieste, 1 bloccata); ingombro misurato 56,1 MiB di RAM e 43,5 MiB su disco.</p>