Risoluzione dei problemi della firewall IPv6: testare ip6tables/nftables ed eseguire il tracciamento del traffico

Una rete IPv6 funzionante può fallire a causa del firewall. La diagnosi dei firewall IPv6 riguarda l’analisi sistematica del motivo per cui i pacchetti IPv6 non arrivano o non vengono elaborati correttamente. In questo articolo imparerete come verificare le regole ip6tables e nftables, tracciare il traffico in modo mirato (trace) e identificare cause tipiche mediante cattura dei pacchetti (tcpdump/tshark). Destinatari sono amministratori, System Engineers e operatori che in esercizio necessitano di sequenze di controllo chiare, test sicuri e strategie di fallback pragmatiche.

Perché la diagnosi dei firewall IPv6 è diversa

IPv6 si differenzia in diversi punti fondamentali da IPv4. ICMPv6 non è un protocollo di sola diagnostica, ma è imprescindibile per Neighbor Discovery (ND) e Path MTU Discovery (PMTUD). Se ICMPv6 viene bloccato in modo troppo RESTrittivo, la risoluzione degli indirizzi e la frammentazione confluiscono e le connessioni possono interrompersi apparentemente senza motivo. Inoltre, in IPv6 il NAT come soluzione standard è quasi assente; il firewalling è quindi più incentrato su routing, policy di indirizzo e stateful inspection.

Termini essenziali, brevemente spiegati

• Neighbor Discovery (ND): meccanismo analogo ad ARP in IPv4, per la risoluzione degli indirizzi a livello link-layer e per i router-advertisements.
• ICMPv6: famiglia di protocolli necessaria per messaggi di errore e controllo (p.es. „Packet Too Big“ per PMTUD).
• conntrack: componente del kernel per il tracciamento delle connessioni (stateful firewalling). Una tabella conntrack piena può impedire nuovi stati o causare lo scarto di pacchetti.
• ip6tables / nftables: due strumenti di gestione delle regole di Netfilter. nftables è il più moderno; molte distribuzioni offrono wrapper di compatibilità.

Preparazioni: controlli di base prima di modificare le regole

Prima di intervenire sulle regole del firewall, verificate indirizzo, routing e supporto del kernel. Questi controlli di base aiutano a escludere cause errate.

1. Verificare indirizzo IPv6 e routing

Controllate indirizzi locali e rotte.

ip -6 addr show dev eth0

ip -6 route show

Se manca l’indirizzo o la rotta non è impostata, il problema non è il firewall. Correggete prima errori di indirizzo/routing, poi verificate le regole.

2. Sysctl e moduli kernel importanti

Verificate se l’IPv6 forwarding e i moduli kernel appropriati sono attivi.

sysctl net.ipv6.conf.all.forwarding
# oder prüfen und temporär setzen
sysctl -w net.ipv6.conf.all.forwarding=1

# Kernel-Module
lsmod | egrep 'nf_tables|ip6_tables|nf_conntrack'

Se mancano nf_tables o ip6_tables, il firewall non può processare i pacchetti. In molte distribuzioni il package manager fornisce i moduli appropriati; in caso contrario caricateli con modprobe.

Ispezione delle regole: verificare sistematicamente ip6tables e nftables

Molti problemi nascono da ordine di priorità sbagliato tra tabelle/chain o dal mescolare entrambi gli strumenti. È fondamentale capire se sul sistema gira uno strato di compatibilità (p.es. ip6tables-nft) o se i due tool gestiscono parallelamente set di regole diversi.

3. Visualizzare le regole ip6tables

ip6tables -t raw -L -v -n
ip6tables -t filter -L -v -n
ip6tables -S

L’opzione -v mostra i contatori di pacchetti e byte; se i valori RESTano 0 non passa traffico attraverso le regole. La tabella raw può introdurre effetti NOTRACK/NOTABLE, quindi verificate anche lì.

4. nftables-Regeln anzeigen

nft --version
nft list ruleset
# oder gezielt
nft list table inet filter

nftables utilizza un’astrazione unificata per le regole. Prestate attenzione a Counters, Log-Statements e alla family (inet, ip, ip6). Un errore comune: le regole sono scritte solo per ipv4 (ip), non per inet o ip6.

5. Erkennen von Wrapper/Compatibility-Schichten

