Dépannage de pare-feu IPv6 : tester ip6tables/nftables et effectuer un traçage du trafic

Un réseau IPv6 fonctionnel peut échouer à cause du pare-feu. Le dépannage du pare-feu IPv6 concerne l’analyse systématique expliquant pourquoi des paquets IPv6 n’arrivent pas ou ne sont pas traités correctement. Dans cet article, vous apprendrez comment vérifier les règles ip6tables et nftables, traquer le trafic de façon ciblée (trace) et identifier les causes typiques au moyen de captures de paquets (tcpdump/tshark). Le public visé comprend les administrateurs, ingénieurs systèmes et opérateurs qui, en exploitation, ont besoin de séquences de vérification claires, de tests sûrs et de stratégies de repli pragmatiques.

Pourquoi le dépannage du pare-feu IPv6 est différent

IPv6 diffère de IPv4 sur plusieurs points essentiels. ICMPv6 n’est pas un simple protocole de diagnostic, mais indispensable pour Neighbor Discovery (ND) et Path MTU Discovery (PMTUD). Si ICMPv6 est bloqué de manière trop RESTrictive, la résolution d’adresses et la gestion de la fragmentation sont affectées et les connexions se coupent apparemment sans raison. De plus, NAT n’existe quasiment pas comme solution standard en IPv6 ; le filtrage est donc davantage axé sur le routage, les politiques d’adressage et l’inspection d’état (stateful inspection).

Principaux termes, expliqués brièvement

• Neighbor Discovery (ND): mécanisme analogue à ARP pour IPv4, pour la résolution d’adresses de la couche liaison et les annonces de routeur.
• ICMPv6: famille de protocoles, nécessaire pour les messages d’erreur et de contrôle (par ex. « Packet Too Big » pour PMTUD).
• conntrack: composant du noyau pour le suivi des connexions (stateful firewalling). Une table conntrack pleine peut empêcher la création de nouveaux états ou provoquer le rejet de paquets.
• ip6tables / nftables: deux outils de gestion pour les règles Netfilter. nftables est plus moderne ; de nombreuses distributions fournissent des wrappers de compatibilité.

Préparations : contrôles de base avant de modifier les règles

Avant d’intervenir sur les règles du pare-feu, vérifiez l’adresse, le routage et le support du noyau. Ces contrôles de base aident à écarter de fausses pistes.

1. Vérifier l’adresse IPv6 et le routage

Contrôlez les adresses locales et les routes.

ip -6 addr show dev eth0

ip -6 route show

Si l’adresse est absente ou si la route n’est pas configurée, ce n’est pas un problème de pare-feu. Corrigez d’abord les erreurs d’adresse/routage, puis vérifiez les règles.

2. Sysctl et modules noyau importants

Vérifiez que le forwarding IPv6 et les modules noyau appropriés sont activés.

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'

Si nf_tables ou ip6_tables manque(nt), le pare-feu ne peut pas traiter les paquets. Sur de nombreuses distributions, le gestionnaire de paquets fournit les modules appropriés ; le cas échéant, chargez-les avec modprobe.

Inspection des règles : vérifier ip6tables et nftables de manière systématique

De nombreux problèmes proviennent d’une mauvaise priorité des tables/chains ou du mélange des deux outils. Il est essentiel de déterminer si une couche de compatibilité est active sur le système (p. ex. ip6tables-nft) ou si les deux outils gèrent en parallèle des jeux de règles distincts.

3. Afficher les règles ip6tables

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

L’option -v affiche les compteurs de paquets et d’octets ; si les valeurs RESTent à 0, aucun trafic ne traverse les règles. La table raw peut avoir des effets NOTRACK/NOTABLE, vérifiez donc également là.

4. Afficher les règles nftables

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

nftables nutzt eine einheitliche Regeln-Abstraktion. Achten Sie auf Counters, Log-Statements und auf die Familie (inet, ip, ip6). Ein häufiger Fehler: Regeln sind nur für ipv4 (ip) geschrieben, nicht für inet oder ip6.

5. Erkennen von Wrapper/Compatibility-Schichten

Distributionen bieten häufig Wrapper, die ip6tables-Kommandos auf nftables-Backends abbilden. Prüfen Sie das:

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

Wenn ip6tables auf ein nft-Backend zeigt, dann schreiben Änderungen mit ip6tables in die nft-Repräsentation — aber paralleles Editieren mit nft kann Inkonsistenzen erzeugen.

