L2 tunnel per il Disaster Recovery: la guida completa

TL;DR

Un tunnel Layer 2 è una connessione che estende la rete del cliente nel cloud preservando broadcast domain, MAC e IP. In un Disaster Recovery questo significa che la VM in cloud parte con lo stesso indirizzo IP della macchina fisica originale. Niente DNS da cambiare, niente NAT, niente VPN da configurare. Il dividendo è enorme: RTO che scende da ore a minuti e applicazioni legacy che restano funzionanti senza ricompilarle.

Cosa è (davvero) un tunnel Layer 2

Le reti dati si parlano a livelli. Il Layer 2 è il livello in cui circolano i frame ethernet, quelli che hanno indirizzi MAC e che permettono ai dispositivi sulla stessa LAN di "vedersi" tramite ARP. Il Layer 3 è dove vivono gli indirizzi IP e dove i router decidono come mandare i pacchetti fra reti diverse.

Un tunnel Layer 2 fa una cosa apparentemente magica: prende i frame ethernet di una rete remota e li trasporta — incapsulati e cifrati — su Internet, in modo che dall'altra parte arrivino come se i dispositivi fossero connessi allo stesso switch fisico. Tecnologie classiche dietro: VXLAN, Geneve, EVPN.

Per il DR significa che la VM in cloud sta sulla stessa subnet della LAN del cliente. Stesso /24, stesso default gateway, stesso ARP space. ARP risolve, DHCP funziona, il vecchio gestionale che pinga 192.168.10.5 trova davvero quell'IP — solo che ora "192.168.10.5" è una VM nel datacenter Sefthy, non più il server fisico in azienda.

Cosa cambia rispetto al DR Layer 3 classico

Una VPN site-to-site classica lavora a Layer 3. La VM in cloud ha un IP nuovo (ad esempio 10.99.0.5), e ai client locali (192.168.10.x) deve arrivare attraverso una VPN con NAT.

I problemi che emergono in pratica:

• Riconfigurazione DNS: i record A interni vanno cambiati. TTL altri = propagazione lenta = chiamate di aiuto durante l'emergenza.
• App con IP cablati: gestionali, stampanti di rete, software industriale. Pre-2010 = quasi sempre IP scritti nel codice.
• Firewall del cliente: regole pensate per IP locale vanno riadattate per IP cloud.
• Re-autenticazione: alcuni servizi (Active Directory in primis) reagiscono male a un IP che salta.

Tutto questo, sommato sotto stress, aggiunge 30-90 minuti all'RTO reale. Il tunnel L2 li elimina.

Anatomia del Sefthy Connector

Il pezzo che rende possibile l'L2 tunnel è un piccolo apparato (NanoPi R3S LTS in case CNC alluminio) che il cliente collega alla propria LAN. Il Connector:

• stabilisce un tunnel cifrato in uscita verso il datacenter Sefthy (porte standard, no inbound rules);
• incapsula il traffico ethernet della LAN locale e lo trasporta al datacenter;
• nel datacenter il traffico viene de-incapsulato e fatto arrivare alla VM ricoverata;
• gestisce ARP proxy e MAC learning per evitare loop e segnali dal lato cloud.

Il Connector è completamente trasparente per la rete del cliente: non serve cambiare niente nei firewall, nei router o nelle policy di rete.

I quattro casi d'uso dove l'L2 tunnel cambia tutto

1. Failover di gestionali con IP cablati

Software italiano pre-2010 (gestionali contabili, software industriale, sistemi di controllo accessi) ha quasi sempre IP scritti nel codice o in file di config. Con un L2 tunnel non li tocchi: la VM ricoverata usa lo stesso IP.

2. Active Directory e server di posta

Cambiare l'IP di un Domain Controller è una procedura non banale. Con L2 tunnel il DC ricoverato ha lo stesso IP, le repliche fra siti non si rompono, i client si autenticano subito.

3. Stampanti, NAS, dispositivi IoT

Dispositivi configurati staticamente con un default gateway preciso sono il caso classico in cui Layer 3 fallisce. L2 tunnel li ignora completamente: tutto resta come prima.

4. Test DR senza stress operativo

Un test di failover L2 può essere eseguito senza disturbare la produzione: la VM di test ottiene un IP diverso ma resta sullo stesso broadcast domain, quindi gli amministratori possono verificare la sua raggiungibilità con strumenti standard.

Sicurezza dell'L2 tunnel Sefthy

Il tunnel L2 di Sefthy ha tre livelli di protezione:

• Cifratura: tutto il traffico viene cifrato in uscita dal Connector (TLS 1.3, autenticazione mutua via certificati X.509).
• Segregazione tenant: ogni cliente ha il suo tunnel logico isolato; non è tecnicamente possibile per il traffico di un cliente raggiungere un altro tenant.
• Audit: ogni sessione di tunnel produce log esportabili (utili per ISO 27001 e NIS2).

L'attacco del tipo "intercetto il traffico fra Connector e datacenter" è bloccato dalla cifratura. L'attacco del tipo "manometto il Connector fisico" richiede accesso fisico all'apparato.

Latenza e performance

Domanda frequente: un L2 tunnel non aggiunge latenza?

Risposta breve: sì, ma poco. Misurazioni reali su connettività FTTH italiana 2.5 Gbps mostrano:

• latenza Connector → datacenter Sefthy (Milano-Bari): 8-14 ms;
• throughput sostenuto: 800-1500 Mbps simmetrici;
• jitter: < 2 ms.

Per il 95% delle applicazioni di linea (gestionali, ERP, posta, file server) questo è invisibile all'utente. Per VoIP e desktop remoto serve verificare caso per caso.

Quando l'L2 tunnel non è la scelta giusta

Onesti: l'L2 tunnel non è universalmente il top.

• Workload puramente cloud-nativi: se l'app è già stateless e gira in container, Layer 3 standard è più semplice.
• Latenza sub-millisecondo richiesta: trading ad alta frequenza, simulazioni real-time. Un L2 cloud non basta.
• Banda dati limitata fra sito e cloud: con < 50 Mbps simmetrici il tunnel diventa un collo di bottiglia.

Per tutto il resto — il 90% delle PMI e dei MSP italiani — l'L2 tunnel è il salto qualitativo più grande che si possa fare in un progetto DR.

FAQ

Il Connector apre porte in entrata sul firewall del cliente?

No. Tutto il traffico è in uscita dal Connector verso il datacenter. Nessuna regola di firewall in entrata da configurare.

Quanti Connector servono per più sedi?

Uno per sede. I tunnel sono indipendenti e Sefthy gestisce eventuali conflitti di subnet con politiche di routing dedicate.

Funziona dietro NAT del provider (CGNAT)?

Sì. Il tunnel parte sempre dal Connector verso l'esterno, quindi CGNAT e firewall ISP non sono un problema.

L'L2 tunnel sostituisce la VPN aziendale?

No, ma ne riduce l'utilità in DR. Per accesso remoto degli utenti normali, la VPN aziendale resta utile.

Vuoi capire come si configura un L2 tunnel multi-sito? Leggi L2 tunnel multi-sito o il deep-dive sul Connector hardware.