Remote Access
Guida VPN IPsec Site-to-Site MikroTik
Crea una VPN IPsec site-to-site MikroTik: configura il peer IKEv2, la proposal, la policy e la regola di bypass NAT che fa funzionare il tunnel.
Riepilogo Una VPN IPsec site-to-site MikroTik cifra il traffico tra due reti intere — una sede centrale e una filiale, un NOC e un sito su torre — così gli host di ciascuna LAN raggiungono l’altra come se fosse locale. Questa guida configura entrambi i router su RouterOS v7: il peer IKEv2, l’identity con chiave pre-condivisa, la proposal di Fase 2, la policy del tunnel, la regola di bypass NAT che manda a monte quasi tutti i primi tentativi, e le regole firewall e i controlli che confermano che il tunnel è attivo.
Che cos’è una VPN IPsec site-to-site MikroTik?
Una VPN IPsec site-to-site MikroTik è un tunnel cifrato permanente tra due router che unisce due LAN separate in un’unica rete instradabile a livello 3, senza che nessuno dei due router esponga una porta di gestione su internet pubblica. A differenza delle VPN di accesso client come WireGuard o OpenVPN — dove si collega un singolo dispositivo di amministrazione — un tunnel site-to-site è sempre attivo e va da subnet a subnet: ogni host dietro il Router A raggiunge automaticamente ogni host consentito dietro il Router B. IPsec è lo strumento giusto qui perché è uno standard aperto supportato praticamente da ogni produttore di firewall e router, gira nel kernel di RouterOS con un buon throughput e su MikroTik è integrato, senza pacchetti aggiuntivi da installare.
Il tunnel si costruisce con due negoziazioni. La Fase 1 (IKE) autentica i due router tra loro e stabilisce un canale sicuro; la Fase 2 (IPsec) negozia le chiavi che cifrano davvero il traffico dati. Se entrambe le fasi coincidono ai due estremi il tunnel sale; basta un solo algoritmo diverso e fallisce in silenzio — ecco perché i passaggi seguenti mantengono i due lati simmetrici.
Prima di iniziare
Servono due router MikroTik con RouterOS v7, ciascuno con un indirizzo IP pubblico o un hostname DDNS funzionante, e due subnet LAN non sovrapposte. Questa guida usa 192.168.10.0/24 nella Sede A e 192.168.20.0/24 nella Sede B. Se entrambe le sedi usano 192.168.88.0/24, il routing è impossibile — cambia prima l’indirizzamento di un lato. Poiché IPsec è molto sensibile allo scostamento dell’orologio, abilita NTP su entrambi i router prima di cominciare; se i due estremi si disallineano, le security association scadono e il tunnel continua a cadere.
Gestire questo prerequisito su più di una manciata di sedi è già una scocciatura. Quando gestisci una flotta, MKController ti dà una console unica per verificare la versione di RouterOS e la sorgente di orario di ogni router prima di attivare un tunnel, così non devi collegarti a ogni dispositivo solo per confermare che sia pronto.
Passo 1: Creare il profilo IKE e il peer
Nella Sede A, definisci il profilo di Fase 1 e punta un peer all’indirizzo pubblico della Sede B:
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048 è il Diffie-Hellman Group 14 — un default moderno e solido. exchange-mode=ike2 seleziona IKEv2, più veloce e più robusto della vecchia modalità main/IKEv1. Entrambi gli estremi devono usare gli stessi valori di profilo e la stessa modalità di scambio.
Passo 2: Aggiungere l’identity (chiave pre-condivisa)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Usa un segreto lungo e casuale e conservalo come faresti con una chiave SSH — non in un messaggio di chat. Lo stesso segreto va su entrambi i router.
Passo 3: Definire la proposal di Fase 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048La Perfect Forward Secrecy (pfs-group) fa sì che ogni rinnovo delle chiavi usi materiale crittografico nuovo, così una chiave compromessa non espone mai il traffico passato. Come per la Fase 1, gli algoritmi devono coincidere ai due estremi.
Passo 4: Creare la policy del tunnel
La policy dice a RouterOS quale traffico cifrare — dalla LAN locale alla LAN remota:
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encrypttunnel=yes è ciò che rende la connessione site-to-site anziché host-to-host: i pacchetti originali vengono incapsulati per intero, così le due LAN comunicano in modo trasparente.
Passo 5: Aggiungere la regola di bypass NAT (il passaggio che tutti dimenticano)
È qui che si rompono quasi tutti i primi tentativi. Il tuo router ha già una regola di masquerade che riscrive l’indirizzo sorgente del traffico LAN in uscita. Se scatta prima di IPsec, l’estremo remoto riceve pacchetti la cui sorgente non corrisponde più alla policy e li scarta. Aggiungi una regola di accept sopra il masquerade così il traffico diretto al tunnel salta il NAT:
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0 mette la regola in cima alla chain srcnat, ed è obbligatorio — una regola di bypass posizionata dopo il masquerade non serve a nulla.
Passo 6: Aprire il firewall e verificare
Consenti le porte IKE e NAT-T più il protocollo ESP nella chain input così il tunnel può stabilirsi, soprattutto se una delle due sedi si trova dietro un altro dispositivo NAT:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptPoi conferma che il tunnel sia attivo:
/ip ipsec active-peers print/ip ipsec policy printUn tunnel in salute mostra un peer attivo e una policy il cui ph2-state riporta established. Un rapido ping da un host di una LAN verso un host dell’altra dimostra la raggiungibilità end-to-end.
Replicare la configurazione sulla Sede B
Ripeti ogni passaggio nella Sede B con gli indirizzi invertiti: il peer punta all’IP pubblico della Sede A, e la policy e il bypass NAT usano src-address=192.168.20.0/24 e dst-address=192.168.10.0/24. Il profilo, la proposal, il segreto dell’identity e la modalità IKEv2 restano identici. Quando i due lati coincidono, la Fase 1 e la Fase 2 si completano e il tunnel sale.
Consigli di sicurezza e operativi
Tieni RouterOS aggiornato — le release recenti hanno introdotto correzioni che toccano la verifica dei certificati peer di IPsec/IKEv2, quindi un tunnel che funzionava lo scorso trimestre merita un nuovo test dopo ogni aggiornamento. Preferisci IKEv2 con PFS ai default della vecchia IKEv1. Dove puoi, passa dalla chiave pre-condivisa all’autenticazione con certificati man mano che i tunnel crescono di numero, perché una sola chiave pre-condivisa trapelata coinvolge tutte le sedi che la condividono. E registra lo stato del tunnel in un posto che guardi davvero: un collegamento site-to-site morto è invisibile finché qualcuno non prova a raggiungere la LAN remota e non ci riesce.
Su una flotta, un tunnel IPsec che cade in silenzio dopo un disallineamento dell’orologio o un’instabilità della WAN è esattamente il tipo di guasto che il cliente nota prima di te. MKController colma quel divario: sorveglia ogni router tramite un tunnel sicuro in uscita che non richiede IP pubblico né port forwarding sul dispositivo, mantiene backup versionati della configurazione così puoi confrontare e ripristinare un blocco IPsec funzionante dopo una modifica sbagliata, e può aprire un ticket su un evento di link-down prima che squilli il telefono. Per la configurazione del tunnel in sé, la nostra guida sul NAT su MikroTik spiega la regola di masquerade che qui stai bypassando, e per raggiungere un singolo router invece di unire due LAN, vedi la gestione remota dietro CGNAT e il nostro tutorial sulla gestione remota con WireGuard.
Riunisci i tuoi tunnel sotto un unico tetto
IPsec unisce due sedi in modo pulito, ma un ISP o un MSP in crescita si ritrova presto con decine di tunnel, chiavi e regole firewall da tenere allineati — e ogni modifica manuale è un’occasione per chiudersi fuori da una sede remota. MKController è costruito esattamente per questa scala: gestione centralizzata della flotta, accesso remoto sicuro senza porte esposte, cronologia delle configurazioni e backup, e push su tutta la flotta di modifiche a firewall e policy, così un template di tunnel si distribuisce una volta sola invece di essere riscritto router per router. Gli operatori che gestiscono MikroTik su larga scala lo usano per trasformare un pomeriggio perso in SSH su ogni dispositivo in pochi clic per modifica.