mikrotik

MikroTik — Management VLAN via SSH

Comandi testati e funzionanti per gestire un MikroTik via SSH tramite VLAN X di management, che arriva taggata dal trunk su ether1.

Prerequisito

Esegui i comandi da una porta da cui non ti tagli fuori (porta LAN diversa da ether1, oppure console).

Comandi

# 1. Safe Mode
[Ctrl+X]

# 2. Creare il bridge
/interface bridge add name=bridge

# 3. vlanX di management sul bridge
/interface vlan add name=vlanX vlan-id=X interface=bridge
/ip address add address=XXXX/24 interface=vlanX

# 4. ether1 nel bridge
/interface bridge port add bridge=bridge interface=ether1

# 5. tabella VLAN: vlanX taggata su ether1 + alla CPU
/interface bridge vlan add bridge=bridge vlan-ids=X tagged=bridge,ether1

# 6. firewall SSH
/ip firewall filter add chain=input action=accept protocol=tcp \
  dst-port=22 in-interface=vlanX src-address=XXXX/24 comment="SSH mgmt"

# 7. filtering ON
/interface bridge set bridge vlan-filtering=yes

Sposta la regola SSH sopra il drop !LAN

/ip firewall filter print
/ip firewall filter move [numero-SSH] destination=[numero-drop-!LAN]

Test e conferma

Da un dispositivo in VLAN X: ssh admin@XXXXX

Se entra, esci dalla Safe Mode con Ctrl+X per rendere permanente.

/system backup save name=mgmt-ok
/export file=config-mgmt

MikroTik — Configurare porte ACCESS e TRUNK (riferimento)

Guida generica per configurare le porte di un bridge VLAN-aware come access (una VLAN, per un PC) o trunk (più VLAN taggate, per un apparato VLAN-aware). Sostituisci i placeholder:

1. Access vs Trunk — il concetto

ACCESS TRUNK
VLAN sulla porta una sola più di una
Tag untagged (senza tag) tagged (col tag)
Cosa colleghi un PC / dispositivo normale switch, router, AP (VLAN-aware)
PVID = la VLAN della porta 1 (neutro)

Le tre primitive:

⚠️ Sicurezza: se metti una porta access sulla VLAN di management, chi si collega lì raggiunge SSH/WinBox del router. Comodo come "porta di rientro" fidata, ma non esporla a utenti non affidabili.

2. Porta ACCESS

Un PC su etherX finisce nella VLAN <VID> senza saperlo.

Creare (VLAN nuova)

/interface bridge vlan add bridge=bridge vlan-ids=<VID> tagged=etherUP untagged=etherX
/interface bridge port set [find interface=etherX] pvid=<VID>

Aggiungere una porta access a una VLAN che ESISTE già

La VLAN c'è già in tabella → modifica (non add), aggiungendo la porta agli untagged:

/interface bridge vlan set [find vlan-ids=<VID>] tagged=etherUP untagged=etherX
/interface bridge port set [find interface=etherX] pvid=<VID>

set riscrive l'intera lista: rielenca i tagged/untagged già presenti che devono restare.

Convertire una porta da TRUNK ad ACCESS

Se la porta era tagged e la vuoi untagged:

/interface bridge vlan set [find vlan-ids=<VID>] tagged=etherUP untagged=etherX
/interface bridge port set [find interface=etherX] pvid=<VID>

(togli etherX dai tagged rielencando solo le porte da mantenere, e mettila negli untagged)

3. Porta TRUNK

Su etherX colleghi un apparato VLAN-aware. Più VLAN taggate.

Creare

# aggiungere la porta al bridge
/interface bridge port add bridge=bridge interface=etherX

# una VLAN
/interface bridge vlan add bridge=bridge vlan-ids=<VID> tagged=etherUP,etherX

# più VLAN nella stessa riga
/interface bridge vlan add bridge=bridge vlan-ids=<VID_A>,<VID_B> tagged=etherUP,etherX

