Come eseguire un controller UniFi su un VPS

Cosa fa realmente un controller UniFi su un VPS

Un controller UniFi su un VPS è un unico server di gestione che rimane raggiungibile anche quando i siti gestiti non sono disponibili. Il software è UniFi Network Application di Ubiquiti: un programma Java con un database MongoDB. Configura gli access point e gli switch, memorizza le relative statistiche e fornisce l'interfaccia di amministrazione. Non trasporta il traffico dei client.

Questo aspetto determina dove deve essere eseguito. Se installi il controller su una macchina all'interno dell'ufficio che gestisce, perdi la rete e lo strumento per monitorarla nello stesso momento. Se lo installi su un VPS con un indirizzo pubblico stabile, il controller continua a funzionare, a raccogliere dati e ad adottare dispositivi presenti in più siti da un unico punto. Ha bisogno di disponibilità elevata, non di molta potenza di calcolo.

Quando il controller è offline, gli access point e gli switch adottati continuano a inoltrare il traffico usando la configurazione già inviata. Perdi il dashboard e le statistiche, oltre a tutte le funzioni che richiedono il controller attivo: l'accesso tramite captive portal per gli ospiti oppure RADIUS (remote authentication dial-in user service) se il controller svolge il ruolo di server RADIUS. I client restano connessi.

Quanta RAM richiede un controller UniFi?

2 GB sono il minimo indispensabile, mentre 4 GB sono la scelta consigliata. In un unico sistema ci sono due componenti che consumano memoria: Java e MongoDB. Ognuno dimensiona il proprio utilizzo di memoria in modo indipendente dall'altro.

L'heap Java è limitato da MEM_LIMIT, che l'immagine del container imposta per impostazione predefinita a 1024 MB. MongoDB costituisce l'altra metà del consumo. Il suo motore di storage WiredTiger dimensiona la cache usando metà della RAM oltre 1 GB oppure 256 MB, scegliendo il valore maggiore. Su un VPS da 2 GB si tratta indicativamente di 512 MB di cache, 1 GB di heap, la memoria non-heap propria della JVM e la memoria del sistema operativo. La configurazione funziona finché il carico non aumenta; poi l'out-of-memory killer del kernel termina uno dei due processi. Dopo un riavvio senza una causa evidente, esegui dmesg -T | grep -i 'killed process' per verificare se è successo questo. Se disponi soltanto di 2 GB, aggiungi un file di swap.

CPU e disco non richiedono risorse elevate. 1 o 2 vCPU sono sufficienti per alcune decine di dispositivi. Parti da 20 GB di spazio su disco e controllane l'utilizzo, perché il database cresce in base al numero di client rilevati e al periodo di conservazione delle statistiche. Un controller da solo lascia inutilizzata gran parte di un server da 4 GB. Se prevedi di affiancargli un altro servizio, dimensiona il sistema in base a quest'ultimo, perché PhotoPrism e Immich richiedono quantità di RAM minime molto diverse e ciascuno dei due richiede più memoria del controller.

Una funzionalità della CPU è importante e può essere facilmente trascurata nei piani economici:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 e versioni successive richiedono AVX (advanced vector extensions) su hardware x86_64. Se il comando non stampa nulla, mongod termina durante l'avvio e il container viene riavviato in un ciclo continuo, perché il binario esegue un'istruzione non disponibile sulla CPU. La causa più comune sono gli host con Intel Celeron e Pentium meno recenti, oltre agli hypervisor che nascondono i flag della CPU al guest. MongoDB 4.4 non richiede AVX ed è l'unico fallback disponibile, ma si tratta di una versione del database che upstream non corregge più. La soluzione migliore è passare a un host con una CPU più recente. Su un VPS ARM il problema non si presenta, perché AVX è un set di istruzioni x86, e entrambe le immagini pubblicano build arm64. Se devi scegliere tra le due architetture, le differenze tra i piani VPS ARM e x86 vanno oltre il prezzo.

