8 sezioni tecniche sono chiuse qui sotto. Apri quelle che ti incuriosiscono, oppure tutte.

In breve

Debug Center è uno strumento che sto costruendo per assistere i computer a distanza. Il proprietario avvia un piccolo programma una volta sola e legge esattamente cosa farà prima di accettare. A quel punto posso controllare la macchina, leggere gli errori che ha registrato ed eseguire riparazioni, attraverso una connessione privata che nient’altro su internet può raggiungere.

Ogni richiesta viene annotata dove il proprietario può leggerla e, a lavoro finito, il programma viene rimosso del tutto, dalla macchina stessa o da parte mia. Non è ancora pubblicato. Le sezioni tecniche qui sotto sono chiuse: aprile se vuoi sapere come funziona.

A cosa serve

Debug Center serve per fare manutenzione su macchine che appartengono ad altri: capire perché un computer è lento, leggere gli errori registrati, lanciare una riparazione, recuperare un file di log o caricare una correzione. Gli strumenti di desktop remoto sono costruiti attorno alla condivisione dello schermo. Per la maggior parte di questo lavoro preferisco avere i dati della macchina e una riga di comando, su Windows, Linux e macOS, e più avanti anche sui telefoni.

Voglio anche che la connessione sia sotto il mio controllo. Il server di coordinamento è mio, non c’è alcun account presso un’azienda di accesso remoto e nulla sulla macchina del cliente resta in ascolto su internet o sulla rete locale. Lo strumento è open source con licenza MIT e il codice è pubblico sui miei profili Forgejo, GitHub e Codeberg.

Repository su GitHub ↗Forgejo (canonico) ↗Mirror su Codeberg ↗

dbc-agent gira sulla macchina da assistere. dbc è il controller che eseguo sulla mia. Entrambi sono scritti in Go e compilano in un singolo eseguibile senza dipendenze, per Windows, Linux e macOS sia su amd64 sia su arm64. Su Windows un doppio clic sull’agente avvia il suo programma di installazione.

L’agente ha tre modalità. install lo configura come servizio di sistema che sopravvive ai riavvii. run avvia una sessione singola in primo piano: quando il cliente preme Ctrl+C, l’agente lascia la rete e cancella tutto ciò che aveva salvato. uninstall lo rimuove completamente.

# Sulla macchina del cliente: installa come servizio oppure esegui una sola volta
dbc-agent install --name acme-desk --auth-key <key> --allow tag:technician
dbc-agent run --auth-key <key> --allow tag:technician

# Sulla mia
dbc ls
dbc info acme-desk
dbc top acme-desk

L’agente incorpora Tailscale tramite tsnet, così il cliente non deve installare Tailscale né altro. All’avvio entra in una tailnet coordinata dal mio server Headscale, con un nome che indica a chi appartiene la macchina: dbc-<name>-<id>, marcato con il tag tag:dbc-agent. Le connessioni sono cifrate end-to-end tra le due macchine e attraversano il NAT da sole, senza dover aprire porte sul router del cliente.

L’agente ascolta soltanto sul suo indirizzo nella tailnet. Il controller chiede l’elenco dei peer al client Tailscale già attivo sulla mia macchina e individua gli agenti per tag o per nome. In questo modo la scoperta è immediata: dbc ls elenca ogni agente con il suo sistema operativo, se è online e quando è stato visto l’ultima volta.

Architettura di Debug Center: il controller dbc sulla mia macchina e dbc-agent sulla macchina del cliente, entrambi coordinati dal mio server Headscale self-hosted e connessi direttamente da un tunnel cifrato che trasporta HTTP sulla porta 7420.
Headscale si occupa solo del coordinamento: distribuisce le chiavi e la lista dei peer. Le richieste vanno direttamente da dbc all’API HTTP dell’agente sulla porta 7420 attraverso la tailnet, passando per le regole di accesso, la allowlist dell’agente e il registro di audit.

tsnet ↗Headscale ↗

Davanti a ogni richiesta ci sono due barriere. La prima è costituita dalle regole di accesso della tailnet, che stabiliscono chi può raggiungere un agente. La seconda è dentro l’agente stesso: chiede alla rete chi sta chiamando e risponde solo alle identità presenti nella sua allowlist, che si tratti del login tailnet di una persona o di un tag come tag:technician. Una macchina dotata di tag non soddisfa mai un controllo basato su login utente, perché i nodi con tag non hanno una persona reale associata.

Ogni richiesta finisce in un registro di audit sulla macchina, che sia stata autorizzata o meno, con chi l’ha inviata, da quale nodo e per fare cosa. dbc audit permette di leggerlo da remoto e il cliente può consultarlo localmente.