# PVID neutro (di solito già 1)
/interface bridge port set [find interface=etherX] pvid=1

Aggiungere una porta a una VLAN già esistente

/interface bridge vlan set [find vlan-ids=<VID>] tagged=etherUP,etherX

⚠️ set tagged=... sovrascrive: rielenca tutte le porte da mantenere.

Native VLAN (una VLAN untagged sul trunk)

/interface bridge vlan set [find vlan-ids=<VID>] tagged=etherUP untagged=etherX
/interface bridge port set [find interface=etherX] pvid=<VID>

4. Togliere / modificare

# togliere una VLAN SOLO da una porta (riscrivi senza quella porta)
/interface bridge vlan set [find vlan-ids=<VID>] tagged=etherUP

# rimuovere una VLAN da TUTTE le porte
/interface bridge vlan remove [find vlan-ids=<VID>]

# togliere la porta dal bridge del tutto
/interface bridge port remove [find interface=etherX]

# cambiare il PVID
/interface bridge port set [find interface=etherX] pvid=1

Disabilitare (granularità)

Obiettivo Comando
VLAN off su tutto lo switch /interface bridge vlan disable [find vlan-ids=<VID>]
VLAN off solo su una porta non c'è disable per-porta: usa set togliendo la porta

5. Verifica

/interface bridge vlan print detail                    # config reale (tagged/untagged)
/interface bridge port print                           # PVID, flag hw-offload (H), inactive (I)
/interface bridge host print where interface=etherX    # MAC appresi sulla porta
/interface bridge host print where interface=etherX vid=<VID>

tagged vs current-tagged: tagged = configurato (sempre); current-tagged = attivo ora (solo porte up). Porta scollegata (I) → non appare in current-tagged ma la config c'è: guarda print detail.

Filtri host: i campi sono interface e vid, NON on-interface/vlan-id. Dopo where premi Tab per l'elenco dei campi validi.

6. Lato switch a monte (Cisco)

Ogni VLAN usata sul MikroTik deve essere allowed anche sul trunk dell'apparato a monte:

vlan <VID_A>
vlan <VID_B>
interface <porta-verso-mikrotik>
 switchport mode trunk
 switchport trunk allowed vlan add <VID_A>,<VID_B>

7. Trappole comuni (imparate sul campo)

  1. set tagged=... / untagged=... SOVRASCRIVE la lista intera — rielenca sempre le porte da mantenere, o le perdi.
  2. add di una VLAN che esiste già → failure: vlan already added, e fallisce l'INTERO comando (anche le altre VLAN della stessa riga). Se una VLAN esiste (es. la management), aggiungi la porta con set, non con add.
  3. Access = untagged + PVID. Servono entrambi: senza PVID il traffico in ingresso dal PC finisce in VLAN 1.
  4. Trunk = tagged + PVID 1. Il PVID resta neutro perché tutto viaggia taggato.
  5. VLAN di management: modificandola, mantieni sempre tagged=bridge,etherUP o perdi l'accesso. Lavora in Safe Mode (Ctrl+X).
  6. Config su entrambi i lati: la VLAN va permessa sia sul MikroTik sia sull'apparato a monte.
  7. Porta scollegata (I): verifica con print detail, non col riepilogo.

8. Chiusura (quando funziona)

[Ctrl+X]                                   # esci da Safe Mode = rende permanente
/system backup save name=porte-vlan-ok
/export file=config-porte-vlan

Scarica i file dal menu Files e conservali fuori dal router.

Guida Accesso Sicuro con Chiavi SSH — MikroTik RouterOS 7.x

Configurazione dell'autenticazione a chiave pubblica su RouterOS: più sicura delle password e ideale per automatizzare SCP/SSH verso più router da remoto.

Regola d'oro: non disabilitare mai l'accesso via password PRIMA di aver verificato al 100% che l'accesso con chiave funziona. Altrimenti rischi il lock-out, soprattutto da remoto.