Installare UniFi Network Application con Docker Compose

Docker è la soluzione che riduce maggiormente gli imprevisti, perché consente di bloccare MongoDB su una versione supportata dall'applicazione invece di utilizzare quella fornita dalla distribuzione. Se Docker non è ancora installato sul server, installare Docker su un VPS prima di procedere.

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

MongoDB richiede un utente prima che l'applicazione possa autenticarsi. L'immagine ufficiale di MongoDB esegue ogni script presente in /docker-entrypoint-initdb.d al primo avvio. Salvare questo contenuto come ~/unifi/init-mongo.sh:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

Lo script viene eseguito solo quando la directory del database è vuota. Se si avvia lo stack una volta con la password errata, l'utente viene creato con quella password. Modificare successivamente il file Compose non cambia nulla, perché lo script non viene più eseguito. Il sintomo è che il container dell'applicazione registra errori di autenticazione MongoDB, mentre l'interfaccia web non viene mai visualizzata. In una nuova installazione, la soluzione consiste nell'arrestare lo stack, eliminare ~/unifi/db e riavviarlo.

Quindi scrivere ~/unifi/compose.yaml:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

Entrambi i tag delle immagini sono bloccati intenzionalmente. 10.5.67-ls141 era la release corrente dell'applicazione ad agosto 2026. Controllare quindi l'elenco delle release dell'immagine e bloccare la versione corrente al momento dell'installazione. Il tag del database è ancora più importante. MongoDB non aggiorna autonomamente i file dati tra versioni principali. Di conseguenza, mongo:latest prima o poi scaricherà una nuova versione principale, rifiuterà di aprire i file presenti e si riavvierà in un ciclo continuo. Bloccare la versione principale e aggiornarla deliberatamente. UniFi Network 8.1 e versioni successive supportano MongoDB dalla 3.6 alla 7.0. La versione 9.0 ha aggiunto il supporto per MongoDB 8.0.

PUID e PGID devono corrispondere a un utente reale sul server. In caso contrario, i file sotto ./config verranno assegnati a un'identità che non può scriverli. Eseguire id per ottenere i propri valori. come funzionano PUID e PGID nelle immagini container spiega come riconoscere un'incoerenza.

Avviarlo e monitorare i log:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

docker compose ps dovrebbe mostrare entrambi i container nello stato running. Un unifi-db bloccato in restarting indica un problema AVX, descritto sopra, oppure un problema di permessi su ./db. Quando i log si stabilizzano, controllare i due listener:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

Qualsiasi codice di stato HTTP indica che il listener è associato alla porta e risponde. Connection refused indica che l'applicazione è ancora in avvio. Al primo avvio, su un VPS di piccole dimensioni, questa operazione richiede uno o due minuti. In alternativa, indica che l'applicazione non è mai stata avviata.

Accedere all’interfaccia di amministrazione senza esporla

La porta 8443 è pubblicata su 127.0.0.1 nel file precedente, quindi nulla all’esterno del VPS può raggiungere l’interfaccia di amministrazione. Inoltrala tramite SSH per eseguire la procedura guidata di configurazione:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

Lascia aperta la sessione e apri https://127.0.0.1:8443 nel browser. Il certificato è autofirmato, quindi il browser visualizza un avviso una sola volta. Crea l’account amministratore, assegna un nome al sito e, per ora, ignora l’adozione dei dispositivi.

Un tunnel SSH è sufficiente per un singolo amministratore. Per un team, assegna al VPS un indirizzo privato e associa l’interfaccia a quell’indirizzo. una VPN WireGuard sul tuo VPS e un router di sottorete Tailscale forniscono entrambi un indirizzo raggiungibile solo dai tuoi utenti. Modifica la porta pubblicata in 10.8.0.1:8443:8443 per WireGuard oppure usa l’indirizzo assegnato da Tailscale. Attenzione: Docker non può pubblicare una porta su un indirizzo che non esiste ancora. L’interfaccia del tunnel deve quindi essere attiva prima dell’avvio del container, altrimenti il container non si avvia e restituisce un errore di binding.