Le distribuzioni forniscono spesso wrapper che mappano i comandi ip6tables su backend nftables. Verificatelo:

update-alternatives --display ip6tables  # Debian/Ubuntu-Varianten
# oder prüfen, wohin das Binary linkt
readlink -f $(which ip6tables)

Se ip6tables punta a un backend nft, le modifiche effettuate con ip6tables vengono scritte nella rappresentazione nft — ma modifiche parallele con nft possono generare incoerenze.

Messbare Tests: Counters, Logging und gezielte Paketerzeugung

Invece di loggare in modo indiscriminato, eseguite test controllati. Sono utili Counters in punti critici, generazione mirata di pacchetti e successiva cattura.

6. Counters in nftables setzen (schnell prüfen, ob Rule matched)

Aggiungete temporaneamente una regola Counter per verificare se i pacchetti attraversano una Chain. I Counters sono robusti e non generano un flusso eccessivo di log.

# Beispiel: Zähle eingehende TCP-Pakete auf Port 80 (IPv6)
nft add rule inet filter INPUT tcp dport 80 counter comment "temp-count-http6"

# Zähler ansehen
nft list ruleset | sed -n '/temp-count-http6/,$p'

# Zurücksetzen / entfernen nach Test
# Handle-ID aus nft list ruleset verwenden
nft delete rule inet filter INPUT handle 42

Perché funziona: i Counters vengono aggiornati nel kernel quando un pacchetto attraversa la regola. Quando fallisce: se i pacchetti vengono scartati prima della Chain (es. in raw o mangle) o se si utilizza il contesto di interfaccia/family sbagliato.

7. Logging sinnvoll einsetzen

Le regole di log sono utili, ma in produzione rischiose a causa del flusso di log. Usate invece filtri di log con rate-limit o instradate tramite nflog a ulogd/tcpdump.

# nftables: rate-limitiertes Loggen
nft add rule inet filter INPUT tcp dport 22 limit rate 5/second counter log prefix "FW-SSH6: "

# ip6tables Beispiel
ip6tables -A INPUT -p tcp --dport 22 -m limit --limit 5/sec -j LOG --log-prefix "FW-SSH6: "

Log-Prefix hilft beim Filtern in syslog/journal. Achten Sie auf Rate-Limits, sonst wird das System belastet.

Traffic captures: tcpdump, tshark und file-basierte Aufnahme

La cattura dei pacchetti è lo standard per verificare se i pacchetti raggiungono il sistema, sono indirizzati correttamente e se vengono inviate risposte.

8. Live-Mitschnitt mit tcpdump

Una cattura tipica per errori IPv6:

# Capture nur IPv6-ICMP und TCP/UDP für ein bestimmtes Host-Paar
tcpdump -n -i eth0 ip6 and host 2001:db8::10 and '(icmp6 or tcp or udp)'

# Schreiben in eine Datei zur Analyse mit tshark
tcpdump -n -i eth0 ip6 and host 2001:db8::10 -w /tmp/trace-ipv6.pcap

Hinweis: Verwenden Sie -n, um Namensauflösung zu vermeiden; das verlangsamt Captures.

9. Analyse mit tshark oder Wireshark

# Schnelle Statistik per tshark
tshark -r /tmp/trace-ipv6.pcap -q -z conv,ip

# Filter in tshark (nur ICMPv6 "Packet Too Big" analysieren)
tshark -r /tmp/trace-ipv6.pcap -Y "icmpv6.type == 2"

È importante filtrare specificamente per i tipi ICMPv6 — Packet Too Big (ICMPv6 Type 2) indicano problemi di PMTUD.

Praktische Tests: Traffic erzeugen und Verhalten beobachten

Simulate le connessioni problematiche da entrambe le estremità. Usate ping6, curl -6, nping (Nmap) o un semplice socat/nc.

10. Test di esempio

# Echo testen: ICMPv6
ping6 -c 4 2001:db8::10

# TCP-Connect Test mit curl (IPv6)
curl -6 -v http://[2001:db8::10]:80/

# Nping für gezielte Paketerzeugung (Teil von nmap)
nping --tcp -p 80 -c 3 -S 2001:db8::1 2001:db8::10

Questi test generano segnali chiaramente riconoscibili che è possibile osservare con tcpdump o nei contatori.

Verificare Conntrack, timeout e limiti