1. Genera la coppia di chiavi (sul tuo PC)

ssh-keygen -t ed25519 -f ~/.ssh/mikrotik_key

Vengono creati due file:

2. Carica la chiave pubblica sul router (via SCP)

scp ~/.ssh/mikrotik_key.pub admin@<IP-router>:

Se RouterOS 7.x rifiuta la connessione per mismatch di algoritmi, abilita lo strong crypto sul router e riprova (vedi anche passo 5):

/ip ssh set strong-crypto=yes

Verifica che il file sia arrivato:

/file print

Deve comparire mikrotik_key.pub.

3. Importa la chiave su RouterOS

Collegati via SSH al router e associa la chiave pubblica all'utente:

/user ssh-keys import public-key-file=mikrotik_key.pub user=admin

Verifica che sia stata importata:

/user ssh-keys print

4. Verifica l'accesso con chiave (dal tuo PC)

ssh -i ~/.ssh/mikrotik_key admin@<IP-router>

Se entri senza che il router chieda la password (al massimo ti viene chiesta la passphrase della chiave), l'autenticazione a chiave funziona.

Non procedere al passo 5 finché questo test non riesce in modo affidabile.

5. Rafforza la sicurezza (solo DOPO aver validato il passo 4)

5.1 Strong crypto

Forza algoritmi robusti e disabilita quelli deboli/obsoleti:

/ip ssh set strong-crypto=yes

5.2 Disabilita il login con password

Da qui in poi si entra SOLO con chiave:

/ip ssh set password-authentication=no

ATTENZIONE: dopo questo comando, chi non ha la chiave non entra più via SSH. Assicurati che:

6. Rete di sicurezza (paracadute)

Con la password SSH disabilitata, se perdi la chiave privata o cambi PC senza aver configurato la nuova chiave, non entri più via SSH. Tieni quindi attivi:

Config lato client (comodità)

Nel tuo ~/.ssh/config puoi definire scorciatoie per non ripetere -i ogni volta:

Host mikrotik-sedeX
    HostName 172.17.5.116
    User admin
    IdentityFile ~/.ssh/mikrotik_key

Poi accedi semplicemente con:

ssh mikrotik-sedeX

Checklist finale

Guida Deploy Template MikroTik — RouterOS 7.x

Procedura per applicare da remoto un template di configurazione base (accesso di management via VLANX + SSH + paracadute MAC) su router MikroTik, in modo pulito e ripetibile.

Principio di fondo: il template applica solo il MINIMO per rientrare. Le VLAN dati e le regole di dettaglio si aggiungono dopo, da remoto, una volta ripreso l'accesso. Il router di prova deve avere la STESSA versione RouterOS dei router di produzione: un collaudo su versione diversa non è valido.

1. Controllo versione e (se serve) aggiornamento

1.1 Verifica la versione attuale

/system resource print

Guarda il campo version (es. 7.21.4) e architecture-name.

Controlla anche il firmware del RouterBoard:

/system routerboard print

Confronta current-firmware con upgrade-firmware: se differiscono, andrà aggiornato (passo 1.5).

1.2 Decidi la versione target

Il template va testato e applicato sulla stessa major/minor version dei router di produzione. Se la produzione è su una versione precisa (es. 7.21.4), allinea tutti i router a quella, non "all'ultima disponibile".

1.3 Aggiornamento ONLINE (se il router naviga)

Richiede connettività Internet e DNS funzionante sul router. Verifica prima:

/ping 8.8.8.8
/ping download.mikrotik.com

Se il primo va ma il secondo no, manca il DNS:

/ip dns set servers=9.9.9.9,149.112.112.112

Poi aggiorna:

/system package update set channel=stable
/system package update check-for-updates
/system package update download
/system package update install

Il comando install riavvia il router e applica la nuova versione.

Per massima stabilità si può usare channel=long-term invece di stable.