Perché un dispositivo UniFi remoto non esegue l'adozione

Per impostazione predefinita, un dispositivo UniFi individua il controller tramite broadcast sulla rete locale, sulla porta UDP 10001. Un broadcast non oltrepassa la LAN, quindi un dispositivo in un ufficio di un'altra città non individuerà mai un controller su un VPS. Questa è l'adozione Layer 3 ed è il punto in cui la maggior parte degli utenti si blocca. Il dispositivo funziona e anche il controller funziona. Nessuno ha indicato al dispositivo dove cercare.

Per prima cosa, indica al controller quale indirizzo distribuire. Nelle impostazioni del controller, nella sezione System, è disponibile l'impostazione inform host con un'opzione di override. Impostala sul nome host pubblico o sull'indirizzo IP del tuo VPS. Senza questa impostazione, il controller pubblicizza l'indirizzo rilevato sulla propria interfaccia, che all'interno di una rete Docker bridge è un indirizzo privato come 172.18.0.3. Il dispositivo riceve quell'indirizzo, non può instradare il traffico verso di esso e riprende la ricerca.

Poi configura il dispositivo affinché utilizzi quell'indirizzo. Connettiti via SSH al dispositivo sulla LAN remota. Un dispositivo con le impostazioni di fabbrica accetta il nome utente ubnt con la password ubnt:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

Il firmware più recente del dispositivo apre un menu invece di una shell. Esegui lo stesso comando in un'unica riga:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

Il dispositivo ora appare nel controller ed è pronto per l'adozione. Fai clic su Adopt; lo stato passa a Adopting. Questo è il passaggio che spesso sorprende: di solito devi eseguire set-inform una seconda volta. Il dispositivo si riavvia per eseguire il provisioning e torna all'URL inform salvato nella propria configurazione, che il controller non ha ancora finito di sostituire. Eseguire di nuovo il comando mentre lo stato è Adopting completa il passaggio di consegne. Digita info sul dispositivo per visualizzare l'URL inform e lo stato attualmente memorizzati.

Se il dispositivo era stato adottato in precedenza da un altro controller, set-inform da solo non completa l'operazione, perché il dispositivo conserva ancora le credenziali di quel controller. Ripristina prima le impostazioni di fabbrica, utilizzando il pulsante di reset oppure set-default tramite SSH con le vecchie credenziali.

Per più di una manciata di dispositivi, utilizza invece DHCP. L'opzione 43 del DHCP (dynamic host configuration protocol) trasporta un valore specifico del produttore e i dispositivi UniFi leggono l'URL inform dalla sottoopzione 2. Crea la stringa esadecimale su un qualsiasi sistema Linux:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

Per http://192.168.3.10:8080/inform, una stringa di 31 byte, il comando stampa 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Incolla il risultato nel campo dell'opzione DHCP 43 del router come valore esadecimale. Ogni dispositivo che si avvia su quella rete apprende quindi l'indirizzo del controller dalla propria lease, senza alcun accesso SSH. Le guide più datate indicano invece la sottoopzione 1, 0104 seguita dai 4 byte di un indirizzo IPv4 in formato esadecimale; i dispositivi accettano ancora questa forma.

Esiste una terza possibilità se gestisci il DNS del sito. Durante l'avvio, un dispositivo UniFi tenta di risolvere il nome host unifi; un record A per unifi che punti all'indirizzo del VPS consente di adottare i dispositivi senza intervenire singolarmente su ciascuno. Questa soluzione funziona solo se controlli il resolver effettivamente utilizzato dai dispositivi.

Quali porte UniFi aprire e quali mantenere private

Solo 2 porte devono essere raggiungibili da un sito remoto.

