Alternative a IP Cloud: un DDNS sul tuo dominio (DuckDNS o Cloudflare)

IP Cloud è comodissimo: una riga e il router ha un nome che segue l’indirizzo pubblico. Ma quel nome è il tuo numero di serie, dentro un dominio di MikroTik. Se preferisci un nome tuo, su un tuo dominio, questo howto ti mostra due strade collaudate: una in cinque minuti e una fatta bene.

Perché cercare un’alternativa?

Il nome che ti dà IP Cloud è numero-di-serie.sn.mynetname.net. Due cose, da qui, le regala a chiunque: che a quell’indirizzo c’è un MikroTik (il dominio sn.mynetname.net è suo), e che è di un certo modello e di una certa epoca (il numero di serie non è casuale, i lotti sono contigui). Non è una falla: è un’impronta. Chi cerca bersagli la può usare per restringere il campo e provarci in modo mirato.

Quanto è concreta? L’abbiamo misurata. Abbiamo provato a risolvere un milione di numeri di serie consecutivi dentro un blocco reale (quello di un nostro apparato): ne risolvono 32, cioè 32 MikroTik vivi, raggiungibili su internet, ognuno con il suo indirizzo pubblico — indirizzi che non abbiamo registrato. Provando invece numeri a caso in tutto lo spazio non risolve quasi nulla: non si trovano “tutti i MikroTik del mondo”, si trova chi sta in un blocco di serie che già conosci. Piccola cosa, nulla che un firewall in input fatto bene non fermi — ma se non vuoi dichiarare di avere un MikroTik, il nome tuo è la risposta.

Cosa ti serve

Un nome DNS dinamico. Due possibilità: un servizio gratuito tipo DuckDNS (nome del tipo tuonome.duckdns.org, zero costi, cinque minuti), oppure il tuo dominio con un DNS che abbia le API, qui usiamo Cloudflare (nome del tipo casa.tuodominio.it, nessuna impronta, è la scelta pulita). In entrambi i casi il router aggiorna il nome da solo con uno script e lo scheduler.

Opzione 1 — DuckDNS, in cinque minuti

Su duckdns.org accedi con un account che già hai, crei un sottodominio e copi il token. Poi, sul MikroTik, questo script: aggiorna il nome e lo scrive nel log. DuckDNS rileva da solo il tuo indirizzo pubblico dal mittente della richiesta, quindi funziona anche dietro il modem dell’operatore.

# DuckDNS updater — put your subdomain and token below
:local host "myhome"
:local token "YOUR-DUCKDNS-TOKEN"
:local url ("https://www.duckdns.org/update?domains=" . $host . "&token=" . $token . "&ip=")
:local res [/tool fetch url=$url check-certificate=yes output=user as-value]
:log info ("DuckDNS: " . [:tostr ($res->"data")])

Due dettagli che fanno perdere un’ora se non li sai: con url= completo non si mette mode=https (lo schema lo prende dalla URL, altrimenti dà bad parameter url), e il ? nella URL non va messo con la barra rovescia. Salva lo script e fallo girare ogni cinque minuti:

/system script add name=ddns-duck source=[:parse [/file get ddns-duck.rsc contents]]
/system scheduler add name=ddns-duck interval=5m on-event="/system script run ddns-duck"

In alternativa incolli il corpo dello script direttamente nell’on-event dello scheduler. Dopo un minuto, da un PC qualunque, nslookup myhome.duckdns.org deve rispondere con il tuo indirizzo pubblico.

Opzione 2 — il tuo dominio con Cloudflare

Questa è la strada pulita: il nome sta sul tuo dominio, non dice niente di te. Su Cloudflare crei un record A (anche fittizio, lo aggiorna lo script), poi un API token con permesso Zone:DNS:Edit sulla zona. Ti servono l’ID della zona e l’ID del record (li leggi dalla dashboard o dall’API). Dietro il NAT il router non conosce il proprio indirizzo pubblico, quindi prima lo chiede a un servizio “echo”, poi aggiorna solo se è cambiato.

# Cloudflare DDNS — update an A record on your own domain
:local zone  "ZONE_ID"
:local rec   "RECORD_ID"
:local name  "home.example.com"
:local token "CF_API_TOKEN"
# 1) current public IP (behind NAT the router asks an echo service)
:local ip ([/tool fetch url="https://api.ipify.org" check-certificate=yes output=user as-value]->"data")
# 2) update only when it changed
:global ddnsLast
:if ($ip != $ddnsLast) do={
  :local body ("{\"type\":\"A\",\"name\":\"" . $name . "\",\"content\":\"" . $ip . "\",\"ttl\":120,\"proxied\":false}")
  /tool fetch url=("https://api.cloudflare.com/client/v4/zones/" . $zone . "/dns_records/" . $rec) \
    http-method=put check-certificate=yes output=none \
    http-header-field=("Authorization: Bearer " . $token . ",Content-Type: application/json") \
    http-data=$body
  :set ddnsLast $ip
  :log info ("DDNS Cloudflare: " . $name . " -> " . $ip)
}

Stesso scheduler di prima, ogni cinque minuti. Lo stesso schema (uno script che chiama l’update in HTTPS) vale per deSEC, Dynu, No-IP, FreeDNS: cambia solo l’indirizzo e il modo di autenticarsi.

Attenzione al CGNAT

Nessun DNS dinamico ti fa entrare se sei dietro un CGNAT dell’operatore: il nome punta all’indirizzo del NAT dell’operatore, e quella porta non è tua. Lì serve una VPN che passa da un relay (come fa Back To Home di MikroTik) — ma quella, di nuovo, ti marca come MikroTik. Per il resto, con un indirizzo pubblico vero, il DDNS su dominio tuo fa esattamente il lavoro di IP Cloud, senza l’impronta.

Una cosa che non cambia: il firewall

Il nome serve solo a trovare il router, non apre niente. Che tu usi IP Cloud o un nome tuo, la sicurezza la fa il firewall in input e gli aggiornamenti di RouterOS. Se hai seguito l’hardening di base, che ti trovino o no cambia poco: dalla WAN non entra nessuno comunque.

Provato in laboratorio: aggiornamento DuckDNS da un MikroTik con RouterOS 7.24.5 (stable), risposta OK e nome che segue l’indirizzo pubblico. La misura sui numeri di serie è aggregata: nessun indirizzo IP di terzi è stato letto o salvato.