La tua VPN cloud dipende ancora dal provider di hosting

Hai installato il sistema operativo, rafforzato il servizio e tieni le chiavi, e comincia a sembrare che il server sia tuo. È tuo come un appartamento in affitto è tuo: la serratura è sotto il tuo controllo e l’edificio no. L’hypervisor, la rete davanti all’istanza e l’account che può ricostruire tutto appartengono a qualcun altro. Questa distinzione decide cosa deve coprire un piano di ripristino, ed è la parte che il self-hosting cambia meno.

L’account è il vero piano di controllo

Un account di hosting gestisce la macchina virtuale, i suoi dischi, gli snapshot, gli indirizzi pubblici e le regole di rete. Ognuno di questi può essere modificato senza mai accedere al guest, il che colloca l’account fuori dal modello di minaccia descritto dalla maggior parte delle guide VPN. Una configurazione di tunnel perfetta sopravvive a un’azione sull’account che sostituisce un disco.

Proteggi quell’account come un asset separato: credenziali indipendenti, secondi fattori supportati dall’hardware e una traccia di audit che qualcuno legga davvero. Condividerlo con la stessa voce del gestore di password del servizio VPN è l’errore che rende irrilevante ogni altro controllo.

Leggi la ripartizione dei compiti del provider per il prodotto specifico, non per il cloud in generale. Il modello di responsabilità condivisa è un esempio utile di come sono divisi i livelli, e altri provider descrivono i propri confini invece di ereditare quello. Quello che cerchi è quali guasti devi riparare e quali puoi solo segnalare.

Eventi di infrastruttura che non puoi amministrare

La migrazione live, la manutenzione dell’host, un guasto hardware sul nodo fisico e un evento di capacità sono tutte cose che il provider gestisce secondo il proprio calendario. Potresti vedere un riavvio, una breve perdita di pacchetti o un cambio di indirizzo, e non vedrai il motivo. Un progetto che tratta l’istanza come un punto fisso interpreterà ognuno di essi come un guasto della VPN. L’azione correttiva è rendere il servizio tollerante a un’istanza che scompare, invece di indagare su una causa che non ti verrà mai mostrata.

I backup appartengono a questo livello, non al tunnel. Conserva la configurazione del server, le identità, il piano degli indirizzi e le rotte consentite in un luogo che non dipenda dalla raggiungibilità dell’istanza, e conferma che la copia possa essere ripristinata senza il disco originale.

Il comportamento dell’indirizzo merita una verifica a sé. Se un indirizzo pubblico sopravviva a uno stop, a una sostituzione o a una cancellazione dipende da come è stato allocato, e le tre operazioni non sono intercambiabili. Annota su quale fai affidamento prima che un incidente renda urgente la domanda.

Verifica cosa sopravvive a una ricostruzione

Costruisci il percorso di ripristino mentre tutto funziona. Individua la console o l’accesso fuori banda offerto dal provider, conferma di poterla raggiungere senza il tunnel e conserva le credenziali in un posto che un portatile guasto o un telefono perso non porti via. Se una modifica locale del firewall blocca il tunnel, quella console è l’unica via di ritorno.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Il servizio di metadati risponde a domande sull’istanza che il guest non può vedere altrimenti, e i suoi percorsi esatti variano tra provider e tra piattaforme, quindi verificali con la documentazione del prodotto che esegui. Poi esegui una ricostruzione controllata di un’istanza di test e cronometrala. Una procedura di ripristino che nessuno ha eseguito è un’ipotesi.

Nota cosa ha fatto la ricostruzione all’indirizzo, alle chiavi dell’host, all’identità del disco e a tutto ciò che i client fissano. I client che hanno memorizzato una chiave dell’host si lamenteranno dopo una ricostruzione, e quella lamentela è un comportamento corretto, non un bug da silenziare.

Decidi cosa cambia realmente il self-hosting

Eseguire una VPN propria sposta la fiducia da un operatore VPN a un provider di hosting più te stesso. È un cambiamento reale, e non è lo stesso che rimuovere una terza parte. Se lo scopo era impedire a una VPN commerciale di osservare il traffico, il provider può ancora osservare la rete dell’istanza, il disco e i registri di fatturazione.

I tuoi log descrivono il tuo software e non descrivono ogni registro di infrastruttura che il provider conserva. È vero anche il contrario: la visibilità dell’infrastruttura non stabilisce cosa un provider trattenga. Entrambe le domande richiedono la policy del provider e la tua configurazione, e nessuna risponde all’altra.

Scrivi la risposta come una divisione del lavoro: quale livello ha fallito, chi può ripararlo e quanto tempo richiede quella riparazione. Il self-hosting cambia di chi ti fidi, e la parte utile dell’esercizio è sapere esattamente per quale livello ti fidi di loro.