• TCP 8080 è il canale inform e tutti i dispositivi adottati si connettono a questa porta. Il payload interno è cifrato con AES usando una chiave che il controller ha fornito al dispositivo durante l'adozione. Per questo, in questo caso, HTTP non cifrato è l'impostazione normale.
• UDP 3478 è STUN (session traversal utilities for NAT), che i dispositivi usano per mantenere un percorso verso il controller.

Su un VPS, tutte le altre porte devono restare chiuse.

• TCP 8443 è l'interfaccia di amministrazione. Questa porta non deve mai essere pubblica. Contiene la configurazione di tutti i siti gestiti dal controller, protetta da un'unica password.
• UDP 10001 e UDP 1900 gestiscono il rilevamento tramite broadcast. I broadcast non attraversano Internet, quindi aprire queste porte non serve.
• TCP 8880 e TCP 8843 gestiscono i redirect del guest portal. Aprile solo se utilizzi un guest portal.
• TCP 6789 è usata dal test di velocità mobile e UDP 5514 dal syslog remoto. Aggiungile quando ti servono.
• TCP 27117 è MongoDB. Nel file compose precedente il database non pubblica alcuna porta, quindi esiste soltanto sulla rete Docker interna. Mantieni questa configurazione.

Se i tuoi siti hanno indirizzi pubblici statici, consenti solo quelli:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

le nozioni di base su ufw per il firewall di un VPS descrive la configurazione predefinita con deny implicita su cui si basano queste regole.

C'è una configurazione errata che causa problemi molto spesso. Le porte pubblicate da Docker aggirano ufw. La pubblicazione di una porta scrive direttamente regole NAT e di forwarding in iptables, e questo traffico viene filtrato nella catena interna di Docker, non nella catena INPUT gestita da ufw. Di conseguenza, ufw deny 8443 sembra corretto in ufw status, mentre la porta resta aperta a chiunque. Esegui il test da un altro computer, mai dal VPS stesso:

nc -vz vps.example.com 8443

Un rifiuto della connessione o un timeout è il risultato desiderato. Se la connessione riesce, la porta è pubblica indipendentemente da quanto indica ufw. La correzione affidabile è già presente nel file compose: pubblica la porta su 127.0.0.1 oppure su un indirizzo del tunnel, così Docker non la associa mai all'interfaccia pubblica. Funziona anche una regola nella catena DOCKER-USER, ma il binding è più semplice e un errore nell'ordine delle regole non può annullarlo.

E gli installer di Ubiquiti?

Ubiquiti pubblica un pacchetto Debian per Network Application. Funziona, ma sulle versioni attuali di Ubuntu introduce un problema relativo a MongoDB a cui la distribuzione non dà più una risposta: Ubuntu 22.04 e 24.04 non includono alcun pacchetto server MongoDB, quindi è necessario aggiungere il repository ufficiale di MongoDB e associare manualmente le versioni compatibili. Il container precedente gestisce questa compatibilità in un unico tag fissato, motivo per cui in questa guida si utilizza questa soluzione.

Il prodotto self-hosted più recente di Ubiquiti è UniFi OS Server. Esegue le applicazioni UniFi in container Podman e fornisce lo stesso UniFi OS delle console hardware del produttore. Ad agosto 2026 richiede Ubuntu 22.04 o 24.04 su x86_64 e Podman 4.3.1 o versione successiva con slirp4netns. Richiede almeno 2 vCPU e 4 GB di RAM; la configurazione consigliata è di 4 vCPU e 8 GB. L'installer è disponibile dietro un account Ubiquiti gratuito nella pagina dei download, quindi non esiste un URL stabile da inserire in una guida. Crea un utente di sistema chiamato uosserver ed esegue i container con quell'utente. Sceglilo se vuoi utilizzare il pacchetto ufficiale del produttore. Scegli lo stack di container se vuoi fissare autonomamente le versioni e lasciare il server disponibile per altre attività.

Dove si trovano i backup di UniFi e come copiarli fuori dal server

