Situazione: ho una serie di router Mikrotik disseminati in giro, che cerco di tenere aggiornati in modo da evitare (noti) problemi di sicurezza.
La maggiore parte di questi router, deve garantirmi l’accesso da remoto usando OpenVPN, un sistema consolidato, ben funzionante e stabile. Da qualche tempo, il mio portatile benchè si connetta ai sistemi remoti, non “naviga” se ho impostato la VPN per fare passare tutti il traffico attraverso il tunnel cifrato.
Ieri, dopo avere faticato per fare funzionare wireguard sul sistema windows, mi sono incaponito. Devo capire dove sia il problema. Ho fatto diverse prove con wireshark, con il torch, con le configurazioni LOG del firewall… nulla. Mi sono messo a carcare su web ed ho trovato un post molto interessante: in soldoni, si dice che la VPN potrebbe non funzionare a causa di un bug firmware introdotto nelle release >7.9.2 Il bug, impedisce al SO, di creare una interfaccia dinamica alla quale associare l’ip della VPN lato “router”.
Ho deciso di dare una prova (ormai… ne ho fatte centinaia) facendo un downgrade della RB da 7.10.2 alla 7.9.2 e …. magia: tutto funziona nuovamente!
Anche questa volta, Mikrotik si è fatta odiare un po’ ma ho imparato che prima di perdere tempo, occorre cercare sui forum!!!
Ieri sera, dopo una lunga attesa, ho deciso di aggiornare il firmware della Mikrotik hAP Ac2 (RBD52G-5HacD2HnD-TC) alla versione 6.49. Ho fatto questa operazione un sacco di volte e non ho mai riscontrato problemi. Anche ieri sera, ho selezionato “Download and Install” ed ho atteso. Malgrado la lunga attesa, il sistema non è tornato disponibile. Ho provato a spegnere e riaccendere, a resettare… nulla. Ho pensato di avere bricckato la MKT, ma prima di buttarla nel cesto del “recupero componenti”, ho voluto fare una prova con “netinstall”.
Si tratta di un software che ha la funzione di bootp e consente di sfruttare il boot da rete per installare il sistema operativo su una Mikrotik, anche se winbox non la dovesse riconoscere. In pratica è la ultima spiaggia prima del ” recupero componenti”. Sapevo che questo programma fosse “ostico” da fare girare su windows ed in effetti così è stato. Malgrado i tentativi di: – disabilitare il firewall; – spegnere/disabilitare tutte le periferiche non 802.3; Non c’è stato verso di avviare il programma che risponde SEMPRE con un errore di bind(), ovvero con l’impossibilità di creare un socket. Amareggiato da questo comportamento ho fatto una prova con WINE in ambiente linux. Il programma viene eseguito ma, in questo caso, penso non gradisca la presenza di più indirizzi IP sullo stessa interfaccia BR0.
La soluzione del problema è arrivata tirando fuori, dallo scatolone dei ricordi, un vecchio adattatore USB – Ethernet della DLINK. Un oggettino del 2009 che ancora funziona. Linux lo ha riconosciuto subito, ho assegnato a questa interfaccia l’indirizzo IP 192.168.88.2 ed ho avviato la versione per linux di netinstall. Avendo preventivamente scaricato la immagine da mettere sulla Mikrotik, il processo di flash è statto “relativamente” veloce e non ha restituito alcun errore. Ho riavviato la MKT e tutto sembra funzionare correttamente.
Dopo diversi anni di attesa, sono finalmente riuscito a completare la configurazione della rete domestica ed a darle un aspetto definitivo. Premessa: il mio fornitore di servizio è un WISP della zona, che lavora molto bene ed è piuttosto “sveglio” a rispondere alle esigenze dei clienti. Malgrado questo non consente all’utente finale di accedere alla CPE, per impostare rotte personalizzate e questo è un grande limite se si vuole mettere una VPN casa-ufficio. La soluzione che ho adottato è probabilmente sub-ottima, ma funziona e consente di coprire le mie esigenze.
Topologia vecchia (SX) e nuova (DX)
A sinistra la precedente topologia, basata sul router del WISP (una ottima cambium) ed uno switch HP gigabit. Tutti i nodi domestici sono collegati allo switch. Lo spazio di indirizzi è 192.168.1.0/24. La nuova architettura di rete ha un forte vincolo: non possono rinumerare per via della presenza di sensori che hanno indirizzo IP hardcoded e non possono essere riprogrammati in tempi ragionevolmente brevi. La soluzione è stata quella di splittare lo spazio in due parti, lasciando lato WISP la parte “alta” della rete e segmentando la parte bassa con un router MIkrotik, in modo da non dovere rinumerare alcun nodo. I servizi che prima erano rediretti dal router WISP ai nodi della rete, sono interamente presi in carico dal Mikrotik, che provvede ad inviarli ai server.
La parte interessante della rete è la infrastruttura Wireless: casa è grande e per coprire bene tutto il volume, ho deciso di installare 3 AP e di coordinarne il funzionamento con una access controller. A posteriori, avrei usato volentieri Unifi che ha molte più funzionalità nei suoi AP, ma alla fine ho un funzionamento decente anche con Mikrotik. Gli apparati sono due AP “hAP ac²”ed un “hAP ac³“. I primi due sono installati nei piani 0 ed 1, mentre il terzo al piano 2 e funge da nuovo router. Su quest’ultimo è anche in esecuzione il CAPsMAN, oggetto della discussione.
La configurazione di CAPsMAN non è difficile, una volta che se ne è capita la bizzarra architettura: si tratta di una serie di moduli che devono essere personalizzati, prima di giungere ad un configurazione che può essere esportata ai dispositivi. Sezioni gerarchicamente superiori (provisioning o configuration) possono sovrascrivere alcune sezioni di configurazione In particolare: Channels: configurazione della banda operativa dell’access point e delle particolarità per ogni singolo canale. Datapaths: configurazione del modo in cui i dati sono consegnati in rete (local forward o tulle forward), della client isolation e della MTU. Security Cfg: metodo di autenticazione ed autorizzazione dei client. Access List: consentono di definire alcuni parametri, sulla base dei quali i client possono o non possono accedere alle risorse. Rates: configurazione degli MCS e dei rate.
Con queste informazioni ho creato una configurazione di sicurezza valida per tutti gli AP. Poi ho creato delle configurazioni “rates” per rimuovere 802.11b dalla banda 2.4GHz e 802.11a dalla 5GHz. La configurazione si concretizza in due “voci”, come mostrato in figura.
Configurazione dei rates
La configurazione complessiva, consta di 6 entries che possono essere “lette” in questo modo: 2G4 CH01 configurazione che assegna la banda di funzionamento 2.4GHz, con un profilo di sicurezza SecProf_01 e rate 2G4Rates ma vincola la frequenza al canale numero 1. 2G4 CH6 analoga alla precedente ma frequenza vincolata al canale 6. In questo modo, possono fare un “provisioning” bloccando la frequenza di lavoro dei singoli ap in modo da evitare sovrapposizioni ed avere un maggiore controllo sull’intero impianto. Il vantaggio di questo approccio è che modificando la configurazione sul CAPsMAN, questa si riflette sugli AP, senza richiedere intervento.
Le “configurazioni”
Il provisioning è effettuato sulla base del mac address della radio. Ci sono sicuramente modi migliori per farlo, ad esempio sfruttando il nome della radio stessa ma non sono riuscito ad ottenere i risultati attesi. Per ogni radio, viene definito un comportamento (create dynamic enabled) ed una configurazione di riferimento, in questo caso 2G4 CH01. Questo significa che alla radio identificata con questo mac, sarà associata una configurazione che la vincola a funzionare sul canale 1. Notare la “identity” nel campo “name format”, questo parametro influenza il modo in cui saranno “nominate” le Cap Interfaces ed è oggetto di ulteriore configurazione.
Provisioning basato su MAC
Selezionando la voce “Remote CAP”, sono elencati tutti i sistemi che partecipano al CAPsMAN. Facendo doppio click su uno di essi è si accede ad una finestra che mostra diverse informazioni e consente di effettuare il “set identity”, ovvero di associare una label a piacere ad ogni radio. Io ho deciso di utilizzare il piano presso il quale è installato l’AP.
Impostazione della identità
Risultati: i tre Ap lavorano su frequenze differenti sia a 5GHz che a 2.4GHz. Rimane da sanare una situazione relativa ad un sensore che richiede un AP dedicato. In tempi brevi spero di riuscire a configurare un “virtual AP” attraverso CAPsMAN in modo da sanare anche questa situazione. I livelli di segnale sono molto buoni. A 2.4GHz sono visibili 4 AP di cui, quello “inserito” sul canale 4 è in via di spegnimento.
AP 2.4GHz
In banda 5GHz, dal “letto” sono visibili 2 AP, ben differenziati in termini di potenza ricevuta.