Messbare Tests: Counters, Logging und gezielte Paketerzeugung

Statt blind zu loggen, sollten Sie kontrollierte Tests ausführen. Sinnvoll sind Counters an kritischen Punkten, gezielte Paketgenerierung und anschließende Captures.

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

Fügen Sie temporär eine Counter-Regel hinzu, um zu sehen, ob Pakete eine Chain passieren. Counters sind robust und erzeugen keine Log-Flut.

# 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

Warum es funktioniert: Counters werden im Kernel aktualisiert, wenn ein Paket die Regel passiert. Wann es scheitert: Wenn Pakete vor der Chain verworfen werden (z. B. in raw oder mangle) oder der falsche Interface-/Family-Kontext genutzt wird.

7. Logging sinnvoll einsetzen

Log-Regeln sind nützlich, aber in Produktion riskant wegen Log-Flut. Stattdessen Log-Filter mit Rate-Limit verwenden oder per nflog an ulogd/tcpdump leiten.

# 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

Paketmitschnitt ist der Goldstandard, um zu sehen, ob Pakete das System erreichen, korrekt adressiert sind und ob Antworten gesendet werden.

8. Live-Mitschnitt mit tcpdump

Ein typisches Capture für IPv6-Fehler:

# 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"

Wichtig ist, speziell nach ICMPv6-Typen zu filtern — Packets Too Big (ICMPv6 Type 2) signalisieren PMTUD-Probleme.

Praktische Tests: Traffic erzeugen und Verhalten beobachten

Simulez les connexions problématiques depuis les deux extrémités. Utilisez ping6, curl -6, nping (Nmap) ou un simple socat/nc.

10. Tests d’exemple

# 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

Ces tests génèrent des signaux clairement identifiables que vous pouvez voir dans tcpdump ou dans les compteurs.

Vérifier Conntrack, les timeouts et les limites

Un déclencheur souvent négligé est la limite de Conntrack. Lorsque la table est pleine, le noyau rejette les nouvelles connexions ou se comporte de façon incohérente.

11. Vérification de 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

Si la table est proche de la limite, augmentez temporairement le paramètre ou analysez quels clients génèrent un nombre anormalement élevé de connexions.

Pièges typiques et causes

• ICMPv6 filtré de façon trop RESTrictive : ND ou PMTUD est bloqué.
• Coexistence ip6tables et nftables : les règles se remplacent ou sont mal interprétées.
• Interventions Raw/PREROUTING : les paquets sont abandonnés avant les vérifications de filtrage (p. ex. NOTRACK).
• Épuisement de Conntrack : de nouveaux états ne sont pas créés.
• Contexte d’interface ou de family incorrect (ip au lieu de ip6, table filter pour IPv4 uniquement).

Dépannage des pare-feux IPv6 : diagnostics approfondis et outils avancés

Une fois les contrôles de base, les compteurs et les captures effectués, des diagnostics avancés aident à comprendre des problèmes difficiles à reproduire. Cela inclut l’analyse ciblée des types ICMPv6, la gestion des fragments, le comportement des Router Advertisements (RA) et des techniques avancées de traçage noyau.

12. Types ICMPv6 et leur signification

ICMPv6 comprend plusieurs types ayant des rôles différents. Les types importants sont :

• Type 1, 2 (Destination Unreachable / Packet Too Big) : indique des problèmes d’atteignabilité ou de MTU.
• Type 133–135 (Router Solicitation/Advertisement) : éléments essentiels pour SLAAC et l’information de routage.
• Neighbor Solicitation/Advertisement : pour la résolution d’adresse au niveau lien et la détection d’adresses dupliquées.

Si les Router Advertisements sont absents ou filtrés, SLAAC (configuration d’adresse automatique) ne fonctionne pas correctement. Vérifiez spécifiquement les règles de filtrage ICMPv6 pour ces types.

13. Fragmentation et PMTUD

IPv6 interdit la fragmentation par les routeurs en forwarding ; seul l’extrémité peut fragmenter. Si un segment du chemin a une MTU trop petite et que ICMPv6 Type 2 est supprimé, les paquets sont silencieusement abandonnés. Surveillez les réglages MTU et les messages d’erreur PAMTUD dans les captures.

# 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

En contre-vérification, vous pouvez effectuer des tests MTU avec hping3 ou ping6 (avec des tailles de paquets appropriées) pour valider le comportement PMTUD.