Il controller crea i propri backup secondo la pianificazione configurata in Settings, nella sezione dei backup, insieme al numero di copie da conservare. I file vengono salvati in /config/data/backup/autobackup all’interno del container, che sul server host corrisponde a ~/unifi/config/data/backup/autobackup, con nomi simili a autobackup_10.5.67_20260813_1200_1755086400004.unf.

Verificate che i file vengano effettivamente creati:

ls -l ~/unifi/config/data/backup/autobackup

Una directory vuota il giorno successivo alla configurazione della pianificazione indica un problema noto nelle nuove installazioni del container. L’applicazione si aspetta che esista la directory autobackup, ma non la crea. Di conseguenza, il job pianificato non scrive alcun file senza generare errori visibili. Create la directory con lo stesso utente utilizzato dal container, quindi attendete la successiva esecuzione:

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

Un file .unf contiene la configurazione dei siti e gli account amministrativi, quindi va trattato come una chiave crittografica. Copiate i backup su una macchina sotto il vostro controllo e manteneteli riservati:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

Il ripristino richiede un solo passaggio. La prima pagina della procedura guidata di configurazione di una nuova installazione permette di ripristinare un file di backup; un controller in esecuzione offre la stessa funzione nella relativa pagina delle impostazioni. Ripristinate il backup sulla stessa versione o su una versione più recente. Un backup creato da un’applicazione più recente rispetto a quella in cui lo state ripristinando viene rifiutato. Per questo motivo, registrate il numero di versione insieme al file.

Cosa può compromettere un aggiornamento del controller

Esegui un backup manuale e scaricalo prima di ogni aggiornamento. Poi:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

Il database è il primo componente a cedere. Modificare il tag mongo impostandolo su una nuova versione principale nella stessa modifica in cui aggiorni l'applicazione è il modo più rapido per ottenere un controller che non si avvia, perché MongoDB non apre i file di dati di una versione principale diversa senza un aggiornamento pianificato per fasi. Aggiorna l'applicazione separatamente. Aggiorna MongoDB in un secondo momento, una versione principale alla volta, dopo aver preparato un backup recente.

La memoria è il problema successivo. Una release più recente richiede un heap più grande. Se l'applicazione si avvia, funziona per alcuni minuti e poi si arresta, aumenta MEM_LIMIT e MEM_STARTUP a 1536 o 2048, quindi riavvia. dmesg -T | grep -i 'killed process' sull'host conferma se è stato il kernel a terminarla.

Il firmware dei dispositivi è il rischio che spesso viene dimenticato. Dopo essersi aggiornato, il controller propone gli aggiornamenti del firmware per i dispositivi adottati. Non accettarli nella stessa sessione. Se un aggiornamento del dispositivo e uno del controller si sovrappongono e il collegamento tra i due viene interrotto, il dispositivo può restare parzialmente configurato. In questo caso dovrai tornare a set-inform tramite SSH su hardware situato in un altro edificio.

La finestra di aggiornamento è meno problematica di quanto possa sembrare. I dispositivi continuano a inoltrare il traffico mentre il controller si riavvia, quindi gli utenti non notano interruzioni. Si interrompono invece il portale guest e RADIUS, se sono erogati dal controller. Scegli quindi un orario in cui nessuno dei due sia in uso. È utile sapere se un controller si arresta senza messaggi alle 3 del mattino. Configura quindi un monitor di stato Uptime Kuma sulla porta 8080 e lascia che sia lui a segnalartelo.

L’alternativa trasparente: la console in hosting di Ubiquiti

Ubiquiti offre la stessa funzione come servizio. Ad agosto 2026, Official UniFi Cloud Console parte da $29 al mese e gestisce fino a 500 dispositivi UniFi; Ubiquiti si occupa degli aggiornamenti e dei backup. L’applicazione self-hosted appena installata è gratuita e non prevede alcun abbonamento.

