Stesso IP nel cloud: come funziona davvero

TL;DR

Il "stesso IP" nel cloud non è marketing: è il risultato di un tunnel L2 con ARP proxy che fa apparire la VM in cloud come se fosse fisicamente sulla LAN del cliente. Walkthrough tecnico con tracce ARP.

Lo scenario

Cliente con LAN 192.168.10.0/24:

• ERP fisico: 192.168.10.50
• File server: 192.168.10.60
• Default gateway: 192.168.10.1

Disaster: ERP fisico down. Sefthy attiva la VM cloud.

Quello che succede a livello di pacchetti

Senza L2 tunnel (Layer 3 classico)

1. Client interno fa ping 192.168.10.50.
2. ARP request: "chi è 192.168.10.50?"
3. Nessuno risponde (la macchina fisica è down).
4. Timeout. Errore.

Il client deve essere riconfigurato per usare il nuovo IP cloud (es. 10.99.0.50).

Con L2 tunnel Sefthy

1. Client interno fa ping 192.168.10.50.
2. ARP request: "chi è 192.168.10.50?"
3. Il Connector Sefthy sulla LAN risponde con il MAC della VM in cloud.
4. Pacchetti vengono incapsulati dal Connector, inviati nel tunnel cifrato al datacenter Sefthy.
5. Nel datacenter, il pacchetto è de-incapsulato e consegnato alla VM.
6. La VM risponde, il pacchetto torna indietro nel tunnel.
7. Il client riceve risposta come se la VM fosse "in casa".

Tutto in trasparenza. Zero riconfigurazione.

ARP proxy: il trucco invisibile

Il Connector funziona come un "ARP proxy": risponde alle ARP request per gli IP che sono stati ricoverati in cloud, sostituendosi alla macchina fisica down.

Non ci sono modifiche al firewall del cliente, al DNS, alle policy di rete. Da fuori sembra che la macchina fisica sia tornata operativa.

La gestione del fail-back

Quando il primario torna online, la procedura inversa:

1. Sefthy sospende l'ARP proxy per quell'IP.
2. La macchina fisica risponde di nuovo agli ARP.
3. I client riconnettono al primario.
4. La VM cloud viene spenta o messa in standby.

Tutto orchestrato dal Console Sefthy.

Il dettaglio sulla cifratura

I frame ethernet incapsulati nel tunnel sono cifrati TLS 1.3 con autenticazione mutua via certificati X.509. Anche se qualcuno intercetta il traffico fra Connector e datacenter, vede solo cifrato.

Limitazioni

• IP duplicati: se un'altra macchina sulla LAN ha lo stesso IP della VM ricoverata, conflitto. Va gestito in fase di setup.
• Multi-cast complesso: alcuni protocolli multi-cast pesanti (es. IPTV in alta definizione) hanno overhead.
• Latenza: 8-15 ms aggiunti, irrilevanti per il 95% delle app.

FAQ

Funziona anche con DHCP?

Sì. La VM cloud ottiene l'IP statico configurato per l'origine; non serve DHCP.

Posso "vedere" il traffico nel tunnel?

Solo voi, dal vostro Connector. Sefthy non ispeziona il contenuto.

Per il pillar L2, L2 tunnel per il DR. Per VPN vs L2, VPN tradizionale vs L2 tunnel.