Il controllo della allowlist ↗

Prima di installarsi, l’agente stampa esattamente ciò che sta per fare: il servizio che registra e il percorso, la rete a cui si collega e con quale nome, chi potrà controllare la macchina e cosa potrà fare, e dove si trova il registro di audit. Richiede i privilegi di amministratore e non fa nulla finché il proprietario non digita yes.

La chiave pre-autorizzata che consente all’agente di entrare nella rete è una credenziale monouso. Una volta che l’agente installato si è registrato, cancella la chiave dalla propria configurazione. La rimozione funziona sia dalla macchina sia dal mio lato con dbc uninstall: l’agente esce dalla tailnet, ferma e rimuove il servizio ed elimina i propri file. La rimozione eseguita localmente può lasciare una copia del registro di audit al proprietario.

dbc info mostra l’inventario hardware e software. dbc stats raccoglie un campione di CPU, memoria, disco, rete e temperature, mentre dbc top lo aggiorna in tempo reale. dbc ps elenca i processi a partire dai più pesanti e dbc kill li termina. dbc exec esegue un comando sulla macchina e ne trasmette l’output mentre gira. dbc files, pull e push permettono di sfogliare e trasferire file.

La maggior parte delle riparazioni non richiede un comando libero, perciò l’agente include un catalogo di azioni diagnostiche e di manutenzione nominate per il proprio sistema operativo: finora 28 su Windows, 14 su Linux e 5 su macOS. Su Windows comprendono scansioni e riparazioni sfc e DISM, chkdsk, stato di salute dei dischi, cronologia dei crash, registro di affidabilità, problemi di driver e dispositivi, report su batteria ed energia, scansione rapida di Defender, reset della rete e pulizia dei file temporanei. Le azioni che interrompono l’uso della macchina, come il riavvio, sono contrassegnate come pericolose e dbc chiede conferma prima di eseguirle.

dbc actions acme-desk
dbc run acme-desk event-errors
dbc run acme-desk sfc-scan
dbc exec acme-desk ipconfig /all
dbc pull acme-desk 'C:\Windows\Logs\CBS\CBS.log'
dbc uninstall acme-desk

Il catalogo delle azioni Windows ↗

Ogni push al repository viene analizzato, testato e compilato per tutti i dodici binari sul mio Forgejo, e ogni esecuzione li conserva per il download. Le versioni con tag vengono pubblicate come release. I nomi dei binari non contengono il numero di versione, così ogni piattaforma ha un unico link stabile che restituisce sempre l’agente più recente, ed è quello che riceve il cliente.

L’agente può essere compilato con il server di coordinamento e i tecnici autorizzati già incorporati, così il cliente non deve digitarli. Le build pubbliche non contengono mai una chiave di pre-autorizzazione: chiunque può scaricarle e una chiave al loro interno permetterebbe a chiunque di entrare nella rete di supporto.

Build e CI ↗

Entrambi i programmi sono scritti, circa 4.500 righe di Go, e il controller è stato provato end-to-end contro i veri gestori di richieste dell’agente sulla mia macchina. Non c’è ancora una release pubblica e nessuno dei due ha ancora girato su una vera tailnet di assistenza. Per la prima release servono una guida rapida, test sul campo su Windows 10 e 11, sulle principali distribuzioni Linux e su macOS, test specifici per il codice sensibile lato sicurezza e la firma del codice su Windows per evitare che SmartScreen e gli antivirus blocchino il download.

Roadmap ↗Changelog ↗Security policy ↗

Debug Center è nato come strumento per PC e si sta estendendo a ogni tipo di dispositivo, a partire dai telefoni. Android riceve lo stesso nucleo dell’agente sotto forma di app, eseguita come servizio in primo piano dietro una schermata di consenso ben visibile. Un telefono collegato via cavo a un computer su cui gira l’agente può anche essere assistito tramite USB con adb, che arriva più in profondità di quanto possa fare un’app. iOS non consente un’app con questo tipo di accesso, quindi gli iPhone vengono assistiti via USB da un computer con l’agente tramite libimobiledevice: dettagli del dispositivo, stato della batteria, log di sistema, crash report e backup.

  • Installazioni a tempo, così che l’agente si rimuova da solo se nessuno si ricorda di disinstallarlo.
  • Un avviso visibile sul dispositivo mentre un tecnico è connesso.
  • Ruoli di sola lettura accanto al controllo completo.
  • Una shell interattiva, screenshot e port forwarding verso il router o la stampante del cliente.
  • Un report prima-e-dopo da consegnare al cliente al termine della riparazione.

adb ↗libimobiledevice ↗