Scegli la console in hosting se gestisci un solo sito e preferisci pagare invece di applicare le patch. Scegli un VPS se gestisci più siti, oppure se vuoi il controller all’interno di una rete che controlli e sullo stesso server degli altri servizi che esegui. La differenza di costo su piccola scala è concreta, ma non è l’unico elemento da valutare: la disponibilità di una console in hosting dipende da un’infrastruttura gestita da altri, mentre il VPS è sotto il tuo controllo, anche quando il disco si riempie durante la notte. Se il server deve comunque ripagarsi, leggi cos’altro puoi eseguire su un VPS.

FAQ

Perché il dispositivo UniFi non viene adottato da un controller su un VPS?

I dispositivi individuano i controller tramite broadcast sulla porta UDP 10001. Un broadcast non lascia mai la rete locale, quindi un dispositivo in una sede remota non può trovare un controller su Internet. Imposta l'override dell'host inform nelle impostazioni di sistema del controller indicando il nome host del VPS, quindi configura il dispositivo puntando a tale host con ssh ubnt@<device-ip> seguito da set-inform http://vps.example.com:8080/inform. Se il dispositivo rimane nello stato Adopting, esegui di nuovo set-inform mentre si trova in quello stato. Se in precedenza è stato adottato da un altro controller, ripristinalo prima alle impostazioni di fabbrica, perché conserva ancora le credenziali del vecchio controller.

Quanta RAM richiede un controller UniFi self-hosted?

2 GB sono il minimo operativo; 4 GB offrono un margine adeguato. L'applicazione usa Java e MongoDB, che dimensionano la memoria separatamente: per impostazione predefinita, l'immagine del container limita l'heap Java a 1024 MB, mentre la cache WiredTiger di MongoDB utilizza metà della RAM oltre 1 GB. Su x86_64, verifica anche che la CPU esponga AVX con grep -m1 -o avx /proc/cpuinfo, perché MongoDB 5.0 e versioni successive non si avviano senza questa estensione e il container del database entra in un ciclo continuo di riavvio.

Devo esporre la porta 8443 a Internet?

No. La porta 8443 espone l'interfaccia di amministrazione, che contiene la configurazione di tutti i siti gestiti dal controller. Pubblicala su 127.0.0.1 e raggiungila con ssh -L 8443:127.0.0.1:8443 you@vps.example.com, oppure assoc iala a un indirizzo WireGuard o Tailscale. Solo le porte TCP 8080 e UDP 3478 devono essere raggiungibili dai tuoi siti. Se gli indirizzi pubblici dei siti sono statici, puoi limitarne l'accesso a tali indirizzi. Ricorda che una porta pubblicata da Docker non viene filtrata da ufw. Esegui quindi il test da una macchina esterna invece di fare affidamento su ufw status.

La rete smette di funzionare se il controller VPS non è disponibile?

No. Gli access point e gli switch adottati continuano a inoltrare il traffico usando la configurazione già distribuita dal controller. I client restano connessi e la rete Wi-Fi continua a funzionare. Si interrompe invece la gestione. Non saranno più disponibili il dashboard e la raccolta delle statistiche, oltre alle funzioni in tempo reale fornite dal controller, come l'autenticazione tramite captive portal per gli ospiti o RADIUS quando il controller svolge il ruolo di server RADIUS.

Dove salva il controller UniFi i backup automatici?

Nell'immagine del container utilizzata in questa procedura, i backup vengono salvati in /config/data/backup/autobackup. Questo percorso corrisponde al percorso dei dati più data/backup/autobackup sull'host, sotto forma di file .unf denominati in base alla versione e a un timestamp. In alcune installazioni iniziali la directory autobackup non esiste. In questo caso il backup pianificato non scrive alcun file e non segnala errori. Un giorno dopo aver configurato una pianificazione, elenca quindi il contenuto di quella directory e, se è vuota, creala manualmente. Copia i file al di fuori del VPS, perché un .unf contiene la configurazione dei siti e gli account amministrativi.