Checklist di preparazione IPv6 per un server domestico self-hosted

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

IPv6 Readiness Checklist for a Self-Hosted Home Server - Zima Store Online

L’approccio sicuro consiste nel trattare una verifica di preparazione al dual stack, che controlli separatamente indirizzamento, filtraggio, DNS, identità dell’applicazione e raggiungibilità esterna, come una sequenza di controlli osservabili, non come un singolo comando.

Su un home server self-hosted e un router dual stack, il rischio concreto è che l’abilitazione di IPv6 crei un percorso in uscita funzionante mentre DNS, filtraggio in ingresso e comportamento dell’applicazione da remoto restano non verificati. Registra l’identità attuale e il punto di ripristino, inizia con il discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo storage diventa instabile o l’unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale funziona oppure le evidenze raggiungono un limite che richiede escalation.

Inventaria indirizzi, prefissi e associazioni dei servizi

Registra il prefisso delegato dall’ISP, i prefissi LAN del router, gli indirizzi globali e link-local del server, la durata degli indirizzi, la route predefinita, i resolver DNS e l’eventuale uso di indirizzamento privato o stabile. Identifica quale indirizzo resterà adatto a un server dopo i rinnovi, invece di pubblicare l’indirizzo temporaneo di un client.

Controlla separatamente i socket in ascolto per IPv4 e IPv6. Un servizio associato a :: può accettare connessioni IPv6 su interfacce che non erano mai raggiungibili tramite port forwarding IPv4, mentre un’associazione limitata a IPv4 può far sembrare un percorso IPv6 funzionante un problema dell’applicazione.

Usa il flusso di esposizione ZimaSpace nel controllo dell’esposizione dell’home server come controllo di sicurezza complementare. Non pubblicare record AAAA né aprire regole in ingresso finché ogni processo in ascolto, route del proxy, nome del certificato e confine di autenticazione non abbia un responsabile.

Verifica la coerenza dei firewall del router e dell’host

Esamina la policy stateful in ingresso sul router, sull’host, sull’hypervisor e sul livello di pubblicazione dei container. Inizia negando il traffico in ingresso non sollecitato, quindi crea eccezioni ristrette per origine, destinazione, protocollo e porta solo per i servizi che devono essere pubblici o raggiungibili da un prefisso VPN attendibile.

L’indirizzamento globale non implica la raggiungibilità globale. La separazione garantita dal firewall stateful IPv6 descritta dall’Internet Society osserva che un firewall IPv6 può consentire le comunicazioni in uscita filtrando al contempo il traffico in ingresso non sollecitato: è un confine che molti utenti attribuiscono erroneamente al NAT stesso.

Esegui i test da una rete IPv6 esterna, non dalla stessa LAN. Conferma che l’HTTPS previsto funzioni e che le porte amministrative, dei database, SMB e quelle inutilizzate restino chiuse o filtrate; ripeti il test sia sull’indirizzo del server sia su eventuali indirizzi pubblici del proxy.

Convalida DNS, TLS, routing e dimensione dei pacchetti

Interroga i record A e AAAA da client interni, esterni e VPN, quindi registra quale indirizzo utilizza effettivamente l’applicazione. Assicurati che la destinazione AAAA presenti il certificato corretto e indirizzi il nome host verso la stessa identità applicativa usata da IPv4.

Verifica le richieste ordinarie e un trasferimento di dimensioni maggiori su IPv6. I messaggi ICMPv6 Packet Too Big fanno parte del funzionamento del percorso, quindi un blocco generalizzato di ICMPv6 può creare un black hole di MTU del percorso anche quando le pagine piccole vengono caricate; consenti il traffico di controllo necessario invece di considerare facoltativo tutto ICMP.

Confronta log e comportamento in base alla famiglia di indirizzi. Se IPv6 non funziona mentre IPv4 sì, mantieni non pubblicato il record AAAA o riducine l’ambito finché le evidenze relative a routing, firewall, DNS e proxy non mostrano la differenza.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Esegui test di errore e persistenza prima del rilascio

Riavvia la connessione del router o rinnova il prefisso durante una finestra di manutenzione, quindi conferma che l’indirizzamento del server, il DNS dinamico se utilizzato, gli oggetti del firewall e le associazioni del proxy si aggiornino come previsto. Riavvia il server e verifica che le regole vengano caricate prima dell’avvio dei servizi pubblici.

Verifica la perdita di IPv6 mentre IPv4 resta disponibile e la perdita di IPv4 mentre IPv6 resta disponibile. I client dovrebbero eseguire il failover in modo prevedibile oppure mostrare chiaramente una dipendenza; un’etichetta dual stack non è utile se una famiglia raggiunge silenziosamente un servizio diverso o un indirizzo obsoleto.

Dichiara la preparazione raggiunta solo quando i servizi previsti funzionano esternamente su IPv6, le porte non previste restano bloccate, DNS e TLS sono coerenti e un cambio di prefisso non aggira la policy. Quando i risultati divergono, ritira per prima la pubblicazione AAAA, quindi conserva le evidenze relative ai pacchetti e al firewall per correggere il problema.