Una causa spesso trascurata sono i limiti di Conntrack. Se la tabella è piena, il kernel scarta nuove connessioni o si comporta in modo incoerente.

11. Verifica di Conntrack

# Conntrack-Tools (conntrack-utils) anzeigen
conntrack -L -f ipv6 | head

# Aktuelle Limits
sysctl net.netfilter.nf_conntrack_max

# Anzahl der Einträge
cat /proc/net/nf_conntrack | wc -l

Se la tabella è vicina al limite, aumentate temporaneamente il parametro o analizzate quali client generano un numero insolitamente elevato di connessioni.

Problemi tipici e cause

• ICMPv6 filtrato in modo troppo RESTrittivo: ND o PMTUD vengono bloccati.
• Esercizio misto ip6tables vs nftables: le regole si sovrascrivono o vengono interpretate in modo errato.
• Interventi Raw-/PREROUTING: i pacchetti vengono droppati prima dei controlli del filtro (z. B. NOTRACK).
• Esaurimento di Conntrack: non vengono creati nuovi stati.
• Contesto di interfaccia o di family errato (ip invece di ip6, filter per IPv4-only).

Risoluzione dei problemi del firewall IPv6: diagnosi approfondite e strumenti avanzati

Dopo aver eseguito i controlli di base, i contatori e le acquisizioni, le diagnosi avanzate aiutano a capire problemi difficili da riprodurre. Tra queste: analisi mirata dei tipi ICMPv6, gestione dei frammenti, comportamento dei Router Advertisement (RA) e tecniche avanzate di kernel tracing.

12. Tipi ICMPv6 e il loro significato

ICMPv6 comprende diversi tipi con ruoli differenti. I tipi importanti sono:

• Tipo 1, 2 (Destination Unreachable / Packet Too Big): indicano problemi di raggiungibilità o MTU.
• Tipo 133–135 (Router Solicitation/Advertisement): componenti essenziali per SLAAC e informazioni di routing.
• Neighbor Solicitation/Advertisement: per la risoluzione degli indirizzi Link-Layer e per la Duplicate Address Detection.

Se i Router Advertisement mancano o vengono filtrati, SLAAC (autoconfigurazione degli indirizzi) non funziona correttamente. Verificate le regole di filtro ICMPv6 per questi tipi.

13. Frammentazione e PMTUD

IPv6 vieta la frammentazione nel forwarding dei router; solo l’endpoint può frammentare. Se nel percorso c’è un segmento con MTU troppo piccolo e il Type 2 ICMPv6 viene soppressa, i pacchetti vengono scartati silenziosamente. PRESTate attenzione alle impostazioni MTU e ai messaggi di errore PAMTUD nelle acquisizioni.

# Nach ICMPv6 Packet Too Big filtern
tshark -r /tmp/trace-ipv6.pcap -Y "icmpv6.type == 2" -T fields -e frame.time -e ip.src -e ip.dst -e icmpv6.code -e icmpv6.mtu

Per verificare potete eseguire test MTU con hping3 o ping6 (con dimensioni pacchetto adeguate) per convalidare il comportamento PMTUD.

14. Router Advertisement (RA) e insidie SLAAC

I Router Advertisement (RA) forniscono prefissi, flag e Router-Lifetime. I firewall che bloccano gli RA impediscono l’assegnazione dinamica degli indirizzi. Verificate la frequenza e la validità degli RA con tcpdump:

tcpdump -n -i eth0 'icmp6 and ip6[40] == 134'  # ICMPv6 type 134 = Router Advertisement
tcpdump -n -i eth0 'icmp6 and ip6[40] == 135'  # Neighbor Solicitation

Se le informazioni RA vengono manipolate o rimosse, ciò può portare a informazioni di prefisso incoerenti e a instradamento inatteso.

15. Approcci avanzati di tracciamento del kernel

Per casi ostinati potete usare il kernel tracing (ad es. perf, ftrace, bpftrace) per vedere quali hook attraversano i pacchetti. eBPF/bpftrace permette di seguire in modo efficiente i percorsi e le esecuzioni degli hook — tuttavia si tratta di una competenza avanzata e richiede il supporto del kernel.

Esempio: un breve controllo con bpftrace (solo in ambienti di test, sui kernel di produzione con cautela):

