Vai al contenuto 
Vi mostrerò come potete rete hetzner e configurarlo correttamente per aumentare le prestazioni, la sicurezza e la scalabilità in modo mirato. L'approccio è pratico: dal pannello cloud e dalle varianti di routing agli IP di failover, ai MAC virtuali, all'IPv6, alla sicurezza, alla diagnostica dei guasti e al monitoraggio.
Punti centrali
- Spazio indirizzi scegliere: Utilizzare la RFC 1918 in modo pulito, pianificare sottoreti pulite.
- Modalità determinare: Routed, Bridge o vSwitch a seconda dell'applicazione.
- Linux-Impostazione: ifupdown, netplan, systemd-networkd mantengono la coerenza.
- Failover & MAC: assegnare correttamente i MAC virtuali, impostare le rotte degli host.
- Sicurezza Monitoraggio: stabilire la segmentazione, i firewall, i log e i controlli.
Nozioni di base sulla configurazione della rete Hetzner
Una pianificazione adeguata evita spese successive e offre vantaggi tangibili. Prestazioni. Separo i sistemi interni in una rete cloud separata, isolo i componenti sensibili e mantengo il vettore di attacco pubblico di dimensioni ridotte, riducendo al minimo i rischi per la salute. Sicurezza è aumentata in modo significativo. Le reti private nel Cloud Hetzner mi consentono un controllo granulare, percorsi chiari per i flussi di dati e meno rumore di trasmissione. Definisco fin dall'inizio quali server hanno bisogno di indirizzi pubblici e quali parlano solo internamente, in modo che il routing, i firewall e l'allocazione degli IP rimangano logici. Questa chiarezza si ripaga quando entrano in gioco failover, bilanciatori di carico o orchestrazione di container e devo gestire più server. Sottoreti organizzato in modo chiaro.
Hetzner Cloud-Panel: creare la rete e selezionare lo spazio degli indirizzi
Nel pannello cloud, creo una nuova rete, assegno un nome univoco per ogni progetto e seleziono un intervallo di indirizzi RFC 1918, come 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16 come indirizzo Blocco IP. Pianifico le sottoreti in una fase iniziale, come /24 per i livelli delle applicazioni, /28 per l'accesso all'amministrazione o /26 per i database, in modo che la crescita rimanga mappata in modo pulito. In seguito integro server, bilanciatori di carico e servizi aggiuntivi in modo che la comunicazione sia stabilita immediatamente. Per i neofiti della piattaforma, sono lieto di fornire il compatto Panoramica dei server cloudche riassume le opzioni più importanti. Non appena la rete è pronta, verifico l'accessibilità di base e controllo i gruppi di sicurezza in modo da non lasciare aperte porte non necessarie e da non lasciare aperte le mie porte di accesso. Firewall-Si applicano le regole.
Progettazione di sottoreti e pianificazione IP in dettaglio
Lavoro con convenzioni chiare di denominazione e numerazione in modo da poter riconoscere intuitivamente le sottoreti in seguito. A ogni zona (ad esempio, app, db, mgmt, edge) viene assegnato un intervallo di numeri fisso e una dimensione standard documentata. Riservo deliberatamente delle aree cuscinetto tra le sottoreti per consentire estensioni senza rinumerazione. Quando i servizi scalano orizzontalmente, preferisco pianificare diverse /25 o /26 invece di una grande /22; in questo modo mantengo le ACL e le rotte snelle. Mantengo un /28 di gestione separato per l'accesso dell'amministratore, che indurisco in modo coerente e rendo accessibile tramite VPN o host bastion. Quando collego sedi esterne, definisco fin dall'inizio aree chiare e non sovrapposte e imposto percorsi statici specifici in modo che non ci siano conflitti.
Routed, Bridge o vSwitch: la modalità giusta
Mi concentro su tre varianti principali: Instradamento per le sottoreti aggiuntive e gli indirizzi di failover, il bridge se gli ospiti devono agire come propri server e il vSwitch per le configurazioni flessibili e il NAT. Con il modello routed, gli indirizzi aggiuntivi sono collegati al MAC principale dell'host; attivo l'inoltro IP per IPv4 e IPv6 e imposto i percorsi dell'host verso il gateway. Con Bridge, gli ospiti richiedono un MAC visibile nella rete; richiedo un MAC virtuale per ogni IP assegnato e lo collego all'ospite. Combino vSwitch con il masquerading in modo che le macchine virtuali con indirizzi privati possano accedere a Internet mentre i servizi interni rimangono protetti. Questa selezione controlla gli sforzi successivi, Trasparenza e la tolleranza ai guasti della mia piattaforma.
| Modalità | Utilizzo | Prerequisiti | Vantaggi | Pericoli di inciampo |
|---|---|---|---|---|
| Instradamento | Subnet aggiuntive, IP di failover | Inoltro IP, percorso host | Percorso chiaro, buono Scala | Mantenere il percorso gateway/host in modo pulito |
| Ponte | Ospiti come "propri server" | MAC virtuale per IP | Visibilità reale per ospite | Gestione del MAC nel Robot necessario |
| vSwitch + NAT | Macchine virtuali private con Internet | Masquerading, Firewall | Elevato isolamento interno | Mantenere correttamente le regole NAT |
Configurazioni ibride: cloud, dedicato e transizioni
Negli ambienti ibridi, collego le reti cloud con i server dedicati tramite istanze di router esplicite. Una sottorete di transito chiaramente definita e percorsi statici assicurano che entrambe le parti vedano solo i prefissi richiesti. A seconda dei requisiti di sicurezza, permetto al traffico di passare attraverso un'istanza edge tramite NAT o di instradare le sottoreti in modo trasparente. È importante che il gateway sia progettato per l'alta disponibilità, ad esempio con due macchine virtuali del router che controllano lo stato dell'altro e subentrano senza problemi in caso di guasto. Ho anche una lista di controllo pronta: le rotte nel pannello del cloud sono corrette, l'inoltro è attivo, gli stati del firewall sono coerenti e i controlli di salute controllano non solo ICMP ma anche le porte rilevanti.
Configurazione di Linux: utilizzare correttamente ifupdown, netplan e systemd-networkd
Sotto Debian/Ubuntu con ifupdown, memorizzo la configurazione in /etc/network/interfaces o in /etc/network/interfaces.d e mantengo il file Percorso dell'host corretto. Per l'indirizzamento IP dell'host uso /32 (255.255.255.255) e imposto il gateway come pointopoint in modo che il kernel conosca il vicino. In netplan (Ubuntu 18.04, 20.04, 22.04) definisco indirizzi, rotte e on-link in modo che la rotta predefinita corrisponda immediatamente. Se cambio l'hardware, controllo la designazione dell'interfaccia e la cambio da eth0 a enp7s0, per esempio, in modo che la scheda di rete torni a funzionare. Per systemd-networkd, gestisco i file .network e .netdev, ricarico i servizi e poi verifico sempre il DNS, il routing e la rete. Connettività.
Messa a punto della rete: MTU, offloading, policy routing
Controllo l'MTU end-to-end, soprattutto quando entrano in gioco VPN, overlay o tunnel. Se i valori non sono corretti, si verificano frammentazioni o cadute. Attivo il TCP MTU probing sui gateway e imposto MSS clamp in punti adeguati per mantenere solide le connessioni. Uso deliberatamente le funzioni di offloading (GRO/LRO/TSO): le disattivo parzialmente sugli hypervisor o per la registrazione dei pacchetti, ma le lascio attive per i percorsi dati puri, a seconda dei valori misurati. Se ho diversi upstream o politiche di uscita differenziate, utilizzo un routing basato su policy con tabelle di routing e regole ip personalizzate. Documento ogni regola speciale in modo che le modifiche successive non provochino effetti collaterali inosservati.
IP di failover, MAC virtuali e bilanciatori di carico in pratica
Per gli IP aggiuntivi che applico nella sezione Robot Hetzner per indirizzo di un'unità virtuale MAC e li assegno al guest in modo che ARP funzioni correttamente. Nella configurazione instradata, il MAC principale rimane sull'host e instrado esplicitamente le sottoreti al guest. Negli scenari bridge, al guest viene assegnato il proprio MAC visibile, in modo che agisca come un server indipendente. Per il failover, definisco quale macchina annuncia attualmente l'IP; quando si cambia, regolo il routing e, se necessario, l'ARP gratuito in modo che il traffico arrivi immediatamente. Uso i bilanciatori di carico per disaccoppiare il traffico del front-end dai sistemi del back-end, garantire una distribuzione uniforme e quindi aumentare il rendimento del sistema. Disponibilità.
Design pulito delle commutazioni IP
Mi affido a meccanismi chiari per le commutazioni attive: o l'istanza attiva annuncia un IP tramite ARP/NDP e quella passiva rimane in silenzio, oppure estraggo specificamente la rotta predefinita verso la nuova macchina attiva. Strumenti come le implementazioni VRRP aiutano, ma io verifico sempre l'intera interazione, compresi i firewall, le cache dei vicini e le possibili tempistiche ARP. Importante: dopo lo switch, verifico l'accessibilità sia dalla rete interna che da punti di test esterni. Per i servizi con molte connessioni TCP, programmo brevi periodi di tolleranza in modo che le sessioni aperte scadano in modo pulito o vengano ristabilite rapidamente.
Configurare IPv6: Implementare il dual stack in modo pulito
Attivo l'IPv6 in parallelo con l'IPv4, in modo che i clienti possano utilizzare i moderni Connettività e i firewall sono duplicati. Per ogni interfaccia, imposto i prefissi assegnati, il percorso del gateway e verifico il rilevamento dei vicini e l'assegnazione statica o SLAAC. Verifico se i servizi devono ascoltare su :: e 0.0.0.0 o se hanno senso i binding separati. I test con ping6, tracepath6 e curl tramite record AAAA mi mostrano se il DNS e il routing sono corretti. Nei firewall, faccio un mirroring delle regole per IPv4 su IPv6, in modo da non lasciare spazi vuoti e da poter usare le stesse regole per IPv4 e IPv6. Livello di sicurezza raggiungere.
Sicurezza: segmentazione, regole, hardening
Segmento le reti in base alle funzioni, come app, dati, gestione e transizioni sicure con un chiaro ACL. Ogni reparto ottiene solo l'accesso di cui ha bisogno, mentre l'accesso dell'amministratore avviene tramite VPN o host bastion. I firewall bloccano tutto il traffico in entrata per impostazione predefinita, poi autorizzo porte specifiche per i servizi. Proteggo SSH con chiavi, controlli delle porte, limiti di velocità e blocco opzionale delle porte per invalidare le scansioni. Collaudo le modifiche in modo controllato, le documento immediatamente e faccio un rollback rapido in caso di problemi, in modo che il sistema sia in grado di funzionare. Sicurezza operativa rimane elevato.
Orchestrare i firewall del cloud e degli host
Combino firewall cloud e regole basate sull'host. I primi mi forniscono un livello centrale che limita in modo affidabile l'accesso di base, mentre le seconde proteggono i carichi di lavoro in modo granulare e possono essere modellizzate. La coerenza è importante: le porte standard e l'accesso alla gestione ricevono regole identiche in tutte le zone. Mantengo i criteri di uscita restrittivi, in modo da poter raggiungere solo gli obiettivi definiti. Per gli ambienti sensibili, utilizzo anche host di salto con accesso di breve durata e protezione a più fattori. Metto in relazione i log a livello centrale per comprendere rapidamente i blocchi e ridurre i falsi allarmi.
Risoluzione dei problemi: riconoscere rapidamente gli errori più comuni
Se un server non ha rete dopo uno swap, per prima cosa verifico il nome dell'interfaccia e regolo il parametro Configurazione on. Se l'instradamento non funziona, riattivo l'inoltro IP e controllo i percorsi degli host e il gateway predefinito. Gli errori di digitazione degli indirizzi, delle netmask o degli on-link sono spesso causa di irraggiungibilità; confronto le rotte configurate e quelle effettive del kernel. In caso di problemi di bridge, controllo i MAC virtuali e le tabelle ARP per assicurarmi che le mappature siano corrette. I registri in /var/log/syslog, journalctl e dmesg mi forniscono informazioni sui driver, sugli errori DHCP o sui blocchi. Pacchetti.
Risoluzione sistematica dei problemi e diagnostica del pacchetto
- Controllo del livello: Link up, velocità/duplex, stato di VLAN/bridge, poi IP/route, quindi servizi.
- Confronto effettivo/target: indirizzo ip/rotta/regola rispetto ai file di configurazione, registrare gli scostamenti per iscritto.
- Registrazione dei pacchetti: mirata all'interfaccia e all'host, osservazione dell'offloading, verifica di TLS-SNI/ALPN.
- Controllo incrociato: test da più fonti (interne/esterne) per rilevare problemi asimmetrici.
- Capacità di rollback: pianificare un percorso di ritorno definito prima di ogni modifica.
Impostare il monitoraggio, la documentazione e la scalabilità in modo mirato
Monitoro la latenza, la perdita di pacchetti e il jitter con controlli ICMP, controlli delle porte e analisi dei flussi, in modo da poter rilevare precocemente le anomalie e Tendenze riconoscere. Eseguo il backup delle versioni degli stati di configurazione, descrivo le modifiche con precisione e tengo pronti i playbook. Per i record DNS e per le convenzioni di denominazione pulite, uso il compatto Guida DNSin modo che i servizi siano sempre risolvibili. Man mano che la piattaforma cresce, espando le sottoreti, aggiungo altri bilanciatori di carico e standardizzo i gruppi di sicurezza. Questo mi permette di scalare in modo sicuro, ridurre al minimo le interruzioni e mantenere chiari gli standard di sicurezza. Strutture.
Automazione: Terraform, Ansible e rollout coerenti
Costruisco reti riproducibili: Nomi, sottoreti, rotte, firewall e assegnazioni di server sono mappati come codice. Questo mi permette di creare topologie di staging e di produzione identiche, di testare le modifiche in anticipo e di ridurre gli errori di digitazione. A livello di host, genero file di configurazione da modelli e inietto parametri come IP, gateway, rotte e MTU per ruolo. Uso Cloud-init per impostare la rete e le basi SSH direttamente durante il provisioning del server. Quando apporto delle modifiche, le convalido prima in staging, poi le metto in funzione in piccoli lotti e tengo sotto controllo la telemetria.
Gestione del cambiamento e delle capacità
Pianifico le finestre di manutenzione e definisco i livelli di fallback. A ogni modifica della rete viene assegnato un piccolo piano di test con punti di misurazione prima/dopo la modifica. Per quanto riguarda la capacità, esamino il throughput per zona, i carichi di connessione ai gateway e lo sviluppo delle connessioni al minuto. Aggiungo subito altri gateway o separo i percorsi del traffico (est/ovest rispetto a nord/sud) prima che si verifichino colli di bottiglia. Mantengo aggiornata la documentazione: Piani IP, schizzi di instradamento, politiche e responsabilità del firewall sono aggiornati e facilmente reperibili dal team.
Confronto tra fornitori per progetti ad alta intensità di rete
Valuto i fornitori in base alla connessione, alla gamma di funzioni, all'usabilità e alla Flessibilità. Per i progetti con elevati requisiti di rete, metto webhoster.de al primo posto per le sue reti dedicate e la versatile personalizzazione. Hetzner offre potenti server dedicati e cloud che si adattano molto bene a molti scenari e ottengono un punteggio elevato. Strato copre i casi d'uso standard, mentre IONOS offre buone opzioni in alcuni casi, ma offre meno margine di manovra per le configurazioni speciali. Questa categorizzazione mi aiuta a scegliere la base giusta e a prendere decisioni successive. Colli di bottiglia da evitare.
| Luogo | Fornitore | Caratteristiche della rete | Prestazioni |
|---|---|---|---|
| 1 | webhoster.de | Reti dedicate, connessione veloce, alta personalizzazione | Eccezionale |
| 2 | Hetzner | Potenti server cloud e dedicati | Molto buono |
| 3 | Strato | Funzioni di rete standard | Buono |
| 4 | IONOS | Opzioni di alto livello, possibilità limitata di configurazioni personalizzate | Buono |
Kubernetes e le reti di container in pratica
Per l'orchestrazione dei container, pongo le basi nella rete. Ai lavoratori vengono assegnate interfacce nella rete privata, il piano di controllo è chiaramente segmentato e ai pod con un'elevata capacità di uscita viene assegnato un percorso NAT definito. Scelgo un CNI adatto alla configurazione: Le varianti basate sul routing mi facilitano la risoluzione dei problemi e risparmiano i costi di overlay, mentre gli overlay spesso offrono maggiore flessibilità in termini di isolamento. I bilanciatori di carico disaccoppiano Ingress dai backend; i controlli di salute sono identici a quelli dell'applicazione, non solo semplici controlli TCP. Eseguo anche un doppio stack nel cluster, in modo che i servizi possano essere raggiunti in modo pulito tramite i record AAAA. Per i servizi stateful, definisco politiche di rete chiare (est/ovest) in modo che siano aperte solo le porte necessarie tra i pod. Collaudo sempre gli aggiornamenti dei componenti CNI e Kube in un cluster di staging, compresi il throughput, la latenza e gli scenari di guasto.
Prestazioni sotto carico: ottimizzazione misurabile
Misuro regolarmente: la latenza di base all'interno delle zone, la latenza verso gli endpoint pubblici, il throughput da porta a porta e i requisiti RTO/RPO per i servizi critici. I colli di bottiglia si verificano spesso in alcuni punti: gateway NAT, firewall stateful sovraccarichi, tabelle di tracciamento delle connessioni troppo piccole o semplicemente CPU insufficiente sui router. Aumento sistematicamente la capacità, distribuisco i flussi, attivo il multi-queue sulle NIC e presto attenzione al bilanciamento di pinning/IRQ, se necessario. È fondamentale evitare ispezioni stateful non necessarie sulle dorsali est/ovest pure e impostare invece ACL chiare. Per l'offloading TLS, separo il traffico dati dal traffico di controllo in modo che i carichi di lavoro L7 non competano con le connessioni di gestione. Documento tutto questo con valori iniziali e target: le ottimizzazioni sono "finite" solo quando portano benefici misurabili.
Breve sintesi: come configurare efficacemente le reti Hetzner
Inizio con un piano chiaro, definisco gli spazi di indirizzamento, seleziono gli strumenti più appropriati. Modalità e documentare ogni passaggio. Configuro quindi le reti Linux in modo coerente, attivo il forwarding IP se necessario e collaudo accuratamente il routing e il DNS. Integro IP di failover e MAC virtuali in modo strutturato, in modo che le commutazioni funzionino senza problemi. La sicurezza rimane elevata grazie alla segmentazione, ai firewall forti e alle patch costanti, mentre il monitoraggio rivela tempestivamente le irregolarità. Ecco come ottengo hetzner La configurazione di rete offre prestazioni affidabili, mantenendo la piattaforma flessibile per la crescita.
