Server tuoi, edge in affitto

Molte piccole realtà finiscono con la stessa configurazione: la posta da un fornitore, il DNS da un altro, il sito su un page builder, il monitoraggio su una dashboard in abbonamento. Ogni servizio, da solo, costa poco ed è comodo. Messi insieme lasciano dati, configurazione e disponibilità in mano ad aziende che possono cambiare prezzi, condizioni o funzioni quando vogliono.

L'estremo opposto, fare tutto da sé compresa la protezione DDoS e una CDN globale, non è realistico. Un singolo VPS non può assorbire un attacco né servire una pagina statica da 300 città.

La divisione che funziona: lo stato sui server tuoi, l'edge senza stato in affitto. Posta, zone DNS, siti e dati stanno sulla tua macchina. Davanti metti Cloudflare, per tutto ciò che guadagna da una rete globale: spesso gratis o quasi.

Perché un server proprio

I dati restano tuoi. Caselle, zone DNS, log di accesso e database stanno su un disco che controlli tu. Sai dove sono, chi può leggerli e per quanto tempo restano. Per un'azienda europea sapere dove si trovano i dati personali è anche un obbligo del GDPR.

Niente lock-in, se scegli formati semplici. Una config di nginx, una Maildir e un file di zona BIND si leggono su qualsiasi macchina Linux. Cambiare fornitore vuol dire copiare file, non esportare da un pannello proprietario sperando che l'importazione funzioni.

Costi prevedibili. Un VPS da 4 GB costa uguale che tu ospiti un sito o venti, cinque caselle o cinquanta. Niente prezzi per utente e niente sorprese tipo "hai superato il tuo piano".

Conosci quello che usi. Quando qualcosa si rompe, puoi leggere i log. Quello che impari gestendo un server tuo serve in qualsiasi lavoro che tocca Linux.

Quanto costa davvero

Il self-hosting ha un prezzo, ed è giusto dirlo:

• Manutenzione: aggiornamenti di sicurezza, rinnovo dei certificati e spazio disco sono compito tuo.
• Backup: nessun altro tiene una copia. Se il disco muore e non hai un backup fuori sede, i dati sono persi.
• Una macchina è un solo punto di guasto: un VPS è disponibile quanto il suo fornitore e la tua configurazione.
• Esposizione: ogni porta aperta è raggiungibile da tutta internet, attacchi compresi.
• Consegna della posta: PTR, SPF, DKIM, DMARC e reputazione dell'IP sono responsabilità tua.

Quasi tutto si gestisce con buoni strumenti e qualche abitudine. Alcuni di questi punti sono proprio quelli dove l'edge aiuta.

Dove entra Cloudflare

I servizi gratuiti o economici di Cloudflare coprono quello che un singolo server fa male. Ognuno risolve un problema preciso.

Un modo sensato di usarli:

• Landing page e documentazione su Pages. L'HTML statico non ha bisogno del tuo server. Spostarlo libera risorse e toglie una cosa da tenere aggiornata.
• Siti molto visitati o esposti dietro il proxy. Cloudflare termina il TLS, mette in cache i file statici e assorbe le ondate di traffico prima che arrivino a te.
• Pannelli admin dietro Tunnel e Access. Il pannello ascolta su 127.0.0.1, cloudflared lo pubblica e Access chiede il login prima. La porta non è mai aperta su internet.
• Backup su R2. Cifrali prima (rclone con un remote crypt funziona bene), così il fornitore conserva solo dati cifrati.

Cosa deve restare diretto

Non tutto può o deve passare da Cloudflare.

• Posta. Proxy e tunnel trasportano HTTP, non SMTP. Il record MX deve puntare direttamente al server sulla porta 25, con un PTR che corrisponde all'hostname.
• SSH. Tienilo diretto, solo con chiave e limitato ai tuoi indirizzi. Se il tunnel o il tuo account Cloudflare hanno un problema, SSH è la via per rientrare.
• Un piano di uscita. Anche l'edge in affitto può diventare lock-in. Tieni documentati i record DNS e assicurati che il server possa servire il traffico direttamente, se un giorno spegni il proxy.

Per il DNS puoi fare un passo in più: tieni il tuo server autoritativo come primario nascosto e lascia che un servizio secondario risponda al mondo. Modifichi la zona sulla tua macchina, i secondari la scaricano con AXFR dopo ogni NOTIFY, e il tuo server non viene mai interrogato direttamente.

Il dettaglio che sbagliano quasi tutti: il vero IP del visitatore

Metti un proxy davanti a nginx e ogni richiesta sembra arrivare da Cloudflare. I log si riempiono di indirizzi Cloudflare, i limiti di frequenza colpiscono l'edge invece del visitatore, e fail2ban comincia a bannare Cloudflare, cioè mette offline il sito per tutti.

nginx può recuperare l'indirizzo vero con il modulo realip, fidandosi dell'header solo dagli intervalli IP di Cloudflare (pubblicati su cloudflare.com/ips-v4 e cloudflare.com/ips-v6):

# dietro il proxy di Cloudflare
set_real_ip_from 173.245.48.0/20;   # ...una riga per ogni intervallo pubblicato
real_ip_header   CF-Connecting-IP;

# dietro cloudflared sulla stessa macchina
set_real_ip_from 127.0.0.1;
set_real_ip_from ::1;
real_ip_header   CF-Connecting-IP;

Due errori da evitare:

• Fidarsi dell'header da chiunque. Chiunque potrebbe mandare un CF-Connecting-IP falso e scrivere nei tuoi log l'indirizzo che vuole.
• Lasciare aperto il server di origine. Se le porte 80 e 443 accettano connessioni da ovunque, un attaccante può saltare Cloudflare e colpire direttamente il server. Dietro il proxy, apri quelle porte solo agli intervalli di Cloudflare. Dietro il tunnel, non aprirle proprio.

Gli intervalli cambiano ogni tanto: aggiornali con un'operazione pianificata invece di copiarli una volta sola.

Un'architettura di riferimento

Il laboratorio NetForge mette tutto insieme su un VPS da 4 GB: siti statici, PHP, in reverse proxy e bilanciati, raggiunti direttamente, tramite il proxy e tramite un tunnel; posta che arriva direttamente sulla porta 25; DNS come primario nascosto con secondari pubblici; pannelli admin raggiungibili solo tramite il tunnel, e SSH diretto come accesso di emergenza.

Checklist

• Dati sul tuo server, in formati che leggi anche senza lo strumento che li ha scritti
• Backup fuori sede cifrati, verificati facendo davvero un ripristino
• Siti statici su Pages, non sul VPS
• Siti dietro proxy: realip solo dagli intervalli Cloudflare, porte dell'origine limitate a quegli intervalli
• Siti dietro tunnel: in ascolto su 127.0.0.1, nessuna porta in ingresso
• Pannelli admin dietro Access, mai pubblici
• Posta e SSH diretti, SSH solo con chiave
• Un piano di uscita, se un giorno lasci Cloudflare