1.4 Aggiornamento OFFLINE (metodo consigliato: non dipende da Internet)

  1. Da un PC, scarica da https://mikrotik.com/download il Main package per architettura ARM della versione desiderata (file .npk).
  2. Carica il pacchetto sul router via SCP: 
    scp routeros-7.xx.x-arm.npk admin@<IP-router>:
  3. Verifica che sia arrivato: 
    /file print
  4. Riavvia: RouterOS installa il pacchetto all'avvio. 
    /system reboot
  5. A riavvio completato, verifica la nuova versione: 
    /system resource print

1.5 Aggiorna il firmware del RouterBoard (dopo l'update di RouterOS)

/system routerboard print

Se current-firmware != upgrade-firmware:

/system routerboard upgrade
/system reboot

1.6 Backup prima di operare (sempre consigliato)

/system backup save name=pre-update
/export file=config-pre-update

2. Upload del template ed esecuzione

2.2 Carica il template via SCP

Dal tuo PC:

scp template-base-mgmt.rsc admin@<IP-router>:

Se RouterOS 7.x rifiuta la connessione per mismatch di algoritmi SSH, abilita lo strong crypto sul router e riprova:

/ip ssh set strong-crypto=yes

2.3 Verifica che il file sia arrivato col nome ESATTO

Collegati via SSH al router e:

/file print

Deve comparire template-base-mgmt.rsc. Il nome deve combaciare esattamente con quello usato nel comando del passo 2.4: se non combacia, il reset azzera il router ma NON esegue lo script.

2.4 Esegui il template con reset-con-script

/system reset-configuration no-defaults=yes skip-backup=yes run-after-reset=template-base-mgmt.rsc

Il router si azzera, applica il template e si riavvia.

2.5 Riconnetti

Dopo ~1–2 minuti, riprova l'accesso all'IP di management:

ssh admin@<IP-management-sede>

Se risponde, il deploy è riuscito. Da qui completi il resto della configurazione da remoto (VLAN dati, firewall, ecc.).

Paracadute

Il template abilita MAC-Winbox su tutte le interfacce: se la VLAN/trunk non passa, chiunque sul posto con un cavo e Winbox può entrare via MAC. Il run-after-reset non ha rollback: una volta azzerato, o il template funziona o serve un intervento fisico. Per questo il collaudo in laboratorio sulla stessa versione deve essere sempre verificato al 100%.

3. Il template: spiegazione e manutenzione

3.1 Perché NON usare le variabili globali nel template

Una versione precedente usava :global e $MGMTIP in cima al file. In un file .rsc importato, l'espansione delle variabili è fragile e cambia tra versioni di RouterOS: produce errori di parsing tipo expected end of command o expected interface value. La versione con valori diretti è robusta e portabile tra versioni. Regola: nei file di configurazione da importare, usa valori diretti, non variabili.

3.2 Mantenere il template per versioni future di RouterOS

La sintassi di alcuni comandi (soprattutto bridge VLAN filtering, routing) cambia tra major version (es. v6 → v7). Per ogni nuova versione RouterOS che adotterai:

  1. Aggiorna un router di prova alla nuova versione (stessa dei futuri router di produzione).
  2. Reimporta il template a mano e verifica che non dia errori: 
    /import file-name=template-base-mgmt.rsc
    Se una riga fallisce, l'import indica riga e colonna: correggi la sintassi.
  3. Rigenera il template dal router aggiornato partendo da una config buona: 
    /export file=nuovo-template
    e ripulisci l'export tenendo solo le righe essenziali (bridge, VLAN mgmt, IP, route, DNS, mac-server), reinserendo i marcatori ### MODIFICA.
  4. Valida il run-after-reset sul banco prima di usarlo in produzione.
  5. Tieni un template per major version se gestisci un parco misto (es. template-v6.rsc, template-v7.rsc), perché la stessa sintassi non è garantita compatibile.

3.3 Checklist di collaudo prima di ogni uso in produzione