Onboarding massivo via WinBox: portare in gestione anche gli apparati che SSH non raggiunge

Chiedi a un ISP quanti apparati MikroTik ha in campo e ti dara' un numero. Chiedigli quanti ne ha in gestione centralizzata e il numero diventa piu' piccolo. La differenza fra i due non e' pigrizia: sono gli apparati installati anni fa, presso il cliente finale, dove SSH non e' stato abilitato o e' stato chiuso, e che oggi si raggiungono solo con WinBox.

Sono apparati che funzionano. Non danno problemi finche' non ne danno uno. E quando lo danno, non hai backup della configurazione, non sai su che versione di RouterOS stanno, e la diagnostica la fai collegandoti a mano.

Il costo di quella differenza

Portare in gestione un apparato alla volta significa: aprire WinBox, autenticarsi, lanciare lo script di onboarding, verificare, passare al successivo. Cinque minuti per apparato quando va bene. Su duecento apparati sono piu' di due giornate di lavoro di un tecnico che potrebbe fare altro, e su un parco piu' grande il conto non torna piu': il progetto si rimanda, e gli apparati restano fuori.

Il paradosso e' che l'automazione esiste da anni, ma presuppone SSH. Tutti gli strumenti di provisioning, i nostri compresi, aprono una sessione SSH e da li' lavorano. Se SSH non c'e', l'automazione non parte e si torna al lavoro manuale.

WinBox non e' solo un'interfaccia grafica

La porta 8291, quella di WinBox, non espone soltanto la GUI. Espone anche una sessione terminale RouterOS completa: la stessa che si apre con "New Terminal" dentro WinBox, cifrata, con la sua autenticazione.

Questo cambia il problema. Se su quella porta si possono eseguire comandi, allora un apparato raggiungibile via WinBox e' un apparato automatizzabile. Non serve abilitare SSH prima, e non serve un tecnico che ci vada sopra a mano.

Come funziona in pratica

Si carica un CSV con la lista degli apparati: indirizzo, credenziali, e se il nome non lo conosci lo lasci vuoto, che viene letto dal system identity dell'apparato stesso.

Da li' il sistema fa tre cose per ogni riga, in parallelo:

Sceglie il canale da solo. Prova SSH. Se SSH non risponde, passa a WinBox. Nessuno deve decidere apparato per apparato, e nel resoconto vedi quale canale e' stato usato per ognuno. Se sai già che un apparato ha SSH chiuso, puoi dichiararlo nel CSV e il tentativo inutile non viene nemmeno fatto: su parchi grandi, dove SSH e' filtrato invece che chiuso, quel tentativo costa un timeout per ogni apparato.

Verifica prima di scrivere. Legge identita', versione e device-mode di ogni apparato e ti dice quali sono onboardabili e quali no, prima di iniziare. Serve perche' esiste una categoria di apparati su cui l'onboarding non e' eseguibile per scelta di fabbrica: quelli in device-mode home hanno fetch e scheduler disabilitati, e riabilitarli richiede accesso fisico all'apparato. Non e' aggirabile da remoto, con nessun canale. Meglio saperlo prima e metterli da parte, che scoprirlo a campagna iniziata.

Esegue e riporta. Crea il device sulla piattaforma, recupera lo script di onboarding e lo esegue sull'apparato. Se qualcosa non va, il messaggio dice cosa e' andato storto su quell'apparato specifico, e puoi ritentare solo quello.

RouterOS 6 e 7

Il parco reale non e' omogeneo. Accanto agli apparati recenti ci sono quelli installati anni fa, ancora su RouterOS 6, che nessuno ha aggiornato perche' funzionano.

Su quella major cambiano cose che contano: la sintassi dei comandi con le barre non esiste, il terminale si comporta in modo diverso, e alcuni menu presenti sulla 7 non ci sono affatto. Sono differenze che si scoprono solo provando su apparati veri. Il supporto alla 6.x e' stato verificato su RouterOS 6.49, non dedotto dalla documentazione.

Le credenziali restano dove sono

C'e' un dettaglio che conta piu' di quanto sembri: lo strumento gira nella rete di chi lo usa, come container sul PC del tecnico.

Non e' solo una questione di connettivita' (gli apparati dei clienti finali spesso sono raggiungibili solo da li'). E' anche il motivo per cui le credenziali degli apparati non lasciano quella rete: restano nel container, cifrate, e non vengono caricate sulla piattaforma. Su un parco di clienti terzi, la differenza fra "le credenziali le tengo io" e "le carico su un servizio" non e' un dettaglio tecnico.

E se hai sbagliato

Ogni onboarding e' reversibile. Lo strumento sa disfare quello che ha scritto: rimuove dal router gli oggetti creati, ripristina i servizi come stavano, e cancella il device dalla piattaforma.

Prima di toccare qualcosa ti mostra l'elenco puntuale di cosa rimuoverebbe, apparato per apparato, e agisce solo dopo la tua conferma. Non e' prudenza di facciata: rimuove solo gli oggetti riconoscibili come propri, mai a peso, perche' su un apparato in produzione cancellare alla cieca vorrebbe dire cancellare la configurazione del cliente.

Cosa cambia davvero

Non e' una funzione che fa una cosa nuova. E' una funzione che rimuove un presupposto: che per automatizzare un apparato MikroTik serva SSH.

Il risultato pratico e' che il progetto "portiamo in gestione anche il vecchio parco" smette di essere un preventivo di giornate-uomo e diventa un CSV da caricare.