# Einfaches Beispiel: Zähle Aufrufe bestimmter Netfilter-Hooks
# Benötigt bpftrace und entsprechende Kernel-Funktion-Symbole
sudo bpftrace -e 'kprobe:netfilter_hook_entry { @[comm] = count(); }'

Perché aiuta: si vede se i pacchetti raggiungono i Netfilter-Hook. Quando fallisce: simboli di debug mancanti, versioni del kernel incompatibili o permessi insufficienti.

Passaggi per un troubleshooting sicuro in produzione

1. Utilizzare contatori a tempo limitato anziché logging estensivo immediato.
2. Eseguire test da entrambe le parti (client e server) e acquisire i pacchetti da entrambi i lati, se possibile.
3. Documentare le regole originali prima delle modifiche: esportare gli output di ip6tables e nftables.
4. Pianificare un backout: eseguire il backup dei file di configurazione e predisporre uno script di emergenza che ripristini lo stato precedente entro pochi minuti.

16. Esempio: backup migliorato della configurazione e script di rollback

# Sichern
ip6tables-save > /root/ip6tables-before-$(date +%F).save
nft list ruleset > /root/nftables-before-$(date +%F).rules

# Einfaches Rollback-Skript (prüft Vorhandensein)
#!/bin/bash
BACKUP_DIR=/root
IP6BK=$(ls -1 $BACKUP_DIR/ip6tables-before-*.save | tail -n1)
NFTBK=$(ls -1 $BACKUP_DIR/nftables-before-*.rules | tail -n1)
if [ -f "$IP6BK" ]; then ip6tables-RESTore < "$IP6BK"; fi
if [ -f "$NFTBK" ]; then nft -f "$NFTBK"; fi

Testare il rollback in un ambiente isolato prima di utilizzarlo in produzione.

Monitoring, Reporting und Prävention

Una volta risolto un problema, è necessario introdurre misure preventive: contatori regolari, alert per anomalie ICMPv6, utilizzo di conntrack e metriche di rule-hit. Esportare periodicamente i contatori (es. con un piccolo script e il Prometheus textfile collector) e allertare precocemente.

17. Esempio: esportazione dei contatori (Prometheus textfile)

#!/bin/bash
# Simple scraper, in crontab alle 30s/1m ausführen
OUT=/var/lib/node_exporter/textfile_collector/nft_counters.prom
echo "# HELP nft_rule_hits rule hit counters" > $OUT
nft list ruleset | grep counter -A1 | awk '/counter/ {print $0} /handle/ {print $0}' | sed 's/.*counter //g' | nl -v0 | while read i line; do
  echo "nft_rule_hits{rule="$i"} $(echo $line | awk '{print $1}')" >> $OUT
done

L’esempio è concettuale e deve essere adattato alla struttura delle vostre regole.

Checklist per il follow-up

Dopo una diagnosi riuscita, è opportuno:

• Integrare i problemi di regole rilevati nella gestione centralizzata delle configurazioni (es. Ansible, Salt).
• Documentare con cura il motivo per cui una regola è stata modificata (riferimento al ticket, data, log dei test).
• Completare il monitoring: monitorare regolarmente i contatori e impostare alert per l’utilizzo di conntrack e i tassi di errore ICMPv6.

Fazit

Il troubleshooting della firewall IPv6 è una combinazione di verifiche di base (indirizzi, routing, sysctls), ispezione basata su regole (ip6tables / nftables), test mirati (contatori, nping, curl) e cattura pacchetti (tcpdump/tshark). Richiedono particolare attenzione ICMPv6 e la disponibilità di conntrack. Pianificate le modifiche con backup e una chiara strategia di rollback. In ambienti produttivi, contatori temporanei e regole di logging limitate sono spesso la via più efficace per non compromettere il funzionamento. Integrare a lungo termine monitoraggio e test automatizzati per rilevare precocemente regressioni.

Weiterführende Empfehlungen

Per ambienti più estesi è consigliabile una migrazione ordinata a nftables (se non ancora presente), regole coerenti nella famiglia inet per uniformare e test automatizzati in un ambiente di staging. Arricchite il monitoraggio con metriche come errori ICMPv6 al secondo, tasso di conntrack e rule-hit-Counters, per gestire le regressioni in modo sicuro.

Per questo tema sono inoltre importanti anche Tcpdump Ip6. L’articolo inquadra questi aspetti in modo comprensibile e mostra a cosa prestare attenzione nella pratica quotidiana.