14. Router Advertisements (RA) und SLAAC-Fallen

Les Router Advertisements (RA) fournissent les préfixes, les flags et la durée de vie du routeur. Les pare-feux qui bloquent les RA empêchent l’attribution dynamique d’adresses. Vérifiez le taux et la validité des RA avec 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

Si les informations RA sont manipulées ou supprimées, cela peut conduire à des informations de préfixe incohérentes et à un routage inattendu.

15. Erweiterte Kernel-Tracing-Ansätze

Für hartnäckige Fälle können Sie Kernel-Tracing verwenden (z. B. perf, ftrace, bpftrace), um zu sehen, welche Hooks Pakete durchlaufen. eBPF/bpftrace erlaubt, Pfade und Hook-Ausführungen effizient zu verfolgen — das ist jedoch fortgeschrittener Skill und benötigt Kernel-Unterstützung.

Beispielhaft, ein kurzer bpftrace-Check (nur in Testumgebungen, auf Produktionskernen mit Vorsicht):

# 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(); }'

Warum es hilft: Sie sehen, ob Pakete überhaupt Netfilter-Hooks erreichen. Wann es scheitert: fehlende Debug-Symbole, inkompatible Kernel-Versionen oder fehlende Berechtigungen.

Umsetzungsschritte für sicheres Troubleshooting in Produktion

1. Arbeiten Sie mit zeitlich begrenzten Counters statt sofort umfassendem Logging.
2. Führen Sie Tests von beiden Seiten (Client und Server) durch und erfassen Sie Pakete beidseitig, falls möglich.
3. Dokumentieren Sie ursprüngliche Regeln vor Änderungen: exportieren Sie ip6tables- und nftables-Outputs.
4. Planen Sie ein Backout: Konfigurationsdateien sichern und Notfall-Skript bereithalten, das innerhalb von Minuten den Vorzustand wiederherstellt.

16. Beispiel: Verbesserte Konfigurationssicherung und Rollback-Skript

# 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

Testen Sie das Rollback in einer isolierten Umgebung, bevor Sie es produktiv nutzen.

Monitoring, Reporting und Prävention

Nachdem ein Problem behoben ist, sollten Sie präventive Maßnahmen einführen: regelmäßige Counters, Alerts für ICMPv6-Anomalien, Conntrack-Auslastung und rule-hit-Metriken. Exportieren Sie Counters periodisch (z. B. mit einem kleinen Skript und Prometheus Textfile Collector) und alarmieren Sie frühzeitig.

17. Beispiel: Zähler-Export (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

Das Beispiel ist konzeptionell und muss für Ihre Regelstruktur angepasst werden.

Checkliste für die Nachbearbeitung

Nach erfolgreicher Diagnose sollten Sie

• Gefundene Regelprobleme in die zentrale Konfigurationsverwaltung übernehmen (z. B. Ansible, Salt).
• Sorgfältig dokumentieren, warum eine Regel angepasst wurde (Ticket-Referenz, Datum, Test-Log).
• Compléter la surveillance : surveiller régulièrement les compteurs et configurer des alertes pour l’utilisation de conntrack et les taux d’erreurs ICMPv6.

Conclusion

Le dépannage du pare-feu IPv6 est une combinaison de contrôles de base (adresses, routage, sysctls), d’une inspection basée sur des règles (ip6tables / nftables), de tests ciblés (compteurs, nping, curl) et de captures de paquets (tcpdump/tshark). Une attention particulière doit être portée à ICMPv6 et à la disponibilité de conntrack. Planifiez les modifications avec des sauvegardes et une stratégie de repli claire. Dans les environnements de production, des compteurs temporaires et des règles de journalisation limitées sont souvent la solution la plus efficace sans mettre en péril l’exploitation. Mettez en place à long terme une surveillance et des tests automatisés pour détecter tôt les régressions.

Recommandations complémentaires

Pour les environnements plus vastes, une migration propre vers nftables (si ce n’est pas déjà fait), des règles cohérentes dans la famille inet pour l’unification et des tests automatisés dans un environnement de staging sont recommandés. Complétez la surveillance par des métriques telles que les erreurs ICMP IPv6 par seconde, le taux de conntrack et les compteurs de hits de règles, afin de travailler en sécurité vis-à-vis des régressions.

Pour ce sujet, tcpdump pour IPv6 est également important. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.